Boost logo

Boost :

Subject: [boost] [UUID] PODness Revisited
From: Scott McMurray ([hidden])
Date: 2008-12-24 15:05:37

On IRC today, Dodheim made an excellent point: A uuid should be a POD,
because that way it interacts better with Boost.MPI and

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.


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.


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].


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

Boost list run by bdawes at, gregod at, cpdaniel at, john at