|
Boost : |
Subject: Re: [boost] [UUID] uuid.hpp Objective C++ conflict.
From: Scott McMurray (me22.ca+boost_at_[hidden])
Date: 2009-08-21 17:46:20
2009/8/21 Mostafa <mostafa_working_away_at_[hidden]>:
>
> 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.
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk