Re: [boost] [UUID] PODness Revisited

Subject: Re: [boost] [UUID] PODness Revisited
From: Vladimir Batov (batov_at_[hidden])
Date: 2008-12-24 15:32:31

Scott,

IMHO you raise a mighty point very much worth looking into. At least I 
surely will be pouring through your references, dusting off and looking at 
those ol' PODs (which I admit long-time discarded) from an entirely 
different angle.

> It's also trivial for someone to build a non-POD out of the pod should
> they desire:

I've been thinking along these lines also. For that reasons I am leaning to 
resigning to the nil-generating def. cnstr as it seems the majority view and 
seems to considerably simplify the implementation.

Best,
V.

P.S. And you named a namespace after me. Isn't it nice? ;-)

----- Original Message ----- 
From: "Scott McMurray" <me22.ca+boost_at_[hidden]>
Newsgroups: gmane.comp.lib.boost.devel
To: <boost_at_[hidden]>
Sent: Thursday, December 25, 2008 7:05 AM
Subject: [UUID] PODness Revisited

> On IRC today, Dodheim made an excellent point: A uuid should be a POD,
> because that way it interacts better with Boost.MPI and
> Boost.Interprocess.
>
> MPI seems like an absolutely perfect situation in which to use UUIDs.
> However, going through serialization can more than 10 times slower
> than using using datatypes[1].  For something to be a datatype, it
> needs to be a POD[2], and thanks to the portable binary format, uuids
> can always use the BOOST_IS_BITWISE_SERIALIZABLE[3][4] trait since a
> UUID's bit format is independent of endianness and word size.
>
> [1] http://www.boost.org/doc/libs/1_37_0/doc/html/mpi/performance.html
> [2] 
> http://www.boost.org/doc/libs/1_37_0/doc/html/boost/mpi/is_mpi_datatype.html
> [3] 
> http://www.boost.org/doc/libs/1_37_0/doc/html/mpi/tutorial.html#mpi.homogeneous_machines
> [4] 
> http://www.boost.org/doc/libs/1_37_0/libs/serialization/doc/traits.html#templates
>
> Of course, you don't want to send UUIDs by themselves.  This is even a
> bigger point, since if uuid isn't a POD, then sending composite types
> that include UUIDs pay the price of going through serialization too,
> even when they could have done the cheap way normally.
>
> Similarly, making uuid a POD allows it to be placed in
> Boost.Interprocess shared memory without the cost of going through
> serialization.  For example, "A message queue just copies raw bytes
> between processes and does not send objects"[5], which requires a POD
> without member pointers to be safe.
>
> [5] 
> http://www.boost.org/doc/libs/1_37_0/doc/html/interprocess/synchronization_mechanisms.html#interprocess.synchronization_mechanisms.message_queue
>
> I think that these are two good examples that POD is the
> quintessential form for a value type, not something "clearly dragged
> in due to backward compatibility with C"[6].  In addition, note that
> even Boost.Proto, one of the fancier libraries in Boost, uses
> aggregates extensively[7].
>
> [6] http://permalink.gmane.org/gmane.comp.lib.boost.devel/184223
> [7] 
> http://www.boost.org/doc/libs/1_37_0/doc/html/proto/appendices.html#boost_proto.appendices.rationale.static_initialization
>
> It's also trivial for someone to build a non-POD out of the pod should
> they desire:
>
> namespace vladimir {
>    struct uuid : boost::uuid {
>        uuid() : boost::uuid(boost::uuids::native_generator()()) {}
>        uuid(boost::uuid id) : boost::uuid(id) {}
>    };
> }
>
> ~ Scott
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>