Hacker News Reader

Comment by stephen82 | Hacker News Reader

Nearly everything that is mentioned in this blog is a subject of change / addition to the latest C standard, code named C2x.

They are in discussions to introduce the following in C:

    * nullptr
    * auto
    * __has_include
    * make false and true first-class language features
    * constexpr

and lots of other goodies [1].

https://gustedt.wordpress.com/2018/11/12/c2x/

View on HN

"Add a type aware print utility with format specification syntax similar to python"

Now thats exciting

does anyone have more information on this? only reference I can find is that blog post; I can't find the specific section of the linked specs that discusses such a utility

__attribute__((format(printf, ...))) makes printf every bit as type-aware as I need it to be. Put that in the standard instead.

Are they trying to make C literally become the same as C++ except classes and templates?

Are classes and templates not the bulwark of what makes C++ C++ though

Well, they are trying to slim down, so to speak, the gap between C and C++ for the sake of a safer interoperability between the languages and for the sake of safer and secure code.

If C could fix _Generic from C11 and make it behave more like a lightweight version of templates, then I could say we have a huge potential of having a safer version of what we currently have.

> Are they trying to make C literally become the same as C++ except classes and templates?

As a C programmer, aren't classes, templates, and exceptions the things that have classically differentiated C and C++?[0] I don't see anything obviously objectionable about nullptr[1], auto, __has_include, or constexpr. (I don't have a ton of experience with them, either.)

I'll admit I don't really grok what "make false and true first-class language features" means — maybe make them reserved keywords? (int)true must still evaluate to 1, in any event.

[0]: "C++ is C with classes!"

[1]: C's "NULL" has this obnoxious wart in that it is implementation-defined whether or not it is a pointer type. I.e., it can be "(void *)0" or just "0". This means that it cannot be used safely in portable incantations of variadic functions that expect pointer arguments.

They're not the "problems" with C++, they're what make C++ great. It's like C is slowly realizing C++ features are actually useful, but doing so as slowly as molasses, while still trying to pretend like this isn't the case...

> [Classes, templates, and exceptions are] not the "problems" with C++, they're what make C++ great.

We're going to have to agree to disagree on that one.

> It's like C is slowly realizing C++ features are actually useful, but doing so as slowly as molasses, while still trying to pretend like this isn't the case...

I think it makes sense to adopt C++ features that do some combination of (1) providing a useful feature, (2) aiding C++ compatibility, and (3) not majorly increasing the conceptual size of the C language. Just like it makes sense for C++ to adopt C99-compatibility (structure literals has taken y'all like 20+ years to adopt).

Templates, classes, and exceptions are a huge huge addition to the complexity of the language. If C programmers wanted them, with all of the pitfalls of manual memory management and C-style lifetime safety, they'd just use C++. Obviously, they don't.

Personally, if I had to choose a language other than C I'd pick something like Zig, Rust, or Go over C++.

C with templates (not classes), STL algorithms/ranges and small things like nullptr, auto, lambdas, stronger basic types, etc is actually a powerful configuration.

Everyone who likes C++ will tell you which parts they like and how powerful they are :-).

> This means that it cannot be used safely in portable incantations of variadic functions that expect pointer arguments.

Why only variadic functions? The answer to that may make my next question obsolete, namely: Wouldn't only C++ complain about this? In C, isn't the input to anything coerced to the data type it will represent, in actual complete disregard of the input type?

For non-variadic functions, the argument is implicitly converted to the parameter type (if possible).

For variadic functions, the compiler doesn't know the parameter type.

So to print a null pointer, you need to do this:

    printf("NULL = %p\n", (void*)NULL);

    printf("null pointer = %p\n", (void*)0);

The %p format requires an argument of type void*, so you have to convert to that type if necessary.

In a fixadic function the integer literal would be promoted to a pointer, because the caller knows that the argument should be a pointer. In a variadic function call, the caller guesses the type of each argument based on what is passed. A variadic function needs to know exactly the size of its arguments and sizeof(int) != sizeof(pointer) on many systems.

This works:

    void f(char *p);
    
         f(0); /* integer literal auto promoted to pointer */

This probably doesn't, at least not as the number of arguments to f is increased:

    void f(...);
    
         f(0); /* assume type of function is void f(int) */

colonwqbang hit the nail on the head.

For non-variadic functions, the function declaration provides the correct parameter type, and caller arguments are coerced to the correct type.

> In C, isn't the input to anything coerced to the data type it will represent, in actual complete disregard of the input type?

In short: no. Implicit casts between incompatible types are warnings/errors.

> aren't classes, templates, and exceptions the things that have classically differentiated C and C++?

The key difference is the destructor. Classes, templates, and exceptions extend the reach and value of the destructor. Absent the destructor, the other stuff is of little value (cf. Java).

I do not really care about new features to C - I would just use C++ for these features - but what is your specific argument against something like auto? Or just in general on new features.

Reply on news.ycombinator.com