This seems like an insane undertaking for one person. I could understand it with C - that would be difficult enough. But a compliant C++11 compiler? It has taken MSVC, GCC, and clang years to get just partial C++11 compliance! None of them are fully compliant in their current state. How is this course supposed to be tractable!?

"More significantly, we are not doing an optimization pass."

Most of the legwork in compilers like gcc involves optimizing the output code and targeting multiple architectures -- writing a dumb translator for a single architecture is a far more tractable problem.

It doesn't matter, optimized or not, the amount of work this entails is ridiculous. Writing a C++11 compiler requires intimate knowledge of the standard (which is a massive, hard to read tome), implementing pretty much all of the standard library from the ground up, and honestly, good luck writing all of that - that's all the containers (set, vector, list, map, unordered_map, multimap, unordered_multimap, forward_list, stack, deque, tuple), algorithms, time and regex libraries (chrono and regex), threading and thread models, type_traits and so on (actually, I just realized, they have it listed on the right hand side).

Honestly, it's worded very poorly. "Compliant with the latest 2011 standard (C++11)" suggests all of this. I have a hard time believing this isn't some kind of joke - there's literally no-one alive that could write all of this in the timeframe of a course.

Not only that, but the dragon book is terrible.

To quote my adviser, "writing a parser from scratch has no value except as a character building exercise."

Anyone who wanted to write their own parser should probably just use a packrat parser (I find it much simpler).

Whoever is organizing this course, frankly, is either way out of their depth or holds their 1985 compilers course in far too high esteem.

I disagree that there's something wrong with writing your own parser. A simple recursive descent parser is very easy to write, and more importantly is very easy for someone else to understand. It does not require any esoteric knowledge of lookup tables and "advanced" parsing algorithms. I far prefer a stack trace from inside someone's hand-written recursive descent parser to the cryptic mess you get from Yacc or Antlr generated code. I also prefer not having to have a whole code generation stage in my build process just to support some small DSL I have embedded.

This whole "you should never write your own parser" thing is so often parroted out as "wisdom"... But I honestly believe that most of the people that say this don't realise how easy it is to "roll your own".

The pedagogical value of writing a parser for your compiler for any language more complex than, say, Scheme, is basically zero.

Skip the parser, learn the useful stuff.

Oh, writing parsers is useful outside of writing compilers. But yes, you shouldn't be writing parsers in low level languages like C++. Write them in OCaml or Haskell. It's a joy there.

This is my cue to mention Spirit http://boost-spirit.com/home/

unless you ever need to process data in a format for which a decent library doesn't already exist

Still no pedagogical value. Any smart undergrad can pick up how to write a parser with a little background reading and a couple hours. The trick is that you spend the rest of your life fixing maddening corner-case bugs in the thing.

Parsers, from a practical perspective, are child's play for people who seek to eventually master a compiler.

Do you have an example in mind of such data?

New file formats of all kinds are invented every day, often with some proprietary tool attached. Writing your own parser allows you to add value and/or interoperate with the proprietary system. Even in the cases where an open source parser already exists it may have performance issues, or not support the latest version of the format. Being able to roll your own in those cases is empowering.

Of course you asked for examples... let me give that a try:

1) data from your favorite application that's been end-of-lifed and you're thinking of replacing with a competitor's tool 2) data from a later version of your favorite application that you want to use with an earlier version, because you don't want to upgrade 3) configuration information from some part of your IT infrastructure that you need to refer to as you restructure and upgrade 4) a big config file for some software, that contains an error somewhere and "grep" won't find it. Maybe it's a semantic error, for example. 5) a config file for some ancient crufty software you're replacing, but the config file is huge and contains a lot of institutional knowledge, so you want to automatically translate it to the new system's setup.

Being able to generate even simple parsers gives you a lot of power. It's not as uncommon as you might imagine.

Having been in the business of reversing data formats in two different real-world contexts, I feel comfortable in saying that just about the last thing I would do is write a parser. One context was building a system to pull live financial data feeds. The other is in the software security business. In the former, often CSVs were what you would get, or fielded data. We built an engine that could easily inhale these. Including the bloomberg feed which was unusually complex.

In the security business, one is often asked to assess some not-very-well specified protocol, or some protocol for which there is no documentation. So to deal with it you 1) fuzz the hell out of it to make the end point fall over or 2) hexdump the protocol and write pieces of it in ruby or python to get messages through so that you can fuzz the hell out of it in a structured way.

