Boost logo

Boost Users :

From: Niels Dekker - mail address until 2008-12-31 (nd_mail_address_valid_until_2008-12-31_at_[hidden])
Date: 2008-07-09 13:46:09


Ferdinand Prantl wrote:
> Thanks for your suggestions! Niels, you nailed it!
  [...]
> The current requirements of boost::any ensure that the contained
> object is always valid there (if not used too wildly). I should have
> thought about the copying myself... :-) Your wrapper is an elegant
> solution isolating the construction differences from the rest of
> the holder template.

I'm glad you like it. :-) But how do you use it in practice? The
added 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?

Maybe an extra function, boost::any::size_of_value(), would be helpful,
returning the number of bytes of the stored object. What do you think?
How would you deal with various string lengths, within your application?

BTW, after re-reading, I found two shortcomings to the implementation as
I originally suggested, caused by the implementation of the wrapper:

    explicit wrapper(const ElementType (& value)[NumberOfElements])
    {
      std::copy(value, value + NumberOfElements, data);
    }

First of all, it doesn't support storing a multidimentional array (e.g.
int[42][69]) into a boost::any. 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. I'm pretty sure that
both of these issues can be solved, though. The data would need to be
stored in a boost::aligned_storage, and the copying should probably be
done by placement-new, to solve the second issue. Anyway, these two
issues are irrelevant to your request for C-style string support...

Good luck,

  Niels


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net