reversible_ptr_container.hpp compilation issue
Hi - We used the ptr_container library under gcc and Linux. We are now porting our software to the Integrity OS and the Green Hills Multi C++ compiler. This compiler has the EDG front end. It cannot compile reversible_ptr_container.hpp. I had to change this: class reversible_ptr_container { private: BOOST_STATIC_CONSTANT( bool, allow_null = Config::allow_null ); typedef BOOST_DEDUCED_TYPENAME Config::value_type Ty_; To this: class reversible_ptr_container { public: typedef BOOST_DEDUCED_TYPENAME Config::value_type Ty_; private: BOOST_STATIC_CONSTANT( bool, allow_null = Config::allow_null ); The compiler complains that the typedef Ty_ is private, but it is used in the public part of the class where it should not be accessible. I believe, but am not completely sure, that technically the compiler is correct. We have noticed that this EDG front end is very picky (in a good way). Thank you.
Brian Neal wrote:
Hi -
We used the ptr_container library under gcc and Linux. We are now porting our software to the Integrity OS and the Green Hills Multi C++ compiler. This compiler has the EDG front end. It cannot compile reversible_ptr_container.hpp.
I had to change this:
class reversible_ptr_container { private: BOOST_STATIC_CONSTANT( bool, allow_null = Config::allow_null );
typedef BOOST_DEDUCED_TYPENAME Config::value_type Ty_;
To this:
class reversible_ptr_container { public: typedef BOOST_DEDUCED_TYPENAME Config::value_type Ty_; private: BOOST_STATIC_CONSTANT( bool, allow_null = Config::allow_null );
The compiler complains that the typedef Ty_ is private, but it is used in the public part of the class where it should not be accessible.
Huh?
I believe, but am not completely sure, that technically the compiler is correct. We have noticed that this EDG front end is very picky (in a good way).
Private doesn't mean that the class's own functions can't use it. In what context does the compiler complain? Thanks -Thorsten
On 3/15/07, Thorsten Ottosen
Brian Neal wrote:
Hi -
We used the ptr_container library under gcc and Linux. We are now porting our software to the Integrity OS and the Green Hills Multi C++ compiler. This compiler has the EDG front end. It cannot compile reversible_ptr_container.hpp.
I had to change this:
class reversible_ptr_container { private: BOOST_STATIC_CONSTANT( bool, allow_null = Config::allow_null );
typedef BOOST_DEDUCED_TYPENAME Config::value_type Ty_;
To this:
class reversible_ptr_container { public: typedef BOOST_DEDUCED_TYPENAME Config::value_type Ty_; private: BOOST_STATIC_CONSTANT( bool, allow_null = Config::allow_null );
The compiler complains that the typedef Ty_ is private, but it is used in the public part of the class where it should not be accessible.
Huh?
I believe, but am not completely sure, that technically the compiler is correct. We have noticed that this EDG front end is very picky (in a good way).
Private doesn't mean that the class's own functions can't use it.
In what context does the compiler complain?
Sorry I should have included the error. Compiling any code that uses
any ptr_container produces the following message (well actually there
are a few more):
"C:\boost\boost_1_33_1\boost/ptr_container/detail/reversible_ptr_container.hpp",
line 86: error #265-D:
type "boost::ptr_container_detail::reversible_ptr_container
On 3/15/07, Brian Neal
On 3/15/07, Thorsten Ottosen
wrote: Brian Neal wrote:
Hi -
We used the ptr_container library under gcc and Linux. We are now porting our software to the Integrity OS and the Green Hills Multi C++ compiler. This compiler has the EDG front end. It cannot compile reversible_ptr_container.hpp.
I had to change this:
class reversible_ptr_container { private: BOOST_STATIC_CONSTANT( bool, allow_null = Config::allow_null );
typedef BOOST_DEDUCED_TYPENAME Config::value_type Ty_;
To this:
class reversible_ptr_container { public: typedef BOOST_DEDUCED_TYPENAME Config::value_type Ty_; private: BOOST_STATIC_CONSTANT( bool, allow_null = Config::allow_null );
The compiler complains that the typedef Ty_ is private, but it is used in the public part of the class where it should not be accessible.
Huh?
I believe, but am not completely sure, that technically the compiler is correct. We have noticed that this EDG front end is very picky (in a good way).
Private doesn't mean that the class's own functions can't use it.
In what context does the compiler complain?
Sorry I should have included the error. Compiling any code that uses any ptr_container produces the following message (well actually there are a few more):
"C:\boost\boost_1_33_1\boost/ptr_container/detail/reversible_ptr_container.hpp", line 86: error #265-D: type "boost::ptr_container_detail::reversible_ptr_container
::Ty_ [with Config=boost::ptr_container_detail::sequence_config >>, CloneAllocator=boost::heap_clone_allocator]" is inaccessible static Ty_* allocate_clone_from_iterator( Iter i ) ^
The problem is, I believe, that null_clone_allocater, as a nested class of reversible_ptr_container, has no special visibility to see the type Ty_, which is private in the outer class. It is my understanding that this restriction will be lifted in a future version of C++, but technically today it cannot see that private type. EDG is very picky about that kind of stuff. Regards, BN
Brian Neal wrote:
On 3/15/07, Brian Neal
wrote: On 3/15/07, Thorsten Ottosen
wrote: Brian Neal wrote:
Hi -
We used the ptr_container library under gcc and Linux. We are now porting our software to the Integrity OS and the Green Hills Multi C++ compiler. This compiler has the EDG front end. It cannot compile reversible_ptr_container.hpp.
I had to change this:
class reversible_ptr_container { private: BOOST_STATIC_CONSTANT( bool, allow_null = Config::allow_null );
typedef BOOST_DEDUCED_TYPENAME Config::value_type Ty_;
To this:
class reversible_ptr_container { public: typedef BOOST_DEDUCED_TYPENAME Config::value_type Ty_; private: BOOST_STATIC_CONSTANT( bool, allow_null = Config::allow_null );
The problem is, I believe, that null_clone_allocater, as a nested class of reversible_ptr_container, has no special visibility to see the type Ty_, which is private in the outer class.
This makes sense. I guess a fix could be to make the class a friend, but I'm not keen on using this with templates. I guess I shuld simply use typedef typename Config::value_type* pointer; inside null_clone_allocator Thomas, can we fix this for 1.34? -Thorsten
participants (2)
-
Brian Neal
-
Thorsten Ottosen