In article <slrn7he02t.ivm.ramon@jl1.quim.ucm.es>,
  ramon@jl1.quim.ucm.es (Ram'on Garc'ia Fern'andez) wrote:
> On 15 Apr 99 13:37:57 GMT, J.Barfurth <techview@bfk-net.de> wrote:
> >    std::vector<A> a_vec(30);
> >I know its not completely the same, but unless you change the
vectors size,
> >there will be no reallocation.
>
> Thanks for your help. However std::vector does not do the job, because
> I do not have any means of getting a pointer to the elements. In fact,
> the spec of vector grants constant access time, but it does not grant
> that the underlying storage is an array, although this is the most
> likely implementation.
>
> In my concrete example, I need a auto_ptr<wchar_t> to point to an
array
> of wchar_t. I need to be sure that the underlying storage is an array,
> because I must call a C function that expects an array of wchar_t (a
Windows
> API function).

If it's a windows API function I must assume that the type is actually
wchar_t and thus a wide string.  Use std::wstring.  It has a member
c_str which will return you a read only pointer to the data.  If you
need buffer space for the API to write to, unfortunately you'll have to
use a true array.  A quick auto_array implementation will suffice, and
it doesn't have to live up to the full implementation of auto_ptr
(though if you want it to, no big deal).  Seriously, if you just copy
your libraries implementation for auto_ptr and modify it to read
auto_array, changing the one or two lines that call delete you should
have your own auto_array within a minute, tops.

> Therefore, I believe that the standard should include a
specialization of
> auto_ptr for arrays.

What I would have liked to have seen, and one should create their own
smart_ptr to operate this way, is for auto_ptr to have taken another
template argument as a DEALLOCATOR type.  This would make it easy to
specialize the smart_ptr for different allocation/deallocation types.
Would be a great way to use the ptr on objects that need to be used
safely in the presence of exceptions, such as thread locks.

----- Posted via Deja.com, The People-Powered Information Exchange -----
------ http://www.deja.com/   Discussions * Ratings * Communities ------
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ram'on Garc'ia Fern'andez wrote:

> In fact,
> the spec of vector grants constant access time, but it does not grant
> that the underlying storage is an array, although this is the most
> likely implementation.

Well, all implementations I know of do it that way, and the standard
will probably be changed (fixed ?) to do it that way.

> In my concrete example, I need a auto_ptr<wchar_t> to point to an array
> of wchar_t. I need to be sure that the underlying storage is an array,
> because I must call a C function that expects an array of wchar_t (a Windows
> API function).
>
> Therefore, I believe that the standard should include a specialization of
> auto_ptr for arrays.

A specialisation ? There is nothing to specialise on.

--

Valentin Bonnard
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

You may have a look at www.boost.org for a proper smart pointer and learn
something about the auto_ptr history ...

Greetings, J   rg
--
BTW: It is normally better to answer to the group! For direct mail reply
exchange the ".A@T." by "@"
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 15 Apr 99 13:37:57 GMT, J.Barfurth <techview@bfk-net.de> wrote:
>    std::vector<A> a_vec(30);
>I know its not completely the same, but unless you change the vectors size,
>there will be no reallocation.

Thanks for your help. However std::vector does not do the job, because
I do not have any means of getting a pointer to the elements. In fact,
the spec of vector grants constant access time, but it does not grant
that the underlying storage is an array, although this is the most
likely implementation.

In my concrete example, I need a auto_ptr<wchar_t> to point to an array
of wchar_t. I need to be sure that the underlying storage is an array,
because I must call a C function that expects an array of wchar_t (a Windows
API function).

Therefore, I believe that the standard should include a specialization of
auto_ptr for arrays.

Ramon
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ram'on Garc'ia Fern'andez wrote:
>
> On 15 Apr 99 13:37:57 GMT, J.Barfurth <techview@bfk-net.de> wrote:
> >    std::vector<A> a_vec(30);
> >I know its not completely the same, but unless you change the vectors size,
> >there will be no reallocation.
>
> Thanks for your help. However std::vector does not do the job, because
> I do not have any means of getting a pointer to the elements. In fact,
> the spec of vector grants constant access time, but it does not grant
> that the underlying storage is an array, although this is the most
> likely implementation.

valarray<> will probably meet your needs. The section 26.3.2.3 p3
guarantees consecutive storage, so &v[0] should give a pointer to the
entire array of values.
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ram'on Garc'ia Fern'andez schrieb in Nachricht ...

> class A { // whatever definition };
> auto_ptr<A> a_ptr =3D new A[30];
> // whatever code you wish

No.

>If it is not correct, I believe that the standard should include
>an alternative to auto_ptr for arrays, so that the programmers do not
>have to bother writting one.
    std::vector<A> a_vec(30);
I know its not completely the same, but unless you change the vectors siz=
e,
there will be no reallocation.

-- J=F6rg Barfurth
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I have a question regarding the interpretation of auto_ptr.

When you allocate an array with new, you should delete it with delete[]
rather that delete, right?

The question is: should the auto_ptr implementation work with arrays?

Is it correct to write:

{
 class A { // whatever definition };
 auto_ptr<A> a_ptr = new A[30];
 // whatever code you wish
}

If it is not correct, I believe that the standard should include
an alternative to auto_ptr for arrays, so that the programmers do not
have to bother writting one.

Thank you,
 Ramon
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <fxtafdraciy.fsf@isolde.mti.sgi.com>, Matt Austern <austern@isolde.mti.sgi.com> writes:
>
> I think that people ask why there isn't one precisely because you
> point out that absence.  You could have pointed out a number of other
> variations on auto_ptr that also aren't there, though: there isn't an
> auto_ptr that uses free() instead of delete, for example, and there
> isn't one that uses STL allocators, and there isn't a reference-
> counted pointer (in fact, there isn't an invasive reference-counted
> pointer and there also isn't a non-invasive reference-counted
> pointer), and there isn't a "smart pointer" where deletion or
> non-deletion is controlled by a user-settable flag.
>
> The answer why all of those classes aren't there?  It's easy to list a
> dozen or more different "smart pointer" classes that are more or less
> similar to auto_ptr.  Greg Colvin's original proposal had several
> different classes of that sort, and even that proposal wasn't
> complete; it couldn't possibly have been, because there are too many
> different smart pointer classes and nobody could list them all.  The
> committee selected just one of those classes for inclusion in the
> standard; in their judgment, the one they selected was the one that
> would most often be useful.
>
> So here's a suggestion for C++ educators.  Instead of pointing out one
> particular variation on auto_ptr that isn't there, you could assign it
> as an exercise: come up with two or three variations on auto_ptr that
> aren't in the standard, but that that you think would be useful.  If
> you did that, I bet you'd be surprised by the variety of answers.
>

Variants of auto_ptr are useful in combination with old C code.
vector cannot be used in that case (valarray could be,
but is not designed for that).

A simple generalization of auto_ptr might be
to add a second template argument that  indicates the kind of allocator;
they same applies
to other forms of smart pointers.
This allows flexibility without generating too many functions.
Below is a simplified code example that should make my idea clear
(Tested on my compiler, which is not yet fully ISO conform).


Helmut Zeisel


--------------------------------------

template<class T> class DefaultDeleter
{
public:
  static free(T* p) {delete p;}
};

template<class T, class Deleter = DefaultDeleter<T> > class my_ptr
{
public:
  my_ptr(T* p): m_p(p) {}
  ~my_ptr() {Deleter::free(m_p);}
private:
  T* m_p;
};

template<class T> class ArrayDeleter
{
public:
  static free(T* p) {delete[] p;}
};

#include <stdlib.h>
template<class T> class CDeleter
{
public:
  static free(T* p) {::free(p);}
};

#include <iostream.h>
class A
{
public:
  A(const char* id=""): m_id(id) {}
  ~A() { cout << "Deleting " << m_id << endl; }
private:
  const char* m_id;
};

int main()
{
  my_ptr<A> a = new A("single");
  my_ptr<A,ArrayDeleter<A> > ar = new A[2];
  return 0;
}
---
[ 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
]

> I have given a couple of talks on auto_ptr<> to groups of C++ programmers
> and when I point out that lack of an "array" auto_ptr<>, someone invariably
> ask why there isn't one.  All I can say is I don't know.
>

Apparently, from what I've been getting in email lately, they
decided that an array version of an auto_ptr<> was redundant
in light of the STL. I can't say I disagree now that I've
thought it through.

--
+-----------------------------------------------------------+
| Tim Ottinger:      http://www.oma.com/ottinger            |
| Object Mentor:     http://www.oma.com        800-338-6716 |
+-----------------------------------------------------------+
|         Design, Consulting, Mentoring, Training           |
+-----------------------------------------------------------+
The important thing is to never stop questioning - A Einstein
---
[ 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                             ]

Tim Ottinger <tottinge@oma.com> wrote:

>Apparently, from what I've been getting in email lately, they
>decided that an array version of an auto_ptr<> was redundant
>in light of the STL. I can't say I disagree now that I've
>thought it through.

Although I agree that an array version of auto_ptr<> does not meet the
criteria for inclusion in the standard (i.e., it is not universally
useful and essential), I don't think vector<> meets many of the needs
that an array version of auto_ptr<> would:

(1) vector<> does not guarentee contiguous memory use.

(2) vector<> does not have the source-sink characteristic of transfering
ownership without copying the array.

Here is one possible use of vector<> to get (2), but not (1) (untested
code):

template <class T, class Allocator = allocator<T> >
class owner_vector
{
    typedef vector<T, Allocator> basetype;
    mutable basetype v;
  public:
    owner_vector() { }
    owner_vector(const basetype& vec) : v(vec) { }

    // Release of ownership:
    basetype& release(basetype& ret) { v.swap(ret); return ret; }
    basetype release() { basetype ret; return release(ret); }

    // Transfer of ownership:
    owner_vector(const owner_vector& rhs) { rhs.release(v); }
    owner_vector& operator=(const owner_vector& rhs)
      { rhs.release(v); return *this; }

    // Take ownership from a plain vector
    void take(basetype& vec) { v.swap(vec); }

    // Get plain vector without releasing ownership
    basetype& get() { return v; }
    const basetype& get() const { return v; }

    // push_back() and other vector functions and types ...
};


-------------------------------------------------------------
Pablo Halpern                   phalpern@truffle.ultranet.com

I am self-employed. Therefore, my opinions *do* represent
those of my employer.
---
[ 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                             ]

Why isn't there an array equivalent to auto_ptr in the Standard?

Mark
---
[ 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
]

Mark G. Wiseman <mwiseman@cosolutions.com> wrote in article
<679jji$9g$1@brokaw.wa.com>...
> Why isn't there an array equivalent to auto_ptr in the Standard?

Two reasons I know of:
1) nobody proposed one, and
2) vector or string works just as well in most cases.

Greg Colvin
---
[ 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
]

"Mark G. Wiseman" <mwiseman@cosolutions.com> wrote:

>Why isn't there an array equivalent to auto_ptr in the Standard?

>Mark

I believe ObjectSpace had it in their library v1.0 before they chucked
it out. As far as I know there is no analog

Jon
>---
>[ 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
>]
---
[ 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
]

I assumed something along the lines of (2), I just wanted to know the
official reason.

greg wrote in message <01bd0b71$41715bc0$6dbd83cc@vagabond.imrgold>...
>> Why isn't there an array equivalent to auto_ptr in the Standard?
>
>Two reasons I know of:
>1) nobody proposed one, and
>2) vector or string works just as well in most cases.
---
[ 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
]

