On Fri, 21 Aug 2009 14:46 -0700, "Scott McMurray" <me22.ca+boost@gmail.com> wrote:
2009/8/21 Mostafa <mostafa_working_away@yahoo.com>:
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.
I think you should communicate to Andy that you'd like it to be called nil_ when compiled for OBJC, as I think that's a reasonable and non-invasive solution.
I will do this if I end up with something called nil. I'm not in front of my code right now but from memory I have: - bool uuid::is_nil() const // return true if a uuid is the nil uuid - struct nil_generator; // to generate a nil uuid - uuid nil_uuid(); to generate a nil uuid, just a easy wrapper function for nil_generator;
Note, however that pod_type x = pod_type(); (or, in C++0x, pod_type x{};) is well-defined value-initialization for all PODs. uuid x{}; will produce a nil UUID just as int *p{}; will produce a null pointer.
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.
I guess I'm thinking now that I should have renamed uuid_namespaces.hpp to uuid_predefined.hpp and included nil() in there.
The only reason I ask this question, and I guess I would advocate this position, is because it makes sense from an OO perspective.
Since I've yet to find agreement on what constitutes "OO", I'm always sceptical of such arguments.
( http://www.paulgraham.com/reesoo.html )
YMMV, ~ Scott
Regards, Andy.