On Thu, 20 Aug 2009 10:53:08 -0700, Scott McMurray <me22.ca+boost@gmail.com> wrote:
2009/8/18 Mostafa <mostafa_working_away@yahoo.com>:
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 entirely.
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 Mathias' suggestion.
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 hash_value 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 uuid class. Hopefully it doesn't seem that I'm beating a dead horse, I just like to spell out my rationale. -Mostafa