Yes, I know there isn't one.  I was just curious why the standards committee
did not include one.

Jon Hornstein wrote in message <34991636.0@news.internex.net.au>...
>>Why isn't there an array equivalent to auto_ptr in the Standard?
>I believe ObjectSpace had it in their library v1.0 before they chucked
>it out. As far as I know there is no analog
---
[ 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
]

Mark G. Wiseman wrote:
> Why isn't there an array equivalent to auto_ptr in the Standard?

Wasn't an autoarray_ptr<> also considered? I don't know if
it made it through or not. I would have liked for it to, but
it's fairly trivial to copy the auto_ptr<> and modify it if
I have to.

--
+-----------------------------------------------------------+
| Tim Ottinger:      http://www.oma.com/ottinger            |
| Object Mentor:     http://www.oma.com        800-338-6716 |
+-----------------------------------------------------------+
|         Design, Consulting, Mentoring, Training           |
+-----------------------------------------------------------+
The important thing is to never stop questioning - A Einstein
---
[ 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
]

"Mark G. Wiseman" <mwiseman@cosolutions.com> writes:

> Why isn't there an array equivalent to auto_ptr in the Standard?

Use vector<> or auto_ptr<vector<> > depending on your needs.


Cheers,
Marcelo

--
______________________________________________________________________
Marcelo Cantos, Research Assistant       __/_  marcelo@mds.rmit.edu.au
Multimedia Database Systems Group, RMIT   /       _ Tel 61-3-9282-2497
L2/723 Swanston St, Carlton VIC 3053, Aus/ralia ><_>Fax 61-3-9282-2490
Acknowledgements: errors - me; wisdom - God; sponsorship - RMIT
---
[ 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
]

