5 ms·

Last year I saw Bjarne Stroustrup give a talk about C++ and one of the things he pointed out was that a modern C++ compiler can still compile 40 year old C code

by minimax 12y ago

Last year I saw Bjarne Stroustrup give a talk about C++ and one of the things he pointed out was that a modern C++ compiler can still compile 40 year old C code. He thought the backwards compatibility was a strength and was one of the reasons C++ is so popular. It was a good talk and I wish I could find a video of it somewhere.

vidoc 12y ago
The keyword here i guess is 'can' :P
mikeash 12y ago
Did he mean because C++ compilers usually include C compilers as well? C++ compilers will reject a lot of good C code, mostly because it disallows implicit casts from void *.
- sjolsen 12y ago
  > C++ compilers will reject a lot of good C code, mostly because it disallows implicit casts from void * When did code that implicitly casts from void * become "good?" Implicit conversions from A to B should never happen unless it's statically known that A can be represented as B, and that's generally not the case when A is type-erased, as when it's referred to through void *.
  - mikeash 12y ago
    The typical case is when you call malloc. There's a ton of C code that looks like: sometype *ptr = malloc(...); A C++ compiler will reject that.
    - sjolsen 12y ago
      > The typical case is when you call malloc. And if there were a proper type-parameterized entry point to malloc (be it a function or macro) for general-purpose contiguous-object allocation, you wouldn't have to compromise the already weak type system with what is possibly the single most absurd implicit conversion possible from a type system perspective just to avoid typing out the type name three times. I suppose it's more of a language quality issue than a program quality issue, but reducing verbosity by undermining the type system rather than providing a simple "allocate<T>(n)" function, especially in a language that doesn't care about verbosity enough to provide even the thinnest of syntactic abstractions, is just ridiculous.
      - mikeash 12y ago
        I agree completely, but none of that changes the nature of C nor the code written in it. If you want to change the API like this, more power to you, but don't then say that existing code still compiles fine.
        sjolsen 12y ago
        > but don't then say that existing code still compiles fine. Oh, I'm not disputing that a lot of existing C code wom't compile as C++; I'm just nitpicking the claim that good C code won't compile as C++. ;) But to be fair, there are perfectly good, valid C programs that don't compile as C++, void * aside.
- deleted 12y ago
  [deleted]
- minimax 12y ago
  It's much more likely that I am misquoting what Bjarne Stroustrup said than that Bjarne Stroustrup doesn't know what is or isn't valid C++. Anyway I found the slide deck from the talk. He was making this point while discussing the slide on page 7. http://files.meetup.com/1455470/C%2B%2B14%20and%20Concepts.pdf http://files.meetup.com/1455470/C%2B%2B14%20and%20Concepts.p...

by minimax 12y ago

vidoc 12y ago

The keyword here i guess is 'can' :P

mikeash 12y ago

Did he mean because C++ compilers usually include C compilers as well? C++ compilers will reject a lot of good C code, mostly because it disallows implicit casts from void *.

sjolsen 12y ago
> C++ compilers will reject a lot of good C code, mostly because it disallows implicit casts from void * When did code that implicitly casts from void * become "good?" Implicit conversions from A to B should never happen unless it's statically known that A can be represented as B, and that's generally not the case when A is type-erased, as when it's referred to through void *.
- mikeash 12y ago
  The typical case is when you call malloc. There's a ton of C code that looks like: sometype *ptr = malloc(...); A C++ compiler will reject that.
  - sjolsen 12y ago
    > The typical case is when you call malloc. And if there were a proper type-parameterized entry point to malloc (be it a function or macro) for general-purpose contiguous-object allocation, you wouldn't have to compromise the already weak type system with what is possibly the single most absurd implicit conversion possible from a type system perspective just to avoid typing out the type name three times. I suppose it's more of a language quality issue than a program quality issue, but reducing verbosity by undermining the type system rather than providing a simple "allocate<T>(n)" function, especially in a language that doesn't care about verbosity enough to provide even the thinnest of syntactic abstractions, is just ridiculous.
    - mikeash 12y ago
      I agree completely, but none of that changes the nature of C nor the code written in it. If you want to change the API like this, more power to you, but don't then say that existing code still compiles fine.
      - sjolsen 12y ago
        > but don't then say that existing code still compiles fine. Oh, I'm not disputing that a lot of existing C code wom't compile as C++; I'm just nitpicking the claim that good C code won't compile as C++. ;) But to be fair, there are perfectly good, valid C programs that don't compile as C++, void * aside.
deleted 12y ago
[deleted]
minimax 12y ago
It's much more likely that I am misquoting what Bjarne Stroustrup said than that Bjarne Stroustrup doesn't know what is or isn't valid C++. Anyway I found the slide deck from the talk. He was making this point while discussing the slide on page 7. http://files.meetup.com/1455470/C%2B%2B14%20and%20Concepts.pdf http://files.meetup.com/1455470/C%2B%2B14%20and%20Concepts.p...