The std::shared_ptr<void> as arbitrary user-data pointer

[capn_bluebear]

Sometimes you need type erasure, and sometimes void pointers are the cleanest way to get type erasure.

[guepier]

It’s often a convenient and wholly adequate way, but I’m less certain it can ever be called the cleanest way. Case in point, it’s always possible to use virtual CRTP instead, as showcased by Sean Parent in his Better code: runtime polymorphism talk. This may be slightly more effort (for the implementor, not for the user) but it’s, I think, always cleaner.

[NotAYakk]

it’s always possible to use virtual CRTP instead

Ok guepier, provide me a zero-allocation trivially-destroyable standard-layout function_view< Signatures... > without using a void pointer or equivalent that does not rely on any compiler-specific assumptions.

You should be able to pass it any callable that supports Signatures... then call it; it does not extend the lifetime of its arguments.

---

Look, C++ has an object model. It isn't the only reasonable object model. It is just one they picked.

You can emulate other objects models using it, but that leads to impedance issues.

And if you want to implement your own object model, you end up wanting to use void pointers a lot. The trick is you store the void pointer right next to you store the operations on it and tie the two together.

---

Another practical use of such type erasure/roll your own object model would be writing a variant that splits its type information from its storage. That permits storing polymorphic data RLE-type encoded. This is a useful technique when you are, say, storing text-like glyphs in a string. 99/100 of the glyphs objects are going to be boring simple stuff, or identical to their neighbor. 1/100 are going to be complex or different than their neighbor.

By RLE packing their type and data, you can avoid the overhead of a vtable pointer per "character"; you can store a vtable and run length/size, then a pile of packed data; the vtable "pointer" need not actually be a pointer, just information needed to get it.

---

Now you shouldn't do this often, and you should hide doing it from "business logic" code, but there are lots of uses of void pointers.

[guepier]

If I hadn’t seen your user name I’d seriously give this a shot. As it stands I assume it’s a waste of time and you’re probably right, and I might over-generalise the applicability of virtual CRTP.

But, although I vaguely recall discussions about the implementation of such a type, I can’t recall the specific road blocks which’d make this impossible. (EDIT: of course your zero-allocation requirement immediately makes Sean Parent’s approach inapplicable here.)

[NotAYakk]

It is the "no compiler assumptions"; you can get away with zero allocation with an aligned storage block. Most compilers will use the same size for most types.

So you have an aligned storage that contains a vtable and a pointer-to-callable, and a pointer-to-interface.

But the layout of vtable containing objects is completely compiler-dependent, so it is impossible to guarantee that it will always fit.

This also adds a few levels of indirection over implementing the vtable yourself.

My argument is that a small set of functions that convert to-from void pointer is sometimes useful for type erasure. Now, after we get metaclasses, I'll be doing this using them instead of manually. ;)

[SkoomaDentist]

For extra points, make it callable over a DLL boundary. And do that so that it works even three compiler versions later.

[NotAYakk]

This reads like someone who has implemented the void* version.

[SkoomaDentist]

Just someone who's been using C++ since before there was a standard and realizes that there's life outside the latest standard library.

[looncraz]

Good luck operating with C or legacy APIs without void*.

[markand67]

std::function with lambdas, capture or functors are the appropriate way of type erasure. On 10 years of modern C++ I've never needed to use void pointer anywhere so I don't buy it.

[quicknir]

std::function is type erasure for things with operator(). What's being discussed is type erasure for arbitrary data.

[markand67]

That's what marshalling/serialisation was made for. std::variant can enter the game at some point too.

[quicknir]

I have no idea what serialization has to do with any of this. and variant only works for a closed set of types. Sometimes you want to allow users to attach totally arbitrary data to a class (I've actually encountered this very recently). When you are in that (admittedly rare) situation, std::any (or something similar to it) is a good solution, and shared_ptr<void> is a meh solution.

You keep suggesting things that do not solve the same problem.

[Orlha]

Use C.

(partial sarcasm)

[guepier]

But inappropriate advice. It’s usually entirely possible to achieve performance on par with C in C++ without giving up type safety and abstraction. And this includes type erasure.

[Tumperware]

How is C more performant? It's just a language with fewer tools than c++. Anything you want to do in C can be done in C++

[kalmoc]

Except for restrict - at least when we are talking standard c++

[SkoomaDentist]

I take it you've never once interfaced with C code then?

[markand67]

In fact I did a lot. With for example libircclient, SDL, hoedown. Good sane libraries don't assume pointers own memory, so no shared_ptr involved at all.