Re: PODs, Constructors and the Boost uuid Class
* ng2010:
From http://www.boost.org/doc/libs/1_42_0/libs/uuid/uuid.html and in the
section titled "POD Efficiencies", they give a workaround to the
defficiency/oversight in C++ that a POD cannot have constructors:
class uuid_class : public boost::uuids::uuid
{
public:
uuid_class() // def ctor shouldn't auto gen IMO else this
// class should be called auto_uuid or something
No, that would be unsound design. There is already the POD class if you want an
uninitialized UUID instance. This class would serve no purpose if did nothing. :-)
: boost::uuids::uuid(boost::uuids::random_generator()())
{}
explicit uuid_class(boost::uuids::uuid const& u)
: boost::uuids::uuid(u)
{}
operator boost::uuids::uuid() {
return static_cast<boost::uuids::uuid&>(*this);
}
operator boost::uuids::uuid() const {
return static_cast<boost::uuids::uuid const&>(*this);
}
};
What I don't understand is why the conversion operators in uuid_class
above guarantee anything more than just having defined boost::uuids::uuid
as a class with the constructors given above. The conversion operators
for the operators are just casting *this. Why the operators at all when
uuid_class IS a uuid?
It appears to be meaningless.
With Boost stuff one can never say for sure because those guys are very very
heavily into SFINAE and other subtle template metaprogramming magic and other
at-the-very-front-edge things (I think that's a problem with Boost), but at
least for ordinary programming it's meaningless to have the operators above.
But notwithstanding my comment about Boost intricacies I'm fairly sure that it's
an error, perhaps something left from an earlier version with private
inheritance, because this class lacks an assignment operator that directly takes
a POD argument, and although it will work without it (via value conversion)
that's inefficient so if this example had been quality checked then that
assignment operator would have been there, so, it's not been checked.
Cheers & hth.,
- Alf