Celebrating 30th Anniversary of the First C++ Compiler: Let's Find Bugs In It

New submitter Andrey_Karpov writes: Cfront is a C++ compiler which came into existence in 1983 and was developed by Bjarne Stroustrup ("30 YEARS OF C++"). At that time it was known as "C with Classes". Cfront had a complete parser, symbol tables, and built a tree for each class, function, etc. Cfront was based on CPre. Cfront defined the language until circa 1990. Many of the obscure corner cases in C++ are related to the Cfront implementation limitations. The reason is that Cfront performed translation from C++ to C. In short, Cfront is a sacred artifact for a C++ programmer. So I just couldn't help checking such a project [for bugs].

Comments

Hardware requirements...

[__aaclcg7560]

I'm sure I got a PDP-8 somewhere in my back closet.

Re:Hardware requirements...

[__aaclcg7560]

Front closet is for coats and jackets after walking through the door. Back closet is typically a walk-in closet off the master bedroom for clothes and junk. In my case, I got five boxes of computer parts that I picked up over the years. Last year I got rid of the AT-to PS2 keyboard adapters and SCSI drives from the 1990's.

Isn't C just a glorified macro assembler?

[Anonymous Coward]

Before C++ came around, wasn't C just a glorified macro assembler?

Re:Isn't C just a glorified macro assembler?

[grimmjeeper]

Before C++ came around, wasn't C just a glorified macro assembler?

Not exactly. It was intended to be an actual compiled language but one with as little overhead as possible and the ability to touch the hardware easily. It's considered a "middle level language". Where low level languages would be various assemblers and what not. High level languages (i.e. most other compiled language) deliberately abstract away the low level functionality to make writing applications easier. C was designed specifically as an in-house tool at Bell Labs for rewriting Unix and escaped sometime in the late 60's/early 70's. It was and always will be a compiled language, albeit one with only a very small base of core functionality.

When they wrote it, Kernighan and Ritchie discarded most of the overhead that came with other languages. The linking of pointers to arrays and array arithmetic simplified the compiling while providing the bare minimum of array functionality. The lack of pretty much any built in functions made the language simple and compact. Putting all that functionality in libraries means you only needed to include just the pieces you used. And if you didn't need something, the language didn't force you to link it in. The language gave you just the few pieces that were absolutely necessary and you were responsible for the rest. The standard libraries that evolved after that are what gave C the ability to be a general purpose language.

C is a great language for writing small, tight, efficient, low level programs as long as you know what you're doing and are willing to work with just a few small, sharp tools. It still has it's place in embedded systems and for writing operating systems (or at least the kernel). Beyond that, it's really quite limited. But no, it's not just a macro assembler. It is more than that.

Re:Isn't C just a glorified macro assembler?

[lgw]

You do realize there are no "memory management issues" in modern C++, right? Java abstracts away the memory management issues of C, and of C++ written like C.

The advantage of Java and C# is the easier learning curve. C++ can be bizarre and arcane, while the managed languages are simpler to get right, and so you can far more easily hire programmers who won't screw everything up.

Re:Isn't C just a glorified macro assembler?

[bobbied]

Oh yes there are memory management issues in C++, you still have to take care of it unless you only use stack and static storage. There are memory management issues in Java too, but most don't understand why they exist or how to avoid them (thankfully most don't run into the issues, but they are there).

What you are talking about is that we have ABSTRACTED memory management tasks by going through libraries and templates. The "problem" hasn't been "fixed", all we've done is make it easy for programmers to not think about it if they wish. That doesn't mean the programmer shouldn't be aware of how C++ manages memory and how your libraries and templates deal with it. It's the same problem that C has, only it can be a lot worse in C++ because many programmers don't fully understand when the compiler is going to run your constructors and destructors.