And if there was some need to write a parser, you can bet it ain't gonna be LALR, it will be hand-crafted, likely recursive descent.

To reply to each of your points:

1) If you are lucky, this XML. I don't need to know how to write a parser if the data is XML. If it is some sort of Java serialization, dejad is your friend--no parser required. If it is binary, you are going to use the protocol reversing route mentioned above.

2) See #1

3) Maybe just insert parentheses around the whole bit of data, and insert more strategically, and you are all but done.

4) See #3 or #1.

5) See #4.

If I was working on a team, and I saw someone writing a parser for a data-related problem, I would seriously question what they are doing.

It's nice that things have gone in the direction of XML and JSON lately, and many people devise formats that build upon those. I was thinking more of arbitrary text formats. Even if it's XML or JSON though, the existing parsers only handle comprehending the structure of the data itself. You have to write some semantic analysis on top of those, because the standard "parser" will just give you the input data as a tree - but the semi-standard format certainly helps a lot.

I do think you overestimate the work required to write a parser for simpler formats - for someone familiar with one of the popular parser generators this can be a handful of hours, and the quality of results should be much higher than an ad hoc method. This can be a good design decision.

No, I don't underestimate it, because I have done it, i know how long it takes, and what one gets from it.

There are simpler ways, as I point out above.

> To quote my adviser, "writing a parser from scratch has no value except as a character building exercise."

I think I just read the best potentially unintentional compiler pun I have ever seen.

I disagree about the Dragon book. In particular, the code generation part was very valuable to me in the code generator.

But I think I see where you are going with this. Using a parser generator for compiling, in the words of Dave Conroy (author of MicroEmacs and many other things), "A Parser Generator makes the hard part harder and the easy part easier."

Edit: Wait--1985? Ah, that is the problem. I used the First dragon book, not the second. I only got the second after I did the compiler work. Was it much worse than the first?

No, even the second edition is hugely out of date.

First, note that basically the first half of the book is about parser implementation. Then, it basically just teaches you that there's only one parser and it's called LALR. Of course, they didn't include anything like packrat, but even worse, they pretend like a LALR generator is still better than LR, even though LR was extended to be tractable for large grammars years ago.

And even with all that, it's far too high level to be of use in actually engineering a compiler (which, by the way, is a good intro book).

packrat is not a panacea: once you try to add left-recursion into the mix, it becomes much slower than LALR parsers.

LALR represents a nice tradeoff: both LR and packrat involve much much larger state tables than LALR parsers.

That's not the point. The point is to impart information and let the compiler designer choose which is appropriate.

The ordering is also confusing because the grammar parsers go from less powerful to more powerful. However, LALR is after LR.

Edit: Oh, and for C++ you need a GLR, which isn't even covered in dragon.

I can't argue with your "hugely out of date" note. It is likely that I am also out of date, not having written compilers since the mid-80s.

Do you have an opinion about the Holub book? Also I have a collection of Davidson papers about code generation that I haven't looked at since back then.

Unless you need to for speed or compat reasons, I don't like writing parsers in C.

Remember, a compiler is a translator from text to (often)text. You're going to be dealing with a lot of strings and probably allocations for your AST. You should think about using a language which doesn't make string manipulation and memory management like pulling teeth.

In general, I'd say the ML family is best for writing a general-purpose compiler. SML even gives your compiler a formal semantics for free.

> And even with all that, it's far too high level to be of use in actually engineering a compiler (which, by the way, is a good intro book).

I actually found it way too low level. And not meaty enough.

as @wglb said below I can't disagree with you more on the Dragon book. Yes, there are probably better resources out there for lexing and parsing but have your looked at the rest of the book? It actually covers most of the important static analysis techniques in sufficient detail to implement many of the important optimizations. In short: there is a reason people keep recommending it: it is a really great resource.

Also, if you do want to implement a traditional Yacc like parser generator then it is a pretty good resource for that as well (having done it). Finally, while writing a parser might be a "character building exercise" sometimes there is also no getting around it.

Have you looked at it?

How can you say there are better references for lexing and parsing and leave out that the entire first half of the book is lexing and parsing?

There are a ton of books that are better at every single thing you would want. Engineering a Compiler. Modern Compiler Implementation in ML. The compiler Handbook.

