7 ms·

> Secondly, the killing feature of C++ is that it is C. If you don't want to use exceptions or RTTI, then you can just switch the features off. Most of C progra

> Secondly, the killing feature of C++ is that it is C. If you don't want to use exceptions or RTTI, then you can just switch the features off. Most of C programs can be just compiled with a C++ compiler with very small changes or without any changes at all. If your C code happens to be compileable with a C++ compiler, then either your program is very small or you are writing really shitty C.

dathinab 6y ago
Idk about "shitty C" but indeed C++ being a super set of C is a common misconception, followed by the misconception that it's nearly a superset of C. ;=) Simplest example is that a `void func()` decl in C and C++ have different semantic meanings.
- simias 6y ago
  I think "nearly a superset" is correct, the empty argument list doesn't really make enough of a difference to really make it a completely different language. I also don't think I've ever seen this "feature" of C used productively in modern codebases, except maybe to declare generic function pointers in something like dlfunc. In general it's just that people are too lazy to type `void func(void)` (or don't know the difference). You can also tell that the C++ standard committee agrees with this to some extent since they tend to add C novelties into the C++ standards whenever possible to make it easier to write compatible code, for instance: https://en.wikipedia.org/wiki/C%2B%2B11#Improved_C_compatibility https://en.wikipedia.org/wiki/C%2B%2B11#Improved_C_compatibi...
  - Gibbon1 6y ago
    I feel like treating C as a subset of C++ has done real harm to the language.
    - rrdharan 6y ago
      Which one?
      - Gibbon1 6y ago
        No arrays, no real strings. Pushing UB issues on the programmer instead of forcing the compiler maintainers to deal. No closures. Threading as a first class construct. No modules. Standard Library is increasingly a bad joke. What's happened is the direct opposite of C++ where every fad gets added to the language. With C lots of standard proven features don't make it into the language.
        rrdharan 6y ago
        Heh, yeah my point was you could plausibly apply your statement to both languages, i.e. their confusing coupling impedes both in different ways.
    - simias 6y ago
      I agree that teaching C++ as "C and then some stuff on top" is probably a bad idea. But I also think that it's not technically incorrect to say that "C is mostly a subset of C++", at least as far as most C constructs will work in C++ with only minor tweaks. It's a bit like saying that operating the windscreen wipers is a subset of knowing how to drive a car. It's strictly correct, but it's probably not where you should start nor where you should put most of your attention if you're looking to get you license.
  - loeg 6y ago
    Standard C++ still lacks C99 compound literals, doesn't it? That's the biggest gap I've run into. It is a common and practical construct in C.
    - jstimpfle 6y ago
      And designated initializers.
      - ncmncm 6y ago
        Yet, C++ supports designated initializers.
MaxBarraclough 6y ago
Why's that? C has a few features that C++ lacks, but it's possible to get by fine without using any of them. The Lua interpreter is written in a subset of C so that it also compiles fine as C++. Or, if you prefer, in a subset of C++ so that it compiles fine as C. https://www.lua.org/pil/24.1.html https://www.lua.org/pil/24.1.html
- josefx 6y ago
  Something as simple as malloc requires a cast in C++ when it is not needed in C, so type errors for even simple code.
  - MaxBarraclough 6y ago
    What type errors? Do you mean that, to get it to compile as C++, you have to add an explicit cast? That isn't a significant burden. Requiring explicit casts, and forbidding implicit conversions, reduces the odds of being surprised by an unwanted conversion. There's a good argument to be made for adding explicit casts to C code even when the language doesn't require them. GCC's -Wconversion flag can help with this.
    - ByteJockey 6y ago
      But the conversion of the result of a malloc call is neither surprising nor unwanted. There's also no ambiguity. You've already explicitly defined the variable's type at that point.
      - MaxBarraclough 6y ago
        There's very little harm in making the conversion explicit. It's more verbose, but it's also more explicit, which is a good thing. There is harm in implicit conversions catching the programmer unawares. This is a fairly significant cause of bugs in C code, and it's why C++ uses stricter rules, requiring you to always make these conversions explicit, even when using malloc.
b20000 6y ago
the linux kernel is written in C ...
- wtetzner 6y ago
  And it’s likely not compatible with a C++ compiler.
  - Subsentient 6y ago
    It definitely isn't. C99 and even some C11 features used all over the place. Designated initializers are heavily used. We'll see when those actually end up stable for C++20. Even then, I never use the latest standards of C++, I stay a couple standards behind so I can rely on whatever compiler I pick being able to handle it. Right now I'm using C++14.
- b20000 6y ago
  downvoted by the rust fanboys
simias 6y ago
I see what you mean but I think the point the article is making here is true: you can effectively strip most of the features of C++ and end up with something with a footprint and runtime cost almost identical to C. You can effectively port almost any C program to C++ by making purely syntactical changes that won't have any impact on the execution.
krizhanovsky 6y ago
Well, we didn't mention this in the article, but this is very practical actually. About 10 years ago we had a request significant reworking an open source DNS server and the main problem with the project was that almost whole logic was placed in about 10 functions and most of the functions exceeded 1000 LoC. Each code update involved plenty of headache with dynamic memory freeing. We spent about 1-2 days to compile it with C++ and replace the most crucial pointers with smart pointers, that we didn't have to care about memory freeing. That time we had to make the job done ASAP, surely we should have spend time in proper code refactoring. Surely you need to modify C code to compile it with C++ and in the article we made an example of the modification. But the point is that the changes are pretty straightforward and small.
- krizhanovsky 6y ago
  Also if you don't like my example with quick fix of some dirty project, then consider InnoDB storage engine which was developed in pure C for 2 decades, but now it's C++.
- the_mitsuhiko 6y ago
  I wouldn’t want to be tasked with maintaining a C++ codebase like that. That sounds horrible.
attractivechaos 6y ago
> If your C code happens to be compileable with a C++ compiler, then either your program is very small or you are writing really shitty C. It is easy to write C code that is compatible with C++ if you have compatibility in mind from the beginning. Most of time: 1) cast malloc() – you can define macros for less code; 2) avoid C++ keywords; 3) don't use VLA which is not recommended anyway; 4) add __STDC_LIMIT_MACROS for uint64_t etc. Use -Wc++-compat also helps. It is harder to modify existing C code for the compatibility with C++.
pengaru 6y ago
> If your C code happens to be compileable with a C++ compiler, then either your program is very small or you are writing really shitty C. And yet the standard practice for games written in C attempting to use Valve's C++ API for Steamworks integration is to switch to using a C++ compiler.
GirkovArpa 6y ago
I pasted the contents of this(1) ~100 line C file into this(2) C++ file with no problems. [1] https://github.com/nospaceships/raw-socket-sniffer/blob/master/raw-socket-sniffer.c https://github.com/nospaceships/raw-socket-sniffer/blob/mast... [2] https://github.com/GirkovArpa/raw-socket-sniffer/blob/master/addon.cpp https://github.com/GirkovArpa/raw-socket-sniffer/blob/master...

