c++.stlsoft - real pointer null (struct NULL_v): question
- Martin J. Moene (96/96) Sep 08 2005 Hi Matthew and al.,
- Matthew (16/112) Sep 08 2005 I'm on it. Give me a day or so.
- Martin Moene (7/14) Sep 08 2005 I wondered why STLSoft *silently* ignores strong NULL for compilers that...
- Matthew (3/9) Sep 09 2005 Because inclusion of stlsoft_nulldef.h will yield a functional NULL - ei...
- Martin Moene (9/26) Sep 09 2005 The question clearly was based on a situation that uses
- Matthew (4/33) Sep 11 2005 I've done some larger compatibility testing, and the changes will be
- Martin J. Moene (3/8) Sep 15 2005 I'll do that.
- Martin J. Moene (57/61) Sep 19 2005 Hi Matthew and others,
- Matthew (3/11) Sep 19 2005 You didn't miss beta 2; I did. (I just released 1.8.7 proper)
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
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/), Chapter15pages 227-233, describe a real pointer null (struct NULL_v ). StructNULL_vis 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 requesttouse 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(page230) 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 -ID:/Libraries/stl-1.8.3/includetest_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/includetest_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
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
(includingFYI: some compilers do not support strong NULL at all, and someBecause inclusion of stlsoft_nulldef.h will yield a functional NULL - either the strong NULL, or the classic NULL - whatever the compiler.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?
Sep 09 2005
Matthew wrote: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.(includingFYI: some compilers do not support strong NULL at all, and someBecause inclusion of stlsoft_nulldef.h will yield a functional NULL - either the strong NULL, or the classic NULL - whatever the compiler.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?
Sep 09 2005
"Martin Moene" <m.j.moene eld.physics.LeidenUniv.nl> wrote in message news:43218FE3.9040706 eld.physics.LeidenUniv.nl...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.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.(includingFYI: some compilers do not support strong NULL at all, and someBecause inclusion of stlsoft_nulldef.h will yield a functional NULL - either the strong NULL, or the classic NULL - whatever the compiler.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?
Sep 11 2005
"Martin J. Moene" <m.j.moene eld.physics.LeidenUniv.nl> 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
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
Thanks MartinI'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.)You didn't miss beta 2; I did. (I just released 1.8.7 proper) :-)
Sep 19 2005