Use std::any for storage?

[T-640]

Greetings!

What you have here is an excellent approach to tackle polymorphism without having to deal with pointers. This trick has let me to simplify the code of my project by a magnitude of order.

Initially I came across this technique by reading this article - https://www.fluentcpp.com/2021/01/29/inheritance-without-pointers/. It uses a slightly different approach, in particular using the std::any itself to store the class instance. Then I found your project here. Looking at both I am trying to figure out what could be the perfect such "Any of" class for me and would like to discuss a few things about it.

What do you think, which of the two approaches is more correct? On one hand using std::any simplifies the code a bit, notably taking care of copy/move constructors and assignment operators, as well as storage, so there is no need to write identical code for any of that. On the other hand, we are not really storing any object here, but rather a constrained subset of objects, so not using std::any seems to be more semantically correct, hence the "Any of" instead of the plain "Any" name.

[samee]

Hi, I'm glad that you think this might be useful!

First, a general comparison before getting into the article you linked.

With this any_of, you will be able to use base class members or methods without any casting. Plus, it helps writing correct code since nobody will be able to accidentally assign an object of the wrong type without raising a compile-time type error.

With std::any, you get the benefit of familiarity. If you expect other people to understand and modify your code, it's one less thing they have to learn.

Looking at the article you linked, I think any_of obviates the need for a separate wrapper class for each interface. Instead of hand-rolling your own Calculator class with storage and getter, you can just use using Calculator = any_of<ICalculator>; to achieve the same effect.

Hopefully this will reduce some more boilerplate in your code.

[T-640]

I'm glad that you think this might be useful!

It's not just a matter of my personal opinion, I do believe this is objectively the best way to deal with copyable polymorphic objects (for non-copyable unique ones the std::unique_ptr should be enough). Polymorphism in C++ is great, but notorious for having to resort to dealing with pointers. This technique fixes this major issue.