dathinab 6y ago

Idk about "shitty C" but indeed C++ being a super set of C is a common misconception, followed by the misconception that it's nearly a superset of C. ;=) Simplest example is that a `void func()` decl in C and C++ have different semantic meanings.

simias 6y ago
I think "nearly a superset" is correct, the empty argument list doesn't really make enough of a difference to really make it a completely different language. I also don't think I've ever seen this "feature" of C used productively in modern codebases, except maybe to declare generic function pointers in something like dlfunc. In general it's just that people are too lazy to type `void func(void)` (or don't know the difference). You can also tell that the C++ standard committee agrees with this to some extent since they tend to add C novelties into the C++ standards whenever possible to make it easier to write compatible code, for instance: https://en.wikipedia.org/wiki/C%2B%2B11#Improved_C_compatibility https://en.wikipedia.org/wiki/C%2B%2B11#Improved_C_compatibi...
- Gibbon1 6y ago
  I feel like treating C as a subset of C++ has done real harm to the language.
  - rrdharan 6y ago
    Which one?
    - Gibbon1 6y ago
      No arrays, no real strings. Pushing UB issues on the programmer instead of forcing the compiler maintainers to deal. No closures. Threading as a first class construct. No modules. Standard Library is increasingly a bad joke. What's happened is the direct opposite of C++ where every fad gets added to the language. With C lots of standard proven features don't make it into the language.
      - rrdharan 6y ago
        Heh, yeah my point was you could plausibly apply your statement to both languages, i.e. their confusing coupling impedes both in different ways.
  - simias 6y ago
    I agree that teaching C++ as "C and then some stuff on top" is probably a bad idea. But I also think that it's not technically incorrect to say that "C is mostly a subset of C++", at least as far as most C constructs will work in C++ with only minor tweaks. It's a bit like saying that operating the windscreen wipers is a subset of knowing how to drive a car. It's strictly correct, but it's probably not where you should start nor where you should put most of your attention if you're looking to get you license.
- loeg 6y ago
  Standard C++ still lacks C99 compound literals, doesn't it? That's the biggest gap I've run into. It is a common and practical construct in C.
  - jstimpfle 6y ago
    And designated initializers.
    - ncmncm 6y ago
      Yet, C++ supports designated initializers.

MaxBarraclough 6y ago

Why's that? C has a few features that C++ lacks, but it's possible to get by fine without using any of them. The Lua interpreter is written in a subset of C so that it also compiles fine as C++. Or, if you prefer, in a subset of C++ so that it compiles fine as C. https://www.lua.org/pil/24.1.html https://www.lua.org/pil/24.1.html

josefx 6y ago
Something as simple as malloc requires a cast in C++ when it is not needed in C, so type errors for even simple code.
- MaxBarraclough 6y ago
  What type errors? Do you mean that, to get it to compile as C++, you have to add an explicit cast? That isn't a significant burden. Requiring explicit casts, and forbidding implicit conversions, reduces the odds of being surprised by an unwanted conversion. There's a good argument to be made for adding explicit casts to C code even when the language doesn't require them. GCC's -Wconversion flag can help with this.
  - ByteJockey 6y ago
    But the conversion of the result of a malloc call is neither surprising nor unwanted. There's also no ambiguity. You've already explicitly defined the variable's type at that point.
    - MaxBarraclough 6y ago
      There's very little harm in making the conversion explicit. It's more verbose, but it's also more explicit, which is a good thing. There is harm in implicit conversions catching the programmer unawares. This is a fairly significant cause of bugs in C code, and it's why C++ uses stricter rules, requiring you to always make these conversions explicit, even when using malloc.

b20000 6y ago

the linux kernel is written in C ...

wtetzner 6y ago
And it’s likely not compatible with a C++ compiler.
- Subsentient 6y ago
  It definitely isn't. C99 and even some C11 features used all over the place. Designated initializers are heavily used. We'll see when those actually end up stable for C++20. Even then, I never use the latest standards of C++, I stay a couple standards behind so I can rely on whatever compiler I pick being able to handle it. Right now I'm using C++14.
b20000 6y ago
downvoted by the rust fanboys

simias 6y ago

I see what you mean but I think the point the article is making here is true: you can effectively strip most of the features of C++ and end up with something with a footprint and runtime cost almost identical to C. You can effectively port almost any C program to C++ by making purely syntactical changes that won't have any impact on the execution.

krizhanovsky 6y ago

Well, we didn't mention this in the article, but this is very practical actually. About 10 years ago we had a request significant reworking an open source DNS server and the main problem with the project was that almost whole logic was placed in about 10 functions and most of the functions exceeded 1000 LoC. Each code update involved plenty of headache with dynamic memory freeing. We spent about 1-2 days to compile it with C++ and replace the most crucial pointers with smart pointers, that we didn't have to care about memory freeing. That time we had to make the job done ASAP, surely we should have spend time in proper code refactoring. Surely you need to modify C code to compile it with C++ and in the article we made an example of the modification. But the point is that the changes are pretty straightforward and small.

krizhanovsky 6y ago
Also if you don't like my example with quick fix of some dirty project, then consider InnoDB storage engine which was developed in pure C for 2 decades, but now it's C++.
the_mitsuhiko 6y ago
I wouldn’t want to be tasked with maintaining a C++ codebase like that. That sounds horrible.

attractivechaos 6y ago

> If your C code happens to be compileable with a C++ compiler, then either your program is very small or you are writing really shitty C. It is easy to write C code that is compatible with C++ if you have compatibility in mind from the beginning. Most of time: 1) cast malloc() – you can define macros for less code; 2) avoid C++ keywords; 3) don't use VLA which is not recommended anyway; 4) add __STDC_LIMIT_MACROS for uint64_t etc. Use -Wc++-compat also helps. It is harder to modify existing C code for the compatibility with C++.

pengaru 6y ago

> If your C code happens to be compileable with a C++ compiler, then either your program is very small or you are writing really shitty C. And yet the standard practice for games written in C attempting to use Valve's C++ API for Steamworks integration is to switch to using a C++ compiler.

GirkovArpa 6y ago

I pasted the contents of this(1) ~100 line C file into this(2) C++ file with no problems. [1] https://github.com/nospaceships/raw-socket-sniffer/blob/master/raw-socket-sniffer.c https://github.com/nospaceships/raw-socket-sniffer/blob/mast... [2] https://github.com/GirkovArpa/raw-socket-sniffer/blob/master/addon.cpp https://github.com/GirkovArpa/raw-socket-sniffer/blob/master...