Maybe my original question was not clear.  I know how to work around this.
What I want to know was why the standards committee decided to not include
an "array" version of auto_ptr<> in the standard.

I have given a couple of talks on auto_ptr<> to groups of C++ programmers
and when I point out that lack of an "array" auto_ptr<>, someone invariably
ask why there isn't one.  All I can say is I don't know.


Mark


Marcelo Cantos wrote in message ...
>"Mark G. Wiseman" <mwiseman@cosolutions.com> writes:
>
>> Why isn't there an array equivalent to auto_ptr in the Standard?
>
>Use vector<> or auto_ptr<vector<> > depending on your needs.
>
>
>Cheers,
>Marcelo
>
>--
>______________________________________________________________________
>Marcelo Cantos, Research Assistant       __/_  marcelo@mds.rmit.edu.au
>Multimedia Database Systems Group, RMIT   /       _ Tel 61-3-9282-2497
>L2/723 Swanston St, Carlton VIC 3053, Aus/ralia ><_>Fax 61-3-9282-2490
>Acknowledgements: errors - me; wisdom - God; sponsorship - RMIT
>---
>[ 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
>]
---
[ 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
]

"Mark G. Wiseman" <mwiseman@cosolutions.com> writes:

> Maybe my original question was not clear.  I know how to work around this.
> What I want to know was why the standards committee decided to not include
> an "array" version of auto_ptr<> in the standard.
>
> I have given a couple of talks on auto_ptr<> to groups of C++ programmers
> and when I point out that lack of an "array" auto_ptr<>, someone invariably
> ask why there isn't one.  All I can say is I don't know.

