3 ms·

The Most Important C++ Software Ever – Opinion by Scott Meyers

peter_d_sherman 6y ago
>"My picks for the [...] most important pieces of software in the history of C++, ordered chronologically by first appearance, are:" [PDS Note: I only include the first item on the list, Cfront, because I feel it is of fundamental importance...]: "Cfront by AT&T Bell Telephone Laboratories, 1985-1993. In the beginning, there was Cfront, the original C++ compiler. It was a true compiler, but it generated C as its object code, so it was common to think of it as a preprocessor that translated C++ to C. It was hard not to think otherwise when debugging, because, at least when I started using it in 1988, there were no C++ debuggers. Instead, we grizzled pioneers used C debuggers and learned to mentally unmangle names (e.g., to recognize that __pl__1Aff in the debugger referred to some operator+ function in the C++ source code). The fact that Cfront generated C had two advantages. First, it was fairly easy to port Cfront to new platforms, because C compilers were ubiquitous. This facilitated the rapid spread of C++ to many environments. Second, it allowed users to look at the generated code to see what was going on during compilation. This helped demystify the language at a time when most people using it were C++ beginners trying to figure out how it worked. It also acted as a kind of security blanket. You didn’t really have to worry about C++ pulling the wool over your eyes if everything it did was sitting there in plain sight (or at least sight as plain as machine-generated C ever gets.) Until about 1990, Cfront not only compiled code, it also acted as the de facto language standard. C++ came from AT&T and Cfront came from the C++ group at AT&T, so whatever Cfront did had to be correct. For a time, this led to other compiler vendors adhering so closely to Cfront behavior, they reproduced its bugs, too. When the Annotated C++ Reference Manual (ARM) was published, Cfront’s role as a reference implementation gradually diminished, especially when it became clear that adding exception-handling support to Cfront called for Herculean effort. The final Cfront release was in 1993, but at least its ghost lives on. Edison Design Group—a company know for producing the most standard-conformant C++ front ends in the business—notes in a July 2006 document that they have a Cfront-compatibility mode. Personally, I suspect that there are a few Cfront implementations being used for embedded projects on platforms where there’s still no native C++ compiler, but that’s just speculation on my part."

>"My picks for the [...] most important pieces of software in the history of C++, ordered chronologically by first appearance, are:" [PDS Note: I only include the first item on the list, Cfront, because I feel it is of fundamental importance...]: "Cfront by AT&T Bell Telephone Laboratories, 1985-1993. In the beginning, there was Cfront, the original C++ compiler. It was a true compiler, but it generated C as its object code, so it was common to think of it as a preprocessor that translated C++ to C. It was hard not to think otherwise when debugging, because, at least when I started using it in 1988, there were no C++ debuggers. Instead, we grizzled pioneers used C debuggers and learned to mentally unmangle names (e.g., to recognize that __pl__1Aff in the debugger referred to some operator+ function in the C++ source code). The fact that Cfront generated C had two advantages. First, it was fairly easy to port Cfront to new platforms, because C compilers were ubiquitous. This facilitated the rapid spread of C++ to many environments. Second, it allowed users to look at the generated code to see what was going on during compilation. This helped demystify the language at a time when most people using it were C++ beginners trying to figure out how it worked. It also acted as a kind of security blanket. You didn’t really have to worry about C++ pulling the wool over your eyes if everything it did was sitting there in plain sight (or at least sight as plain as machine-generated C ever gets.) Until about 1990, Cfront not only compiled code, it also acted as the de facto language standard. C++ came from AT&T and Cfront came from the C++ group at AT&T, so whatever Cfront did had to be correct. For a time, this led to other compiler vendors adhering so closely to Cfront behavior, they reproduced its bugs, too. When the Annotated C++ Reference Manual (ARM) was published, Cfront’s role as a reference implementation gradually diminished, especially when it became clear that adding exception-handling support to Cfront called for Herculean effort. The final Cfront release was in 1993, but at least its ghost lives on. Edison Design Group—a company know for producing the most standard-conformant C++ front ends in the business—notes in a July 2006 document that they have a Cfront-compatibility mode. Personally, I suspect that there are a few Cfront implementations being used for embedded projects on platforms where there’s still no native C++ compiler, but that’s just speculation on my part."