I usually reference a combination of: Dragon Book, Muchnicks: Advanced Compiler Design, and Semantics with Applications. I have been meaning to pick up a copy of Engineering a Compiler. (I should also note I am currently reading: Principles of Program Analysis, it is a good book focusing on just theory. Read Semantics with Applications first it is basically the follow up)

A guess my point is this: I have learned a great deal from the Dragon book. I think it is a solid book that has taught me a lot. There may be better books out there but I haven't read one yet (Advanced Compiler Design is great but it really is only about optimization and analysis you need an undergrad book to supplement it).

Finally, I have encountered worse books on the subject of compilers. So yes, this is a book that I would recommend and continue to recommend.

ps. You mis-characterize the length of the lexing and parsing coverage. It starts on page 109 and ends on page 302, the content goes to 964. Chapter wise: 3-4 lexing->parsing, (chapter 1-2 are really an introduction and illustrative example so they don't count). Chapters 5-8 cover the rest of what you need to get a working compiler + some other stuff. Chapters 9-12 (page wise 583-964) cover optimization and analysis in depth. So really, nearly 40% is optimization while about 20% is syntax analysis. This book has a lot of good material most of it isn't to do with syntax analysis and the syntax analysis is for the most part high quality.

And if I were to start writing a compiler today, I would certainly start with Holub's book Compiler Design in C.

Except when you work on embedded systems (I'm talking about the type where you have a few hundred kilobytes of ram and flash, no OS under your ass and crap libraries). I've used a recursive descent parsing technique that's described in a paper of about 5 pages by David Hanson to great effect [1]. Depends on the situation you find yourself in, sometimes it's unavoidable to re-invent the wheel.

[1] http://drhanson.s3.amazonaws.com/storage/documents/compact.p...

Pretty much all the good compilers (gcc,clang,...) have a hand-written parser. An exception is javac, but that one is a minimalistic parser.

Handwritten parsers have better error reporting and might even be faster.

Yes, that's called a production compiler.

If you glance in my profile you will see I'm well aware of the practices of production compilers and also how few people ever even look inside one.

> Not only that, but the dragon book is terrible.

Agreed. I can never believe the people who still praise it.

Which is the best book for compiler design then?

I haven't read all of them. But I liked "Modern Compiler Design" (http://www.amazon.com/Modern-Compiler-Design-D-Grune/dp/0471...).

If you have a functional bend, Simon Peyton Jones' book (https://research.microsoft.com/en-us/um/people/simonpj/Paper...) is worth reading, too. His book, however, is not a complete treatment. It assumes you know e.g. how to write a parser, and concentrates on the challenges unique to lazy functional languages.

Is there any parser autogeneration tool that can cope with c++11's grammer? Including weird edge cases like template vs. comparison depending on previously declared types?

C++ is messed up that you're gonna need to do some weird stuff. First, the grammar is ambiguous. Second, the template language is undecidable. Nothing you can do about the second.

The first, you'll at least need something capable of parsing context-free languages. My recommendation is to start here[1].

[1] http://arxiv.org/abs/1010.5023

I was just replying to the comment regarding GCC and MSVC -- the argument seemed to be that most of the development manhours were devoted to C++11 when in fact most of it was devoted to optimization strategies and cross-architectural compatibility.

Look at clang. In this case they already had, and continue to use, LLVM, so their only job is to turn C++11 into a bytecode, in any way possible.

It has still taken a number of the best C++ programmers and compiler designers years to accomplish, and they haven't finished yet.

I beg to disagree. For something as complex as C++, writing the preprocessor, the parser, and the code generator is very much beyond a man year.

I wasn't saying that it would take a year or even a few years. I was merely saying that most of the effort in gcc/msvc was related to things like optimizing and maintaining multiple architectures. A simple compliant C compiler that only targets x86_64 and performs no optimization, for example, would be much smaller than GCC.

Unclear to me if that is really the case.

Consider tcc, which is indeed much simpler than gcc.

Ah, yes. I was still thinking C++ as the discussion seemed to slip over to simple C.

there are parser generators .. you dont have to build one from scratch

As noted elsewhere, these usually make the hard part harder.

The other part of the issue is building the internal representation so that halfway decent code can be generated, not even thinking about optimization.

And, like the syntax and grammar of the language, the semantics of C++ are quite complex.

It's kinda like saying that most of the legwork in space exploration goes into space ships and mission logistics so just building a dumb launcher rocket is far more tractable problem.

Indeed, building Saturn V is nothing compared to flying men to the Moon and back. Does not mean you can build a Saturn V from scratch. And people who are promising to teach you how either are geniuses or just in denial.

Point remains that gcc already has an optimizer and working backend and it's still hard to implement just the necessary changes.

adding C++11 features to GCC is a far more difficult undertaking than it should be because of RMS and his fear of proprietary frontends to GCC (so the plugin system, which is relatively easy to work with in LLVM, is a nightmare in GCC). That was a design decision

Quote:

"The concern that has long been expressed by the FSF (which owns the copyrights on GCC) is that a general plugin mechanism would make it possible for companies to traffic in binary-only GCC modules. Rather than contribute a new analysis or optimization tool - or a new language - to the community, companies might have an incentive to distribute their work separately under a restrictive license. That runs very much counter to what the FSF is trying to accomplish, so opposition from that direction is not particularly surprising."

https://lwn.net/Articles/301135/

> adding C++11 features to GCC is a far more difficult undertaking than it should be because of RMS and his fear of proprietary frontends to GCC

Whatever you think of RMS's stance on plugins, or gcc's plugin system, they have little relationship with the ease or otherwise of adding C++11 features to gcc.

The latter has much more to do with the difficulty of understanding the gcc C++11 front end, the difficulty of understanding the fine details of the C++11 standard sufficiently to implement it, and the amount of manpower available from people who can do both those things (or who have the time to learn).

gcc certainly does have a lot of historical baggage in its code base (though this is slowly improving with time), but given its rather complete support for C++11 (on par with clang certainly, and far ahead of MS's compiler and most other proprietary C++ compilers), they're not doing so bad...

No, RMS's stance of plugins does make adding C++11 features to gcc much harder.

I have a (basic) understand of clang, which is helped by the fact that there is a very clear, simple and DOCUMENTED boundary into LLVM, which I can ignore the other side of. The interface between gcc front ends and backends is none of clear, simple or documented.

> No, RMS's stance of plugins does make adding C++11 features to gcc much harder

> clang, which is helped by the fact that there is a very clear, simple and DOCUMENTED boundary into LLVM

(1) People adding C++11 features to clang are not going to be dealing with LLVM, they're going to be modifying and extending clang's existing C++ parser. So however nice the clang-LLVM front-end-middle-end interface is, that's not going to have much impact on this job. Rather, what's important is the quality of clang's internal algorithms and data-structures (and those in gcc's c++ front-end). If clang does better there (dunno), that's great for them, but it has nothing to do with RMS's plugin position.

(2) RMS is not against clean code, nice interfaces, good data structures, and good documentation. His concerns (whether you agree with them or not) are the degree to which interfaces are expressed in a way that circumvents the GPL. Good interfaces don't circumvent the GPL;

So it's perfectly fine to clean up and document gcc's data structures and interfaces (and indeed, this is already happening, and has been for a long time). RMS isn't going to stop you.

"GCC suffers from layering problems and leaky abstractions: the back end walks front-end ASTs to generate debug info, the front ends generate back-end data structures, and the entire compiler depends on global data structures set up by the command line interface."

Chris Lattner, "The Design of LLVM" http://www.drdobbs.com/architecture-and-design/the-design-of...

(Seems possibly relevant to the boundary issue.)

Are you suggesting that C++11 support would be implemented as a plugin, rather than by modifying the existing C++ front end?

I'm not sure how seriously to take that.

No, I'm suggesting that understanding and modifying the C++ front end is much easier when the output the front-end produces is in well defined and documented output, rather than the ad-hoc and undocumented results of a gcc front-end.

Hmm? Front ends emit GENERIC, which is detailed at http://gcc.gnu.org/wiki/GenericAPI.

I don't see what this has to do with RMS or plugins.

Have you scrolled down that page? It is an extremely brief introduction. The 'types' and 'functions' sections are completely empty, and the whole page amounts to 2 examples!

There's more at http://gcc.gnu.org/wiki/GENERIC: my purpose was more to point out that an interface exists than to pinpoint the exact documents for you.

As far as I know, Walter Bright is the only person on this planet who could maybe claim to have written a C++ compiler all by himself [0], though I cannot find an original quote from him.

[0] http://www8.cs.umu.se/~isak/snippets/mem.txt

I agree with this. In fact, it isn't really productive even trying to implement a language as complex as C++ (many might say overly complex).

This is a massive undertaking, but the fact you are starting with no baggage from existing systems and don't need to optimise might be some consolation. Assume you're also free to study other compiler designs prior to the course.

It's a joke. It's hardly doable by a single person. For the record there is currently no fully C++11 compliant compiler.

Oh, and I'd like to say that knowing everything about C++11 makes you a language lawyer, not a Grandmaster. Grandmaster is more than knowing the language. It's about using it right.

WHOIS records are of DomainsByProxy. I use a similar service for my private (not work) domains, but take what you will from it.

I think something like this might be a very cool project for those of us who have the time. You get intimate knowledge of C++, compilers, assembly and other close-to-the-metal aspects of programming. I wonder how much time it is going to take; the very simple compiler I had to write in college using yacc/Bison, supplied boilerplating and a trivial output format already took several days of full-time work. Full C++-compliance seems like a _huge_ project.

The website is missing some information however: who's behind it? It says:

  The CPPGM Foundation was formed by a software company that
  recognized the value to programmer productivity that a good
  knowledge of language mechanics had to new developers to
  their team.  The C++ Grandmaster Certification began
  development as an internal training program, and the
  foundation was founded to offer it publicly.

but fails to mention what that company is. Additionally, the domain is registered anonymously...

Edit: After some digging, it seems that the only information available on the people behind this is the fact that they emailed the press release to the comp.lang.c++ newsgroup from a residential IP-address in Switzerland. (NNTP-Posting-Host header)

Google? Facebook?

Why would either do it without putting their name on it.

This also might be a top talent filtering system. If someone is able to complete the absolutely massive amount of work - in their spare time for fun, no less - they are quite likely to be of interest to some of the top companies.

In this case, putting a flashy name will lessen the scheme, as it will attract people that will do it with purely career-oriented motives. Or, as another post noted, it might just be a scam.

Or maybe for black listing? i.e. filter out those persons who are extremely naive and/or who overestimate their abilities.

Then they came after the C++ hackers, and I did not speak up because I didn't know C++...

:)

Okay I signed up to see what it's all about. But I can't get rid of the feeling that this is a joke of some sort.

1.) There is not a single name of anyone involved in this endeavor.

