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

141–150 of 182 posts

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

#141

Post by MaulingMonkey »

ryandrake wrote: post #93
AnimalMuppet wrote: post #85

Earlier quoted context omitted.

> `void*` is frequently clearer - it's a signal that it's an opaque blob at this point in the code, and that something else will try to give it meaning later. And that's fine, until something else gives it the wrong meaning later. If you're just plumbing, and you're pumping around opaque blobs, if somewhere in the plumbing you connect the wrong source to the wrong destination, you get no warning .

Yes, in this case, void* is kind of smelly. If the intent of your function is to receive a const struct MyCustomData*, then that should be the type of the argument. If you later need to handle a const struct MyOtherCustomData*, you can add an overload that takes that argument. Or use a template as others pointed out. Use the type system to help you, so you're warned if you try to pass the method const struct BadCusto…

To be fair, the `void*` is already a pretty big hint that you're in the danger zone.

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

#142

Post by tialaramex »

spacechild1 wrote: post #136
tialaramex wrote: post #133

Earlier quoted context omitted.

> The committee is not a one man show Of course it isn't, all the great egotists need a parade of sycophants to heap praise on them, you've doubtless seen modern US "Cabinet meetings" in which TV hosts newly elevated to run parts of the US government compete with experienced politicians as they all try to offer the most effusive praise for their snoring God King. Personally, I'd throw up, but then I'm very much of Gr…

Are your seriously comparing the C++ standard committee to the Trump administration? I know you have an axe to grind, but this is getting ridiculous. Where exactly have you seen this "parade of sycophants" in the C++ standards committee? As far as I know, Bjarne is just a regular committee members with just as many votes as everyone else and no veto powers. The committee frequently accepts or rejects proposals agains…

Yes, I am seriously making that comparison. It's not as bad of course but it's certainly enough to make me cringe.

> Where exactly have you seen this "parade of sycophants" in the C++ standards committee?

AIUI The committee itself operates under the "Chatham House Rule" in which participants agree not to tell anybody who said anything and so we can only see group outcomes for the committee itself. For example 100% affirmative votes for Bjarne's "Profiles" proposal. At 100% everybody who had the opportunity to vote "Against" has to admit that er, they didn't, because that's just maths - but you won't now find anybody who was enthusiastic, somehow a room full of people who all now remember being uncertain voted affirmatively anyway. How about that.

> Bjarne is just a regular committee member

For almost a decade, WG21 has a "Direction Group" with a handful of members which insists that while as you say everybody is just a "regular committee member" their group ought to set the "direction" for the language and thus the committee. The exact membership of the Direction Group varies over time, but of course Bjarne Stroustrup has always been a member of this group. The group (whatever its present membership) writes only unanimously, which means everything it says has been agreed by Bjarne Stroustrup, and it cites as its reference for how to set the direction several books about C++ all written by that same Bjarne Stroustrup.

So, sure, Bjarne is "just a regular committee member" in the same way that Britain's Prime Minister is "just a regular Member of Parliament" that is, very much in theory but not at all in practice.

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

#143

Post by drivebyhooting »

fluffybucktsnek wrote: post #139
drivebyhooting wrote: post #132

Earlier quoted context omitted.

It’s this kind of attitude that perpetuates bad compilation time. Templates have to get parsed and instantiated over and over again. Then you need link time optimization to deduplicate all the redundant copies of the same code.

If youif you are using C++, your last concern will be compilation times. By this point, just use C.

Untrue. Lots of effort is spent optimizing compilation time at big FAANG companies. And there a lot of established techniques for creating “compiler firewalls” and explicitly instantiating templates once.

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

#144

Post by drivebyhooting »

ndiddy wrote: post #137
drivebyhooting wrote: post #131

Earlier quoted context omitted.

The caller still needs to construct the span correctly.

