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 <thorsten.ottosen@dezide.com> 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<Config, CloneAllocator>::Ty_ [with Config=boost::ptr_container_detail::sequence_config<int, std::deque<void *, std::allocator<void *>>>, CloneAllocator=boost::heap_clone_allocator]" is inaccessible static Ty_* allocate_clone_from_iterator( Iter i ) ^ detected during: instantiation of class "boost::ptr_container_detail::reversible_ptr_container<Co nfig, CloneAllocator>::null_clone_allocator<allow_null_values> [with Config=boost::ptr_container_detail::sequence_config<int, std::deque<void *, std::allocator<void *>>>, CloneAllocator=boost::heap_clone_allocator, allow_null_values=false]" at line 283 instantiation of "void boost::ptr_container_detail::reversible_ptr_container<Con fig, CloneAllocator>::null_policy_deallocate_clone(const boost::ptr_container_detail::reversible_ptr_container<Con fig, CloneAllocator>::Ty_ *) [with Config=boost::ptr_container_detail::sequence_config<int, std::deque<void *, std::allocator<void *>>>, CloneAllocator=boost::heap_clone_allocator]" at line 233 instantiation of "void boost::ptr_container_detail::reversible_ptr_container<Con fig, CloneAllocator>::remove(I) [with Config=boost::ptr_container_detail::sequence_config<int, std::deque<void *, std::allocator<void *>>>, CloneAllocator=boost::heap_clone_allocator, I=boost::void_ptr_iterator<std::deque<void *, std::allocator<void *>>::iterator, boost::ptr_container_detail::sequence_config<int, std::deque<void *, std::allocator<void *>>>::U>]" at line 240 instantiation of "void boost::ptr_container_detail::reversible_ptr_container<Con fig, CloneAllocator>::remove(I, I) [with Config=boost::ptr_container_detail::sequence_config<int, std::deque<void *, std::allocator<void *>>>, CloneAllocator=boost::heap_clone_allocator, I=boost::void_ptr_iterator<std::deque<void *, std::allocator<void *>>::iterator, boost::ptr_container_detail::sequence_config<int, std::deque<void *, std::allocator<void *>>>::U>]" at line 213 instantiation of "void boost::ptr_container_detail::reversible_ptr_container<Con fig, CloneAllocator>::remove_all() [with Config=boost::ptr_container_detail::sequence_config<int, std::deque<void *, std::allocator<void *>>>, CloneAllocator=boost::heap_clone_allocator]" at line 364 instantiation of "boost::ptr_container_detail::reversible_ptr_container<Co nfig, CloneAllocator>::~reversible_ptr_container() [with Config=boost::ptr_container_detail::sequence_config<int, std::deque<void *, std::allocator<void *>>>, CloneAllocator=boost::heap_clone_allocator]" at line 162 of "C:\boost\boost_1_33_1\boost/ptr_container/ptr_sequence_a dapter.hpp" instantiation of "boost::ptr_sequence_adapter<T, VoidPtrSeq, CloneAllocator>::ptr_sequence_adapter(const boost::ptr_sequence_adapter<T, VoidPtrSeq, CloneAllocator>::allocator_type &) [with T=int, VoidPtrSeq=std::deque<void *, std::allocator<void *>>, CloneAllocator=boost::heap_clone_allocator]" at line 45 of "C:\boost\boost_1_33_1\boost/ptr_container/ptr_deque.hpp" instantiation of "boost::ptr_deque<T, CloneAllocator, Allocator>::ptr_deque(const boost::ptr_deque<T, CloneAllocator, Allocator>::allocator_type &) [with T=int, CloneAllocator=boost::heap_clone_allocator, Allocator=std::allocator<void *>]" at line 42 of "Common\Ttnt\JtrsKeyTag.cpp" Regards, BN

On 3/15/07, Brian Neal <bgneal@gmail.com> wrote:
On 3/15/07, Thorsten Ottosen <thorsten.ottosen@dezide.com> 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<Config, CloneAllocator>::Ty_ [with Config=boost::ptr_container_detail::sequence_config<int, std::deque<void *, std::allocator<void *>>>, 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 <bgneal@gmail.com> wrote:
On 3/15/07, Thorsten Ottosen <thorsten.ottosen@dezide.com> 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