Re: [Boost-users] Is there an elegant way to initialize an instanceof boost::any with a C-style string constant?

From: Ferdinand Prantl (prantlf_at_[hidden])
Date: 2008-07-09 15:50:59

On Wed, Jul 9, 2008 at 7:46 PM, Niels Dekker
> boost::any array support I suggested would require you to always specify the
> number of character, when retrieving C-style string (char[N]) from a
> boost::any. Wouldn't it?

Damn' you're right again. It broke my code. I realized that I edited
the final version in a different file than I included, oh my...

I use boost::any for serialization and deserialization of both
user-provided values and hard-coded constants. Stream output has to be
done a little clumsily by a custom operator<<() which consists of a
big if/elseif code block deciding what to do according to
boost::any::type(). I found boost::any a little easier to use than
boost::variant for recursive structures. I

Well, it throws me back. Exposing the number of elements of arrays by
boost::any::size_of_value() would help the safety a little but I would
still have to use unsafe_any_cast<ElemType>() assigning it to a
ElemType const *... And I would not be able to decide about the type
by typeid(); at least without introducing any other helper methods.
Bad.

> First of all, it doesn't support storing a multidimentional array (e.g.
> int[42][69]) into a boost::any.

Hmm, even if I will not need it, it would be probably unacceptable for
a general library.

> Secondly, it copies its argument by means
> of copy-assignment, instead of copy-initialization.  So when T is a class,
> wrapping an array of T would do default-construction + assignment, instead
> of just copy-construction.

Yes, it adds another requirement on ValueType which the current
boost::any does not need. Its assignment operator uses std::swap()
which could be used to lessen this but still, generally it remains.

It looks like that retaining the array type would cause quite a
trouble in getting the data out of the boost::any object. Not speaking
about storing it appropriately. It seems that just storing a pointer
does not bring too much overhead. I will have to rethink it.

Thank you very much for your deep insight!
Ferda