2.) The sing-up confirmation is a simple alert box? It seems like an XHR request does go out but no email is sent to the email address provided. Also they don't even check for email uniqueness. That seems somewhat...strange.

If it is a joke, I will be pretty sad :-(.

Also there is this announcement message https://groups.google.com/forum/?fromgroups=#!topic/comp.lan... where they say "For press information contact support@cppgm.org". Nevertheless, the domain has no associated MX record. I'm calling it, this is almost definitely not real. And the class has a start date but no end date?

If a domain doesn't have a MX record, it fallsback to the A record.

The IP pointed to by the A record does have a service running on the SMTP port.

Well, the lack of an end date could be a recognition of how seriously big this effort is expected to be.

It's probably a recruiter phishing scheme.

For what kind of job would you recruit people who think single handedly implementing a fully compliant C++ compiler is suitable coursework?

Hopefully nothing involving project planning.

Or someone wants a fully C++-11 complaint compiler for free. ;)

Maybe, but why not just start with Clang?

Anyway, I signed up, too.

(If it's a joke we might organize a study group ourselves^^)

So this seems like a pretty enormous task. Having written a couple of compiler code generation phases, I must admit that this challenge is very attractive.

However, there is something a little off about this proposal. First, the size of this effort is really quite substantial, even neglecting optimization. Secondly, the phrase The C++ Grandmaster Certification began development as an internal training program, and the foundation was founded to offer it publicly suggests some compiler-writing company heavily involved in the C++ space. How many of those are there really? I mean, it has been 20 years since anyone made any money producing C++ compilers. All for-profit companies do it as a side effect. VC++, for example, in the 90s had 50 people working on just the compiler itself, not counting the Visual part.

So it presents a secondary challenge, which is 1) is this a real company 2) what really is the end goal?

