Had nobody ever attempted to fix these problems in a non-backwards-compatible way? I'm imagining a new "almost-c++" that ditches the preprocessor for something better and makes a few other changes with the goal of vastly improved compile times. Then it should be possible to produce a GCC or Clang++ plugin that translates from C++ to "almost-C++" automatically, making it trivial to switch.
It doesn't have an automatic translator, but it's design does follow a rule of "If a piece of C code is dropped into a D compiler, either it compiles with the same semantics, or it doesn't compile."
BTW, Someone needs to fix the CSS for this text-entry box. Someone set the text color to black, but forgot to set the background color too. So on my light-on-dark system, I get Invisible-text-syndrome and have to edit in notepad and copy-paste into the text-box. Wheee!
C++ isn't without it's age spots, but articles like this do nothing to give a balanced view of its usefulness vs. issues. Many languages have boasted to topple C++ and it hasn't happened it, mostly because C++ does its job well enough and other languages aren't better enough so that migrating large code bases is cost effective.
The article was not intended to give a balanced view of issues vs usefulness. It was attempting to explain why C++ compiles relatively slowly, which is a common question people ask me. Whether or not the speed issues are balanced by other considerations is up to the C++ user.
As far as this specific complaint goes, I've worked on large-scale C++ programs and I've rarely come across anything prohibitive as far as compile times are concerned. Granted, C is faster, as are some other languages, but in terms of overall project development time, compiling is dwarfed under requirements, design, coding, testing, collaboration, etc. It's a non-sequitur that improving compile time would have any overall impact on development.
Comments
Had nobody ever attempted to fix these problems in a non-backwards-compatible way? I'm imagining a new "almost-c++" that ditches the preprocessor for something better and makes a few other changes with the goal of vastly improved compile times. Then it should be possible to produce a GCC or Clang++ plugin that translates from C++ to "almost-C++" automatically, making it trivial to switch.
Yes, they have. It's called D: http://www.digitalmars.com/d
It doesn't have an automatic translator, but it's design does follow a rule of "If a piece of C code is dropped into a D compiler, either it compiles with the same semantics, or it doesn't compile."
BTW, Someone needs to fix the CSS for this text-entry box. Someone set the text color to black, but forgot to set the background color too. So on my light-on-dark system, I get Invisible-text-syndrome and have to edit in notepad and copy-paste into the text-box. Wheee!
Also note that the author of the article is also the author of D.
I think the automatic translator is the most important part.
C++ isn't without it's age spots, but articles like this do nothing to give a balanced view of its usefulness vs. issues. Many languages have boasted to topple C++ and it hasn't happened it, mostly because C++ does its job well enough and other languages aren't better enough so that migrating large code bases is cost effective.
The article was not intended to give a balanced view of issues vs usefulness. It was attempting to explain why C++ compiles relatively slowly, which is a common question people ask me. Whether or not the speed issues are balanced by other considerations is up to the C++ user.
As far as this specific complaint goes, I've worked on large-scale C++ programs and I've rarely come across anything prohibitive as far as compile times are concerned. Granted, C is faster, as are some other languages, but in terms of overall project development time, compiling is dwarfed under requirements, design, coding, testing, collaboration, etc. It's a non-sequitur that improving compile time would have any overall impact on development.