That's not how you do type erasure in C++.<p>Have a look at std::any :
<a href="https://en.cppreference.com/w/cpp/utility/any/" rel="nofollow">https://en.cppreference.com/w/cpp/utility/any/</a><p>you can place a value of any type T in it (well, obviously it needs to be constructible etc.), or a std::nullopt, which is like an "Empty" or "Nothing" indicator that is not in T.<p>Then you can pass the `any` around without knowing its type. Finally, when you want to restore the typed value, you use any::get<T>(). It will succeed if T is the correct type, and throw an exception otherwise.<p>This was introduced into C++ in the C++17 version of the standard. Before, it existed as a Boost library facility.
This article is not a good explainer of type erasure because it uses inheritance to do it.<p>I’m waiting for the day that someone figures out and does a blog post showing that every std data structure can be rewritten with type erasure.<p>Here’s how it works:<p>Let’s use vector because it’s simple. This vector impl works with just plain void* memory with no type information.<p>The vector type wrapper (matching std::vector) is a template but instead of recreating the entire data structure with a different type, it will instead create the void* implementing vector in a unique_ptr and pass boiler plate functions so that the vector know how to:
1. the size of T
2. in place constructor of T at the void*
3. in place destructor of T at the void*
4. A copy constructor of T at void* src, dst.<p>The wrapper vector<T> that owns the vector impl then does the necessary casts back to T. For example vector::at could be implemented as such:<p><pre><code> <template typename T>
class vector { // type wrapper.
T& at(size_t i) {
void* p = vector_impl_->get(i);
T* t = static_cast<T*>(p);
return *t;
}
...
}
</code></pre>
In this example, vector<T> wrapper would still be inlined everywhere, however VectorImpl could be defined exactly once in a cpp file. The template bloat problem is reduced from the entire data structure to just the wrapper casting back and forth from void* <—> T&.<p>This can be extrapolated to complex algorithms like std::map. And as a bonus the polymorphic wrapper can do all the boiler plate generation so that the interface could be made to match the std::map.<p>Testing the bloat size reduction could be performed on a code base with significant usage of std map across multiple types, and see if the optimizing compiler will reduce the final binary size with the type erased map swapped in.
I'm not sure whether Bar having a duck-typed constructor looking for the <i>presence</i> of a method is a good or bad idea, and I rather dislike how `Bar *` and `Bar &` requires a double-indirection to call its contents. It feels inefficient, but I don't know if it's actually slower in practice, and I haven't setup a benchmark to test. <a href="https://www.reddit.com/r/cpp/comments/cs9ue4/performance_benchmarks_of_type_erasure_methods/" rel="nofollow">https://www.reddit.com/r/cpp/comments/cs9ue4/performance_ben...</a> looks interesting but there's a lot of data and I didn't look at the source code of the various benchmark cases.
> <i>But the result is beautiful.</i><p>Ugly as hell, ouch! Really?<p>GNU C++ had something called signatures years ago, which was removed. It was far more elegant.<p>You could declare a <i>signature</i> which was a class-like thing: function declarations in curly braces.<p>Having that signature declared, you could lift a pointer of that type to any object which had those functions (without any relationship to the signature having to be declared by that object).<p>Found a nice document on it:<p><a href="https://csc.lsu.edu/~gb/Signatures/index.html" rel="nofollow">https://csc.lsu.edu/~gb/Signatures/index.html</a><p>So, here is how the code would look:<p><pre><code> class Bar { // nothing to inherit here
public:
void doSomething() { }
};
signature Do {
void doSomething();
};
void foo(Do &doer)
{
doer.doSomething();
}
int main()
{
Bar bar;
foo(bar);
}
</code></pre>
When <i>foo</i> is called with <i>bar</i>, a <i>Do &</i> signature reference is taken to <i>bar</i>. This is allowed because the type Bar has all the functions declared in the signature type Do, making it compatible.<p>Sure, the implementation has to bend over backwards. But signatures are more declarative, so the implementation has a clearer idea of your intent. It can do whatever magic is required.<p>It seems clear to me that there is a static way to bind the Do signature reference to the Bar type. You probably have to construct some vtable like object which does the right sort of indirection.<p>The translation unit could emit some hidden __Do__Bar_table item which does exactly that: it's a vtable-like table made in the shape of Do, which is filled with pointers (perhaps fat pointers with offsets and whatever is necessary) to the matching functions in Bar.<p>If that can be set up at compile time, then maybe the <i>Do &doer</i> argument just has to be some sort of fat reference consisting of the pointer to <i>bar</i>, and to the __Do_Bar_table which translates the Do calls into Bar calls.<p>It seems cheaper than the convolution presented in this article.<p>Signatures didn't make it into ISO C++, but since that time, a lot of cruft has which is worse.<p>Looks like this 1999 commit may be what removed signatures:<p><a href="https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=6eabb2412f6c4c8306fb2f8fd05abf608e29caa9" rel="nofollow">https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=6eabb2412f6c4c...</a><p>It doesn't point to any information about the removal. We probably have to dig into mailing lists. At least it gives a date, thanks to which we can find this posting. Unfortunately, the one from which it quotes is missing for some reason:<p><a href="https://gcc.gnu.org/pipermail/gcc/1999-August/035433.html" rel="nofollow">https://gcc.gnu.org/pipermail/gcc/1999-August/035433.html</a><p>"This patch removes support for `signature', a g++ extension that is little-used and which Jason and I agreed should go. The reduction in complexity elsewhere in the front-end will be a big win."<p>OMG, you would absolutely not see this today in C++ development. "Jason and I" decided that some C++ gadget is too little used and we will remove it.<p>How naive that seems; these people had no idea about the deluge of garbage that was coming down the pipe into standard C++ over the following two decades, that they would have to implement.<p>They removed a good thing on a whim.
I am not sure this is an improvement.<p>What is the added value? What is the cost?
Virtual methods are not free.
Indirections are not free (when you read the code)