On Tue, Oct 27, 2009 at 7:13 PM, Domagoj Saric <dsaritz@gmail.com> wrote:
...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...
...for example: 1.... 2.... 3....
4. An in-place fast pimpl. see Herb Sutter's http://www.gotw.ca/gotw/028.htm for why not to do this. Yet I've done it anyhow. I templatized it and it probably turns out to be the same as most of the internals of optional<>. I also managed to mitigate most of the list of his concerns for why not to do this. Still not something to do without good reason, but manageable. eg: // just forward declare CRITICAL_SECTION, // instead of including <windows.h> // and polluting everything with its macros: struct CRITICAL_SECTION; class CriticalSection // windows version of cross-platform CS { in_place_pimpl<CRITICAL_SECTION, 16> pCS; // 16 is sizeof(CRITICAL_SECTION) //... }; In the cpp file for CriticalSection, we check that sizeof(pCS) really is 16, properly aligned, etc. The in_place_pimpl<> also forwards constructor args, implements operator=, etc. But it is not just for in_place_pimpl, it is for any time you need finer control over construction/destruction/storage. In fact, each of those is a policy to the underlying reinterpret_bytes<> or whatever I called it. I probably should have looked at the internals of optional<>, would have made my life easier... Tony