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