Sure, Java (aka C#), seems easier to you. It's what they teach in school because you can ignore whole swaths of information about what the hardware is really doing because it's abstracted away. But that doesn't mean C++ is old and arcane, nor is it bizarre if you truly understand what is going on beneath your programs feet. Java and C# just isolate you from all this by abstraction, but you pay a price for the convenience. Java and C# are slower, MUCH slower, and they use a lot more resources when they run. You also don't have much control over memory management, in Java and C#, everything pretty much stops when the garbage collector is running and there is not much you can do about it. In C and C++ you can write code that you know won't be interrupted for garbage collection, which may not be important to you, but it is important to some of us who are writing time sensitive systems with strict time budgets.

Admit it. Java and C# are only tools, just like C and C++. Each is a the preferred solution for specific tasks and are not better or worse than the other. They are just tools that bring their unique features to the table. A wise programmer has as many tools in the tool box as possible. He keeps them sharp and hones his skills so he can skillfully apply the BEST tool for the job at hand.

Re:Isn't C just a glorified macro assembler?

[grimmjeeper]

Well sure. Any time you had a project that already mixed C and assembly, there already was a lot of detailed work to manipulate the processor very specifically and no small amount of just inlining the assembly code rather than figuring out how to write C syntax. And I've done my share of that, mostly early in my career. But compared to high level languages, C offered substantial efficiency improvements at the cost of having to "roll your own" on just about everything you wanted to do. And more often than not, the compiled C code was "good enough" to get the job done.

Re:Isn't C just a glorified macro assembler?

[david_thornley]

Way back when, there were lots of different architectures, and they had their own C-level languages (CDC system programmers used Cybol, for example). C is the one that survived, because it was the language of Unix, and Unix caught on. It's multiplatform because Unix is. That gave it staying power. Nobody uses Cybol anymore, because it was tied to an architecture that just died.

Re:Isn't C just a glorified macro assembler?

[bobbied]

What you are talking about is that we have ABSTRACTED memory management tasks by going through libraries and templates. The "problem" hasn't been "fixed", all we've done is make it easy for programmers to not think about it if they wish.

Yeah, sure, that's all any programming language ever is: layers of abstraction over assembly. My point was, from a practical perspective, you don't worry about memory leaks in modern C++ code any more than you do in modern Java code. But of course Java only offers the "no leaks" way, which in C++ you must discover the "no leaks" way, giving Java the easier learning curve. (You can still get memory leaks with anything, of course, if you try hard enough, but I'm talking about the 99% case here).

Um, like it or not, memory leaks still exist in Java and it's not that hard to stumble into code that causes them. The problem is that most people don't understand the parts that are abstracted away, they don't think they need to, so it's easy to stumble over your shoelaces and not know why. Yea, Java makes it a bit harder to bleed memory, but it doesn't eliminate the problem.

But that doesn't mean C++ is old and arcane, nor is it bizarre

Placement new. Weak references. Static initialization quirks (so many lock management and reference counting bugs caused by that over the years!). A Turing-complete templating language, so that you can turn your compiler run into a game of Tetris. Heck, just the fundamental need to understand that vectors will copy their member as they grow, and so you need to use the appropriate kind of smart pointer for that (which has changed, what 3 times now over the life of the language).

Bizarre and arcane. All there for good reason, to solve problems that can't otherwise be solved, but bizarre and arcane.

One man's garbage is another's treasure. You need to understand what you pay for all this convenience. I'm not saying Java doesn't have it's good points. All I'm saying is that there are time when other tools are better choices. I use Java, I use C++, heck I use Perl and Python too, but part of my job is to know what tool works best for which problem and have the skills to effectively apply the tool necessary.

Java and C# are slower, MUCH slower, and they use a lot more resources when they run.

I used to work on code where that mattered, back in the day. Now everything is I/O bound and horizontally scalable, in my world, and CPU load is around 5% average in my service fleet.

OTOH, guys working in the IOT world with devices with 4K of memory still love C.

You work on large machines, great. Some of us work in constrained places, where size, weight, power consumption and heat dissipation are primary design constraints. I work in embedded systems where I don't have the luxury of just inserting more memory or a faster processor and where a Java interpreter would NEVER fit, much less run. No, I'm not writing device drivers, but I do have design constraints that make using Java a problem. So I say again, you pick the tool for the job at hand, so you want as many tools in the box as you can get.

Admit it. Java and C# are only tools, just like C and C++

Do you see anyone around here saying different?

Yes, I see you defending Java while talking down C++ and I'm not sure you know the details well enough to make the claims you have. Java DOES have memory leaks, they are just not common because the JVM takes care of most of that for you. Plus, all the convienince comes at a price, all the abstraction costs you. You may not care for your application, but it's still there. I've always been saying "Use the best tool."

So, shall we discuss Emacs verses VI next?

Re:C++ is...

[bobbied]

Only if you know what you are doing...

Re:C++ is...

[serviscope_minor]

If you know what you're doing, you probably are already using another language.

Such as? I doubt that there's anyone not relying on C++. Never mind that every major browser (and a few minor ones) are written in C++. Many language implementations are in C++. And for those that are in C, well, all the major C compilers (LLVM, VisualStudio and now GCC of course) are written in C++.

Personally, I like the language. Oh I can whine about it all day and it has many warts, but the combination of efficiency, expressiveness, flexibility and static typing fit well with me.

Re:what to be thankful for 30 years on

[bobbied]

But it's small and fast when you use it right..

C++ is but a tool we use to get our jobs done. Every tool has it's limitations, provisos, flaws and a purpose. When a tool is placed in the hands of a skilled craftsman using it for it's intended purpose it produces excellent results, but if it's used by somebody without the necessary skills, or for a task it is not designed to do, the results can be horrid. C++ may be dated, but for some problem domains it remains the tool of choice. You don't write device drivers in Java for a reason.

The wise programmer keeps as many tools in his tool box as possible. He sharpens them and maintains them and keeps adding the new and useful tools he finds. He knows the intended purpose and best use of his tools and selects the appropriate tools for the job at hand. All to often, young bucks show up to work armed with only ONE tool shiny and new, thinking that it is the only tool they need for any job. They deride the old salts who use the "old" tools well and make fun of the well warn, old tools they use. "Use this new shiny tool," they say, "It's the only tool you need." While the old experienced guys chuckle and shake their heads, remembering when they too said similar things and try to teach the younger ones that there is value in putting tools in the box...

CFront wasn't a compiler

[mveloso]

CFront wasn't a compiler, it was a preprocessor that spat out C code that was subsequently compiled by whatever C compiler you happened to have.

Looking at CFront output was the best way to understand how C++ actually worked at the time, since it was all mapped to pretty straightforward C constructs. I don't think anyone around today knows what a vtable and ptable is, but back then it was how you could tell the programmers who really dug in to the language from those that didn't.

Re:what to be thankful for 30 years on

[Anonymous Coward]

it is an unmanaged language that gives low level access without adequate tools to guard that access.

Uh, have you heard of smart pointers? Or RAII? Have you used C++ in the last 5-10 years... at all, actually?

Re: Imagine if it had never been done

[__aaclcg7560]

Security was never the primary design goal for C, UNIX or the Internet. The technology for the last half-century got "foisted on this world" because it worked and worked quite well.

Re:Imagine if it had never been done

[Anonymous Coward]

Without C++ there would be no Java. Since my community college couldn't afford a new Microsoft site license, I had to learn every flavor of Java for all my programming courses. Meh...

GCC was free the last time I checked and a free graphical frontend should be possible to find as well. Notepad++ would do (not 100% of license for a college though). Using java instead of C++ for license issues sounds more like an excuse to me, partly because in my university days Microsoft donated licenses to the students and I got free windows and stuff. After all they wanted the new engineering students to be used to microsoft products when they joined the software workforce.

I learned Java as well, not due to costs, but because the cross platform code made it "the only language you will ever need in the future". Everybody hated it and preferred C or C++ (C was actually surprisingly popular compared to C++) and to this day I haven't had the need to use java even once since I graduated. I use C++ for performance and scripting langauges for whatever uni figured I should use Java for.

Re:C++ is...

[Dutch Gun]

Nope, C++ is still a thing when you need to create really large, complex programs, and when efficiency still really matters. Here in the videogame industry, C++ absolutely reigns supreme. Nothing else even comes close. Large applications like MS Office are still written in C++, from what I'm told, as are *many* large applications. It's not just legacy stuff either.

C++ has the native performance of C, but is able to use powerful zero-cost abstractions that allow programs to scale up safely. For instance, if you write modern C++, it's almost impossible to write code that will stomp on random memory or leak resources, a real issue with C or older style C++ programs, yet that protection is completely optimized away and costs *nothing* at run-time (which I think is something many programmers don't properly appreciate).

An easy language to master? Absolutely not. It's a language that takes a long time to learn well, and it can be rather unforgiving at times, but it's great for what it does. C++ 11/14 has also really breathed new life into things as well, IMO. It's really amazing how much the language feels almost like it's using managed memory (e.g. garbage collection) now that I'm using smart pointers ubiquitously.

C++ is incredibly portable as well. My game engine works across several platforms, only a smallish percentage of the code is different between platforms, mostly for low-level graphics, audio, windowing, or other system calls.

It's stability as a language is legendary as well, and that's important for real-world projects that depend on it. You can probably still compile most the earliest C++ code on a modern compiler and expect it to still work, not to mention most C code as well.

I'd never claim C++ is the end-all, be-all of languages (I sound like I'm gushing, but I have plenty of complaints as well), but it most assuredly has a very long future with us, and for some very good reasons.

