5 ms·

There might be some merit to this. If you want a language that is very portable and has a definition that is compact enough to be fully understood both by you

by dsrguru 14y ago

There might be some merit to this. If you want a language that is very portable and has a definition that is compact enough to be fully understood both by you and by programs you might write that operate on source code (static analyzers, interpreters, compilers, etc.), you are probably going to use C89/90 instead of C99 (at least that seems to be what K&R felt--and what K still feels). Otherwise, what advantages do you have in going with pure C99 over the C99 almost subset of ISO C++? Even if you don't really use any language features unique to C++, you would still get some safer library functions and better portability than you would if you limited yourself to the C99 standard.

TazeTSchnitzel 14y ago
These are my feelings too. C++ is not supposed to be object-oriented C, rather, it is supposed to be an improved C with more features, one being language support for OOP. You might as well just use C++.
- tmhedberg 14y ago
  Perhaps C++ is mostly a superset of C in a technical sense, but in practice, it comes with its own idioms, its own conventions, its own design patterns, and its own culture, all very distinct from those of C. There's far more to consider when selecting a programming language beyond "Does Language X have a superset of the features of Language Y?". Plus, sometimes having fewer features is itself a feature. I would say that this is especially true when comparing the slim, minimal design of C with the "everything and the kitchen sink" approach of C++. Not that C++ is never useful in its own right, but that doesn't mean its appropriateness for a given task is always greater than or equal to that of C.
  - TazeTSchnitzel 14y ago
    With C99 and C11 though, C is becoming larger and less minimal. I'm not sure that argument still applies.
- derleth 14y ago
  > an improved C with more features This mostly means it's incompatible with C even in the parts of the language both of them share. Completely valid and idiomatic C code will therefore not always compile if you use a C++ compiler.
tjr 14y ago
In avionics development, having a compiler certified for production use is a big (expensive) deal. Accordingly, you'll still find avionics people using C89 if for no other reason than because they certified a C89 compiler years ago and it still works.
comex 14y ago
If MSVC supported C99, it would be portable enough for the three major platforms plus all the ports of GCC and any analyzers written for Clang/LLVM. What do you get versus C++? Implicit casting of void *, so you don't have to repeat yourself every time you use malloc, restrict, structure literals, faster compilation (yes, the same code compiles faster in C mode than C++ mode, at least in gcc), not having to remember slightly different rules about scoping, ...
- comex 14y ago
  Self-reply: That's only C99, by the way. Compared to C++11, C11 adds anonymous structs, and incompatible handling of atomics, noreturn, and even generics.
- dsrguru 14y ago
  What do you typically use in C99 that you don't get in C89?
  - oconnore 14y ago
    'for' loops
  - _delirium 14y ago
    A few things I like, though not all of them are strictly needed: long long foo; /* bigger ints on 32-bit platforms */ uint32_t bar; /* stdint.h, integers of specific bit width */ int array[n]; /* length-n array, where n is a variable */ for (int i = 0; i < n; i++) /* loop-local variable */ Also, the safer stdio functions like snprintf.
    - yuhong 14y ago
      Some of them are already in MSVC.
  - stephencanon 14y ago
    Off the top of my head, C99 features that I've used in the past couple months: - declarations mixed with statements - declarations in `for` constructs - hexadecimal floating-point literals and conversion specifiers - the strtoxx( ) conversion routines - the restrict qualifier - the expanded math library - designated initializers - extended integer types - compound literals - // comments - VLAs - complex support Note that some of these features are still not present in C++11. C11 features that I have used in the past few months: - CMPLX macros - anonymous structures and unions - <stdalign.h>
haberman 14y ago
> If you want a language that is very portable and has a definition that is compact enough to be fully understood both by you and by programs you might write that operate on source code (static analyzers, interpreters, compilers, etc.), you are probably going to use C89/90 instead of C99 C99 has some very hard-to-replicate features; most notably designated initializers. Without them, you cannot statically initialize any union member except the first. This is a significant problem for me. C99 is mostly supported by every C compiler I am aware of except MSVC, so it would be portable if not for Microsoft. > Even if you don't really use any language features unique to C++, you would still get some safer library functions and better portability than you would if you limited yourself to the C99 standard. C++ is not available in the Linux kernel, it mangles names, and it's tricky to be disciplined enough to write in a C++ subset without letting C++ features creep in, especially on a multi-person project. Once you let C++ features creep in you can inadvertently end up with runtime static initializers, type_info symbols, exception unwinding code and debugging symbols, etc. My current compromise is to compile as C99 everywhere except on MSVC, where I will compile as C++ and use C++ alternatives to features like designated initializers.
- chocolatebunny 14y ago
  What's the C++ alternative to designated initializers?
  - stephencanon 14y ago
    Constructors, I would assume, but that's not a very attractive alternative in my opinion.
  - haberman 14y ago
    With C++11, you can use constexpr constructors to guarantee that they run at compile-time and end up as flat data in the .data/.rodata section instead of run-time static initialization. Or so I'm told by the C++11 people I asked about it.
EvilTerran 14y ago
C++'s name mangling feels like a dealbreaker to me; it really hurts interoperability with other languages. In general, C feels well-suited to be the language that (almost) every other language can talk to; C++ just doesn't fit that role so well.
- Erwin 14y ago
  You can explicitly export functions you want available outside, disabling the name mangling (using export "C"). I'm not sure how else you think C++ could handle its goals without the name mangling: overloading and compatibility with C's linker system. If you have two overloaded "foo" functions you need to somehow designated them as separate linker symbols. C has similar problems of its own: like what's the calling convention for the exported symbol? Do I push the arguments on the stack, and who cleans up? Do some arguments go into registered? Where does the return value go? What's the layout of a struct? All things are platform, compiler and compiler configuration dependent. What other languages, that compile to object files or shared objects, that support the level of OO features etc. that C++ has, have a well-defined ABI?

