On Wed, Feb 9, 2011 at 1:07 PM, Nevin Liber wrote:

What are your exception safety guarantees compared with the current implementation of boost::any?

I do not see the exception safety gurantees required of the held value object changing from the original any.hpp. I am using the placed new construction of course. Does it make any difference? -Adarsh Soodan

AMDG On 2/8/2011 11:54 PM, Adarsh Soodan wrote:

On Wed, Feb 9, 2011 at 1:07 PM, Nevin Liber wrote:

...

What are your exception safety guarantees compared with the current implementation of boost::any?

I do not see the exception safety gurantees required of the held value object changing from the original any.hpp.

What about swap? swap is no-throw now.

I am using the placed new construction of course. Does it make any difference?

In Christ, Steven Watanabe

On Wed, Feb 9, 2011 at 9:44 PM, Dave Abrahams wrote:

Just to be a little less opaque about this, everyone is asking because what you did is very similar to what's done in boost::variant, which led to some very interesting problems described in http://www.boost.org/doc/libs/1_45_0/doc/html/variant/design.html#variant.de... with very non-obvious solutions.

So you might also consider what happens under assignment when the constructor of the new object throws.

Thank you. I realize now that the code I posted will have to become comparatively a lot more complicated to replace boost::any in all situations. I will clean this up when time permits. I was curious if others have solved similar performance problems. I couldn't use boost::variant because I needed it for a message passing library where library user can pass in any message type. boost::variant would have been restrictive if the user wanted to use too many top level types of messages. - Adarsh Soodan

On 9 Feb 2011, at 22:29, Kim Barrett wrote:

On Feb 9, 2011, at 12:38 PM, Adarsh Soodan wrote:

...

I was curious if others have solved similar performance problems. I couldn't use boost::variant because I needed it for a message passing library where library user can pass in any message type. boost::variant would have been restrictive if the user wanted to use too many top level types of messages.

I would be interested in having boost::any (or some variation on it) providing small buffer optimization. That was done for boost::function back around boost 1.34, and something like that would work just fine for my usage. I've given the SBO for boost::any problem a cursory look, but have not yet demonstrated a sufficiently bad performance problem for use there to convince my managers that I should work on that rather than something else.

I believe spirit/home/support/detail/hold_any.hpp contains something like boost::any, with a small buffer optimisation. This is not suitable for directly copying out into general boost. In particular I believe it assume any type held in the 'any' is streamable, and quite possibly doesn't consider issues of exception safety. On the subject of exception safety, I quite like how boost::variant will put a 'boost::blank' in (if that exists in the variant) if the value is lost. A similar 'empty' state for boost::any might solve problems with exception safety, at least for me. Chris