Edit: Also, the bootstrapping question is not well addressed. What do we have to start with? Regular C? can I do the first phase in Lisp or Arc or Factor?

Am I allowed to look at other source, like that of g++ or clang or llvm or objective C?

Finally, the apparent copyright terms seem at least unacceptable, if not downright goofy.

Regarding the company in question -- my own best guess would be one that does static code analysis -- Coverity [0] comes to mind, for example. I can't really think of any other companies that would benefit greatly from having a large stock of employees that all know the C++ standard intimately. Except of course for those that write compilers, but as you say, there aren't many of those around.

[0] http://www.coverity.com/

Ah, a good possibility.

I can't find it now, but they published a paper that said "There is no such thing as C" in which they discuss the widely varying implementations and expectations of C, different enough that special flags had to be invented on their tool to get weird programs to pass.

The "meat" of the joke imho: ...there is a start date but not an end date for the class :)

...with an end date somewhere in 2023, it might be feasible.

Considering it normally takes 10 years to develop a reasonable standard library alone -- and that's about 10% of what's being asked here -- this is clearly a joke. But it's a humbling and enjoyable trolling for sure. It would be interesting to develop a very limited amount of material for each layer of the stack being addressed here though, that would give some valuable experience.

Who in their right mind would write a C++ compiler without getting paid a lot of money to do it? It's an incredibly hairy spec: full of corner cases and ambiguities and nearly impossible to parse.

