On 09/20/10 10:50, dherring@ll.mit.edu wrote:
On Sat, 18 Sep 2010, Larry Evans wrote:
On 09/17/10 13:31, OvermindDL1 wrote:
On Fri, Sep 17, 2010 at 9:46 AM, <dherring@ll.mit.edu> wrote: [snip]
It doesn't satisfy my need for everything to be in-place (e.g. for seamless use with shared memory, memory pools, etc.). [Note: we don't actually use std::string; it was just convenient for the example.]
How is it not in-place? ... Maybe Daniel doesn't want to pay for the extra memory required by the which. At least that's the only reason I can think of :(
See http://www.boost.org/doc/libs/1_44_0/doc/html/variant/design.html
In particular, "Temporary Heap Backup" and "Future Direction".
We have some specialized requirements. We couldn't even use boost::shared_ptr until it added both the custom allocator and deleter. The "never-empty guarantee" conflicts with our needs and is not a concern at this time.
As a side note, we also must expose both the type of the "which" and the discriminant to member mapping (which may be N:1; see the CORBA IDL spec). So I believe boost::variant would still be hard to use even if the heap issue were resolved.
Later, Daniel
An alternative to boost::variant is the: http://svn.boost.org/svn/boost/sandbox/variadic_templates /boost/composite_storage/pack/container_one_of_maybe.hpp which *might* work for you. I say *might* because I don't know exactly what you mean by: "never-empty guarantee" conflicts with our needs because those needs are not spelled out. The container_one_of_maybe doesn't have a "never empty" guarantee. Instead, it allows the container to have an uninitialized state indicated by which() returning a special value. Also, the type of which() can be user specified which may satisfy your requirement to: expose the type of the "which" This user specification is done by specializing: template < typename Index //2nd arg to composite_storage template //e.g. mpl::integral_c<int,Index0> //where Index0 is index of 1s element //of the components. > struct enum_base { typedef //type of discriminant. For example, int or char. //Usually some function of Index. type ; }; I'm also unsure of what's meant by: the discriminant to member mapping (which may be N:1). If you mean types could be duplicated, IOW, allow: variant<int,int> then that's what one_of_maybe does. The one place I found for corba spec (found with google "corba idl spec") was here: http://www.objs.com/x3h7/corbaidl.htm A search for "discrimin" on that page found: discriminated union type consistingof a discriminator followed by an instance of a type appropriate to thediscriminator value This layout (discriminant followed by dependent value) is the exact reverse of the container_one_of_maybe is laid out. Originally, the discrimiant was 1st; however, the following post: http://article.gmane.org/gmane.comp.parsers.spirit.general/19226 explains the reason for the change. It also shows the location of the non-variadic template version of the code. If you really need the order reversed, it could be changed back without much trouble. I guess it could be made a policy for one_of_maybe; however, that would mean another template parameter :( Hope that was clear enough ;) Please let me know if not. -regards, Larry