4 ms·

> a simple statement like `a = b++;` can mean multiple constructors being called, hidden allocations, unexpected exceptions [...] Yes, nothing like that is pos

> a simple statement like `a = b++;` can mean multiple constructors being called, hidden allocations, unexpected exceptions [...] Yes, nothing like that is possible in C https://godbolt.org/z/Ge4EqzznT https://godbolt.org/z/Ge4EqzznT

jay-barronville 2y ago
Haha. You can’t be serious—what’s the likelihood of running into C code like this in anything remotely serious (compared to the millions upon millions of lines of innocent-looking C++ code that does like a dozen different things under the hood)?
- gpderetta 2y ago
  No true Scotsman. I assume you haven't looked at the expansion of errno lately? edit: also https://github.com/KxSystems/kdb/blob/master/c/c/k.h https://github.com/KxSystems/kdb/blob/master/c/c/k.h
quietbritishjim 2y ago
The difference is that in C++ it's expected that you'll overload operators, provide implicit conversions and throw exceptions. Of course you can write terrible code in C but it is not common accepted practice to hide a longjmp in a macro disguised as an identifier.
- gpderetta 2y ago
  pthread_cleanup_{push,pop}
- jay-barronville 2y ago
  The funny thing is, examples of macro craziness only strengthen my point, because C++ inherits all of that in addition to its hidden behaviors and magical semantics. It’s rare to find serious C code doing a lot of crazy things behind macros. In my experience, the few exceptions I can think of include the GMP library and data structure-related code trying to emulate generics (mostly hash tables).
  - gpderetta 2y ago
    Yes, C++ is a larger language for sure. But because it has better abstraction facilities, macro hackery is less common.
- pjmlp 2y ago
  Indeed, you hide longjump in a #define macro instead, with a do while block trick.
fargle 2y ago
that's a deliberately unfair comparison. operator overloading, constructors, assignments, etc. happen "under-the-hood" in c++ and are standard language features. whereas you can see the user-defined macro definition of "b" at the top of the file. you can't blame the c language for someone choosing to write something like that. sure it's possible, but its your choice and responsibility if you do stupid things like this example.
- gpderetta 2y ago
  Macros are also standard C features, and good luck figuring out that an identifier is a macro without IDE help when the definition is buried in some header.
  - fargle 2y ago
    what you say is partially true (you can also of course use -E to check macros) but: - macros are also standard C++ features too, so this point doesn't differentiate between those languages - i'm failing to adequately communicate my point. there's a fundamental difference practically and philosophically between macro stupidity and C++ doing things under-the-hood. of course a user (you, a co-developer, a library author you trusted) can do all sorts of stupid things. but it's visible and it's written in the target language - not hard-coded in the compiler. yes - sure, good luck finding the land-mine "b" macro if it was well buried. but you can find it and when you do find it, you can see what it was doing. you can #undef it. you can write your own version that isn't screwed up, etc. you can do none of those things for operations in c++ that occur automatically - you can't even see them except in assembly.
    - gpderetta 2y ago
      > there's a fundamental difference practically and philosophically between macro stupidity and C++ doing things under-the-hood. of course a user (you, a co-developer, a library author you trusted) can do all sorts of stupid things. but it's visible and it's written in the target language - not hard-coded in the compiler I specifically reject this. Constructors, exceptions, and so on are as similarly visible at the source level as macro definitions. And thanks to macros, signal handling, setjmp, instrumentation, hardening, dynamic .so resolution, compilers replacing what look like primitive accesses with library functions, any naïve read of C code, is, well, naïve. I'm not claiming C++ superiority here [1], I'm trying to dispel the notion that C is qualitatively different from C++ form a WYSIWYG point of view, both theoretically and in practice. [1]although as I mentioned else, other C++ features means that macros see less use.

jay-barronville 2y ago

Haha. You can’t be serious—what’s the likelihood of running into C code like this in anything remotely serious (compared to the millions upon millions of lines of innocent-looking C++ code that does like a dozen different things under the hood)?

gpderetta 2y ago
No true Scotsman. I assume you haven't looked at the expansion of errno lately? edit: also https://github.com/KxSystems/kdb/blob/master/c/c/k.h https://github.com/KxSystems/kdb/blob/master/c/c/k.h

quietbritishjim 2y ago

The difference is that in C++ it's expected that you'll overload operators, provide implicit conversions and throw exceptions. Of course you can write terrible code in C but it is not common accepted practice to hide a longjmp in a macro disguised as an identifier.

gpderetta 2y ago
pthread_cleanup_{push,pop}
jay-barronville 2y ago
The funny thing is, examples of macro craziness only strengthen my point, because C++ inherits all of that in addition to its hidden behaviors and magical semantics. It’s rare to find serious C code doing a lot of crazy things behind macros. In my experience, the few exceptions I can think of include the GMP library and data structure-related code trying to emulate generics (mostly hash tables).
- gpderetta 2y ago
  Yes, C++ is a larger language for sure. But because it has better abstraction facilities, macro hackery is less common.
pjmlp 2y ago
Indeed, you hide longjump in a #define macro instead, with a do while block trick.

fargle 2y ago

that's a deliberately unfair comparison. operator overloading, constructors, assignments, etc. happen "under-the-hood" in c++ and are standard language features. whereas you can see the user-defined macro definition of "b" at the top of the file. you can't blame the c language for someone choosing to write something like that. sure it's possible, but its your choice and responsibility if you do stupid things like this example.

gpderetta 2y ago
Macros are also standard C features, and good luck figuring out that an identifier is a macro without IDE help when the definition is buried in some header.
- fargle 2y ago
  what you say is partially true (you can also of course use -E to check macros) but: - macros are also standard C++ features too, so this point doesn't differentiate between those languages - i'm failing to adequately communicate my point. there's a fundamental difference practically and philosophically between macro stupidity and C++ doing things under-the-hood. of course a user (you, a co-developer, a library author you trusted) can do all sorts of stupid things. but it's visible and it's written in the target language - not hard-coded in the compiler. yes - sure, good luck finding the land-mine "b" macro if it was well buried. but you can find it and when you do find it, you can see what it was doing. you can #undef it. you can write your own version that isn't screwed up, etc. you can do none of those things for operations in c++ that occur automatically - you can't even see them except in assembly.
  - gpderetta 2y ago
    > there's a fundamental difference practically and philosophically between macro stupidity and C++ doing things under-the-hood. of course a user (you, a co-developer, a library author you trusted) can do all sorts of stupid things. but it's visible and it's written in the target language - not hard-coded in the compiler I specifically reject this. Constructors, exceptions, and so on are as similarly visible at the source level as macro definitions. And thanks to macros, signal handling, setjmp, instrumentation, hardening, dynamic .so resolution, compilers replacing what look like primitive accesses with library functions, any naïve read of C code, is, well, naïve. I'm not claiming C++ superiority here [1], I'm trying to dispel the notion that C is qualitatively different from C++ form a WYSIWYG point of view, both theoretically and in practice. [1]although as I mentioned else, other C++ features means that macros see less use.