You can pass both C arrays and some STL containers (i.e. std::vector, std::array) into a function that takes a span, and the span will get constructed automatically. You have to construct it manually if all you have is a pointer and a length, but I don't know what you'd expect to happen there.

It’s not semantically safe to pass arbitrary vectors into a generic buffer copying function. The T in a vector could have internal pointers or worse things.

Either the objects are simple and trivially copiable, or you need a proper serialization library.

Sure you can use span to generalize slides and iteration, but I don’t think that’s the point of the article.

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

#145

Post by uecker »

wahern wrote: post #138
wahern wrote: post #126

Earlier quoted context omitted.

WG14 adopted variably modified types, a kind of dependent type. From a security standpoint it offers all the same qualities. It also in principle was easier to integrate from a backwards compatibility standpoint, with the exception of struct member analogs (which we now have but aren't yet standardized). Maybe we would have been better off with Ritchie's counter proposal. But neither proposal was chiefly concerned wi…

Just to be clear, I often think we would have been better off with Ritchie's proposal, assuming it would have seen at least as much adoption in implementations and usage as variably modified types, which sadly remained poor for many years after C99, and arguably still poor. But being better off doesn't mean being in a drastically better situation than we are today from a security perspective. The proposed alternative…

The support for variably modified types is excellent, if you discount MSVC which is lacking support for modern C anyway (it seems to catch up a bit though).

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

#146

Post by uecker »

pjmlp wrote: post #108
locknitpicker wrote: post #86

Earlier quoted context omitted.

> 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?

This has not much to do with skill. Standardization does not work like this, and I told you this before.

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

#147

Post by wahern »

uecker wrote: post #145
wahern wrote: post #138

Earlier quoted context omitted.

Just to be clear, I often think we would have been better off with Ritchie's proposal, assuming it would have seen at least as much adoption in implementations and usage as variably modified types, which sadly remained poor for many years after C99, and arguably still poor. But being better off doesn't mean being in a drastically better situation than we are today from a security perspective. The proposed alternative…

The support for variably modified types is excellent, if you discount MSVC which is lacking support for modern C anyway (it seems to catch up a bit though).

Real-world usage certainly remains poor. Using pointers to VM types remains annoying, and I wish the committee would settle on a solution to the ordering of VM parameters. But, yeah, the VM types are solid in GCC and clang and should be used more.

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

#148

Post by fluffybucktsnek »

drivebyhooting wrote: post #143
fluffybucktsnek wrote: post #139

Earlier quoted context omitted.

If youif you are using C++, your last concern will be compilation times. By this point, just use C.

Untrue. Lots of effort is spent optimizing compilation time at big FAANG companies. And there a lot of established techniques for creating “compiler firewalls” and explicitly instantiating templates once.

But these compilation times optimizations don't significantly undermine the other goals. Given that we're talking about std::span, a pretty small template all things considered, I think practical evidence (e.g. actual cases) of impact is needed.

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

#150

Post by fluffybucktsnek »

drivebyhooting wrote: post #144
ndiddy wrote: post #137

Earlier quoted context omitted.

You can pass both C arrays and some STL containers (i.e. std::vector, std::array) into a function that takes a span, and the span will get constructed automatically. You have to construct it manually if all you have is a pointer and a length, but I don't know what you'd expect to happen there.

It’s not semantically safe to pass arbitrary vectors into a generic buffer copying function. The T in a vector could have internal pointers or worse things. Either the objects are simple and trivially copiable, or you need a proper serialization library. Sure you can use span to generalize slides and iteration, but I don’t think that’s the point of the article.

In comparison to a plain void* and a separate size, it's still an improvement. As others mentioned, void* suffers from the same problem (it might point to a type that is not trivially copyable), except it has more opportunities for mistakes.

In contrast, with span, you can instantiate only to span (or something similar) and you'd still be able to accept other buffer types (such as vector, array, etc.). Alternatively, you can make T bounded to be trivially copyable. You can't do that with void*.

Post reply on HN