incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Sebor (JIRA)" <j...@apache.org>
Subject [jira] Created: (STDCXX-494) access error using UD new to construct a container with a UD allocator
Date Tue, 24 Jul 2007 00:49:31 GMT
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
            Reporter: Martin Sebor


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 <abhushan@adobe.com>
To: Aditya Bhushan <abhushan@adobe.com>, cxx-dev@cxx.cup.hp.com,  
hpux-devtools@cxx.cup.hp.com
CC: Prashant Verma <pverma@adobe.com>, Atul Puri <apuri@adobe.com>
References: <029301c4eda6$fce9a0a0$c519280a@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 <sebor@roguewave.com>
To: cxx-dev@cxx.cup.hp.com
References: <029301c4eda6$fce9a0a0$c519280a@corp.adobe.com> 
<05ad01c4ef2c$80f38920$c519280a@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.


Mime
View raw message