Subject: Re: [boost] [UUID] uuid.hpp Objective C++ conflict.
From: Mostafa (mostafa_working_away_at_[hidden])
Date: 2009-08-21 05:10:36
On Thu, 20 Aug 2009 10:53:08 -0700, Scott McMurray
> 2009/8/18 Mostafa <mostafa_working_away_at_[hidden]>:
>> 1.0) Why not make a static class variable named NIL, since nil() returns
>> the same value all the time?
> Actually, is there a define for Objective C like __cplusplus? Since
> the value-initializer of a POD uuid gives a nil UUID, the function is
> just in case someone wishes added clarity, and could be #ifndef'ed out
Yes, it's "__OBJC__".
I actually like the idea of an explicit function or const variable for nil
uuid *exactly for the purpose of adding clarity*. With instances of POD
types I don't assume that declaration implies initialization, since that's
not the case with the usual cast of characters, i.e., pointers, int,
float, etc. Hence, I automatically initialize any instance of a POD type
that I declare.
For the time being and for my internal copy of the lib, I'm just following
>> As for 2), now I'm wondering why this particular function is a namespace
>> function and not a method (static) of class uuid? (I'll scrounge the
>> mailing lists for an answer in the mean time).
> Part of the point of the alt v13 was to turn the uuid class itself
> into a completely minimal dumb value type. All UUID generation (be it
> random, time-based, hash-based, known values, ...) was moved outside.
> Part of the advantage of this is in making uuid.hpp as limited as
> possible, avoiding the need to pull SHA1 hashing or Mercenne Twisters,
> for instance, into an interface header just because it has a uuid
> parameter somewhere.
Maybe I'm missing something, but a static method does not negate the
PODness of a type, and the nil uuid is already being generated in
uuid.hpp. The only reason I ask this question, and I guess I would
advocate this position, is because it makes sense from an OO perspective.
The creation of an empty instance is usually the responsibility of the
class type of that instance. (That doesn't mean that the class is
responsible for creating all useful variations of itself, that task can
and should be delegated to utility classes.)
A little more into my thought process:
It would seem that all other namespace functions in uuid.hpp must be
namespace functions for two reasons:
1) the language forces it, in the case of the operator functions.
2) it's existing practice for their use in STL, for the case of swap and
Also, via Koenig lookup, these functions would qualify being part of class
uuid's public interface. Let's just say it's OOP with C++ characteristics
But nil didn't fit into the above two categories, therefore no special
reason for it to be a stand alone function, and Koenig lookup does not
apply to it, therefore it really can't be be considered as part of class
uuid's public interface. So, it either should be part of a util class
that generates various uuid values or it should be part of class uuid
itself. Because generating the trivial instance has traditionally been
done by the instance's class, I thought that nil should be moved into the
Hopefully it doesn't seem that I'm beating a dead horse, I just like to
spell out my rationale.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk