9 ms·

I'm tired of people blaming the bad things in C++ on C. Most of the bad things in C++ came from C++ itself, not from anywhere else. The Modula-3 type system w

I'm tired of people blaming the bad things in C++ on C. Most of the bad things in C++ came from C++ itself, not from anywhere else. The Modula-3 type system with its inheritance anti-patterns can't be found anywhere in C. "Guru meditation" template error messages can't be found anywhere in C, nor do C programs typically take hours to compile. In C, functions and types that are "static" to a file don't appear in header files... C++ "improved" that so that private types and functions must appear in header files, greatly extending compile times. Global constructors are not in C... you know what order your program will run in when using C. The set of things in C that were "fixed" by C++ is very small, possibly even the empty set for reasonably modern dialects of C. For example, having the compiler implicitly declare functions as returning "int" was on its way out with or without C++. Probably the worst thing about C was all the implicit type conversions-- between long and int, and char* and boolean. Of course C++ didn't fix this. They even made it worse by declaring that any C++ constructor that took one argument would be a candidate for implicit type conversion. So if you declared Foo::Foo(int i), in the future any time you have an int the compiler would consider promoting it to a Foo. Later they realized their mistake and added the "explicit" keyword so C++ gurus can avoid this error most of the time (when they remember).

hellofunk 11y ago
The new syntax using curly braces to initialize a variable disallows type conversion and is the recommended method now iirc.
- reality_czech 11y ago
  OK, so C++ came out in 1984, and it only took them 30 years to add a way to bypass the implicit conversions they added to the language. Just once, I'd like to hear a C++ advocate say "we made a mistake." Of course it won't happen, so it's time to deny, obfuscate, and redirect blame.
  - hellofunk 11y ago
    Bjarne has been very open over the years about mistakes he thinks affected parts of c++'s development. There is no perfect language but c++ does keep trying to improve.
  - unscaled 11y ago
    Hey, C came earlier and strcat is still in the standard, as well as non-prototyped function calls. Someone told me FORTRAN still maintains backward compatibility with arithmetic ifs, and it's been like, what, 60 years? Strange that.
    - reality_czech 11y ago
      You are comparing apples and oranges. strcat is a library function which is easy to avoid, whereas the implicit type conversion behavior is part of the core C++ language and very difficult to escape. Non-prototyped function calls are there, but they trigger warnings on any compiler from the last 3 decades. Anyway, thanks for playing the "deny, obfuscate, shift blame for broken C++ design decisions" game.
nickpsecurity 11y ago
You're saying directly, C-level style and compatibility at a language-level in early C++ couldn't negatively impact its safety or maintainability vs Modula-2/3, etc? I highly doubt that given most crashes early on were C++ being done in a C-like style, using C runtimes, or calling C OS functions. The C++ style modernists here advocate greatly reduces problems outside compile times. So, I'm a C++ opponent but it's still obvious C dragged it down a lot. Stroustrup's writings on its origins and why he made specific tradeoffs shows it's a fact. There were often more ideal stuff, from high-level perspective, that wouldn't fit with C, would break legacy, or would take a performance hit C developers would reject. None was allowed as C developer adoption was main goal. We failed to convince them to use lots of other low-level languages, too. C developers are picky. So, their foundation of quicksand remains a the bottom.
- reality_czech 11y ago
  Please think carefully about what you're saying and try to avoid making unfounded generalizations about large groups of people ("C developers are picky" etc.) People were willing to accept a lot of performance compromises to use C++. For example, C++ streams are at least 3x slower than stdio to this day. But they were still widely adopted. Similarly, exceptions caused a performance hit, but were widely used for a while. There isn't a single "modernist" style in C++, there are dozens of permutations (exceptions vs. no exceptions, boost vs. no boost, quasi-functional vs. C-like). I was a C++ developer for 10 years. More than half of the really difficult problems we encountered were C++-only, relating to constructs that didn't exist or were simpler in C. The reality is that C++ just has much more undefined behavior than C, which tends to make it less safe and less secure than that language. And some of the most exploitable software out there like Adobe Flash is written in the oh-so-safe C++ rather than the evil old C.
  - nickpsecurity 11y ago
    "Please think carefully about what you're saying and try to avoid making unfounded generalizations about large groups of people ("C developers are picky" etc.) " I did. Over a decade of research, empirical comparisons, non-C-like alternatives to C, C-like alternatives to C, safer subsets of C... literally everything attempted failed to get a huge chunk of C people off C's problems. Even stuff that had most of C's advantages with less of its disadvantages. Tiniest tweaks didn't work. Whereas people on other languages and niches were more likely to experiment and try all kinds of languages for projects. So, I think it's clear the C crowd has some strong, emotional attachment to their language and way of thinking. So, to get adoption, C++ had to build on that nonsense we were trying to replace. It had to merge very contradictory philosophies. Without the C part, the job would've been easier. We know that's true because it was in a number of safe, system and application languages. Anything with C or C-style at foundation has problems.
pjmlp 11y ago
If you cared to follow my posts you would see that I would rather be discussing about Modula-3 and Ada than C or C++. Yes the blame is 100% on C compatibility. There is an interview that I can gladly search for you, where Bjarne says he was dismayed the lack of knowledge about other languages and he had to do his thesis in C,swering never to use it again. So when he joined AT&T, he started right away to create his improved C version, which had to be copy-paste compatible with it. Had C++ had proper modules, it wouldn't work with C linkers. Those implicit conversions were added to make C++ data types fit into the way C developers were used to write their code. I can assure you than I worked on a C project in 2000 that took around one hour per platform to compile. As for enjoying C++, I rather programm in memory safe languages and since Oberon I am big fan of GC enabled systems programming languages. But C++ was my escape from C, when Turbo Pascal started fading away. Compared with Turbo Pascal, C always seemed a meh language, only thing going for it was better portability as the Pascal dialects. So, even with its inherited C defects, C++ does provide the tools for the security conscious developers, if one does decide to use them. Of course, ideally, both should be replaced, but it will take ages until it becomes a reality.
- reality_czech 11y ago
  Blaming someone else for your own poor design decisions is cowardly and irresponsible. Better languages than C++ can easily be built on top of C. For example, Objective C is a better language than C++, also built on top of C. Implicit type conversions could have been eliminated by having a "use strict" mode for new files, as was done in Perl 5. C++ didn't do this because the designers didn't see implicit type conversions as a problem. In fact they dramatically expanded the number of types that could be implicitly converted to include all user-defined types, as I have just described. But I guess the evil C designers somehow forced them to do that? At what point do you start taking responsibility for your own mistakes? It's sounding a lot like "never". By the way, C++ could have had a module system too. Objective C does, and people are talking about adding one to C++. But then again, Objective C had good designers, not "I just work here" type people who blamed all their problems on the previous engineer.
  - pjmlp 11y ago

hellofunk 11y ago

The new syntax using curly braces to initialize a variable disallows type conversion and is the recommended method now iirc.

reality_czech 11y ago
OK, so C++ came out in 1984, and it only took them 30 years to add a way to bypass the implicit conversions they added to the language. Just once, I'd like to hear a C++ advocate say "we made a mistake." Of course it won't happen, so it's time to deny, obfuscate, and redirect blame.
- hellofunk 11y ago
  Bjarne has been very open over the years about mistakes he thinks affected parts of c++'s development. There is no perfect language but c++ does keep trying to improve.
- unscaled 11y ago
  Hey, C came earlier and strcat is still in the standard, as well as non-prototyped function calls. Someone told me FORTRAN still maintains backward compatibility with arithmetic ifs, and it's been like, what, 60 years? Strange that.
  - reality_czech 11y ago
    You are comparing apples and oranges. strcat is a library function which is easy to avoid, whereas the implicit type conversion behavior is part of the core C++ language and very difficult to escape. Non-prototyped function calls are there, but they trigger warnings on any compiler from the last 3 decades. Anyway, thanks for playing the "deny, obfuscate, shift blame for broken C++ design decisions" game.

nickpsecurity 11y ago