Re:C backend would not impose limitations

[lgw]

Translating to C would not impose a limitation on the language features of C++

Practical limitations, for one guy banging out a language implementation in a hurry. C syntax was kept intact wherever possible, so that no translation would be needed. Which in turn led to quick adoption of C++ by C coders (which doomed C++ code to forever be ruined by C-style coding).

Re:Imagine if it had never been done

[__aaclcg7560]

While Microsoft may donate to the universities, it required payment from the community college that I attended. The dean taught C/C++ and GCC in the Linux Admin classes. The administration refused to go with open source programming because Microsoft Visual Studio was the industry norm and Java was the next industry norm on the horizon. When the funding issue did get resolved, none of the classroom computers could run VS .NET as the hardware was too old. I never used Java after graduating from school. These days I use Python and occasionally Cython (C compiler for Python).

Re:C++11 is almost a different language

[david_thornley]

Yes, and the pre-C++11 std::auto_ptr was a confusing piece of crap.

Which is why you'll never get one through a code review at my company. std::unique_ptr does what auto_ptr did, only much more elegantly. std::shared_ptr is also useful.

Isn't that the trade group that sues music fans? Oh wait, that's RIAA. But yes, I understand the advantages of automatic finalization.

I'm not sure you really do understand RAII, if you refer to it as "automatic finalization". It's far more useful than finalization in the languages I've seen that use it. It's a unified resource manager that can handle every type of resource uniformly.