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@gmail.com> Newsgroups: gmane.comp.lib.boost.devel To: <boost@lists.boost.org> 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.homogene... [4] http://www.boost.org/doc/libs/1_37_0/libs/serialization/doc/traits.html#temp...
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_m...
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_pr...
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