that is not the same thing as gottlob was proposing.
What Domagoj was asking for was: ...because that is what i was whishing for to be extracted from optional<> - the placement new/in-place construction + aligned storage + reference workarounds&co. wrapped up machinery... with examples of uses. I gave another example of where those internals could be useful, and what I ended up doing.
boost::optional<> doesn't have the problems herb sutter lists, and a type that is only used for in place construction, without optional's conditional bool, wouldn't either.
agreed. I was off on a tangent about just my example.
I've been missing such a type, too, but I think it should be part of the boost in place utility instead of boost::optional: http://www.boost.org/doc/libs/1_35_0/libs/utility/in_place_factories.html
see "container-side usage" there.
Yes, in-place is again similar. At least it handles the construction issues. I see it as either my templates have 10 overloads, or I use in_place (easier for me) and make my users use it as well (bit harder for them). For a fast_impl, the user is probably another library writer, already doing forwarding, so I don't see that as a problem. Definitely lots of code doing similar things - more reasons why it could maybe be split up / reorganized / grouped / etc. Of course, C++0x vararg templates + 'perfect forwarding' would make things easier and change much of this. Tony