Corrado Zoccolo wrote:
>
> as
> well as providing a well known optimization technique to avoid dynamic
> allocation when the involved objects are small.
The problem with small object optimization is that you get the same
issue that boost.variant has: it's hard to maintain the never-empty
guarantee in operator=, because the copy constructor of a new value can
throw and thus you lose the old value.
I wonder, by the way, how boost.function solves that issue.
Apart from that, what does optional_poly<T> give that optional< poly<T>
> doesn't, apart from a small save of memory ?
Maybe optional should be specialized, rather, to allow it to be more
efficient for your type.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
