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

The beauty and simplicity of the good old C-style void* in C++

giodicanio.com

Post reply on HN
Print view View original

51–60 of 182 posts

Re: The beauty and simplicity of the good old C-style void* in C++

#51

Post by bcjdjsndon »

repelsteeltje wrote: post #42
_the_inflator wrote: post #21

I think that the author is right in everything he says and yes, there is beauty in it. However, the antithesis is also correct that there exist better solutions to solve the issues. Both premises hold true. I have an extensive assembler coding background on 6510, M68000, and i486. I had a very hard time accepting that something could be solved faster and more stable in a higher order language while the downside is mo…

There will always be cases (like audio processing, car brakes, pace makers) where hard real-time constraints prohibit GC languages (as well as l1 cache, instruction reordering and other optimizations). Also, consider that Python's performance frequently originates in it's bindings to libraries written in C, C++, Fortran, Rust. I recently ran a few Java benchmarks and found that an array holding a bunch of objects inc…

What's your point here? The higher the language level, the less performant they are? Why are using anything but assembler then?

Re: The beauty and simplicity of the good old C-style void* in C++

#52

Post by bcjdjsndon »

pjc50 wrote: post #37
_the_inflator wrote: post #21

I think that the author is right in everything he says and yes, there is beauty in it. However, the antithesis is also correct that there exist better solutions to solve the issues. Both premises hold true. I have an extensive assembler coding background on 6510, M68000, and i486. I had a very hard time accepting that something could be solved faster and more stable in a higher order language while the downside is mo…

One of these days I want to do a "typesafe macro assembler" that actually is the language people think that C is.

You could call it rust and just rename the remaining UB as "unsafe" and call the problem solved

Re: The beauty and simplicity of the good old C-style void* in C++

#53

Post by trumpdong »

pjc50 wrote: post #35
trumpdong wrote: post #11

Earlier quoted context omitted.

There's lots of UB in C-family execution models. Some of which is not actually UB because the implementation defines it - e.g. aligned DWORD-sized memory access is atomic on Windows because Microsoft said it is. By choosing to use this language you choose to navigate the UB. Otherwise you'd be writing in Go, or Python. It is possible to write reliable code despite the presence of UB in a language just like it's possi…

> Some of which is not actually UB because the implementation defines it No - if something is UB in the spec, it's UB. The implementation will do something , sure, but what it does is not fixed and may even change based on compiler version and optimization level. > DWORD-sized memory access is atomic on Windows because Microsoft said it is Well, Intel said it is. Mind you I don't think there are any 32-bit native arc…

"Undefined behavior" in the C standard literally means "behavior which this C standard does not put any requirements on" - it says so in the definitions section of the C standard. Other things can still put requirements on it. MSVC isn't just a C++ compiler - it's a C++ compiler for x64 Windows and therefore follows the rules of C++, x64, and Windows all at once.

Re: The beauty and simplicity of the good old C-style void* in C++

#54

Post by spacechild1 »

pjmlp wrote: post #25
spacechild1 wrote: post #9

Earlier quoted context omitted.

> but `std::span` should have been there decades ago Absolutely! I now use it consistently in all new projects where I can afford to mandate C++20. I guess nobody bothered to make a proposal before...

They did in C, from one of the language authors even, and it was not accepted. https://www.nokia.com/bell-labs/about/dennis-m-ritchie/varar... By the way, both Extended Pascal, Mesa/Cedar and Modula-2 have them, under the name of open arrays. Basically it took Go, C# and others for C++ to finally get its span. C probably never will.

Everybody knows that C++ did not invent the concept of spans and that it was late to the party. It doesn’t change the fact that (presumably) nobody made a proposal to the C++ standard.

Re: The beauty and simplicity of the good old C-style void* in C++

#55

Post by trumpdong »

pjc50 wrote: post #37
_the_inflator wrote: post #21

I think that the author is right in everything he says and yes, there is beauty in it. However, the antithesis is also correct that there exist better solutions to solve the issues. Both premises hold true. I have an extensive assembler coding background on 6510, M68000, and i486. I had a very hard time accepting that something could be solved faster and more stable in a higher order language while the downside is mo…

One of these days I want to do a "typesafe macro assembler" that actually is the language people think that C is.

You could even give it identical syntax to C!

Re: The beauty and simplicity of the good old C-style void* in C++

#56

Post by stinos »

thomasmg wrote: post #29
stinos wrote: post #8

> Why should people complexify and uglify their C++ code with the uint8_t pointer (or std::byte), when void* works just fine?? Fair point (although to be honest: 'complexify' feels a bit of an exaggeration here to me), but the answer to this why is simple: document and express intent clearly. The compiler gave you an error first such that you're forced to consider what you're doing. Any seasoned C++ developer seeing…

