You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@stdcxx.apache.org by "Martin Sebor (JIRA)" <ji...@apache.org> on 2008/07/17 22:51:31 UTC
[jira] Updated: (STDCXX-494) access error using UD new to construct
a container with a UD allocator
[ https://issues.apache.org/jira/browse/STDCXX-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Sebor updated STDCXX-494:
--------------------------------
Severity: Compiler Error
Affects Version/s: 4.1.4
4.2.0
4.2.1
Fix Version/s: 4.2.2
Remaining Estimate: 8h
Original Estimate: 8h
This affects all released versions.
This should be doable in a binary-compatible way. Scheduled for 4.2.2.
> access error using UD new to construct a container with a UD allocator
> ----------------------------------------------------------------------
>
> Key: STDCXX-494
> URL: https://issues.apache.org/jira/browse/STDCXX-494
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 23. Containers
> Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0, 4.2.1
> Reporter: Martin Sebor
> Assignee: Martin Sebor
> Fix For: 4.2.2
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> Moved from Rogue Wave Bugzilla: http://bugzilla.cvo.roguewave.com/show_bug.cgi?id=1456
> -------- Original Message --------
> Subject: Re: CXX-DEV: cannot access member through private base
> Date: Fri, 31 Dec 2004 17:03:02 +0530
> From: Aditya Bhushan <ab...@adobe.com>
> To: Aditya Bhushan <ab...@adobe.com>, cxx-dev@cxx.cup.hp.com,
> hpux-devtools@cxx.cup.hp.com
> CC: Prashant Verma <pv...@adobe.com>, Atul Puri <ap...@adobe.com>
> References: <02...@corp.adobe.com>
> Furthur investigation points out to the code in /opt/aCC/include_std/list:
> template <class _TypeT,
> class _Allocator _RWSTD_COMPLEX_DEFAULT (allocator<_TypeT>) >
> class list : private _Allocator{...
> I suspect the problem is due to the private derivation from
> _Allocator, though that should not be the case because
> a) all our classes have been publically derived and
> b) the overloaded method new is also public
> What is a recommended solution to this problem, keeping in mind the
> fact that our code provides its own implementation of allocator?
> Regards,
> Aditya Bhushan
> Adobe Systems India Pvt. Ltd.
> ----- Original Message -----
> From: Aditya Bhushan
> To: cxx-dev@cxx.cup.hp.com ; hpux-devtools@cxx.cup.hp.com
> Cc: Prashant Verma ; Atul Puri
> Sent: Wednesday, December 29, 2004 6:34 PM
> Subject: CXX-DEV: cannot access member through private base
> On compiling the file(source below) the following error is encountered.
> Error 183: "abcd.cpp", line 60 # "int main()" cannot access member
> "static void *XYZ::BaseClass::operator new(unsigned long)" through
> private base.
> new STLList();
> ^^^^^^^^^^^^^
> I used aCC -AA abcd.cpp
> we are using aCC version 3.52
> Is there a workaround for this problem?
> the Source file abcd.cpp is
> *************************************************************************************************************************************************************************************
> typedef unsigned long size_t;
> namespace XYZ
> {
> class BaseClass
> {
> public:
> inline static void* operator new (size_t n) { return 0; }
> };
> template<class T> struct Derived1 : public BaseClass {
> typedef T value_type;
> };
> template<class T> class Derived2 : public Derived1<T>
> {
> public:
> typedef typename Derived1<T>::value_type value_type;
> typedef const value_type* const_pointer;
> typedef const value_type& const_reference;
> typedef int difference_type;
> typedef value_type* pointer;
> typedef value_type& reference;
> typedef size_t size_type;
> pointer address(reference _Val) const { return (&_Val); }
> const_pointer address(const_reference _Val) const { return
> (&_Val); }
> pointer allocate(size_type n) {
> return 0; }
> pointer allocate(size_type n, void*) {
> return 0; }
> Derived2() {} // NOP
> Derived2(const Derived2<T>&) {} // NOP
> // construct from a related allocator (NOP)
> template<class _Other> Derived2(const Derived2<_Other>&) {}
> void construct(pointer ptr, const T& val) {
> ::new (ptr) T(val); }
> void destroy(pointer ptr) {
> ptr->~T(); }
> template<class _Other> struct rebind { typedef
> Derived2<_Other> other; };
> };
> }
> using namespace XYZ;
> #include <list>
> int main(){
> typedef std::list<void*, XYZ::Derived2<void*> > STLList;
> new STLList();
> return 0;
> }
> ************************************************************************************************************************************************************************************
> _________________________________________________________________
> To leave this mailing list, send mail to majordomo@cxx.cup.hp.com
> with the message UNSUBSCRIBE cxx-dev
> _________________________________________________________________
> _________________________________________________________________
> To leave this mailing list, send mail to majordomo@cxx.cup.hp.com
> with the message UNSUBSCRIBE cxx-dev
> _________________________________________________________________
> ------- Additional Comments From sebor@roguewave.com 2005-01-03 14:38:34 ----
> -------- Original Message --------
> Subject: Re: CXX-DEV: cannot access member through private base
> Date: Mon, 03 Jan 2005 15:34:14 -0700
> From: Martin Sebor <se...@roguewave.com>
> To: cxx-dev@cxx.cup.hp.com
> References: <02...@corp.adobe.com>
> <05...@corp.adobe.com>
> Aditya Bhushan wrote:
> > Furthur investigation points out to the code in
> /opt/aCC/include_std/list:
> >
> > template <class _TypeT,
> > class _Allocator _RWSTD_COMPLEX_DEFAULT (allocator<_TypeT>) >
> > class list : private _Allocator{...
> >
> > I suspect the problem is due to the private derivation from
> _Allocator, though that should not be the case because
> > a) all our classes have been publically derived and
> > b) the overloaded method new is also public
> >
> > What is a recommended solution to this problem, keeping in mind the
> fact that our code provides its own implementation of allocator?
> I couldn't compile your test case because your allocator is missing
> the deallocate() member function. But once I added it I was able to
> reproduce the error. The private derivation does indeed seem to be
> the cause of the error. We use it throughout the library to take
> advantage of the empty base optimization implemented by some compilers.
> Unless you are willing to give up the operator I'm afraid I can't think
> of a simple workaround for you.
> Martin
> PS Here's a smaller test case that reproduces the error with vector:
> #include <cstddef>
> #include <vector>
> template <class T>
> struct MyAllocator: std::allocator<T>
> {
> template <class U>
> struct rebind { typedef MyAllocator<U> other; };
> MyAllocator () { }
> MyAllocator (const MyAllocator &rhs): std::allocator<T>(rhs) { }
> template <class U>
> MyAllocator (const MyAllocator<U> &rhs): std::allocator<T>(rhs) { }
> void* operator new (std::size_t) { return 0; }
> void operator delete (void*) { }
> };
> int main ()
> {
> delete new std::vector<int, MyAllocator<int> >;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.