Crash when running basic shape example with MSVC

[benjamind2330]

The basic example:

struct Drawable {
  void draw(std::ostream &out) const {
    te::call([](auto const &self, auto &out) { self.draw(out); }, *this, out);
  }
};

struct Square {
  void draw(std::ostream &out) const { out << "Square"; }
};

int main() {
   
    Square s;
    te::poly<Drawable> d{s};
    d.draw(std::cout);
    return 0;
}

Crashes at runtime when compiled with MSVC. See the live example here:
https://godbolt.org/z/znrPGjxK6

A question about this is also open here:
https://stackoverflow.com/questions/78037810/boost-te-memory-access-failure-with-visual-c

[benjamind2330]

After a little investigating, if we use this version:

struct Drawable : te::poly<Drawable> {
    using te::poly<Drawable>::poly;

it works. Seems to be that this:

return detail::call_impl<I>(
    reinterpret_cast<const detail::poly_base &>(interface),

seems wrong. If we don't inherit from poly as a base, then we still reinterpret cast as if we are, this seems to work for gcc etc, but not for msvc. I don't think this code is valid for this case.

[pfeatherstone]

This library is known to not work with several versions of clang. I think it uses some stateful metaprogramming which is not consistent across compilers. I think type erasure libraries will be much better once we get reflection.

[benjamind2330]

I think type erasure libraries will be much better once we get reflection.

True, but i don't know that i can wait until 2029 for this :p

[pfeatherstone]

The best thing to do is pinch the storage classes (or write your own), manually write a vtable for each type-erased class (interface thing) and manually write the member methods which in turn call the vtable. Does that make sense? It's a bit more manual but it is correct and doesn't rely on heavy metaprogramming to automatically generate a vtable

[pfeatherstone]

The guts of the type erasure stuff are the storage classes which correctly manage memory, copy constructors and move constructors.