Problem with shared_ptr in MSVC8.0 (only when compiled in /clr mode ?)

Hello everybody, In boost::shared_ptr, there is a trick to get a type convertible to bool that is not a bool... unspecified_bool_type is a function pointer. However, with MSVC8.0, and at least when I compile with /clr, I seem to have some problem with it : The null fct ptr seems to be coded 0xffffffff. That is just fine in non /clr compilation, where it gets evaluated as false when converted in boolean. But in /clr mode, it is converted to true. I guess this is a problem with the compiler, but would it not be possible to use a not so clever unspecified_bool_type with this compiler as a work-around ? Best regards, -- Loïc

Loïc Joly wrote:
Hello everybody,
In boost::shared_ptr, there is a trick to get a type convertible to bool that is not a bool... unspecified_bool_type is a function pointer.
However, with MSVC8.0, and at least when I compile with /clr, I seem to have some problem with it : The null fct ptr seems to be coded 0xffffffff. That is just fine in non /clr compilation, where it gets evaluated as false when converted in boolean. But in /clr mode, it is converted to true.
I can't reproduce this problem with the following code: #include <boost/shared_ptr.hpp> #include <iostream> int main() { boost::shared_ptr<int> px; std::cout << ( px? true: false ) << std::endl; } compiled as /clr. The compiler does seem to encode a NULL member pointer as -1, but the example prints 0, as it should.

Peter Dimov a écrit :
Loïc Joly wrote:
Hello everybody,
In boost::shared_ptr, there is a trick to get a type convertible to bool that is not a bool... unspecified_bool_type is a function pointer.
However, with MSVC8.0, and at least when I compile with /clr, I seem to have some problem with it : The null fct ptr seems to be coded 0xffffffff. That is just fine in non /clr compilation, where it gets evaluated as false when converted in boolean. But in /clr mode, it is converted to true.
I can't reproduce this problem with the following code [...]
Ok, I'll try to post a code that reproduces the problem, as soon as I can. It may take a while. Best regards, -- Loïc

Peter Dimov a écrit :
However, with MSVC8.0, and at least when I compile with /clr, I seem to have some problem with it : The null fct ptr seems to be coded 0xffffffff. That is just fine in non /clr compilation, where it gets evaluated as false when converted in boolean. But in /clr mode, it is converted to true.
I can't reproduce this problem with the following code:
#include <boost/shared_ptr.hpp> #include <iostream>
int main() { boost::shared_ptr<int> px; std::cout << ( px? true: false ) << std::endl; }
compiled as /clr. The compiler does seem to encode a NULL member pointer as -1, but the example prints 0, as it should.
Here is finally some code that reproduces the problem. The compilation options are the default ones when creating a "CLR console application" project: // TestBoostSharde_ptrAnd.NET.cpp : main project file. #include "stdafx.h" #pragma unmanaged #include "boost/shared_ptr.hpp" class A{}; typedef boost::shared_ptr<A> APtr; #pragma managed using namespace System; int main(array<System::String ^> ^args) { A *a = NULL; APtr aPtr(a); if (aPtr.get()) Console::WriteLine(L"KO!"); else Console::WriteLine(L"Ok!"); if (aPtr) Console::WriteLine(L"KO!"); else Console::WriteLine(L"Ok!"); return 0; } Is displays Ok! KO! Whereas it should display Ok! Ok! Best regards, -- Loïc

Loïc Joly wrote:
Peter Dimov a écrit :
However, with MSVC8.0, and at least when I compile with /clr, I seem to have some problem with it : The null fct ptr seems to be coded 0xffffffff. That is just fine in non /clr compilation, where it gets evaluated as false when converted in boolean. But in /clr mode, it is converted to true.
I can't reproduce this problem with the following code:
#include <boost/shared_ptr.hpp> #include <iostream>
int main() { boost::shared_ptr<int> px; std::cout << ( px? true: false ) << std::endl; }
compiled as /clr. The compiler does seem to encode a NULL member pointer as -1, but the example prints 0, as it should.
Here is finally some code that reproduces the problem. The compilation options are the default ones when creating a "CLR console application" project:
// TestBoostSharde_ptrAnd.NET.cpp : main project file.
#include "stdafx.h"
#pragma unmanaged #include "boost/shared_ptr.hpp"
class A{}; typedef boost::shared_ptr<A> APtr;
#pragma managed
Thanks very much. You should probably report this managed/unmanaged inconsistency as a bug to Microsoft. In the meantime, can you please add the following: #elif defined( _MANAGED ) static void unspecified_bool( this_type*** ) { } typedef void (*unspecified_bool_type)( this_type*** ); operator unspecified_bool_type() const // never throws { return px == 0? 0: unspecified_bool; } at shared_ptr.hpp:333 and verify if everything works for you. I'll commit it to 1.34 after your confirmation. I wonder whether this new and improved unspecified bool could replace the other variations altogether for 1.35. Member pointers traditionally prove problematic. :-)

Peter Dimov a écrit :
Thanks very much. You should probably report this managed/unmanaged inconsistency as a bug to Microsoft. In the meantime, can you please add the following:
That is on my to-do list, but I cannot access Microsoft bug website from my workplace...
#elif defined( _MANAGED )
static void unspecified_bool( this_type*** ) { }
typedef void (*unspecified_bool_type)( this_type*** );
operator unspecified_bool_type() const // never throws { return px == 0? 0: unspecified_bool; }
at shared_ptr.hpp:333 and verify if everything works for you.
Except that I had to add it line 283 (I have a plain out of the box 1.33 version), it seems to work now. Thank you, -- Loïc Joly
participants (2)
-
Loïc Joly
-
Peter Dimov