Dealing with the lack of regex engine^ is such a tiny part of the monumental task of implementing C++ compiler from scratch - it's like quitting Mt. Everest summit expedition because a three-story hotel on the way there doesn't have elevator.
That's where he lost me as well, I've written a few parsers and seen a lot of compiler implementations, and almost never is a regex library a part of the equation.
Regexes aren't powerful enough for a full language, so you'll have to write your own lexer/parser anyway (or use a parser generator). And once you're going down that road, it's pretty awkward and unnecessary to try to jam in a regex library to only parse subsections.
In my admittedly limited experience, I've never seen anyone parse languages with regex for compilers. It doesn't take long to figure out that it'd be unwieldy and hard to be thorough.
LL / recursive descent seems to be the most common.
But anyway, yeah, how the heck do you sign up for such an absurdly huge task and worry that a lack of regexes is the main problem you'll be encountering?
Flex [1], too, uses regular expressions. However, the generated source that performs the actual tokenizing/lexing, does not need any library support for them as it is all implemented in the code. So even there lack of regex support in standard library would not be an issue.
I know someone who is doing this course. I can understand both the desire to do this course (get a deeper understanding of the C++11 spec) and why this is the course matter (building a compiler will give you a deeper understanding of the spec).
Still, as others have noted, C++ is a daunting spec, probably the most complicated of any language. Perhaps they resolved this with C++11 but previous versions of C++ were also ambiguous in certain corner cases [1].
What I don't really understand is why you can't publish your code before or after. I guess I understand why: they want to offer this in later years without prepackaged solutions being on github but is that really avoidable?
So you have to invest a massive amount of effort into building this. Sure you get some technical knowledge but you don't get any code you can really use at the end.
All of this makes me appreciate the relative simplicity of the grammars of, say, Go or Lisp. I see the need for C++ but I can't help but view is as a hideous Frankenstein of a language nonetheless.
It is just education. It is hard to argue that going through the course is not making you a better programmer or that knowing someone did is not a strong signal they can implement complex requirements.
What code does one have to show for college. That is not the point. I think the author just realized he either doesnt need to send that strong a signal thtough pure education (maybe his work allows him todo it cheaper) or the course is too hard for him(again not an insult I think I would feel the same)
I'm not sure that programming is so linear that being a 'better programmer' translates to universal programmatic utility. It's entirely possible that things learnt about low-level compiler writing has little application to higher-level stuff.
There's no shame in admitting that the course is too hard or demanding for you current skill level--I ended up dropping out because I didn't have the time to do the work justice.
However, the somewhat whiny tone of the article seems like the author is trying to justify their own shortcomings by complaining about the code sourcing terms and the lack of regex. It seems kind of childish.
Here, maybe this will help in the future--a simple regex parser in like 30 lines of vanilla C:
I think this touches on something important - rather than writing from scratch some asinine limited use case software, make useful software. You can prove your worth in the useful products you produce, not in the bravado you accrue saying you wrote a compiler from scratch - it is the difference between using a dozen programs a day that I know I've commited patches to and seeing the fruits of your labor or having your standards compliant C++11 compiler rot in some directory on your PC while you still use clang/gcc because the program said you can't even put it in a public git repo and instead of spending 10k lines improving the current best of the crop you reinvented the wheel as a stone brick while major players are comparing rubber treads.
The regex engine is small potatoes in the larger scheme of things, but the reason it's so problematic is the two bigger problems in the CPPGM: the questionable architecture and absolutely insane project plan, which both appear to be "convert the spec directly into code, in printed order".
This is no way to approach a complex project with serious technical risk, and willingly signing up for the death-march enterprise project from hell is the kind of thing that disqualifies you from being qualified to take on a project of this scope, let alone a grandmaster, whatever that means.
You can see the outcome coming a mile away: "We cut some corners, but it's 80% done. Now all that's left is the impossible part."
I wish I weren't so gullible! When this thread came around the first time, it seemed quite interesting, but the comments totally convinced me it was supposed to be a joke. Now I'll have to wait until 2014!
To me the "jump right in to a huge project" approach seems like a great way to learn a language, even if it doesn't necessarily produce high quality results (or even functioning results). Nevertheless OP is entitled to their opinion.
It's a great approach to learn a language, but you have to be careful what kind of "huge" you're dealing with. There's "huge" in the sense of technical ambition, and there's "huge" in the sense of "large number of implicated functional areas" and there's "huge" in the sense of "sprawling requirements that capture many different people's needs".
A C++ compiler is all three; it's challenging, like any compiler for a real language is; it's functionally dense (preprocessing, parsing, evaluating, code generation), and it's one of the most sprawling language specifications there is.
Building a native-code-generating Lisp would not be an unreasonable learn- a- new- language project.
"Building a native-code-generating Lisp would not be an unreasonable learn- a- new- language project."
Eh, I do not think it is terribly hard if optimizations are not a concern. Yeah, CLtL2 is rather lengthy, but the bulk of it can be implemented with macros and functions if you just want something that will work. I suppose implementing those macros/functions might teach you the language, but I think you would learn a whole lot more implementing something else (say, an email client).
The biggest flaw in all of this is ... Who says you need a course or a certification in order to write a compiler? Go, write a compiler. Use a well-recommended textbook or web-based resources if you need to. But there's nothing to stop you from going out on your own and doing it.
The other is... Not going to write a compiler because you don't have regexes? That sounds like major whining. You might as well say you won't write a compiler because you already have a compiler. If learning by re-implementing low-level details is what you're after (in my experience a very helpful exercise), don't complain because you have to do low-level details. OTOH, if you take my first suggestion and not bother with a course or certification, you can define your own rules and you don't have to feel bad about using an external regex library.
Really? Why don't you write your own regex? Regular languages are definitely relevant. It's not that hard to write a basic regex engine (make NFA and convert to DFA). This is a compilers course after all.
Agreed. Having done a lot of language work, I don’t find regexes suitable at all. State machines are generally simple both to write and to understand, can be made more efficient when you don’t need the full generality or dynamism of a regex, and force you to be explicit about things like which Unicode code points you actually meant.
For learning the best principles about actually driving (aka coding) in C++, what are the best resources these days? I learned from Stroustrup, Accelerated C++, and on the job programming. However, every company seems to have an idea of what "good C++" looks like and they all disable/enable a varying subset of C++ features to support their individual standards.
What's the closest guide out there that's representative of "ideal" C++ code and style?
Stop and consider if you really need to be programming in C++; if not, don't do it. If you do, then focus on problem domain (embedded, gaming, OS, low-level stuff, ...) you need C++ for rather than C++ coding in isolation.
I think this is wise. On a one man team, assigned a task of 'just get it done', I can think of better languages than C++ for most tasks. I think a general awareness of C++ is good, so that when joining a team you can learn their corner of C++. Whereas spending your own time learning all corners of it is bad, because a lot of that time could be wasted, unless it's an enjoyable way to spend time for that given person.
In the games world, C++ is still ubiquitous as it is one of the few places where bleeding edge performance is a competitive advantage. In my case, I want to write my own game engine :). I've been using other engines for years and have plenty of experience in other languages (Haskell, Ruby, Python, Lisp, Erlang, etc). Although I have a lot of C++ experience, I feel like the idioms sometimes allude me.
Even between Sutter, Stroustrop, and Alexandrescu you will find completely different approaches and styles.
Use what makes sense to you, and by makes sense to you, I mean you know exactly what you are doing, if you are starting or managing a project.
If you aren't the lead, follow the leader, unless they have some glaring issues in their style and technique. This happens most of the time, though, because C++ is a huge beast.
I could see a C++ project with many people being difficult without some basic guidelines. Sometimes style guidelines are less about the "best" way and more about consistency for people to be able to work with code they didn't write.
The author brings up a great point in that C++ really does have a massive lack of modern development tools. I can envision a lot of the language being fixed up from the tooling angle, eliminating a large part of the repetitive and boilerplate work that bogs the language down the most.
Could anyone point me in the direction of modern C++ development tools or would be interested in beginning a project to create them, possibly through Sublime plugins and a preprocessor? (email in profile) I'm familiar with CDT & Visual Studio, both of which are hardly satisfactory (not to say they don't do some things well.) I've also written some tools to close some gaps that I see in C++, but nothing too intrusive or ambitious yet. These are here: https://github.com/personalcomputer/supermake & https://github.com/personalcomputer/cppinterp
There are also clang-based auto-complete and syntax-checking plugins for sublime, emacs, and presumably others.
Another emacs package I've been meaning to try is "disaster", which shows you the assembly that the code under your cursor compiles to: https://github.com/jart/disaster
What c++ is sorely lacking, in my opinion, is a (library) package management system.
I think clang/LLVM is where the active point of development for a lot of that kind of stuff is. There's been a lot of code-checking/sanitization features that have been added in the last few releases.
The most recent release of clang can even track undefined integer behavior (as recently posted to HN).
I wrote a C++ compiler back in 2000. It took me couple of years to polish that. And it was not even the full compiler: parser and semantic analysis, but no code generation in the usual sense. It did, however, support several idiosyncratic compiler dialects.
C++ is an ugly, ugly, _ugly_ language. Even C language, the base of C++, is context-dependent, which in practice means that you need to intermix parsing and semantic analysis. Consider for example this code 'T*t'. If 'T' is a type, then this is declaration of variable 't' that is pointer to 'T'. If it is identifier, then it is non-assigned multiplication of 'T' and 't'.
C++ added its own quirks on top of that. You have, for example, parse class definitions two times. First, just the declarations and only then inline method bodies. There is no other way to do it correctly.
While I'm no fan of C++, I find it odd that people criticize languages as "ugly" because they are difficult to build correct parsers, compilers, etc. for. While obviously this is annoyance to the tool writer, I would think it is more important how useful (and clarity and expressiveness are important here) the language is to people who have to read and write code in the language, rather than how easy it is to write tooling that parses or compiles the language.
Seems to me that calling a language ugly on the basis of how it is to build a compiler is like calling a dish ugly because it takes skill to prepare it properly.
(That said, I think C++ is an ugly language, but not for the reasons stated in your post.)
There is something missing from this post. It seems from the previous thread that people knew what the course involved - so why did he sign up for it in the first place if he philosophically disagrees with it? What changed/what new information came up?
Well, he seems to not have done any actual exercises. So now that they are actually releasing exercises (have been for some time now), he took a second look and realised he doesn't want to do it.. because the environment does not have library support for regexes?
It's such a bizarre reason, because a mini-version of regex in the form of automata is the basis of any compiler. It's about the first exercise in the course, and very simple and fun training for any programmer, really.
You seem to be saying that he saw through the BS that many technical certifications are, and I agree that some (or even many, or most) technical certifications are BS, but that's really not what happened here at all. That was not the reason he bailed on this one. He didn't call anybody's bluff. This is not representative of technical certifications on any level.
I'm wondering why I should care. Is completion of this course considered de rigeur in C++ programming circles or is this just a case of someone changing their mind and writing off some course fees?
When I first heard about it, I thought the same, but there's a number of people who are taking it seriously now - the course has structured assignments with deadlines and a user forum ... check it out: http://www.cppgm.org/index.html
I will now use this example going forward when someone asks me to explain what I mean by "a team of one is the most efficient possible team, just not the most effective."
What a pussy! I've been working on my c++ compiler compiler for 6 years now and will complete the 1981 c++ specification any day now. I think can get up to 1995 around 2015 now that I've defeated regex. I'll have my certification within the next 5 years! And you'll have what? A regular paying job? Ha! Pussy!
But you didn't defeat regex, they didn't add it to the std until C++11. Don't look forward to that mastery until around 2084. And like the author says, you aren't a true C++ master until you write your own regex parser in order to write your own compiler. Or the other way around. It gets messy.
Also, I don't think you ever master regexes. When you think you know what you are doing you see a 5k character text parser in one giant regex and want to slam your head on a desk.
^ - which he probably didn't need to begin with