No, cfront was true compiler that emitted C as the object code. Ex-cfront user speaking. For details of the real history of C++, as opposed to something you heard down the pub, take a look at Stroustrup's The Design and Evolution of C++.

I highly recommend The Design and Evolution of C++ if you want to learn about the original design decisions behind C++ that the current ISO committee seems to not care about in the slightest.

It's a bit dated but offers a tremendous amount of insight into why the language was made as it is.

The correct answer to:

Q. Should I learn C or C++ first?

Is:

A. Yes.

WARNING: Highly Opinionated Analysis of C vs C++

I see a lot of people recommending one way but no one offering an analysis of BOTH the Pro's & Con's.

I've been using C++ since ~1990. I've briefly worked on a PS3 C++ compiler when I worked for Sony. I've seen 2 major problems over the years with C++ programmers:

1. People don't exercise discipline and restraint in K.I.S.S.

They use (and abuse) every language feature because they can. There is this tendency to over-engineer even the simplest things. Take a look at this complete clusterfuck of CRC in the Boost library.

1109 lines of over-engineered C++ crap for a simple CRC32 function instead of a mere 25 lines of code!?!?! The C version would:

• do the same thing,
  
• be simpler to write, and
  
• be simpler to debug, and
  
• more importantly solve the problem at hand, not abstracted to the point of being over-engineered.
  
  The trade-off would be is that it is less flexible, but WHEN was the last time you needed to use a custom CRC polynomial!?!? One would instead use a different algorithm such as MD5, SHA, etc. that:
  
  
• has better better error-rate detection,
  
• less collisions,
  
• is multi-core.
  
  This excellent SO on hashing is but one example of focusing on the big picture.
  
  2. People lack a basic understanding of the cost let alone the implementation of C++ expressions.
  
  I've seen people stick a virtual function inside an inner loop and wonder why their performance is crap. I've seen people fail to grasp a basic understanding of pointers. I've seen people not understand memory management and how to guarantee zero memory leaks. I've seen people spend more time on writing an "über" template and waste hours debugging that instead of just writing something in 1/10 of the time and move on.
  
  IMO, due to the bloated, over-excessive verbose nature of C++ it is for these reason that I strongly recommend a beginner learn C first and then learn C++. You'll have a better understanding of why C++ is designed the way it is, what the design trade-offs are/were, what C++ hacks are, and how to best use the languages to their potential.
  
  However, this is ignoring the benefits and disadvantages of the Pro's/Con's of why one would learn C++ or C first.
  
  

  Learn C++ first
  

  
  

• C++ Pro
  
• C++ really is a better C then C in so many ways, too numerous to enumerate
  
• In the ways it is worse the smart people / companies use a sub-set of the language: Ubisoft avoid Templates, Exception Handling, and Run-Time Type Identification. When even a C++ committee member admits he writes in a sub-set of C++ himself you know the language is b-l-o-a-t-e-d.
  
• You won't have to unlearn certain "bad habits" of C
  
• Your skills will up-to-date
  
• Your code will be textually smaller (See note about Con)
  
• Job Security -- that is half joking, half serious. Seriously.
  
• You can enjoy the time exploring the different nooks and crannies of the language. You will see a different way to solve the same old problems. This can be both good and bad.
  
• Eventually you'll be able to enjoy deep technical C++ comedy such as Hitler on C++
  
• OOP (Object Orientated Programming) makes it almost easy to quickly write bigger scale programs
  
• Is multi-paradigm: Procedural, OOP, Functional, Generic. You have the freedom to pick and choose the parts of the language that fits your needs.
  
• For every problem you're trying to solve there is probably language support. Threads, and Atomics are finally part of the language.
  
  
• C++ Con
  
• You won't understand some of the C idioms used in practice
  
• The language is HUGE -- it will take you a decade to properly learn the language
  
• Debugging C++ is a PITA
  
• While people write crap code in any language, it is harder to read bad C++ code then C code.
  
• Compiler Support for the latest standards is a constantly moving target. Translation: Microsoft's Visual C++ has traditionally had crap support for the latest C and C++ standards. The good news is that MSVC 2015 finally supports a nice section of the language.
  
