Slashdot Mirror
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].
I'm sure I got a PDP-8 somewhere in my back closet.
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.
SJW n. One who posts facts.
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...
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
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.
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.
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.
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.
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.
Irony: Agile development has too much intertia to be abandoned now.
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).
Socialism: a lie told by totalitarians and believed by fools.
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.
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.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
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.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes