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;
}

===

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
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;
> }
>
> ===
>
>

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.

> > 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.

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.

"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.

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.

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;
}
===

> > 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)

:-)