Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The C23 edition of Modern C

gustedt.wordpress.com

Post reply on HN
Print view View original

121–130 of 360 posts

Re: The C23 edition of Modern C

#121

Post by MathMonkeyMan »

enriquto wrote: post #85
pjmlp wrote: post #83

Earlier quoted context omitted.

That isn't really how it goes, that is how it used to be up to C99.

Thanks for the correction! Do you know if there is a document from the standards body explaining the change in philosophy?

I've heard something along the lines of "the standard is to define facilities that will be used in most programs, and to codify widespread existing practice." That was in the context of "I don't like this proposed feature," though. This was for C++, not C.

A lot of stuff in the C++11 standard library was based on widespread use of Boost. Since then, I don't know. Also, were things like templates and lambdas implemented as compiler extensions before standardization? I don't know, but I doubt it. Maybe "we're a committee of people who will decide on a thing and we hope you like it" was always the norm in many ways.

Re: The C23 edition of Modern C

#122

Post by wahern »

kbolino wrote: post #97
greyw wrote: post #92

Earlier quoted context omitted.

Unsigned overflow wraps. Signed overflow is undefined behavior.

This distinction does not exist in K&R 2/e which documents ANSI C aka C89, but maybe it was added in a later version of the language (or didn't make it into the book)? According to K&R, all overflow is undefined.

I don't have my copy of K&R handy, but this distinction has existed since the initial codification. From C89:

  3.1.2.5 Types

  [...] A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting unsigned integer type.
Source: C89 (draft) at https://port70.net/~nsz/c/c89/c89-draft.txt

Re: The C23 edition of Modern C

#123

Post by adamrezich »

uecker wrote: post #69
adamrezich wrote: post #28

Earlier quoted context omitted.

Correct, and you did ask specifically for OO things, but I thought I'd list namespaces too as far as “C++ things you might use when writing C-like C++ code”. Another big one that I always forget C still doesn't support is function overloading.

Function overloading is a feature that makes code less self-documenting without providing any meaningful value. Operator overloading is more interesting, because you can build you domain language with nice syntax. But I also tend to think that this is not really worth it.

In C++ where you have methods? Sure. It would be nice to have in C, though. But, alas, ABI compatibility.

Re: The C23 edition of Modern C

#124

Post by tightbookkeeper »

Dwedit wrote: post #109
pjmlp wrote: post #80

Earlier quoted context omitted.

Perfectly iostreams happy user since 1993.

int a; cin >> a; Then the program goes berserk as soon as the first non-number is read out of standard input. All the other "cin >> integer" lines are immediately skipped. Yes, I know about error checking, clearing error condition, discarding characters. But it's a whole lot of stuff you need to do after every single "cin>>" line. It makes the simplicity of cin not worth it.

You’re holding it wrong. Like nan, the point is you don’t have to error check every operation.

You check error for the whole batch.

Re: The C23 edition of Modern C

#125

Post by tightbookkeeper »

pjmlp wrote: post #80
tialaramex wrote: post #63

Earlier quoted context omitted.

The entire I/O streams (where std::cout comes from) feature is garbage, if this was an independent development there is no way that WG21 would have taken it, the reason it's in C++ 98 and thus still here today is that it's Bjarne's baby. The reason not to take it is that it's contradictory to the "Don't use operator overloading for unrelated operations" core idea. Bjarne will insist that "actually" these operators so…

Perfectly iostreams happy user since 1993.

Yep, it’s very clean once you get the hang of it.

Re: The C23 edition of Modern C

#126

Post by tightbookkeeper »

tialaramex wrote: post #63
jasode wrote: post #45

Earlier quoted context omitted.

>Takeaway #1: "C and C++ are different: don’t mix them, and don’t mix them up" Where "mixing C/C++" is helpful: - I "mix C in with my C++" projects because "sqlite3.c" and ffmpeg source code is written C. C++ was designed to interoperate with C code. C++ code can seamlessly add #include "sqlite3.h" unchanged. - For my own code, I take advantage of "C++ being _mostly_ a superset of C" such as using old-style C printf…

The entire I/O streams (where std::cout comes from) feature is garbage, if this was an independent development there is no way that WG21 would have taken it, the reason it's in C++ 98 and thus still here today is that it's Bjarne's baby. The reason not to take it is that it's contradictory to the "Don't use operator overloading for unrelated operations" core idea. Bjarne will insist that "actually" these operators so…

What’s wrong with it?

Re: The C23 edition of Modern C

#127

Post by eMSF »

Dwedit wrote: post #109
pjmlp wrote: post #80

Earlier quoted context omitted.

Perfectly iostreams happy user since 1993.

int a; cin >> a; Then the program goes berserk as soon as the first non-number is read out of standard input. All the other "cin >> integer" lines are immediately skipped. Yes, I know about error checking, clearing error condition, discarding characters. But it's a whole lot of stuff you need to do after every single "cin>>" line. It makes the simplicity of cin not worth it.

How could you ever continue after the second statement without checking if you actually read an integer or not? How would you know what you can do with a?

Re: The C23 edition of Modern C

#128

Post by einpoklum »

pjmlp wrote: post #80
tialaramex wrote: post #63

Earlier quoted context omitted.

The entire I/O streams (where std::cout comes from) feature is garbage, if this was an independent development there is no way that WG21 would have taken it, the reason it's in C++ 98 and thus still here today is that it's Bjarne's baby. The reason not to take it is that it's contradictory to the "Don't use operator overloading for unrelated operations" core idea. Bjarne will insist that "actually" these operators so…

Perfectly iostreams happy user since 1993.

Then I suppose you don't care about:

* Performance

* Support for localization (as the format string and positions of values to format differ between languages).

* Code reuse & dogfooding - the data structures used in iostreams are not used elsewhere, and vice-versa

* C and OS interoperability - as you can't wrap a stream around a FILE* / file descritor

* bunch of other stuff...

iostreams work, but are rather crappy.

Re: The C23 edition of Modern C

#129

Post by tialaramex »

dieortin wrote: post #120
tialaramex wrote: post #63

Earlier quoted context omitted.

The entire I/O streams (where std::cout comes from) feature is garbage, if this was an independent development there is no way that WG21 would have taken it, the reason it's in C++ 98 and thus still here today is that it's Bjarne's baby. The reason not to take it is that it's contradictory to the "Don't use operator overloading for unrelated operations" core idea. Bjarne will insist that "actually" these operators so…

> The biggest problem is that today C++ doesn't have a way to implement this for your own types easily I’m not sure about the stdlib version, but with fmtlib you can easily implement formatters for your own types. https://fmt.dev/11.0/api/#formatting-user-defined-types

I think the problem is that your idea of "easy" is "Here's a whole bunch of C++ you could write by hand for each type" while the comparison was very literally #[derive(Debug)]. I wasn't abbreviating or referring to something else, that's literally what Rust programmers type to indicate that their type should have the obvious boilerplate implementation for this feature, in most types you're deriving other traits already, so the extra work is literally typing out the word Debug.

Re: The C23 edition of Modern C

#130

Post by einpoklum »

It's only been a few years since I've come to feel I can rely on C compilers all supporting C99, for a library I'm maintaing [1]. And after a couple of years, sure enough - I get an issue opened asking for C89 compatibility because of some arcane embedded toolchain or what-not.

So, C23? ... that's nice and all, but, let's talk about it in 20 years or so T_T

[1]: https://github.com/eyalroz/printf

Post reply on HN