And also it appears to be invaluable when multithreading and polymorphism are involved together. Before I came across this trick multiple threads had to access pointers to these polymorphic objects (let's call them "calculators" for the sake of simplicity). I had to take great care of making sure that access to these pointers is thread-safe, that at shutdown threads terminate before the "calculators" get destroyed and so on. But now all I have to do is to supply each thread with its own set of "calculators", so each thread deals with its own copies of "calculators". No more pointers and manual memory management, threads can not mess up other threads because now they have their "personal" "calculators".

I am surprised that this technique does not have the attention it deserves. That article and your repository is all I could find on the subject.

With this any_of, you will be able to use base class members or methods without any casting

True, also std::any_cast in that implementation from the article introduces a performance penalty, although it can be circumvented by adding a pointer to the object stored in std::any and then supplying copy constructor and copy assignment operator to update that pointer. Pretty much what you're doing, except instead of using the any_of_dispatcher_base::copy we copy the std::any object. std::any also uses RTTI which might not be available, so one more point towards your implementation.

Plus, it helps writing correct code since nobody will be able to accidentally assign an object of the wrong type without raising a compile-time type error

I think the std::is_base_of check that you are referring to might be redundant. This was the first thing I myself added when I took the code from that article, but then out of curiosity I removed it and tried to pass some unrelated object into the wrapper, and it still raised a compile-time error. I think this might be true in your case as well, so you could check it out.

With std::any, you get the benefit of familiarity. If you expect other people to understand and modify your code, it's one less thing they have to learn.

That's the point. With std::any we get a simpler code at the cost of bloating the class with features we do not use. With your implementation we get precisely what is required to get the job done, no more no less ("Do One Thing and Do It Well" as the Unix wisemen say), at the cost of doing a few things manually. Which one is the most correct approach? At first I thought I'd better stick with the std::any solution, thinking that anything else is probably reinventing the wheel. But now I am starting to change my mind, gravitating more towards your solution, because using std::any for this narrow use case seems like using heavy artillery in a situation where lighter but more precise "weaponry" would suffice. So despite being more sophisticated your solution is probably more elegant nonetheless. And the extra complexity is not really that hard to understand. I know it's not easy to stay objective when talking about your own work, but are you thinking the same way?

I am probably being pedantic here, just trying to find out what would be the perfect such class, since this technique plays an extremely important role in my project.

...you can just use using Calculator = any_of ICalculator to achieve the same effect...

Yea, that's pretty much what I am using already, switching to your implementation would be just a matter of changing a single header.

[samee]

I am surprised that this technique does not have the attention it deserves. That article and your repository is all I could find on the subject.

Thanks for the praise. Please feel free to spread the word. I am not good at bragging for myself.

std::any also uses RTTI which might not be available, so one more point towards your implementation.

I believe RTTI will still be needed for dynamic_cast inside any_of_cast. That said, you are right that many typical uses of any_of might not need any casting. Or anything like the type() method.

I think the std::is_base_of check that you are referring to might be redundant.

I'll keep it for now. If I remove it, I worry that the error messages might get more cryptic. If user provides the wrong type, it can now complain directly about not finding a user-visible compatible constructor. If I remove it, it will probably complain about some internal method that the user should not need to know about. But thanks for the suggestion. I can see myself removing it in some projects where I don't want the extra compilation time for including type_traits.

I know it's not easy to stay objective when talking about your own work, but are you thinking the same way?

Yes, that's why I took the time to post it here. Cheers!

[samee]

That article and your repository is all I could find on the subject.

I wanted to ask, how did you find this repository at all? I didn't try hard to publicize it.

[T-640]

... Please feel free to spread the word ...

I guess I could post this on Reddit, but first I suggest discussing this thoroughly here until we run out of ideas on how to improve the code, and once we are done we may try starting a broader discussion. I have also written to the author of that article, but unfortunately he has never replied. It appears he is not active anymore and has not written any new articles for about two years already.

... That said, you are right that many typical uses of any_of might not need any casting. Or anything like the type() method

Precisely, the type information is captured at compile time so RTTI is not a fundamental dependency here, but still having a few extra convenience functions that do not ruin the architecture of the class, just in case someone might need that, is nice. Hard to imagine anyone using them though, and relying on the type_info and dynamic_cast might be a sign of some poor design choices, but why not?

... If I remove it, I worry that the error messages might get more cryptic ...

Very good point, I agree that this should stay. In that case perhaps moving this check into the constructor's body to use static_assert could provide the most informative message? Regarding the extra compilation time, is it worth it to take this into account? Correctness comes first, and while I have never thoroughly examined the subject of templates impacting the compile time, I feel this could be negligible here.

I wanted to ask, how did you find this repository at all?

I do not remember it now, but as far as I recall by pure accident. I think I have been looking for some std::any implementation to examine how the instance storage is handled and casting is done. By that time I had already read that article, so seeing the any_of name in the search result I have probably decided to have a look out of curiosity.

So finding this, even for those who know what they are looking for, is quite difficult, to say the least. Perhaps adding something like "Inheritance/Polymorphism without pointers" and probably some other keywords could help the search engines?

P. S. Finally, I think I have found a way to simplify the code to the point when I can confidently claim "We definitely don't need std::any for this". The major point of the both any_of_dispatcher classes is to provide the copying mechanism, and I think they can be removed in favour of a lambda function doing the same job. The trick here is that the lambda can capture the compile-time context like the type of the Derived class, so we do not need to create extra base classes to store that. And with any_of_dispatcher classes removed we can now store the pointer to the contained instance in the any_of class itself. Also using a function pointer instead a virtual function improves performance.

Beware that this is a rough sketch, I have not tested it and simply immediately wrote the first thing that came to my mind. Note the added make_copy function pointer and the edited constructor that assigns the lambda to it.

#include <typeinfo>
#include <type_traits>

template <class Base>
class any_of
{
public:
    // This checks is_base_of, but we can relax this if needed.
    // In the worst case, just delete the second type parameter.
    template <class Derived,
              class = typename std::enable_if <std::is_base_of <Base,Derived>::value>::type>
    any_of (Derived d)  // can't be noexcept, because 'new'
        // Used reinterpret_cast just in case, it is probably redundant
        : make_copy ([] (Base* base) { return new Derived (*reinterpret_cast<Derived*>(base)); }),
	  ptr_ (this->make_copy (&d)) {}

    any_of (const any_of& that) : ptr_ (make_copy(that.ptr_)) {}

    any_of (any_of&& that) noexcept { ptr_ = that.ptr_; that.ptr_ = nullptr; }

    ~any_of () { delete ptr_; }

    any_of& operator=(const any_of& that)
    {
        reset();
        if (that) this->ptr_ = make_copy (that.ptr_);
        return *this;
    }

    any_of& operator=(any_of&& that) noexcept
    {
        reset();
        this->ptr_ = that.ptr_;
        that.ptr_ = nullptr;
        return *this;
    }

    void reset() noexcept { delete ptr_; ptr_ = nullptr; }
    bool has_value() const noexcept { return ptr_ != nullptr; }
    operator bool() const noexcept { return ptr_ != nullptr; }
    const std::type_info& type() const { return ptr_ ? typeid(*ptr_) : typeid(void); }

    Base& operator*() { return *ptr_; }
    const Base& operator*() const { return *ptr_; }
    Base* operator->() { return ptr_; }
    const Base* operator->() const { return ptr_; }
    Base* get() { return ptr_; }
    const Base* get() const { return ptr_; }

    template <class D, class B> friend D* any_of_cast(any_of<B>* a);
    template <class D, class B> friend const D* any_of_cast(const any_of<B>* a);

private:
    Base* (*make_copy) (Base*);
    Base* ptr_; 
};