As part of my GSOC project (auto-generating Common Lisp bindings for C++ libraries), I tried to implement parts of the Itanium C++ ABI (http://refspecs.linux-foundation.org/cxxabi-1.83.html#vtable). Like the language itself, the spec heaps complexity onto the compiler in a pointless effort to save the occasional load or arithmetic operation here and there. Yet ironically, it's faster and simpler to just have a simpler v-table layout and put a PIC in front of it: http://www.jot.fm/issues/issue_2009_01/article4.pdf (see page 233).

shivers

Well, when I first dove into compilers, i may have not been in my right mind. Three of us were too inexperienced to know that we couldn't produce a production compiler in a year, so we did. And I pretty much went through a wall to get into the compiler field.

I don't disagree with anything you said here, but I admit I am feeling a pull.

Don't get me wrong: I love hacking on compilers and I do it for fun. And you can ship a production compiler in a year. But for C++ 11? That's a different beast. That's a language that's neither fun to write a compiler for nor do I think it's tractable to write one in a year (but who knows?)

Out of curiosity, what was the compiler for?

The company was Sycor--unlikely anyone has heard of it. They invented the Intelligent Terminal--a data entry device replacing keypunches that could do validation checks on entered data.

They were building an 8085 powered computer with their own OS. They hacked the PL/M compiler--actually rewrote it in Fortran to emit the appropriate object code and the rest of their tool chain. They started an effort to rewrite the compiler, but it failed. I came in, and being familiar with XPL (From the book "A Complier Generator"), having finished a port of it for the Xerox Sigma 5 at a previous gig. One other person on the team had finished a PhD in computational complexity and the other had project experience writing COBOL compilers.

The project stared with a desire to change the language a bit, so we designed a new language. It wasn't too different from PL/M as it had to be mechanically translatable. The language was named, embarrassingly, Syclops. We started out with batch jobs on a 360/35, writing it in PL/1. They shortly got a PDP-10, which I miss, and we commenced to rewrite the compiler in Bliss-36. So it was essentially a cross-compiler, spitting out 8085 machine code with a very fancy assembler listing, including timings for each basic block.

The project was wildly successful, and opened the door to switching processers. For a while, they considered the 6809, but ultimately stuck with the 8085. The CEO was very pleased, at least, to have the opportunity to consider the switch.

My favorite activity was taking bug reports from the programmers who always looked at the generated code. The would come in with the listing, saying that the code was wrong. I would go over the code, and the reaction from them always was "wait--that is odd, the code is right. Weird."

My boss at the time like to say "A compiler should produce code that an assembly-language programmer would be fired for writing."

I signed up and am excited. It is definitely something that will be challenging, but the fact that it is free means that I have nothing to lose and everything to gain. (One would say that time is something I can lose, but this is a better use of my time than Diablo 3). The only hesitation I have is that this is just yet another joke that I'm too naive to recognize. We shall see!

Good point. I hope it is not some joke or some way of getting email addresses of programmers.

EDIT - Looking a little more, I can't tell exactly but I feel like the people that put this site up should put some more explanation up about who is doing it and ensure it is on the up and up. Surely, they are aware of this HN post so I'm waiting. :)

I was tempted until "We ask you to agree, when you start the course, to not release your toolchains source code anywhere but the cppgm site.". Interesting work I do not-for-pay I release as FOSS on github. They're worried about plagiarism (which is fair); they should use anti-plagiarism tools to check whether submitted code matches previous submissions or any known C++ library and compiler code in the wild.

