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

101–110 of 182 posts

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

#101

Post by gpderetta »

Making DoSomething a template because span is a template is a non-sequitur.

If DoSomething works with untyped bytes, it should require a std::span (or const byte if read only). Incidentally the standard provides a convenient as_bytes(std::span)->std::span; There isn't an as convenient helper to convert a singular object to a span of bytes, but it is easy to write.

As to why one should use span, is that a) it helps making sure that the size travels together with the pointer for some additional safety, b) it is more convenient to work with byte ranges than void ptrs (which do not support pointer math), c) helps a bit communicating intent: in C++ void* are used more often for type erasure than for byte related things.

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

#102

Post by kstenerud »

The real question here is: WHY are you passing a blob of memory rather than a struct that uses the type system to describe and enforce what the contents are?

I don't mean dressing up an anonymous pointer, which the author rightly complains about. I mean WHY are you making an API that takes such a pointer to an unknown type to begin with? Whenever you change the structure within that blob, your type checker won't flag that the receiver hasn't been updated to handle it.

Even worse: nothing's stopping you from accidentally passing in the wrong type.

And now you have a SEGV. Or a security hole.

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

#104

Post by gpderetta »

pjmlp wrote: post #75
usrnm wrote: post #58

Earlier quoted context omitted.

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

Contrary to the FOSS compile from source culture, other platforms have a different point of view on ABI breaks. Which is why Valve ended up using Proton.

I'm pretty sure GCC has been ABI stable far longer that MSVC which used to break ABI every release.

GCC was forced to break the std::string ABI by the C++11 standard and they have been lobbing ever since against ABI breaks.

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

#105

Post by locknitpicker »

kstenerud wrote: post #102

The real question here is: WHY are you passing a blob of memory rather than a struct that uses the type system to describe and enforce what the contents are? I don't mean dressing up an anonymous pointer, which the author rightly complains about. I mean WHY are you making an API that takes such a pointer to an unknown type to begin with? Whenever you change the structure within that blob, your type checker won't flag…

> The real question here is: WHY are you passing a blob of memory rather than a struct that uses the type system to describe and enforce what the contents are?

I completely agree. It's particularly egregious when the blogger complains that the complexity and ugliness lies in the type casting to force an incompatible type where it doesn't belong, and use a reinterpret_cast of all things.

This doesn't even feel like a strawman argument anymore. This sounds like a coding horrors entry.

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

#106

Post by fp64 »

kstenerud wrote: post #102

The real question here is: WHY are you passing a blob of memory rather than a struct that uses the type system to describe and enforce what the contents are? I don't mean dressing up an anonymous pointer, which the author rightly complains about. I mean WHY are you making an API that takes such a pointer to an unknown type to begin with? Whenever you change the structure within that blob, your type checker won't flag…

I think the article names hashing as a use-case, which I can somewhat still agree. Operations that only depend on the bytes, I guess. But yeah, most things worth saying about this article have been said here already

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

#108

Post by pjmlp »

locknitpicker wrote: post #86
pjmlp wrote: post #74

Earlier quoted context omitted.

Easy, even one of the author's could not change WG14 mind towards security. Governments,related cybersecurity agencies, and companies are the ones getting outraged when looking at money spent in cyber attacks due to memory corruption issues.

> Easy, even one of the author's could not change WG14 mind towards security. Your comment conveys a hefty dose of ignorance on the topic. I recommend you read the proposal's arguments, including how it required breaking the ABI.

Are you asserting that WG14 never had the necessary skills among all the members to help improve this proposal, or dare to bring another one during the last 40 years?

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

#109

Post by pjmlp »

gpderetta wrote: post #104
pjmlp wrote: post #75

Earlier quoted context omitted.

Contrary to the FOSS compile from source culture, other platforms have a different point of view on ABI breaks. Which is why Valve ended up using Proton.

I'm pretty sure GCC has been ABI stable far longer that MSVC which used to break ABI every release. GCC was forced to break the std::string ABI by the C++11 standard and they have been lobbing ever since against ABI breaks.

You haven't used Windows in a while I imagine.

MSVC has stabilised the ABI since VS 2015, we are on VS 2026 now.

Due to customer pressure to stop doing exactly that, to the point some ISO C and C++ stuff that requires breaking the ABI has not been implemented thus far.

I am quite certain that I will find ABI breaks in GCC release notes since Slackware 2.0, when I used it for the first time.

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

#110

Post by mwkaufma »

s28l wrote: post #67
mwkaufma wrote: post #63

If you know you want bytes -- A void* of unknown provenance cast to anything other than char* is UB so just skip the middleman and use char*.

char* can also be a C-style string. std::byte has the same special treatment in the standard as char and unsigned char, with the added benefit of not being used for other purposes (i.e. ASCII character or uint8, respectively).

I was trying to appeal to OPs maladaptive "C++ that looks like C is more legitimate" aesthetic preference, haha.
Post reply on HN