• While C++ can be textually smaller, one's code can easily be "bloated" if not careful (such as templates and partial template specialization)
  
• You really won't understand the run-time costs, nor be motivated to understand the underlying assembly language generated, by a "simple" C++ expression.
  
• Expect L-O-N-G compile times for any significant code base unless you use a "Bulk / Unity" build (you compile one .cpp file that includes EVERYTHING)
  
• It will be hard to resist over-engineering, over-complicating even the most basic tasks
  
• iostreams is a complete clusterfuck. Even the C++ committee recognizes there are many problems with C++ iostreams but sadly nothing is being done towards performance at the cost of type safety.
  
• It is far easier to blow your cache. Even Bjarne Stroustrup, the language designer, until 2012 didn't have a clue in understanding why Doubly Linked Lists were so slow compared to Arrays. HINT: The L1 Cache usage is critical for performance sensitive code.
  
• People tend to over-use the OOP paradigm even when they shouldn't. People make dogma and religion of "Design Patterns", failing to think if the model applies or not.
  
• The OOP paradigm is slow and bloated compared to Data-Orientated-Design. See Sony's Pitfalls of Object Orientated Programming
  
• Reflection STILL isn't standardized -- everyone has their own "home grown" approach. Maybe in C++17 ?
  
  
  

  Learn C first
  

  
  

• C Pro
  
• The language is tiny and easy to learn. Learn C the Hard Way is a great tutorial.
  
• No operator overloading
  
• No function overloading
  
• No lambas
  
• Has no reflection
  
• Has no exceptions
  
• Has no RTTI (Run-Time Type Identification)
  
• Has no STL (Standard Template Library)
  
• You will have a better understanding of the run-time "cost" or performance of code instead of a single line hiding "hidden" behaviour.
  
• You'll be a better programmer for understanding more of the lower-level implementation. If you don't know how to write itoa() or atoi() you're a noob programmer.
  
• You'll be forced to keep things simple
  
• You'll understand how to implement OOP in a non-OOP-native language, and better appreciate C++'s syntax sugar of OOP.
  
• You'll appreciate how C++ templates solve some but not all "textual replacement" problems and why #define macro's suck for debugging.
  
• Is ubiquitous, runs everywhere, and easy to get a C compiler for everything under the sun. Matz's Ruby Interpreter (MRI) was written in C, the Java VM was originally implemented in C, Perl is implemented in C, Linux is written in C. Anything popular and older then 10 years was probably written in C.
  
