1

I came across an older pondering Type erasure techniques, by Xeo, and I became to wonder, how should one to amend that code to make it work with std::unique_ptr'ers and std::shared_ptr'ers.

The code in the post can be found here. The code won't compile if fed with something containing unique_ptrs and the data in shared_ptr'ers become garbage. What I tried was a class inherited from a templated base class, so maybe it was somewhat complicated too. Now, this is mainly out of curiosity, as I became to wonder if it would be difficult (in general case) as this could become handy when storing complex objects, say, in std::vector when Boost.Any isn't available for use.

Edit: I noticed I just had a bug in my code whilst testing, the code works just fine with shared_ptr'ers (the contents aren't garbage), though not with unique_ptr'ers. And then also, why not store a newed instance of this type erasured Any_Virtual (as in code provided by Xeo) to, say, std::unique_ptr'ers.

I guess then the questions would be:

  1. How to amend the Any_Virtual so that it could work with std::unique_ptr?
  2. Which one would be better design, a std::vector<Any_Virtual> objects, where Any_Virtual holds a smart pointer, or a std::vector<std::unique_ptr<Any_Virtual>> objects? Or does it even matter?
Community
  • 1
  • 1
Veksi
  • 3,556
  • 3
  • 30
  • 69

1 Answers1

3

When you use type-erasure there is always a set of requirements that a type must satisfy to be compatible with the type-erasing container: this set is called the model. In particular, the holder<T>::clone member that copies *this requires in turn that held_ (of type T, the type being erased) be copy constructible. Hence the model of your type-erasing class is copy constructible.

However a type containing an std::unique_ptr will not be copy constructible out of the box.

There is no obvious fix without knowing what you want to achieve. Perhaps you really want the model to be less strict, e.g. it could only require to be move constructible (which a type containing an std::unique_ptr can easily fulfill, right out of the box). Or perhaps you really want those types that do hold std::unique_ptrs to be copy constructible.

In my opinion the very worst you can do with type-erasure is to compromise, and make an operation on the model work conditionally, depending on whether the type being erased supports such an operation itself. Here that would mean that coyping an Any_Virtual value would result in an exception if it happened to hold a value of non-copy constructible erased type.

Perhaps more worryingly, the fact that you obtain garbage std::shared_ptrs heavily suggest that there is a problem with either your implementation of Any_Virtual or your use of it. You should definitively not assume that there is a problem with using std::shared_ptr in tandem with Any_Virtual alone, but that there might be a problem with using anything with Any_Virtual. Since I haven't noticed a problem in the implementation (but I could easily have overlooked something), I'd like to see an example of a program exhibiting the problem.

Luc Danton
  • 34,649
  • 6
  • 70
  • 114
  • Indeed, it was that I made an erroneous .As() operation, so the fault on garbage lay solely on my feet. It looks like I made the edit whilst you composed your answer. Move constructible would be enough in this case, and I have a feeling in general it rhymes better with what std::unique_ptr stands for. So, in this case, what would suffice is to add facilities for move contructor to Any_Virtual, I understand..? I concur with the compromise thing. – Veksi Aug 18 '12 at 18:56
  • Though I'm still split on should one have a vector full of Any_Virtual (or boost::any) types, which may be smart pointers, or a vector full of smart pointers, which have type erasing objects as a pay-load. Is there, can there be, preference in any direction? Or does it depend on matters like if there will be POD (built-in type and POD classes) and more complex types? – Veksi Aug 18 '12 at 18:58
  • @Veksi There is no reason to have `std::vector>` over `std::vector`. – Luc Danton Aug 19 '12 at 02:40