You're saying directly, C-level style and compatibility at a language-level in early C++ couldn't negatively impact its safety or maintainability vs Modula-2/3, etc? I highly doubt that given most crashes early on were C++ being done in a C-like style, using C runtimes, or calling C OS functions. The C++ style modernists here advocate greatly reduces problems outside compile times. So, I'm a C++ opponent but it's still obvious C dragged it down a lot. Stroustrup's writings on its origins and why he made specific tradeoffs shows it's a fact. There were often more ideal stuff, from high-level perspective, that wouldn't fit with C, would break legacy, or would take a performance hit C developers would reject. None was allowed as C developer adoption was main goal. We failed to convince them to use lots of other low-level languages, too. C developers are picky. So, their foundation of quicksand remains a the bottom.

reality_czech 11y ago
Please think carefully about what you're saying and try to avoid making unfounded generalizations about large groups of people ("C developers are picky" etc.) People were willing to accept a lot of performance compromises to use C++. For example, C++ streams are at least 3x slower than stdio to this day. But they were still widely adopted. Similarly, exceptions caused a performance hit, but were widely used for a while. There isn't a single "modernist" style in C++, there are dozens of permutations (exceptions vs. no exceptions, boost vs. no boost, quasi-functional vs. C-like). I was a C++ developer for 10 years. More than half of the really difficult problems we encountered were C++-only, relating to constructs that didn't exist or were simpler in C. The reality is that C++ just has much more undefined behavior than C, which tends to make it less safe and less secure than that language. And some of the most exploitable software out there like Adobe Flash is written in the oh-so-safe C++ rather than the evil old C.
- nickpsecurity 11y ago
  "Please think carefully about what you're saying and try to avoid making unfounded generalizations about large groups of people ("C developers are picky" etc.) " I did. Over a decade of research, empirical comparisons, non-C-like alternatives to C, C-like alternatives to C, safer subsets of C... literally everything attempted failed to get a huge chunk of C people off C's problems. Even stuff that had most of C's advantages with less of its disadvantages. Tiniest tweaks didn't work. Whereas people on other languages and niches were more likely to experiment and try all kinds of languages for projects. So, I think it's clear the C crowd has some strong, emotional attachment to their language and way of thinking. So, to get adoption, C++ had to build on that nonsense we were trying to replace. It had to merge very contradictory philosophies. Without the C part, the job would've been easier. We know that's true because it was in a number of safe, system and application languages. Anything with C or C-style at foundation has problems.

pjmlp 11y ago

If you cared to follow my posts you would see that I would rather be discussing about Modula-3 and Ada than C or C++. Yes the blame is 100% on C compatibility. There is an interview that I can gladly search for you, where Bjarne says he was dismayed the lack of knowledge about other languages and he had to do his thesis in C,swering never to use it again. So when he joined AT&T, he started right away to create his improved C version, which had to be copy-paste compatible with it. Had C++ had proper modules, it wouldn't work with C linkers. Those implicit conversions were added to make C++ data types fit into the way C developers were used to write their code. I can assure you than I worked on a C project in 2000 that took around one hour per platform to compile. As for enjoying C++, I rather programm in memory safe languages and since Oberon I am big fan of GC enabled systems programming languages. But C++ was my escape from C, when Turbo Pascal started fading away. Compared with Turbo Pascal, C always seemed a meh language, only thing going for it was better portability as the Pascal dialects. So, even with its inherited C defects, C++ does provide the tools for the security conscious developers, if one does decide to use them. Of course, ideally, both should be replaced, but it will take ages until it becomes a reality.

reality_czech 11y ago
Blaming someone else for your own poor design decisions is cowardly and irresponsible. Better languages than C++ can easily be built on top of C. For example, Objective C is a better language than C++, also built on top of C. Implicit type conversions could have been eliminated by having a "use strict" mode for new files, as was done in Perl 5. C++ didn't do this because the designers didn't see implicit type conversions as a problem. In fact they dramatically expanded the number of types that could be implicitly converted to include all user-defined types, as I have just described. But I guess the evil C designers somehow forced them to do that? At what point do you start taking responsibility for your own mistakes? It's sounding a lot like "never". By the way, C++ could have had a module system too. Objective C does, and people are talking about adding one to C++. But then again, Objective C had good designers, not "I just work here" type people who blamed all their problems on the previous engineer.
- pjmlp 11y ago