[UUID] uuid.hpp Objective C++ conflict.
Hello, I'm interested in using the uuid library for iphone development. Unfortunately, I can't use it "out of the box" because the function nil in uuid.hpp collides with the Objective C keyword of the same name and, hence, I get a compiler error. If I change the name to mynil, then it compiles ok. 1) Given this conflict, will you still proceed with the same function name? (As an fyi, all other boost libraries I've incorporated into the iphone fortunately don't have this problem.) 2) If so, do you have any suggestions on how I can handle this issue besides manually changing the function name from nil to something else? Thanks, Mostafa
You can use #define to redefine nil. I've used it for this very problem. Chris On Mon, Aug 17, 2009 at 6:02 PM, M M<mostafa_working_away@yahoo.com> wrote:
Hello,
I'm interested in using the uuid library for iphone development. Unfortunately, I can't use it "out of the box" because the function nil in uuid.hpp collides with the Objective C keyword of the same name and, hence, I get a compiler error. If I change the name to mynil, then it compiles ok.
1) Given this conflict, will you still proceed with the same function name? (As an fyi, all other boost libraries I've incorporated into the iphone fortunately don't have this problem.)
2) If so, do you have any suggestions on how I can handle this issue besides manually changing the function name from nil to something else?
Thanks,
Mostafa
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
2009/8/17 M M <mostafa_working_away@yahoo.com>:
1) Given this conflict, will you still proceed with the same function name? (As an fyi, all other boost libraries I've incorporated into the iphone fortunately don't have this problem.)
The name was chosen as that's what it's called in S4.1.7 of the UUID RFC: http://www.ietf.org/rfc/rfc4122.txt Do you have a suggestion for a new one?
2) If so, do you have any suggestions on how I can handle this issue besides manually changing the function name from nil to something else?
I think the only other option would be something nasty like this: #define nil empty #include <boost/uuid.hpp> #undef nil
Scott McMurray wrote:
The name was chosen as that's what it's called in S4.1.7 of the UUID RFC: http://www.ietf.org/rfc/rfc4122.txt
Do you have a suggestion for a new one?
When using a keyword, the typical approach is usually to append _. So you could rename nil to nil_.
Scott McMurray wrote:
2009/8/17 M M <mostafa_working_away@yahoo.com>:
1) Given this conflict, will you still proceed with the same function name? (As an fyi, all other boost libraries I've incorporated into the iphone fortunately don't have this problem.)
The name was chosen as that's what it's called in S4.1.7 of the UUID RFC: http://www.ietf.org/rfc/rfc4122.txt
Do you have a suggestion for a new one?
1.0) Why not make a static class variable named NIL, since nil() returns the same value all the time? 2) (I know this is off topic and I admit that I haven't researched the mailinglists for this one) If it's still going to remain a function, shouldn't it be static?
Mostafa wrote:
1.0) Why not make a static class variable named NIL, since nil() returns the same value all the time?
2) (I know this is off topic and I admit that I haven't researched the mailinglists for this one) If it's still going to remain a function, shouldn't it be static?
Oops: I thought "uuid nil()" was a method of class uuid. So the class I was talking about in 1) and 2) refer to class uuid. 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).
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.
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.
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
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. 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
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.
participants (6)
-
Andy Tompkins -
Chris Weed -
M M -
Mathias Gaunard -
Mostafa
-
Scott McMurray