Implementing a class with void*

Post by [deleted] » Tue, Aug 31, 2021, 1:08 AM UTC

duped wrote: post #17

vvanders wrote: post #13

Earlier quoted context omitted.

> and maybe more surprisingly, add/removing virtual functions I don't have the spec handy but fairly certain that v-table implementation is compiler specific and while it may work it isn't guaranteed. However if you declare the function symbols as dynamic then you can leverage the linker to dynamically resolve the right symbols with the matching opaque data and achieve binary compatibility(assuming you use the same c…

vtable layout is defined by the ABI, which is (mostly) consistent across major compilers everywhere except MSVC, however if MSVC ever broke vtable layout then everything that relies on COM would break on Windows. Which is basically all of Windows user space.

Post by srwest » Tue, Aug 31, 2021, 1:22 AM UTC

Post by ridiculous_fish » Tue, Aug 31, 2021, 1:51 AM UTC

vlovich123 wrote: post #20

prewett wrote: post #4

I'm surprised he doesn't refer to it by name (Pimpl). In C++ it has the advantage that you can change your implementation and retain binary compatibility because the size of your class doesn't change as you add/remove member variables (and maybe more surprisingly, add/removing virtual functions). If you're going to use C++, seems like it would be better to avoid the void* by class C { protected: struct Impl; std::uni…

The downside of unique_ptr used this way is that you have to define ~C in the same translation unit that the declaration of C::Impl lives.

    struct deleter_t { void operator()(impl_t *); };
    using impl_unique_ptr_t = std::unique_ptr;

Post by sgerenser » Tue, Aug 31, 2021, 1:54 AM UTC

guerrilla wrote: post #3

sillycross wrote: post #2

This is a well-known way to achieve separation of definition and implementation. The disadvantage of the method proposed in the article is that, now everything needs a pointer indirection. A solution that fixes the drawback is used by lz4's library implementation: instead of storing a void star, store a char[] array of same size as the real struct. (of course, now you have to manually make sure the struct size are in…

Why not `typedef struct state state_t` in the header file, then have a `state_t state` in the header file with the `struct state { ... }` definition in the source file? This is similar to what I do in C, I don't see why it wouldn't work in C++.

Post by ryandrake » Tue, Aug 31, 2021, 2:33 AM UTC

anthony_r wrote: post #6

prewett wrote: post #4

I'm surprised he doesn't refer to it by name (Pimpl). In C++ it has the advantage that you can change your implementation and retain binary compatibility because the size of your class doesn't change as you add/remove member variables (and maybe more surprisingly, add/removing virtual functions). If you're going to use C++, seems like it would be better to avoid the void* by class C { protected: struct Impl; std::uni…

Came here to say exactly that. You can also do this, thought it looks a little worse it allows for even more flexibility, such as complete decoupling of Impl from A across different files: // Forward declaration of Impl. What does Impl do? // You're not allowed to know. class Impl; class A { protected: Impl* mImpl; }; I've been using this trick but for a different reason - to reduce the number of #include statements…