4 ms·

Why "bullshit"? I looked at the article, and everything looks extremely reasonable, and desirable in C. * nullptr: fixes problems with eg, va_arg * better enu

Why "bullshit"? I looked at the article, and everything looks extremely reasonable, and desirable in C. * nullptr: fixes problems with eg, va_arg * better enums: Who doesn't want that? C is a systems language, dealing with stuff like file formats, no? So why shouldn't it be comfortable to define an enum of the right type? * constexpr is good, an improvement on the macro hell some projects have * unprototyped functions removed: FINALLY! That's a glaring source of security issues. Really I don't see what's there to complain about, all good stuff.

oblio 3y ago
> Really I don't see what's there to complain about, all good stuff. It's called "change" and people don't like it.
hgs3 3y ago
> nullptr: fixes problems with eg, va_arg nullptr is an overkill solution. The ambiguity could have been solved by mandating that NULL be defined as (void*)0 rather than giving implementations the choice of (void*)0 or 0.
- zajio1am 3y ago
  Are there any mainstream implementation where NULL is not typed as (void *)? That seems like a choice that would cause so many problems (type warnings, va_arg issues), i wonder why would anyone do that.
  - peterfirefly 3y ago
    Vintage code or code written by vintage coders. Code written by C++ programmers. Code written to be both C and C++.
  - ori_b 3y ago
    No.
- peterfirefly 3y ago
  That would have been my preference as well. Either force it to be (void*)0 or, maybe, allow it to be 0 iff it has the same size and parameter passing method.
- cremno 3y ago
  dmr would've approved of going a step further - only nullptr, no 0 and (void*)0: >Although it would have been a bit of a pain to adapt, >an '89 or '99 standard in which the only source representation >of the null pointer was NULL or nil or some other built-in token >would have had my approval. https://groups.google.com/g/comp.std.c/c/fh4xKnWOQuo/m/IAaOe1elOx4J https://groups.google.com/g/comp.std.c/c/fh4xKnWOQuo/m/IAaOe...
peterfirefly 3y ago
constexpr is also ridiculously simple to implement -- because the existing compilers already do something similar internally for all enumeration constants. (Enumeration constants are the identifiers defined inside enum xxx {...})
- flohofwoe 3y ago
  ...and most compilers also already silently treat compile time constant expressions like constexpr, an explicit constexpr just throws an error if the expression isn't actually a compile time constant.
kats 3y ago
It has a lot of costs to add to the C language, even if it's just the increased complexity in the documentation, and doesn't effect c99. Every processor, OS, programming language needs used in business needs to fully support a C standard. So adding to C effects every processor and computer architecture, every new OS, every new language. If you look at CPPreference you can see how much complexity has been added to the C standard in the last few years.
- dale_glass 3y ago
  What do those have to do with that? A processor has no need to know anything about constexpr, auto, or static_assert. In fact I don't see anything that needs support anywhere but the actual compiler.
quelsolaar 3y ago
constexpr is terrible. -constexpr is not anything like constexpr in C++. -It makes no guarantees about anything being compile time. -It in no way reflects the ability of the compiler to make something compile time. -It adds implementation burden by forcing the implementations to issue errors that do not reflect any real information. (For instance you may get an error saying your constexpr isnt a constant expression, but if you remove the constexpr qualifier, then the compiler can happily solve it as a constant expression) -All kinds of floating point issues. We should not have admitted this in to the standard, please do not use. nullptr is the third definition of null. one should be enough, two was bad. why three?
- dale_glass 3y ago
  Well, that's interesting. Got any more information on that? Why does it fail in that way? Is that an implementation or a specification problem?
  - quelsolaar 3y ago
    Im in the WG14 so ive been involved in the discussions. It fails for 2 reasons: In order to make it easy to implement it had to be made so limited, that it in no way useful. The second reason, and the real killer, is the "as if" rule. It states that any implementation can do what ever it wants, as long as the output of the application is the same. This means that how a compiler goes about implementing something is entirely up to the compiler. This means that any expression can be compile or execution time. You can even run the pre-processor at run time if you like! This enables all kinds of optimizations. In reality, modern compilers like gcc, llvm and MSVC are far better at optimizing than what constexpr permits. However since the specification specifies exactly what can be in a constexpr, the implementations are required to issue an error if a constexpr does something beyond this.
    - dale_glass 3y ago
      Okay, so that's a good start, but I still don't get it. > In order to make it easy to implement it had to be made so limited, that it in no way useful. Such as? > The second reason, and the real killer, is the "as if" rule. Why is that a problem? It sounds like a benefit. It means that the optimization can't break anything, which to me is kind of the point.

