In c++17, std::any was added to t he standard library. Boost had their own version of “any” for quite some time before that.

I’ve been trying to think of a case where std::any is the best solution, and I honestly can’t think of one. std::any can hold a variable of any type at runtime, which seems incredibly useful until you consider that at some point, you will need to actually use the data in std::any. This is accomplished by calling std::any_cast with a template argument that corresponds to the correct type held in the std::any object.

That means that although std::any can hold a type of any object, the list of valid objects must be known at the point that the variable is any_cast out of the std::any object. While the list of types that can be assigned to the object is unlimited, the list of types that can be extracted from the object is still finite.

That being said, why not just use a std::variant that can hold all the possible types that could be any_cast out of the object? Set a type alias for the std::variant, and there is no more boilerplate code than you would have otherwise. As an added benefit, you ensure type safety.

  • corroded@lemmy.worldOP
    link
    fedilink
    arrow-up
    3
    ·
    2 months ago

    You bring up a great point with callback functions. I have written plenty of code that uses a 3rd-party library that expects a void* in a callback, and code I write myself is almost certainly never going to be used by anyone other than me (so I already know what types are valid). If library authors would start using std::any instead of void*, that would certainly improve things significantly. void* is really one of the very few C-style language features that I still use, and only because of necessity.