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

131–140 of 360 posts

Re: The C23 edition of Modern C

#131

Post by wpollock »

card_zero wrote: post #27
jpcfl wrote: post #8

Earlier quoted context omitted.

Bjarne should have called it ++C.

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

The PDP-11 that C originally targeted had address modes to support the stack. Pre-increment and post-decrement therefore did not require a separate instruction; they were free. After the PDP-11 went the way of the dodo, both forms took a machine cycle so it (mostly) became a stylistic issue. (The two operators have different semantics, but the trend to avoid side-effects in expressions means that both are most often used in a single expression statement like "++x;" or "x++;", so it comes down to your preferred style.)

Re: The C23 edition of Modern C

#132

Post by pjmlp »

einpoklum wrote: post #128
pjmlp wrote: post #80

Earlier quoted context omitted.

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.

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.

Re: The C23 edition of Modern C

#133

Post by JonChesterfield »

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?

It's a nuisance to implement the thing you want to add to the standard yourself. It's easier to ship it in the language and then complain at compiler devs that they're running behind the edge of progress.

This interacts in the obvious way with refusing to correct mistakes after the fact for fear of breaking user code.

I don't believe anyone has written a paper along the lines of "let's not bother with the existing practice part anymore", it's more an emergent feature of people following local incentive structures.

Re: The C23 edition of Modern C

#134

Post by JonChesterfield »

accelbred wrote: post #52
bitbasher wrote: post #3

Really looking forward to #embed, once the compilers catch up. Until then, Golang.

I end up using a .S asm file with .incbin directives to embed files. #embed would be much nicer

Incbin works just fine from inline asm fwiw

Re: The C23 edition of Modern C

#135

Post by renox »

uecker wrote: post #72
renox wrote: post #59

Earlier quoted context omitted.

You'd be surprised: Zig has one UB (Undefined Behaviour) that C doesn't have! In release fast mode, unsigned overflow/underflow is undefined in Zig whereas in C it wraps. :-) Of course C has many UBs that Zig doesn't have, so C is far less safe than Zig, especially since you can use ReleaseSafe in Zig..

UB is does not automatically make things unsafe. You can have a compiler that implements safe defaults for most UB, and then it is not unsafe.

Well Zig has ReleaseSafe for this.. ReleaseFast is for using these UBs to generate the fastest code.

Re: The C23 edition of Modern C

#136

Post by emmanueloga_ »

zkirill wrote: post #29

I was going to ask if there is a good list of C books and then answered my own question. It categorizes _Modern C_ as Intermediate level. https://stackoverflow.com/questions/562303/the-definitive-c-...

Note that this is not a complete list, fwiw. For example, I doesn't include "Effective C." [1].

I like "Effective C" over "Modern C" because it's more engaging ... "Modern C" is super rigorous and feels a bit like reading an annotated spec of the language, which is what an expert may need, but makes for a dull read for a casual C user like me.

--

1: https://nostarch.com/effective-c-2nd-edition

Re: The C23 edition of Modern C

#137

Post by bsder »

TZubiri wrote: post #99
layer8 wrote: post #68

Earlier quoted context omitted.

> no array bounds checking is possible. This isn’t strictly true, a C implementation is allowed to associate memory-range (or more generally, pointer provenance) metadata with a pointer. The DeathStation 9000 features a conforming C implementation which is known to catch all array bounds violations. ;)

"The DeathStation 9000" The what now?

Nasal daemons for those of us of a slightly older vintage ...

Re: The C23 edition of Modern C

#139

Post by WalterBright »

uecker wrote: post #71
layer8 wrote: post #68

Earlier quoted context omitted.

> no array bounds checking is possible. This isn’t strictly true, a C implementation is allowed to associate memory-range (or more generally, pointer provenance) metadata with a pointer. The DeathStation 9000 features a conforming C implementation which is known to catch all array bounds violations. ;)

Right. Also it might it sound like array-to-pointer decay is forced onto the programmer. Instead, you can take the address of an array just fine without letting it decay. The type then preserves the length.

C: int foo(int a[]) { return a[5]; }

    int main() {
        int a[3];
        return foo(a);
    }

    > gcc test.c
    > ./a.out
Oops.

D: int foo(int[] a) { return a[5]; }

    int main() {
        int[3] a;
        return foo(a);
    }

    > ./cc array.d
    > ./array
    core.exception.ArrayIndexError@array.d(1): index [5] is out of bounds for array of length 3
Ah, Nirvana!

How to fix it for C:

https://www.digitalmars.com/articles/C-biggest-mistake.html

Re: The C23 edition of Modern C

#140

Post by wakawaka28 »

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…

>No other language does this, and it's not because they can't it's because it was a bad idea when it was created, it was still a bad idea in 1998, the only difference today is that C++ has a replacement.

Hindsight is 20/20, remember that. Streams are not that bad of an idea and have been working fine for decades. You haven't named a problem with it other than the fact the operators are used for other stuff in other contexts. But operator overloading is a feature of C++ so most operators, even the comma operator, can be something other than what you expect.

>The biggest problem is that today C++ doesn't have a way to implement this for your own types easily, Barry illustrates a comfortable way this could work in C++ 26 via reflection which on that issue closes the gap with Rust's #[derive(Debug)].

You can trivially implement input and output for your own types with streams.

You appear to be a Rust guy whose motive is to throw shade on C++ for things that are utterly banal and subjective issues.

Post reply on HN