www.digitalmars.com         C & C++   DMDScript  

c++.stlsoft - real pointer null (struct NULL_v): question

reply "Martin J. Moene" <m.j.moene eld.physics.LeidenUniv.nl> writes:
 Hi Matthew and al.,

Imperfect C++ (http://synesis.com.au/publishing/imperfect/cpp/), Chapter 15
pages 227-233, describe a real pointer null (struct NULL_v ). Struct NULL_v
is also part of STLSoft
(http://synesis.com.au/software/stlsoft/help/stlsoft__null_8h.html).

Attracted to the idea to trace improper use of NULL, I tried the code from
the book and then from the STLSoft library (1.8.3) itself (See the listing
below)

The results where not what I expected though.

I found that

  a.. with Visual C++ (6.0, 7.1), the library silently ignores my request to
use NULL_v for NULL instead of the original NUL (!)
  b.. whith GNU C++ (Win32 3.2.3) several things do not work as (I think)
they should
The unexpected bahaviour is
  1.. NULL_v cannot be assigned to (converted to) a member-pointer with
STLSoft--GNU C++;
  it works with the code from the book with Visual C++ 7.1 though
  2.. integer i == NULL is accepted where it should not
  3.. integer NULL == i is accepted where it should not
Using struct NULL_v without the free functions ( operator==() and
operator!=() ), work more as expected, but I understand from the book (page
230) that this varies with the compiler:

  In fact, there is a surprising amount of equivocation between the
compilers on which this was tested.  . . .
To overcome the variation, the definition of NULL_v is then expanded with
member equals() and four free operator functions (== and !=).

Now my question is: do the free comparison functions defeat the proper
working of struct NULL_v in combination with non-pointer types (int in the
example)?

When I change the signature of the equality operators in my "book code" to
  inline bool operator== ( NULL_v const &lhs, T * const &rhs )
  inline bool operator== ( T * const &lhs, NULL_v const &rhs )


the compilation with Visual C++ 7.1 fails at the poper places.

Changing it further to

  T const * const& rhs


results in "2 overloads have similar conversions. . . note: qualification
adjustment (const/volatile) may be causing the ambiguity" for the
  fp == NULL_v()
  NULL_v() == fp


comparations, which I can understand.

Can someone shine some light on this matter?

Thanks in adcance.

Please bear with me if I misunderstand the whole thing.

Best regards, Martin.
___

/*
 * test_stlsoft_null.cpp - test STLSoft's NULL_v real null pointer.
 *
 * Visual C++ 7.1:
 * prompt>cl -GX -D_STLSOFT_NULL_v_DEFINED -I D:/Libraries/stl-1.8.3/include
test_stlsoft_null.cpp
 * This compiler silently ignores our request for NULL as NULL_v (!).
 *
 * GCC 3.2.3:
 * prompt>g++.exe -c -I D:/Libraries/stl-1.8.3/include test_stlsoft_null.cpp
 * test_stlsoft_null.cpp: In function `int main()':
 * test_stlsoft_null.cpp:33: cannot convert `stlsoft::NULL_v' to `int' in
assignment
 * test_stlsoft_null.cpp:39: cannot convert `stlsoft::NULL_v' to `int
(A::*)()' in assignment
 */

#define _STLSOFT_COMPILE_VERBOSE 1

#include <stlsoft_nulldef.h>

struct A
{
   int f();
};

int main()
{
   using stlsoft::NULL_v;

   int  i  = 0;                         // integer
   int *pi = &i;                        // pointer to integer
   int (A::*fp)() = &A::f;              // member function pointer

   // Ok: fails
   i = NULL_v();

   // Ok: succeeds:
   pi = NULL_v();

   // Error: fails: test_stlsoft_null.cpp:41: cannot convert
`stlsoft::NULL_v' to `int (A::*)()' in assignment
   fp = NULL_v();

   // Error: should fail (integer)
   if ( i == NULL_v() ) { }

   // Error: should fail (integer)
   if ( NULL_v() == i ) { }

   // Ok: succeeds (pointer):
   if ( pi == NULL_v() ) { }

   // Ok: succeeds (pointer):
   if ( NULL_v() == pi ) { }

   // Ok: succeeds (member pointer):
   if ( fp == NULL_v() ) { }

   // Ok: succeeds (member pointer):
   if ( NULL_v() == fp ) { }

   return 0;
}

===
Sep 08 2005
parent reply "Matthew" <matthew hat.stlsoft.dot.org> writes:
I'm on it. Give me a day or so.

FYI: some compilers do not support strong NULL at all, and some (including
GCC) do not support pointer-to-member.

As for VC7.1, that's just a mistake around lines 74-5 of stlsoft_null.h,
which I've now fixed (and am in the process of testing with various
compilers.)

Cheers

Matthew



"Martin J. Moene" <m.j.moene eld.physics.LeidenUniv.nl> wrote in message
news:dfov05$2abf$1 digitaldaemon.com...
 Hi Matthew and al.,

 Imperfect C++ (http://synesis.com.au/publishing/imperfect/cpp/), Chapter

 pages 227-233, describe a real pointer null (struct NULL_v ). Struct

 is also part of STLSoft
 (http://synesis.com.au/software/stlsoft/help/stlsoft__null_8h.html).

 Attracted to the idea to trace improper use of NULL, I tried the code from
 the book and then from the STLSoft library (1.8.3) itself (See the listing
 below)

 The results where not what I expected though.

 I found that

   a.. with Visual C++ (6.0, 7.1), the library silently ignores my request

 use NULL_v for NULL instead of the original NUL (!)
   b.. whith GNU C++ (Win32 3.2.3) several things do not work as (I think)
 they should
 The unexpected bahaviour is
   1.. NULL_v cannot be assigned to (converted to) a member-pointer with
 STLSoft--GNU C++;
   it works with the code from the book with Visual C++ 7.1 though
   2.. integer i == NULL is accepted where it should not
   3.. integer NULL == i is accepted where it should not
 Using struct NULL_v without the free functions ( operator==() and
 operator!=() ), work more as expected, but I understand from the book

 230) that this varies with the compiler:

   In fact, there is a surprising amount of equivocation between the
 compilers on which this was tested.  . . .
 To overcome the variation, the definition of NULL_v is then expanded with
 member equals() and four free operator functions (== and !=).

 Now my question is: do the free comparison functions defeat the proper
 working of struct NULL_v in combination with non-pointer types (int in the
 example)?

 When I change the signature of the equality operators in my "book code" to
   inline bool operator== ( NULL_v const &lhs, T * const &rhs )
   inline bool operator== ( T * const &lhs, NULL_v const &rhs )


 the compilation with Visual C++ 7.1 fails at the poper places.

 Changing it further to

   T const * const& rhs


 results in "2 overloads have similar conversions. . . note: qualification
 adjustment (const/volatile) may be causing the ambiguity" for the
   fp == NULL_v()
   NULL_v() == fp


 comparations, which I can understand.

 Can someone shine some light on this matter?

 Thanks in adcance.

 Please bear with me if I misunderstand the whole thing.

 Best regards, Martin.
 ___

 /*
  * test_stlsoft_null.cpp - test STLSoft's NULL_v real null pointer.
  *
  * Visual C++ 7.1:
  * prompt>cl -GX -D_STLSOFT_NULL_v_DEFINED -I

 test_stlsoft_null.cpp
  * This compiler silently ignores our request for NULL as NULL_v (!).
  *
  * GCC 3.2.3:
  * prompt>g++.exe -c -I D:/Libraries/stl-1.8.3/include

  * test_stlsoft_null.cpp: In function `int main()':
  * test_stlsoft_null.cpp:33: cannot convert `stlsoft::NULL_v' to `int' in
 assignment
  * test_stlsoft_null.cpp:39: cannot convert `stlsoft::NULL_v' to `int
 (A::*)()' in assignment
  */

 #define _STLSOFT_COMPILE_VERBOSE 1

 #include <stlsoft_nulldef.h>

 struct A
 {
    int f();
 };

 int main()
 {
    using stlsoft::NULL_v;

    int  i  = 0;                         // integer
    int *pi = &i;                        // pointer to integer
    int (A::*fp)() = &A::f;              // member function pointer

    // Ok: fails
    i = NULL_v();

    // Ok: succeeds:
    pi = NULL_v();

    // Error: fails: test_stlsoft_null.cpp:41: cannot convert
 `stlsoft::NULL_v' to `int (A::*)()' in assignment
    fp = NULL_v();

    // Error: should fail (integer)
    if ( i == NULL_v() ) { }

    // Error: should fail (integer)
    if ( NULL_v() == i ) { }

    // Ok: succeeds (pointer):
    if ( pi == NULL_v() ) { }

    // Ok: succeeds (pointer):
    if ( NULL_v() == pi ) { }

    // Ok: succeeds (member pointer):
    if ( fp == NULL_v() ) { }

    // Ok: succeeds (member pointer):
    if ( NULL_v() == fp ) { }

    return 0;
 }

 ===

Sep 08 2005
parent reply Martin Moene <m.j.moene eld.physics.LeidenUniv.nl> writes:
Matthew wrote:
 I'm on it. Give me a day or so.

Great!
 
 FYI: some compilers do not support strong NULL at all, and some (including
 GCC) do not support pointer-to-member.

I wondered why STLSoft *silently* ignores strong NULL for compilers that do not support it *at all* like Visual C++ 6.0. Wouldn't it be better in that case to issue an error instead of given the (false) impression tat one is using strong NULL when you are not?
 
 <snip>
 

Martin.
Sep 08 2005
parent reply "Matthew" <matthew hat.stlsoft.dot.org> writes:
 FYI: some compilers do not support strong NULL at all, and some


 GCC) do not support pointer-to-member.

I wondered why STLSoft *silently* ignores strong NULL for compilers that do not support it *at all* like Visual C++ 6.0. Wouldn't it be better in that case to issue an error instead of given the (false) impression tat one is using strong NULL when you are not?

Because inclusion of stlsoft_nulldef.h will yield a functional NULL - either the strong NULL, or the classic NULL - whatever the compiler.
Sep 09 2005
parent reply Martin Moene <m.j.moene eld.physics.LeidenUniv.nl> writes:
Matthew wrote:
FYI: some compilers do not support strong NULL at all, and some


(including
GCC) do not support pointer-to-member.

I wondered why STLSoft *silently* ignores strong NULL for compilers that do not support it *at all* like Visual C++ 6.0. Wouldn't it be better in that case to issue an error instead of given the (false) impression tat one is using strong NULL when you are not?

Because inclusion of stlsoft_nulldef.h will yield a functional NULL - either the strong NULL, or the classic NULL - whatever the compiler.

The question clearly was based on a situation that uses stlsoft_nulldef.h only in a test situation and probably with only one one-compiler. Indeed error-behaviour is certainly undesired in a situation in which stlsoft_nulldef.h is always used in a project (I didn't think about this aspect). So the behaviour *is* ehm, practical. Martin.
Sep 09 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Martin Moene" <m.j.moene eld.physics.LeidenUniv.nl> wrote in 
message news:43218FE3.9040706 eld.physics.LeidenUniv.nl...
 Matthew wrote:
FYI: some compilers do not support strong NULL at all, and some


(including
GCC) do not support pointer-to-member.

I wondered why STLSoft *silently* ignores strong NULL for compilers that do not support it *at all* like Visual C++ 6.0. Wouldn't it be better in that case to issue an error instead of given the (false) impression tat one is using strong NULL when you are not?

Because inclusion of stlsoft_nulldef.h will yield a functional NULL - either the strong NULL, or the classic NULL - whatever the compiler.

The question clearly was based on a situation that uses stlsoft_nulldef.h only in a test situation and probably with only one one-compiler. Indeed error-behaviour is certainly undesired in a situation in which stlsoft_nulldef.h is always used in a project (I didn't think about this aspect). So the behaviour *is* ehm, practical.

I've done some larger compatibility testing, and the changes will be in the next beta, coming out soon. Please let me know how this goes.
Sep 11 2005
next sibling parent "Martin J. Moene" <m.j.moene eld.physics.LeidenUniv.nl> writes:
Matthew wrote:
 
 I've done some larger compatibility testing, and the changes will be 
 in the next beta, coming out soon. Please let me know how this goes. 
 
 

I'll do that. Martin.
Sep 15 2005
prev sibling parent reply "Martin J. Moene" <m.j.moene eld.physics.LeidenUniv.nl> writes:
Matthew wrote:
 
 I've done some larger compatibility testing, and the changes will be 
 in the next beta, coming out soon. Please let me know how this goes. 
 

Hi Matthew and others, STLSoft 1.8.7's strong NULL works as expected with Visual C++ 6.0 (uses plain NULL), Visual C++ 7.1 (passes the tests below) and GNU C++ 3.2.3 (does not support member function pointers, but otherwise passes tests). (I've probably missed STLSoft release 1.8.7 beta2 to test.) Thanks, Martin. ___ /* * test_stlsoft_null-1.8.7.cpp - test STLSoft's strong NULL_v. * * Visual C++ 6.0: * prompt>cl -c -GX -I D:/Libraries/stl-1.8.7/include null-stl.cpp * Ok: doesn't use strong NULL at all. * * Visual C++ 7.1: * prompt>cl -c -GX -I D:/Libraries/stl-1.8.7/include null-stl.cpp * Ok: correctly handles the tests in this file. * * GCC 3.2.3: * prompt>g++.exe -c -I D:/Libraries/stl-1.8.7/include null-stl.cpp * Partly Ok: GCC 3.2.3 cannot handle member function pointer, * but otherwise correctly handles the tests in this file. */ #define _STLSOFT_COMPILE_VERBOSE 1 #include <stlsoft_nulldef.h> struct A { int f(); }; int main() { int i = 0; // integer int *pi = &i; // pointer to integer int (A::*mfp)() = &A::f; // member function pointer // must fail i = NULL; // must succeed pi = NULL; // must succeed mfp = NULL; // must fail if ( i == NULL ) { } // must fail if ( NULL == i ) { } // must succeed if ( pi == NULL ) { } // must succeed if ( NULL == pi ) { } // must succeed if ( mfp == NULL ) { } // must succeed if ( NULL == mfp ) { } return 0; } ===
Sep 19 2005
parent "Matthew" <matthew stlsoft.com> writes:
 I've done some larger compatibility testing, and the changes will be
 in the next beta, coming out soon. Please let me know how this goes.

Hi Matthew and others, STLSoft 1.8.7's strong NULL works as expected with Visual C++ 6.0 (uses plain NULL), Visual C++ 7.1 (passes the tests below) and GNU C++ 3.2.3 (does not support member function pointers, but otherwise passes tests).

Thanks Martin
 (I've probably missed STLSoft release 1.8.7 beta2 to test.)

You didn't miss beta 2; I did. (I just released 1.8.7 proper) :-)
Sep 19 2005