by dsrguru 14y ago

TazeTSchnitzel 14y ago

These are my feelings too. C++ is not supposed to be object-oriented C, rather, it is supposed to be an improved C with more features, one being language support for OOP. You might as well just use C++.

tmhedberg 14y ago
Perhaps C++ is mostly a superset of C in a technical sense, but in practice, it comes with its own idioms, its own conventions, its own design patterns, and its own culture, all very distinct from those of C. There's far more to consider when selecting a programming language beyond "Does Language X have a superset of the features of Language Y?". Plus, sometimes having fewer features is itself a feature. I would say that this is especially true when comparing the slim, minimal design of C with the "everything and the kitchen sink" approach of C++. Not that C++ is never useful in its own right, but that doesn't mean its appropriateness for a given task is always greater than or equal to that of C.
- TazeTSchnitzel 14y ago
  With C99 and C11 though, C is becoming larger and less minimal. I'm not sure that argument still applies.
derleth 14y ago
> an improved C with more features This mostly means it's incompatible with C even in the parts of the language both of them share. Completely valid and idiomatic C code will therefore not always compile if you use a C++ compiler.

tjr 14y ago

In avionics development, having a compiler certified for production use is a big (expensive) deal. Accordingly, you'll still find avionics people using C89 if for no other reason than because they certified a C89 compiler years ago and it still works.

comex 14y ago

If MSVC supported C99, it would be portable enough for the three major platforms plus all the ports of GCC and any analyzers written for Clang/LLVM. What do you get versus C++? Implicit casting of void *, so you don't have to repeat yourself every time you use malloc, restrict, structure literals, faster compilation (yes, the same code compiles faster in C mode than C++ mode, at least in gcc), not having to remember slightly different rules about scoping, ...

comex 14y ago
Self-reply: That's only C99, by the way. Compared to C++11, C11 adds anonymous structs, and incompatible handling of atomics, noreturn, and even generics.
dsrguru 14y ago
What do you typically use in C99 that you don't get in C89?
- oconnore 14y ago
  'for' loops
- _delirium 14y ago
  A few things I like, though not all of them are strictly needed: long long foo; /* bigger ints on 32-bit platforms */ uint32_t bar; /* stdint.h, integers of specific bit width */ int array[n]; /* length-n array, where n is a variable */ for (int i = 0; i < n; i++) /* loop-local variable */ Also, the safer stdio functions like snprintf.
  - yuhong 14y ago
    Some of them are already in MSVC.
- stephencanon 14y ago
  Off the top of my head, C99 features that I've used in the past couple months: - declarations mixed with statements - declarations in `for` constructs - hexadecimal floating-point literals and conversion specifiers - the strtoxx( ) conversion routines - the restrict qualifier - the expanded math library - designated initializers - extended integer types - compound literals - // comments - VLAs - complex support Note that some of these features are still not present in C++11. C11 features that I have used in the past few months: - CMPLX macros - anonymous structures and unions - <stdalign.h>

haberman 14y ago

> If you want a language that is very portable and has a definition that is compact enough to be fully understood both by you and by programs you might write that operate on source code (static analyzers, interpreters, compilers, etc.), you are probably going to use C89/90 instead of C99 C99 has some very hard-to-replicate features; most notably designated initializers. Without them, you cannot statically initialize any union member except the first. This is a significant problem for me. C99 is mostly supported by every C compiler I am aware of except MSVC, so it would be portable if not for Microsoft. > Even if you don't really use any language features unique to C++, you would still get some safer library functions and better portability than you would if you limited yourself to the C99 standard. C++ is not available in the Linux kernel, it mangles names, and it's tricky to be disciplined enough to write in a C++ subset without letting C++ features creep in, especially on a multi-person project. Once you let C++ features creep in you can inadvertently end up with runtime static initializers, type_info symbols, exception unwinding code and debugging symbols, etc. My current compromise is to compile as C99 everywhere except on MSVC, where I will compile as C++ and use C++ alternatives to features like designated initializers.

chocolatebunny 14y ago
What's the C++ alternative to designated initializers?
- stephencanon 14y ago
  Constructors, I would assume, but that's not a very attractive alternative in my opinion.
- haberman 14y ago
  With C++11, you can use constexpr constructors to guarantee that they run at compile-time and end up as flat data in the .data/.rodata section instead of run-time static initialization. Or so I'm told by the C++11 people I asked about it.

EvilTerran 14y ago

C++'s name mangling feels like a dealbreaker to me; it really hurts interoperability with other languages. In general, C feels well-suited to be the language that (almost) every other language can talk to; C++ just doesn't fit that role so well.

Erwin 14y ago
You can explicitly export functions you want available outside, disabling the name mangling (using export "C"). I'm not sure how else you think C++ could handle its goals without the name mangling: overloading and compatibility with C's linker system. If you have two overloaded "foo" functions you need to somehow designated them as separate linker symbols. C has similar problems of its own: like what's the calling convention for the exported symbol? Do I push the arguments on the stack, and who cleans up? Do some arguments go into registered? Where does the return value go? What's the layout of a struct? All things are platform, compiler and compiler configuration dependent. What other languages, that compile to object files or shared objects, that support the level of OO features etc. that C++ has, have a well-defined ABI?