• Variables must be placed at top of a brace {
  
  
• C Con
  
• Compared to C++, you'll hate how primitive the language is such as typedefs for structs, no local functions, const is only "half" useful in C -- it can't be used in array declarations (See: http://stackoverflow.com/questions/5248571/is-there-const-in-c ), etc.
  
• No operator overloading
  
• No function overloading
  
• No lambas
  
• Has no reflection
  
• Has no exceptions
  
• Has no RTTI (Run-Time Type Identification)
  
• Has no STL (Standard Template Library)
  
• Simple algorithms can be tedious to write
  
• Variables must be placed at top of a brace {
  
  With that said there are numerous C++ books I would recommend to ALL C++ programmers. They are sorted from beginner to expert:
  
  
• The Design and Evolution of C++, Bjarne Stroustrup -- another ancient but fundamental to understanding all the kludges in C++
  
• The C++ Programming Language, 4th Edition <-- "Mandatory"
  
• ALL the books by Scott Meyer
  
• Effective Modern C++: 42 Specific Ways to Improve Your Use of C++11 and C++14
  
• Effective C++: 55 Specific Ways to Improve Your Programs and Designs (3rd Edition)
  
• Effective STL: 50 Specific Ways to Improve Your Use of the Standard Template Library -- ancient but good
  
• Modern C++ Design: Generic Programming and Design Patterns Applied by Andrei Alexandrescu -- another ancient but it blew the doors open for C++ Meta-Programming. IT is interesting that he hates C++ -- he now works on the D language.
  
  If you can get only one book, get the The C++ Programming Language.
  
  Even though Bruce's book is ancient he keeps it simple and is a fun easy read. Remember this is before C++98 where the language is much simpler.
  
  
• Thinking in C++, Bruce Eckel
  
  You can find it online for free
  
  Lastly, just because you can, doesn't imply you should. Use balanced C++ and you'll be fine.

Check out Bjarne's book:
(https://www.amazon.com/Design-Evolution-C-Bjarne-Stroustrup/dp/0201543303)

For a book-length rationale/apology for why C++ is the way it is. I think C++ language is shooting off it's feet bit by bit with the way they design things: in a couple standards the language will be so complex developers will be cargo-cult-copying-boiler-plate over most things like this.

For c++ at least http://www.amazon.com/The-Design-Evolution-Bjarne-Stroustrup/dp/0201543303 this goes over pretty much all the early design desisions, including why they picked that idiom.

You could take a look at The Design and Evolution of C++.

Yeah, no worries; just emphasizing. I wasn't programming when it was introduced either. ;-) I had to dig out my D&E to try to track it down.

> It's you little hipstor who're trying to prove the outrageous idea that what people do now is somehow the best possible

Nope I haven't once tried to argue that. I'm arguing against your stupid idea, not that what we have is perfect. But again your inability to grasp basic knowledge doesn't really surprise me.

> Even that useless wikipedia does not say anything about

I pulled several literal direct quotes out. Were you unable to read those? Was it too hard? Should we check and see if there's a simple english version of that wikipedia page for you?

> What for? Wikipedia is for idiots. Why would anyone at all care about the idiots?

Okay so can you provide a list of sources you consider valid? Since anybody who's made a compiler that's actually used is stupid and idiotic, the entire world is stupid and idiotic, wikipedia with sources is idiotic and stupid. Who besides you do you consider not stupid and idiotic?

Would the creator of Parser Expression Grammar be a valid source? Because Bryan Ford says

> Parsing Expression Grammars (PEGs) provide an alternative, recognition-based formal foundation for describing machine-oriented syntax, which solves the ambiguity problem by not introducing ambiguity in the first place. Where CFGs express nondeterministic choice between alternatives, PEGs instead use prioritized choice.

I assume that if his scientific paper isn't a good enough source then MIT itself is just full of stupid idiots too?

What about lambda the ultimate?

What about the MIT mailing list for PEG who reference this site that advocates for users to read the wikipedia entry on it. You know why it advocates that? Because Bryan Ford wrote the wikipedia page on it.

I could literally go all day finding more and more sources that directly contradict you, or reaffirm that the wikipedia entry is indeed correct. Could you find a single source besides yourself?

> Since when C++ is mainstream?

Since pretty much it's creation. Usage isn't even significantly dropping as it's doing a fairly good job of adding more and more features.

> And nobody would dare to call it a "general purpose"

Yeah nobody except for, you know the literal standard which has it as the first sentence of the second paragraph.

> designed explicitly for building eDSLs.

Where the hell did you get this idea? Seriously who told you this?

Because Bjarne Strousrup says that it

> was designed to provide Simula's facilities for program organization together with C's efficiency and flexibility for systems programming. It was intended to deliver that to real projects within half a year of the idea.

But he's probably an idiot too right? What would he possibly know about the reason why C++ was created?

> Objective fact is an implementation of error recovery operator. Which you claim is somehow "impossible" in PEG.

Nope never claimed that. Again you fail to be able to read.

What I claimed is that the naive trivial implementations where you auto-generate stuff does not support this well. You have to go very far out of your way to get decent error messages out of a parser generator. Which is why nobody making a widely used language uses them. And certainly even you can agree that adding the error recovery operator does mean you do more work than not having it.

> I demonstrated a PEG-based extensible parser generator that integrates with IDEs and literate programming tools automatically.

I didn't say it didn't do that. Just that it's rather shitty. You can get the barest minimum of features that are expected out of every IDE extension.

> What the fuck did you just say? It does not even mean anything.

I'm sorry, were those words too complicated for you? You wanted a single example because in your mind it was impossible to find a single example. I gave you one. You can't even understand literally the world's easiest set of requirements? Would you like a more thorough spec for the 5 minute task?

Or do you need another example because you're going to change your mind again and say something like "well actually the web is stupid and nobody uses websites".