oblio 3y ago

> Really I don't see what's there to complain about, all good stuff. It's called "change" and people don't like it.

hgs3 3y ago

> nullptr: fixes problems with eg, va_arg nullptr is an overkill solution. The ambiguity could have been solved by mandating that NULL be defined as (void*)0 rather than giving implementations the choice of (void*)0 or 0.

zajio1am 3y ago
Are there any mainstream implementation where NULL is not typed as (void *)? That seems like a choice that would cause so many problems (type warnings, va_arg issues), i wonder why would anyone do that.
- peterfirefly 3y ago
  Vintage code or code written by vintage coders. Code written by C++ programmers. Code written to be both C and C++.
- ori_b 3y ago
  No.
peterfirefly 3y ago
That would have been my preference as well. Either force it to be (void*)0 or, maybe, allow it to be 0 iff it has the same size and parameter passing method.
cremno 3y ago
dmr would've approved of going a step further - only nullptr, no 0 and (void*)0: >Although it would have been a bit of a pain to adapt, >an '89 or '99 standard in which the only source representation >of the null pointer was NULL or nil or some other built-in token >would have had my approval. https://groups.google.com/g/comp.std.c/c/fh4xKnWOQuo/m/IAaOe1elOx4J https://groups.google.com/g/comp.std.c/c/fh4xKnWOQuo/m/IAaOe...

peterfirefly 3y ago

constexpr is also ridiculously simple to implement -- because the existing compilers already do something similar internally for all enumeration constants. (Enumeration constants are the identifiers defined inside enum xxx {...})

flohofwoe 3y ago
...and most compilers also already silently treat compile time constant expressions like constexpr, an explicit constexpr just throws an error if the expression isn't actually a compile time constant.

kats 3y ago

It has a lot of costs to add to the C language, even if it's just the increased complexity in the documentation, and doesn't effect c99. Every processor, OS, programming language needs used in business needs to fully support a C standard. So adding to C effects every processor and computer architecture, every new OS, every new language. If you look at CPPreference you can see how much complexity has been added to the C standard in the last few years.

dale_glass 3y ago
What do those have to do with that? A processor has no need to know anything about constexpr, auto, or static_assert. In fact I don't see anything that needs support anywhere but the actual compiler.

quelsolaar 3y ago

constexpr is terrible. -constexpr is not anything like constexpr in C++. -It makes no guarantees about anything being compile time. -It in no way reflects the ability of the compiler to make something compile time. -It adds implementation burden by forcing the implementations to issue errors that do not reflect any real information. (For instance you may get an error saying your constexpr isnt a constant expression, but if you remove the constexpr qualifier, then the compiler can happily solve it as a constant expression) -All kinds of floating point issues. We should not have admitted this in to the standard, please do not use. nullptr is the third definition of null. one should be enough, two was bad. why three?

dale_glass 3y ago
Well, that's interesting. Got any more information on that? Why does it fail in that way? Is that an implementation or a specification problem?
- quelsolaar 3y ago
  Im in the WG14 so ive been involved in the discussions. It fails for 2 reasons: In order to make it easy to implement it had to be made so limited, that it in no way useful. The second reason, and the real killer, is the "as if" rule. It states that any implementation can do what ever it wants, as long as the output of the application is the same. This means that how a compiler goes about implementing something is entirely up to the compiler. This means that any expression can be compile or execution time. You can even run the pre-processor at run time if you like! This enables all kinds of optimizations. In reality, modern compilers like gcc, llvm and MSVC are far better at optimizing than what constexpr permits. However since the specification specifies exactly what can be in a constexpr, the implementations are required to issue an error if a constexpr does something beyond this.
  - dale_glass 3y ago
    Okay, so that's a good start, but I still don't get it. > In order to make it easy to implement it had to be made so limited, that it in no way useful. Such as? > The second reason, and the real killer, is the "as if" rule. Why is that a problem? It sounds like a benefit. It means that the optimization can't break anything, which to me is kind of the point.