6

New C features in GCC 13 (Red Hat Developer)

 1 year ago
source link: https://lwn.net/Articles/930899/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

New C features in GCC 13 (Red Hat Developer)

[Posted May 4, 2023 by corbet]
The Red Hat Developer site has an overview of some of the new C-language features supported by the GCC 13 release.
The nullptr constant first appeared in C++11, described in proposal N2431 from 2007. Its purpose was to alleviate the problems with the definition of NULL, which can be defined in a variety of ways: (void *)0 (a pointer constant), 0 (an integer), and so on. This posed problems for overload resolution, generic programming, etc. While C doesn’t have function overloading, the protean definition of NULL still causes headaches.

(Log in to post comments)

New C features in GCC 13 (Red Hat Developer)

Posted May 4, 2023 19:31 UTC (Thu) by bartoc (subscriber, #124262) [Link]

Nullptr is probably the least exciting new feature mentioned! Also included is "auto" (which works like the existing __auto_type), explicit types for enumerations, and constexpr.

New C features in GCC 13 (Red Hat Developer)

Posted May 4, 2023 19:48 UTC (Thu) by kreijack (guest, #43513) [Link]

I agree, 'auto' is one of the more interesting new feature.

Another interesting thing that I hope to be standardized is the GCC[*] __attribute__((cleanup)) will be standardized (with a better syntax).

[*] However IIRC also clang has the same attribute.

New C features in GCC 13 (Red Hat Developer)

Posted May 4, 2023 19:56 UTC (Thu) by mpolacek (subscriber, #66426) [Link]

There actually is a proposal for a feature along the lines of __attribute__((cleanup)): N2895.

New C features in GCC 13 (Red Hat Developer)

Posted May 4, 2023 21:04 UTC (Thu) by mss (subscriber, #138799) [Link]

There actually is a proposal for a feature along the lines of __attribute__((cleanup))
Shame that the defer feature didn't make C23 - neither did its dependency of lambda functions.

While having lambda functions support in the language just save some typing when implementing callbacks, having the defer feature would allow implementing pseudo-RAII in a standard complaint way - so it would be an important improvement.

Without that standard support current implementations, like Glib's g_autoptr(), have to resort to per-compiler extensions like the aforementioned GCC's attribute.


In general, I think it's very good that, as the article says, these proposals align the C and C++ languages a little bit closer to each other by entwining certain features, and make programming in C easier and more secure.

New C features in GCC 13 (Red Hat Developer)

Posted May 5, 2023 4:09 UTC (Fri) by alison (subscriber, #63752) [Link]

> having the defer feature would allow implementing pseudo-RAII in a standard complaint way - so it would be an important improvement.

CppCast Episode 297 had a great interview with JeanHeyd Meneide called "Defer is better than destructors" in which they wax eloquent on this topic. Meneide also says that defer and lambdas would make writing a C container library possible.

New C features in GCC 13 (Red Hat Developer)

Posted May 4, 2023 21:13 UTC (Thu) by atai (subscriber, #10977) [Link]

C++ like "auto" in C?

New C features in GCC 13 (Red Hat Developer)

Posted May 5, 2023 9:24 UTC (Fri) by ballombe (subscriber, #9523) [Link]

On the other the addition of new keywords is very worrying. This will cause code to fail to compile.
This will cause macros to produce unintended behavior.
It is way too late to make this kind of change to the language.

New C features in GCC 13 (Red Hat Developer)

Posted May 4, 2023 21:45 UTC (Thu) by ceplm (subscriber, #41334) [Link]

> Consider the following:
>
> enum F : int { A = 0x8000 } f;
>
> […] Thus a better variant would be to use one of the types defined in <stdint.h>, for example:
>
> enum F : int_least32_t { A = 0x8000 } f;

I am just a stupid Pythonista, but is there anybody really who would willingly routinely use types like “int_least32_t”?

Beautiful is better than ugly!

New C features in GCC 13 (Red Hat Developer)

Posted May 5, 2023 0:56 UTC (Fri) by branden (guest, #7029) [Link]

Explicit is better than implicit.

With a plain "int" you get an integer of whatever size the platform feels like providing. Is it a fast int? Is it a small int? Undefined.

New C features in GCC 13 (Red Hat Developer)

Posted May 5, 2023 6:56 UTC (Fri) by mb (subscriber, #50428) [Link]

It's certainly not undefined.
And the fast/least types are BS. Sprinkling the code with ugly fast-types doesn't make it any faster. It just increases the likelihood of subtle bugs due to actual type size differences between platforms.
Just use fixed types like uint32_t.

New C features in GCC 13 (Red Hat Developer)

Posted May 5, 2023 9:35 UTC (Fri) by ballombe (subscriber, #9523) [Link]

Except there is no libc support for it (no int32abs() , no support in printf etc.) so it is difficult to use correctly.

New C features in GCC 13 (Red Hat Developer)

Posted May 5, 2023 10:03 UTC (Fri) by adobriyan (subscriber, #30858) [Link]

printf support exists with PRIu32 macros etc

New C features in GCC 13 (Red Hat Developer)

Posted May 5, 2023 10:05 UTC (Fri) by hkario (subscriber, #94864) [Link]

there is support for uint32_t in both printf and sscanf, it's just fugly

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK