Re: [boost] [UUID] uuid.hpp Objective C++ conflict.

Subject: Re: [boost] [UUID] uuid.hpp Objective C++ conflict.
From: Andy Tompkins (atompkins_at_[hidden])
Date: 2009-08-25 09:04:54

On Fri, 21 Aug 2009 14:46 -0700, "Scott McMurray"
<me22.ca+boost_at_[hidden]> wrote:
> 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.

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.