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

341–350 of 360 posts

Re: The C23 edition of Modern C

#341

Post by int_19h »

RantyDave wrote: post #326

Wait, C programmers now put the star on the left hand side? char* thing; // good char *thing; // bad This ... is awesome. As a C++ "native" I've always found the "star on the right" thing to be really horribly confusing.

Given that putting it on the right reflects the actual syntax tree of the code, why do you find it "horribly confusing"?

I mean, one can reasonably argue that C & C++ declarator syntax is itself horribly confusing because it doesn't read left-to-right. But it is what it is, so why pretend that it's something else?

Re: The C23 edition of Modern C

#342

Post by int_19h »

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…

Sather (1991) used operator overloading for output. And, even more hilariously, they overloaded + in the same way as C++ overloaded 
   #OUT + "Hello, " + name + "!";

Re: The C23 edition of Modern C

#343

Post by int_19h »

chipdart wrote: post #249
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 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. I think this is a very lazy and somewhat conspiratorial take. C++'s IO stream library, along with C++'s adoption of std::string, is a response to and improvement over C's standard…

The problem is precisely that C++ iostream library was, in practice, not an improvement on C stdio in many ways. Some of us were actually there 30 years ago, and even right after C++98 was standardized, it was pretty common for (then-)modern C++ projects to adopt all of stdlib except for iostreams (and locales/facets, another horrible wart).

Re: The C23 edition of Modern C

#344

Post by int_19h »

uecker wrote: post #67
int_19h wrote: post #36

Earlier quoted context omitted.

You can handcode vtables in C, just as you can handcode loops in assembly (i.e. it works but it's verbose, not particularly readable, and brings more footguns). But why would you do that if you have an instrument that lets you work at the same level as C, but with methods provided as a proper abstraction that maps exactly to what you'd have written yourself anyway?

I don't know, I never found the "proper abstraction" be more than irrelevant syntactic sugar. And the cost of C++ is that you end up putting everything in the header (IMHO the biggest design flaw of the language) and then compile time start to get long....

At the very least, the proper abstraction is the one that guarantees that you pass the same pointer as the first argument of the method call as the one you used to read the vtable from.

And no, you don't have to put everything in the header with C++, and especially not if you're using it in "C with classes" mode. C++ only needs it for templates - and even then only if you want to use implicit instantiation, with `extern template` available for fine-grained control allowing you to have those specializations separately compiled and implementations kept out of the header file.

Re: The C23 edition of Modern C

#345

Post by int_19h »

tjoff wrote: post #107
kccqzy wrote: post #70

Earlier quoted context omitted.

There are a lot of large C++ shops that purposefully disable exceptions and yet still use RAII usefully. It's so useful that in many C codebases you see people using RAII. For example Gtk has g_autoptr and g_autofree. One of the most compelling things C++ offers to embedded use case is moving runtime initialization to compile-time initialization by liberally using constexpr functions. You literally ask the compiler t…

RAII is useful without exceptions yes. I guess it is the other way around. Exceptions are not useful without RAII (sorry not sorry most garbage collected languages ;)). But without exceptions it is mostly syntactic sugar anyway. If compile time initialization is the most compelling usecase I'll rest my case. Good feature, yes! Hardly worth switching language for.

It's very useful syntactic sugar, though.

Re: The C23 edition of Modern C

#346

Post by int_19h »

wang_li wrote: post #296
spc476 wrote: post #184

Earlier quoted context omitted.

Some idiomatic C code to copy a string (I'm not saying this is good C code, but it's just an example): while(*d++ = *s++) ; On the Motorola 68000 (based somewhat on the PDP-11) the code would look like: loop: move.b (a0)+,d0 move.b d0,(a1)+ bne loop while on the x86 line, it would be: loop: mov al,[rsi] mov [rdi],al inc rsi ; extra instruction! inc rdi ; extra instruction! cmp al,0 jne loop Yes, there are better ways…

> loop: move.b (a0)+,d0 move.b d0,(a1)+ ... > loop: mov al,[rsi] mov [rdi],al This hurts my brain. When we invent time machines I'm going to use it to go back and slap whoever at intel came up with that operand order.

memcpy etc also take the destination as their first argument, and it mirrors the usual way we write assignments. Personally I always found Intel syntax to be more straightforward, but I think it's ultimately down to whatever one was exposed to first.

I wonder sometimes why we keep insisting on the "OP ARG, ARG" format in general for assembly. Why not something like `MOV X -> Y` that would make it absolutely clear and unambiguous? For that matter, why not `COPY X -> Y`, since that's what it actually does?

Re: The C23 edition of Modern C

#347

Post by int_19h »

tialaramex wrote: post #40
card_zero wrote: post #27

Earlier quoted context omitted.

Because people choose to use pre-increment by default instead of post-increment? Why is that?

Why use this operator? Like most C and C++ features the main reason tends to be showing off, you learned a thing (in this case that there are four extra operators here) and so you show off by using it even if it doesn't make the software easier to understand. This is not one of those beginner -> journeyman -> expert cycles where coincidentally the way you wrote it as a beginner is identical to how an expert writes it…

For iterators, += may not even be available.

Re: The C23 edition of Modern C

#348

Post by tialaramex »

int_19h wrote: post #342
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…

Sather (1991) used operator overloading for output. And, even more hilariously, they overloaded + in the same way as C++ overloaded #OUT + "Hello, " + name + "!";

I did not know this nor indeed that Sather existed. Thanks. I don't feel as though "But Sather did it too" counts as a good reason for I/O streams, but thanks for telling me.

Re: The C23 edition of Modern C

#349

Post by int_19h »

tialaramex wrote: post #348
int_19h wrote: post #342

Earlier quoted context omitted.

Sather (1991) used operator overloading for output. And, even more hilariously, they overloaded + in the same way as C++ overloaded #OUT + "Hello, " + name + "!";

I did not know this nor indeed that Sather existed. Thanks. I don't feel as though "But Sather did it too" counts as a good reason for I/O streams, but thanks for telling me.

I don't think it's a good reason, and FWIW I'm pretty sure they got the idea from C++ - iostream design predates ISO C++ by quite a bit. I remember seeing etc. Just noting that this is not such an obviously bad idea that nobody else hasn't fallen into the same trap.

Re: The C23 edition of Modern C

#350

Post by bboygravity »

dhhfss wrote: post #194
bboygravity wrote: post #187

Earlier quoted context omitted.

Or in other words, for embedded and existing code: most use c99, some use c11 and nobody uses c23 until at least 10 years from now.

This depends on the platform. Many embedded systems are based on arm these days and have modern toolchains available. I cannot remember the last time I saw C99 used. C codebases generally use C11 or C17, and C++ code bases use C++20

Most devices that are 6+ years old (as far as I can tell) use C99. If not C89. And/or C++17, if that.

That's A LOT of devices out there. A lot of which still get maintenance and even get feature updates (I'm working on one right now, C99).

So the claim that "C codebases generally use C11 or C17, and C++ code bases use C++20" intuitively sounds like totally untrue to someone working in embedded C/C++. I've been doing this for 15+ years and I've never touched anything higher than C99 or C++17.

If you're talking about gaming, sure. But that's not "C code bases generally".

Post reply on HN