> For that matter (changing the subject a bit), why isn't auto_ptr
> parameterized in terms of an allocator?  Why doesn't it look like:
>
> template<class X, class Allocator=allocator>
> class auto_ptr {
> <<<guts deleted>>>
> };

I wholeheartedly agree, auto_ptr<X> NEEDS to know how to deallocate objects
of class X, and just using the global operator delete won't cut it. Makes
auto_ptr less than worthless for objects allocated using an allocator, as
it will cause runtime errors, but won't be caught at compile time in most
cases. You'd think the committee would realize this, but I guess they're
too caught up in how to do auto_ptr *period*, let alone how to make it work
with everything else. They can't even come up with a version that works
with the rest of STL, let alone the allocators (though it would be a step
in the right direction to allow templatization on allocator type)

I think auto_ptr ought to use the new typename keyword (I'm not sure if
it's from the standard or not, Borland's docs on it are so crappy) as well,
to allow declaring auto_ptr's on as-yet-undefined classes (either that or
make the standard assume that every class has a destructor, even if it
hasn't been declared yet), and in turn that would allow classes to contain
auto_ptr's to their own class.





[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

> For that matter (changing the subject a bit), why isn't auto_ptr
> parameterized in terms of an allocator?  Why doesn't it look like:
>
> template<class X, class Allocator=allocator>
> class auto_ptr {
> <<<guts deleted>>>
> };

I wholeheartedly agree, auto_ptr<X> NEEDS to know how to deallocate objects
of class X, and just using the global operator delete won't cut it. Makes
auto_ptr less than worthless for objects allocated using an allocator, as
it will cause runtime errors, but won't be caught at compile time in most
cases. You'd think the committee would realize this, but I guess they're
too caught up in how to do auto_ptr *period*, let alone how to make it work
with everything else. They can't even come up with a version that works
with the rest of STL, let alone the allocators (though it would be a step
in the right direction to allow templatization on allocator type)

I think auto_ptr ought to use the new typename keyword (I'm not sure if
it's from the standard or not, Borland's docs on it are so crappy) as well,
to allow declaring auto_ptr's on as-yet-undefined classes (either that or
make the standard assume that every class has a destructor, even if it
hasn't been declared yet), and in turn that would allow classes to contain
auto_ptr's to their own class.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Sean L. Palmer (sean@delta.com) wrote:
> I wholeheartedly agree, auto_ptr<X> NEEDS to know how to deallocate objects
> of class X, and just using the global operator delete won't cut it. Makes
> auto_ptr less than worthless for objects allocated using an allocator, as
> it will cause runtime errors, but won't be caught at compile time in most
> cases. You'd think the committee would realize this, but I guess they're
> too caught up in how to do auto_ptr *period*, let alone how to make it work
> with everything else. They can't even come up with a version that works
> with the rest of STL, let alone the allocators (though it would be a step
> in the right direction to allow templatization on allocator type)

> I think auto_ptr ought to use the new typename keyword (I'm not sure if
> it's from the standard or not, Borland's docs on it are so crappy) as well,
> to allow declaring auto_ptr's on as-yet-undefined classes (either that or
> make the standard assume that every class has a destructor, even if it
> hasn't been declared yet), and in turn that would allow classes to contain
> auto_ptr's to their own class.

I think most of problems with auto_ptr came from the fact that auto_ptr
need to destroy an object allocated outside auto_ptr and because pointers
do not remember who allocated them it seems for me non-standard allocators
can not be used with current design of auto_ptr at all. One possible solution
to make auto_ptr look more like true container class i.e. auto_ptr should
allocate object itself, here simple code how it can be done:

template<class T> class ???_ptr {
   private:
      T* p;
   ...
   public:
      ???_ptr()
      {
         ...  p = new T; ...
      }
      template<class X> ???_ptr(X x)
      {
         ... p = new T(x); ...
      }
      template<class X1, class X2> ???_ptr(X1 x1, X2 x2)
      {
         ...p = new T(x1, x2); ...
      }
      template<class X1, class X2, class X3> ???_ptr(X1 x1, X2 x2, X3 x3)
      {
         ... p = new T(x1, x2, x3); ...
      }
      /* Idea here is to provide as much ???_ptr constructors as possible
         to cover almost all cases of constructor call in new T(...)
       */
      ...

      ~???_ptr()
      {
         ... delete p; ...
      }

};

And now instead of:
auto_ptr<T> a(new T), b(new T("Test")), c(new T(10, 2.0));
one can write:
???_ptr<T> a, b("Test"), c(10, 2.0);

Now memory management belong totally to ???_ptr so it can be easy
extended to cover non-standard allocators. And of cause some kind of ???_ptr
can be used with STL containers.,,,

--
Regards, Igor Boukanov.
igor.boukanov@fi.uib.no
http://www.fi.uib.no/~boukanov/


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]