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

141–150 of 360 posts

Re: The C23 edition of Modern C

#141

Post by wakawaka28 »

pjmlp wrote: post #132
einpoklum wrote: post #128

Earlier quoted context omitted.

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.

I care about performance, when it actually matters to acceptance testing. The less C the merrier. If you care about correct use of localisation, standard C and C++ libraries aren't really what you're looking for, or even C and C++ to start with.

C and C++ are the bedrock of operating systems with the best performance and extensive support for all languages.

The only reason why iostreams are slow is because of its incompatible buffering scheme, and the fact that C and C++ need to stay in sync when linked together. And that brand of slow is still faster than other languages, except sometimes those that delegate i/o to pure C implementations.

Re: The C23 edition of Modern C

#142

Post by layer8 »

TZubiri wrote: post #138
layer8 wrote: post #104

Earlier quoted context omitted.

Google it.

Yeah, why have any type of human interaction in a forum when you can just refer your fellow brethren to the automaton.

I’m saying this because any explanation I could offer would provide less insight than the Google results.

Re: The C23 edition of Modern C

#143

Post by com2kid »

f1shy wrote: post #14
com2kid wrote: post #11

Earlier quoted context omitted.

Perfectly valid to do if you need to interface with a large C code base and you just want to do some simple OO here and there. Especially if you cannot have runtime exceptions and the like. This is how I managed to sneak C++ into an embedded C codebase. We even created some templates for data structures that supported static allocation at compile time.

What would be an example of "simple OO here and there" that cannot be done cleanly in plain C?

You can do anything in C that you want to. Of course one can make v-tables and all of that, and even do inheritance.

But having the "class" keyword is nice. Having built in support for member functions is nice.

Sometimes a person just wants the simplicity of C++ 2003.

(In reality I was working on a project where our compiler only supported C++ 2003 and we had a UI library written in C++ 2003 and honestly pure C UI libraries kind of suck compared to just sprinkling in a bit of C++ sugar.)

Re: The C23 edition of Modern C

#144

Post by jvanderbot »

eMSF wrote: post #127
Dwedit wrote: post #109

Earlier quoted context omitted.

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?

You couldn't or wouldn't. but why have a read statement like cin>> which looks so nice and clean when you then have to go and check everything with flags and boolean casts on stateful objects.

I agree. It's lunacy. just be explicit and use functions or equivalent like literally every other language.

Re: The C23 edition of Modern C

#145

Post by EasyMark »

zerr wrote: post #48

Do they still use 0-terminated strings/char* as the main string type? Is the usage of single linked lists still prevalent as the main container type?

I don’t think that will ever change. Will the possibly introduce a more modern string2 type? Maybe but it will probably be unlikely before 2050

Re: The C23 edition of Modern C

#146

Post by amomchilov »

russellbeattie wrote: post #98

Wow, the use of attributes like [[__unsequenced__]], [[maybe_unused]] and [[noreturn]] throughout the book is really awful. It seems pretty pedantic of the author to litter all the code examples with something that is mostly optional. For a second I wondered if C23 required them.

Such is the issue with bad defaults. Opting into the sensible thing makes most of your code ugly, instead of just the exceptions.

Re: The C23 edition of Modern C

#148

Post by spacechild1 »

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…

Remember that C++ originally didn't have variadic templates, so something like std::format would have been impossible back in the day. Back in the day, std::iostream was a very neat solution for type safe string formatting. As you conceded, it also makes it very easy to integrate your own types. It was a big improvement over printf(). Historic perspective is everything.

Re: The C23 edition of Modern C

#149

Post by wnoise »

jpcfl wrote: post #8
belter wrote: post #2

Important reminder just in the Preface :-) Takeaway #1: "C and C++ are different: don’t mix them, and don’t mix them up"

Bjarne should have called it ++C.

Nah. It's just the natural semantics -- he added stuff to C, but returned something that wasn't actually more advanced...
Post reply on HN