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