You could write your own C++ compiler from scratch outside the scopes of the course, and open source your work on github.

That will show them!

I don't think that is that crazy. I'm not saying you are this exactly but I'm saying this position, to me, is one of an ideologue. I feel that I am an intellectual "friend" of FOSS, to be sure, but I just can't bring myself to take the ideology to that serious of an extent. Also, anti-plagiarism tools aren't very good, like Berkeley MOSS. I mean they are great and everything but easily bypassed.

Given the amount of work this project is, I would presume that very few people will get anywhere near completing the course. So it doesn't seem impossible for the people running it to study the submitted solution in some depth and compare it to earlier submissions by hand.

It's largely practical; I like being able to discuss what I've done with people, including specifics. I make exceptions, but the amount of work that goes into writing a compiler is probably worth more than a certificate is to me. A compiler project would definitely produce things I'd want to discuss with folks and code I'd want to reuse in later projects. One benefit I find of releasing something as FOSS (when permitted to do so) is that I know I'll be able to reuse it later[].

[] (this bit of reasoning deserves more explanation than I've given...)

They do not want student to copy on each others before deadlines. Even latter, if they want to give the same course a second time, they need students of first session to never publish their homework.

Subtle. A lot of effort just to prove that there will never be a "C++ Grandmaster".

"You will also earn the title Certified C++ Grandmaster [CPPGM]."

A certificate or title isn't worth anything unless the organization who emits it has the authority to emit them. And if you can truthfully claim to have written a fully-compliant C++11 compiler all by yourself... you're already so badass that throwing in an extra title or certificate won't make a difference.

I signed up, but I share the feeling here that this has to be a joke or email harvester or something else... Still, it'll be neat if there's at least an attempt. If it's real, I doubt I'd make it to the end. One aspect of this that is pretty doable and far more important than being a C++ Grandmaster is knowing how to implement the pieces that get basic code (in any language) from text file to the registers on your x86-64 CPU with a Linux kernel managing your program and others.

I had a real-time operating systems course a few years ago in which we developed a simple real-time kernel running directly on an arm9 microcontroller board. The toolchain of cross-compiling with gcc and programming the device (and creating the required linker file for the architecture and bootup assembly) was fortunately done for us with source available, and we did a high-level overview of how openOCD works and a whirlwind tour near the end of the course of how we might compile a program independent of our RTOS kernel's program and load the separate program from SD card with the RTOS and run it. We talked about elf files and related topics but didn't go too deep--it'd be nice to revisit some of the topics and especially in the context of Linux. (I would prefer an arm device over x86 though.)

I borrowed a copy of the Dragon Book from a friend and I'm starting to go through some of the parsing exercises as a refresher. I think the undergraduate compiler course I took used MIPS, so this might be a little different, but I always did like AMD. C++ is a big language, but as the FAQ says, we won't be writing an optimizer, and hey, we're not even writing an OS or designing a CPU, so we're only doing a tiny fraction of a complete implementation.

I went to a C++ standards committee meeting once. They were having this fascinatingly complex discussion about temporary object lifetimes; it was so amazing how everyone there understood C++ so thoroughly. I'm hoping that taking this course will give me a better appreciation for their art.

Neat but I will say this, I think the course is mis-named. This seems to be less of a C++ master class and a course on compilers. I would expect such a course as a C++ master class would be more on using the language rather than compiling it. But that doesn't mean the course isn't good, I haven't seen the content. :)

- For those criticizing the amount of work ... I tend to agree with you all. However, in the faq this is addressed, take that for what it's worth. However, it's free so it seems like, even if you fail at building a fully working compiler, you could learn a lot, so I say good for them!

"Written entirely in C++ with no third-party dependencies" -- so your work is writing a C++ compiler, in C++.

To truly understand a language, one must write a compiler for it - An old sage.

I don't believe this is a joke, but I do think the organizers need to be much more forthcoming. The crucial unanswered question is what timeline they expect to follow.

I believe it would be possible for an expert C++ programmer (and this is clearly who they're targeting) to write an essentially compliant ("fully" sounds difficult, and I expect some fudge there) compiler in a year; two, perhaps, if it's a nights and weekends effort. This estimate comes straight out of my bum. It's an intuition. I'm not including the standard library: that would be a multi-year job even for a small team of truly excellent C++ programmers. But if we focus on the compiler, and allow a little fudge in compliancy, I think there are some individuals who could do it in a year. So I don't believe the scope of the task implies a joke.

The lack of information on the site raises worries. Do the organizers lack the confidence to reveal themselves? Or are they scamming? They shouldn't leave this a question.

I've got to agree with some of the comments here that this is insane. Sounds fun, but insane. There are probably 3 or 4 programming-intensive undergrad courses wound together here, with a more difficult substrate than your average compilers course.

Then I remember that this is the Internet, and if it's 'free' you're usually not looking at the product; but you can see it in the mirror.

off on a tangent: does anyone know a good resource/book for learning C++ from a C background? I've loathed C++ every time I've gone to use it, I'm sure there's something good in there....

i.e. is there a good book "C++ for C programmers who hate the thought of it"

Accelerated C++ (http://www.amazon.com/dp/020170353X) is perfect. I learned C++ from a C background and this book is written exactly for people like us.

I'd recommend "C++ Primer". It's been updated for C++11, and is written in precise and clear language. As a C programmer, I find understanding details are important; Accelerated C++ was just too chatty, casual, and vague for my tastes.

thanks. added to amazon wishlist

There is nothing good in there! Run away! :P There are reasons companies like Google et al. strictly enforce their developers to use only a subset of C++, or to use it as an "augmented C". There's also this fun problem as you learn and use it: http://lbrandy.com/blog/wp-content/uploads/2010/03/c++.png

http://yosefk.com/c++fqa/index.html isn't a book, but the author shares your disgust for C++ and it's fairly detailed. As he says somewhere, he knows C++ better than it deserves to be known. I also don't like C++ as much as C (and I'd like to replace ever having to use either of them with Rust, hence Rust is my language-of-the-year to learn for 2013), and I found the FQA immensely useful for understanding the craziness and defectiveness of C++.

I'd also recommend http://www.amazon.com/The-Standard-Library-Tutorial-Referenc... I own the first edition and found it useful.

There is a thread on Stack Overflow that has a pretty good list http://stackoverflow.com/questions/388242/the-definitive-c-b... I'm currently working my way through Accelerated C++ and I'm finding it to be an excellent resource

I found the scott meyers books to be good (effective C++ and effective STL)

I particularly like the -Weffc++ ;)

These require some background in C++ before you pick them up, however.

That is true. Those books take "C programmers with a very basic understanding of some C++ fundamentals" to "C++ programmers"

They are very good, particularly for the intermediate C++ programmer.

I'd suggest the course reader from Stanford's CS 106L, authored by Keith Schwarz. It brought me upto speed on major parts of STL, the C++ object model, operator overloading, functors, etc. within a week. (Of course that's assuming you have a prior programming background).

Since this is probably a joke, is there a comparable class for a simpler language available online? Anyone have any resources for people wanting to self-teach themselves compilers?

There's a Stanford compilers class on Coursera. You can supplement it with the dragon book. Another book goes well with it, one of my favorites: Programming Language Pragmatics 3rd ed.

Gonna go with "recruiter phishing schemes" for $1000, Alex

Grammar reference: http://www.externsoft.ch/media/swf/cpp11-iso.html

World class senior engineers and having spare time for such an undertaking generally don't go together.

The fact it took me some time to realize this might be a joke, shows how far from being a Grandmaster I am :(

I'm so not a candidate for a class like this, but damn I wish I could take it.

Side note, I forgot that CPTTv2 was $101 (for the Kindle version no less).

No one calls it CPTTv2. Aho and Ullman both refer to it as the dragon book, and even wikipedia recognizes it: https://en.wikipedia.org/wiki/Dragon_Book_(computer_science)

lol wow when I first read the parent I wondered what book it was! You're right, I've only ever referred to it as the Dragon book.

Pfft, I got my copy of the second run first edition for about 4 cents (not including shipping) off Amazon. If you want second edition: http://www.abebooks.com/servlet/BookDetailsPL?bi=9476545617&... it is there for $18.

Anyone gotten an acknowledgement of having signed up?

This looks awesome! Now to read about compilers....

I signed up, but it doesn't feel real.

OK, I forked LLVM and libstdc++ on github, and compiled them.

In the process I learned about the joys of code reuse, surely what a true grandmaster would use.

When can I expect my certificate in the mail?

That's either a troll or will take decades for each person.