I think that people ask why there isn't one precisely because you
point out that absence.  You could have pointed out a number of other
variations on auto_ptr that also aren't there, though: there isn't an
auto_ptr that uses free() instead of delete, for example, and there
isn't one that uses STL allocators, and there isn't a reference-
counted pointer (in fact, there isn't an invasive reference-counted
pointer and there also isn't a non-invasive reference-counted
pointer), and there isn't a "smart pointer" where deletion or
non-deletion is controlled by a user-settable flag.

The answer why all of those classes aren't there?  It's easy to list a
dozen or more different "smart pointer" classes that are more or less
similar to auto_ptr.  Greg Colvin's original proposal had several
different classes of that sort, and even that proposal wasn't
complete; it couldn't possibly have been, because there are too many
different smart pointer classes and nobody could list them all.  The
committee selected just one of those classes for inclusion in the
standard; in their judgment, the one they selected was the one that
would most often be useful.

So here's a suggestion for C++ educators.  Instead of pointing out one
particular variation on auto_ptr that isn't there, you could assign it
as an exercise: come up with two or three variations on auto_ptr that
aren't in the standard, but that that you think would be useful.  If
you did that, I bet you'd be surprised by the variety of answers.
---
[ 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                             ]

>>>>> "MGW" == Mark G Wiseman <mwiseman@cosolutions.com> writes:

 >> Use vector<> or auto_ptr<vector<> > depending on your needs.

 MGW> I know how to work around this.  What I want to know was why
 MGW> the standards committee decided to not include an "array"
 MGW> version of auto_ptr<> in the standard.

That's your answer.  The array version of auto_ptr<> ends up
looking too much like vector<>.  So, you should just use vector<>.

Or, in other words, the array version of auto_ptr is spelled "vector".
It's not a workaround.  It's the solution.

Michael.
---
[ 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                             ]

I think I'm right in believing that an auto_ptr should not be used
with a pointer allocated using operator new[](), so that

   auto_ptr<char> p(new char[20])

is not correct.

One of the "obvious" uses I can see for auto_ptrs is to handle memory
buffers to pass to old-fashioned C-style functions (eg, operating
system calls), where I want to simplify the freeing process (ie, get
the system to do it for me!)

gustav@morpheus.demon.co.uk (Paul Moore) wrote:

>I think I'm right in believing that an auto_ptr should not be used
>with a pointer allocated using operator new[](), so that

>   auto_ptr<char> p(new char[20])

>is not correct.

You are right, this is not correct.  In some compiler/library
implementations of auto_ptr and operator new, this specific example will
work. But it is definitely incorrect.

>One of the "obvious" uses I can see for auto_ptrs is to handle memory
>buffers to pass to old-fashioned C-style functions (eg, operating
>system calls), where I want to simplify the freeing process (ie, get
>the system to do it for me!)

>From what I say above, this is not valid.

IMHO, the *only* reason to use an auto_ptr is to temporarily hold a
newly allocated object in an exception-safe manner.  For example,
auto_ptr is especially useful in the bodies of constructors where the
constructor or any function the constructor calls may throw exceptions.


Beyond use as an exception-safe temporary resource manager, auto_ptr is
too tricky, unless you're very careful.

>Surely - as auto_ptr's implementation is straightforward - it is
>simple to define a further class, auto_array (say) which has all the
>places where auto_ptr has operator delete() replaced by operator
>delete[]().
>So then I could do:

[example snipped....]

>Is there any reason why the standard didn't include this?

None of the facilities of the standard library require what you suggest,
although some could use it :-)

>Is there a way of doing it with the standard library types?

As long as you don't need to release the allocated array to a new owner,
then try vector<T>.  If you require implicit conversion to T* and const
T*, you could derive a new type that provides these operations.

OTOH, deriving a new type of vector would surely be more work than the
solution you propose...

>PS What is the standard get_temporary_buffer() function intended for?
>I can't think when I'd use it...

Mostly, it is used internally by some of the generic algorithms for
times when they need some extra elbow room.  I've never had occasion to
use it directly.

--Bob
---
[ 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
]