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

C constructs that still don't work in C++

lospino.so

Post reply on HN
Print view View original

131–140 of 182 posts

Re: C constructs that still don't work in C++

#131

Post by tialaramex »

uecker wrote: post #114
tialaramex wrote: post #108

Earlier quoted context omitted.

I don't think the numbers bear out that "this works nicely" in C, it seems like you have worse perf numbers for some common cases like sorting ?

Not sure what numbers you are talking about. If you use qsort from the C library the comparison function will not be inlined, but if you provide your own, this is no problem.

> if you provide your own, this is no problem.

If just "providing my own" would help why wouldn't the stdlib benefit too? You're going to have to spell out what you think can actually work here if you want me to believe there's "no problem".

Re: C constructs that still don't work in C++

#132

Post by tialaramex »

uecker wrote: post #97
tialaramex wrote: post #75

Earlier quoted context omitted.

> no ISO standard I'm sure I could argue with you about the actual technical differences but this part in particular is very, very stupid. JTC1/SC22 † shouldn't exist at all. A committee structure is a bad way to do this work, and the practice of having periodic meetings - exclusively in person for much of the time these existed - actually makes it less rather than more useful. ISO mandates a bunch of rules and proce…

It doesn't have to be ISO, but some organization which follows some official rules and not some entity dependent on industry donations.

LOL. You do know ISO/IEC 29500 exists right?

ISO agreed that despite there being an existing, popular, broadly supported and open XML document standard they should define Microsoft's proprietary alternative OOXML as an international "standard". They even held votes repeatedly until the voters gave the "correct" answer... no worry about "industry donations" there.

Re: C constructs that still don't work in C++

#133

Post by jstimpfle »

pjmlp wrote: post #126
uecker wrote: post #105

Earlier quoted context omitted.

Assuming you mean the standard does not provide features for numa and simd? It doesn't necessarily have to. I think it is not surprising that you seem always bewildered that people still use C (as per your comments), as it seems you fundamentally do understand neither standardization nor systems programming.

I do certainly understand it, by the eyes of C++, Rust, Ada, Object Pascal, Modula-2, D.

Systems programming is not primarily about programming languages though...

Re: C constructs that still don't work in C++

#134

Post by uecker »

tialaramex wrote: post #132
uecker wrote: post #97

Earlier quoted context omitted.

It doesn't have to be ISO, but some organization which follows some official rules and not some entity dependent on industry donations.

LOL. You do know ISO/IEC 29500 exists right? ISO agreed that despite there being an existing, popular, broadly supported and open XML document standard they should define Microsoft's proprietary alternative OOXML as an international "standard". They even held votes repeatedly until the voters gave the "correct" answer... no worry about "industry donations" there.

I remember the story, but it was considered outrageous for a reason.

Re: C constructs that still don't work in C++

#135

Post by 1718627440 »

spacechild1 wrote: post #94
uecker wrote: post #29

Earlier quoted context omitted.

The "stronger type system" is mostly a myth in my opinion. It was true in the past in pre-prototype C. The void pointer rules are better in C IMHO as they avoid unneeded casts (that then remove more type safety) and FAMs and variably-modified types can express things C++ simply can't do well.

I don't get your point at all. C++ has different casting operators (static_cast, const_cast, reinterpret_cast) that are strictly safer than C-style casts. Also, let's not forget that implicit casts between unrelated pointer types is only a warning in C. Fortunately, modern C compilers started treating it as an error by default because it caused so much harm: https://gcc.gnu.org/gcc-14/porting_to.html . In C++ this wa…

> implicit casts between unrelated pointer types is only a warning in C

A warning in C has the meaning of a "stern warning" aka. "That very much won't work, I warned you!". An error means, "I literally, don't what you mean".

Also as far as I know, the C standard only talks about diagnostics.

Re: C constructs that still don't work in C++

#136

Post by uecker »

tialaramex wrote: post #131
uecker wrote: post #114

Earlier quoted context omitted.

Not sure what numbers you are talking about. If you use qsort from the C library the comparison function will not be inlined, but if you provide your own, this is no problem.

> if you provide your own, this is no problem. If just "providing my own" would help why wouldn't the stdlib benefit too? You're going to have to spell out what you think can actually work here if you want me to believe there's "no problem".

It would also, but nobody cares enough because qsort is already fast enough for most things, and if you cared it is simply enough to do yourself. Are you doubting that C compilers can devirtualize function calls? Here is a small example that illustrates this. The compiler dervirtualizes all calls than folds the result: https://godbolt.org/z/E6cMMr8vx

Re: C constructs that still don't work in C++

#137

Post by 1718627440 »

flohofwoe wrote: post #51
pjmlp wrote: post #21

Earlier quoted context omitted.

Yet C23 isn't K&R C any longer, nor is the hardware a PDP 11. Also when we eventually start talking to agents that perform the whole execution steps by themselves, that is kind of irrelevant. Except for the lucky ones that still code to keep the infrastructure going, which is mostly C++.

The PDP-11 myth is getting a bit tired by now ;) If C would be so hardwired to the PDP-11 architecture it would have died with it. In reality C works just fine on all sorts of hardware (like GPUs) with only minor extensions.

Yeah, a continuous memory model is used, because it is convenient, not because some old hardware happen to use it.

Re: C constructs that still don't work in C++

#138

Post by 1718627440 »

pjmlp wrote: post #87
uecker wrote: post #35

Earlier quoted context omitted.

Anyway, I do not see how this affects the design of C in a way that makes no sense anymore today (except that one could require CHAR_BIT to be eight, but there are still DSPs where this is not the case). I think people repeat the "the C design reflects the out-dated PDP-11 hardware" meme because it sounds smart while in reality it is just nonsense.

So when is WG14 standardising modern hardware into the C standard? Basic stuff like SIMD, SIMT, without requiring users to go beyond language extensions, something that any programming language can offer in similar capacity?

Why does the language standard need to prescribe everything. It is a standardization of between existing compilers, they are allowed and intended to invent things. If anything the experience from C++ has shown, that writing too much behaviour into the standard accidentally has consequences on the possible performance. The C standard is descriptive, not prescriptive.

> something that any programming language can offer in similar capacity?

By your measure a lot of other languages don't offer anything to begin with, because they do not have a standard at all, only a reference implementation.

Re: C constructs that still don't work in C++

#139

Post by 1718627440 »

p0w3n3d wrote: post #12

Address white_house{ .street = "1600 Pennsylvania Avenue NW", .city = "Washington", .state = "District of Columbia", .zip = 20500, }; For me this is the most important initialization in C that helps with clarity so much, I used mostly structs to have function parameters intialized like this However C++ had at time no default initialization for unmentioned fields, so in 2017 I had to remove it when converting the code…

Yeah you can even create linked lists of static data that way, as you can very well just take the pointer of an object here.

Re: C constructs that still don't work in C++

#140

Post by 1718627440 »

cocoto wrote: post #39
arcadialeak wrote: post #24

Earlier quoted context omitted.

> std::string_view or std::span should be used instead That is for when the owner is a std::string or an owning range respectively. But a raw pointer does still make sense as a non-owning view over a single element, doesn't it? I'm new to C++ so I might be wrong.

Non-owning view over a single element should simply be a reference, you don’t care where this element is located.

That won't work with NULL.
Post reply on HN