5

I got tired of waiting for compiler support of nullptr (gcc 4.6 does but it's so new few distributions support it).

So as a stop gap until nullptr is fully supported I decided to emulate it. There are two examples of emulation: one from here, and one from wikibooks.

Of note, neither implementation mentions an operator ==. However, without one, the following code will not compile.

int* ptr = nullptr;
assert( ptr == nullptr ); // error here: missing operator ==

Is this operator == error a compiler bug?
Is operator == (and !=, <, <=, etc) needed to more perfectly emulate nullptr?
What else is different between an emulated nullptr and the real deal?

Community
  • 1
  • 1
deft_code
  • 57,255
  • 29
  • 141
  • 224
  • 2
    Why would you do this instead of `assert(ptr);` in the first place? – ildjarn Jun 07 '11 at 17:23
  • @Neil Butterworth: That's not true. `nullptr` has to be part of the Standard because it only has value when everybody uses the same null pointer type- `std::nullptr_t`. If everyone implemented their own null pointer, how would you write a function that would accept a null pointer? You don't know what the null pointer type is. – Puppy Jun 07 '11 at 17:28
  • @ildjarn: I used an assertion to clean up the code. My actual example was `std::remove( v.begin(), v.end(), nullptr );` which uses the equality operator. And the reason I wont just use `std::remove_if` is I don't want to. I want it to just work like the real `nullptr`. – deft_code Jun 07 '11 at 17:41
  • Fair enough, I didn't think about implications within the standard library. – ildjarn Jun 07 '11 at 23:20

3 Answers3

3

You compiled it with C++0x compiler that failed for unknown reason. It compiles fine in C++03.

Yakov Galka
  • 70,775
  • 16
  • 139
  • 220
  • So, back to my original question. Is this error an effect of new c++0x language rules? Or is it a bug that was introduced into gcc when the other c++0x features were added? – deft_code Jun 07 '11 at 17:44
  • 3
    @deft_code: 1) your code is invalid C++0x because it uses the keyword nullptr. 2) I'm 90% sure it's a GCC bug 3) there already was a [similar bug](http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33990). – Yakov Galka Jun 07 '11 at 17:45
  • Great find with that bug. My [exact error case](http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33990#c4) is listed in the comments. In response to point 1 I've gotta say _no duh!_ It's obviously invalid in a fully compliant c++0x compiler. gcc 4.5 isn't fully compliant yet, and hence my need to emulate a keyword. – deft_code Jun 07 '11 at 17:57
1

Yes, you should implement such a thing. I am, however, surprised that the implicit conversion operators aren't kicking in and allowing you to compare without providing an explicit operator.

template<typename T> bool operator==(T* ptr, nullptr_t null) {
    return ptr == 0;
}
template<typename C, typename R> bool operator==(R C::* ptr, nullptr_t null) {
    return ptr == 0;
}
// And the reverse
Puppy
  • 144,682
  • 38
  • 256
  • 465
1

It's actually mentioned in the official proposal from your first example reference:

Experiments with several popular existing compilers show that it generates poor and/or misleading compiler diagnostics for several of the common use cases described in section 2. (Examples include: “no conversion from „const ‟ to „int‟”; “no suitable conversion function from „const class ‟ to „int‟ exists”; “a template argument may not reference an unnamed type”; “no operator „==‟ matches these operands, operand types are: int == const class ”.) We believe that compilers will still need to add special knowledge of nullptr in order to provide quality diagnos- tics for common use cases.

So you should fill this gap yourself if the compiler doesn't yet.

littleadv
  • 20,100
  • 2
  • 36
  • 50
  • That poor compiler diagnostics discussion is in reference to an unnamed `nullptr` type. However, the standards committee decided that `nullptr` would have the type `nullptr_t`. All of those cryptic error messages get a lot better when the `nullptr` class is named `nullptr_t`. – deft_code Jun 07 '11 at 18:06