I don't have a strong opinion what is better in this case, but my view is: > document and express intent clearly Arguably, the void* does that as well? > Any seasoned C++ developer seeing this knows what this reinterpret_cast means. Same for void*? > it's a bit more text to read If you have to call it many times, this adds up. > Some might also say it complexifies and uglifies the code I think the point is that it ad…

> Arguably, the void* does that as well?

Sort of (I mean: seeing void* and a size probably means 'arbitrary sequence of bytes' or something like that, but well it's void* so it can be like anything whereas with std::span you get more of a hint what's going on just based on the type), but not at the callsite which is what the author is referring to when it's about reinterpret_cast.

> I think the point is that it adds security, which the other options don't

Imo span also does that to some extent, but already when writing the code and not afterwards in e.g. static analysis. E.g. if I get an std:span I'd have to do counterintuitive things to misuse it. Annotating a void* still leaves it a void* which I then need to cast to char* if I think that's what it is intended.

Don't get me wrong: I've written my fair share of void* but these days I really feel like there's almost always a better thing which can be used instead. Though I do admit that since I've written and consumed a lot of code with such alternatives I'm not hindered by readability/apparent complexity of it anymore but I understand that's not the same for everyone.

Re: The beauty and simplicity of the good old C-style void* in C++

#57

Post by locknitpicker »

gignico wrote: post #50
locknitpicker wrote: post #14

Earlier quoted context omitted.

> I understand that people can have many things to say about C++, and I do as well, but `std::span` should have been there decades ago (...) Decades is kind of a stretch. C++11 introduced smart pointers, and finally getting C++0x out of the door was already a major victory. Given the history of C++, it would be unrealistic to introduce something like std::span before C++17. Meantime, some organizations are still stru…

Afaik std::span does not need anything that was not in C++98 already, or am I missing something?

> Afaik std::span does not need anything that was not in C++98 already, or am I missing something?

You're missing the fact that following C++98 it took around 13 years to get the next version of the standard published delivered.

Re: The beauty and simplicity of the good old C-style void* in C++

#58

Post by usrnm »

j16sdiz wrote: post #47
usrnm wrote: post #36

Earlier quoted context omitted.

Sounds like a compiler bug to me. It is a valid reason to avoid them in some rare cases right now, but it doesn't make the feature itself bad

Those are ABI. Unless it is inlining them, the overhead is to stay.

ABI changes do happen. gcc had an ABI change in std::string because of C++11. It was long and painful, but everyone survived, the world did not end

Re: The beauty and simplicity of the good old C-style void* in C++

#59

Post by locknitpicker »

pjmlp wrote: post #28
locknitpicker wrote: post #14

Earlier quoted context omitted.

> I understand that people can have many things to say about C++, and I do as well, but `std::span` should have been there decades ago (...) Decades is kind of a stretch. C++11 introduced smart pointers, and finally getting C++0x out of the door was already a major victory. Given the history of C++, it would be unrealistic to introduce something like std::span before C++17. Meantime, some organizations are still stru…

It could have been there since the beginning, given that open arrays (aka spans) already existed in other languages, and there was even a failed proposal from Denis Ritchie regarding C. The C++ span proposal came from Microsoft, https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p01...

> already existed in other languages

This argument is moot. The issue with spans is not that they require cutting edge technology to deliver.

Before commenting, perhaps you should research why even Denis Ritchie himself could not sell his idea to C.

It's funny how every single idea that's rejected is blindly lauded as brilliant but silenced due to some kind of conspiracy, and only the ideas that emerged are somehow bad, unacceptable, or late. Is the point to feel outraged?

Re: The beauty and simplicity of the good old C-style void* in C++

#60

Post by zahlman »

VulgarExigency wrote: post #27
stinos wrote: post #8

> Why should people complexify and uglify their C++ code with the uint8_t pointer (or std::byte), when void* works just fine?? Fair point (although to be honest: 'complexify' feels a bit of an exaggeration here to me), but the answer to this why is simple: document and express intent clearly. The compiler gave you an error first such that you're forced to consider what you're doing. Any seasoned C++ developer seeing…

It seems unlikely that this is the case, as the author appears to be experienced, but the post reads like the author has never had to maintain a "simple" and "beautiful" function that was mangled into incomprehensibility over the years, and where if a more expressive type signature had been written from the start, it would have restricted the damage caused over time.

> a "simple" and "beautiful" function that was mangled into incomprehensibility over the years, and where if a more expressive type signature had been written from the start, it would have restricted the damage caused over time.

...Can you give a concrete example? I've been programming literally since the 80s and that doesn't ring true at all for me.

Post reply on HN