In article <N3Okc.135155$04.3167644@twister.southeast.rr.com>,
 jgottman@carolina.rr.com ("Joe Gottman") wrote:

> "David Abrahams" <dave@boost-consulting.com> wrote in message
> news:uhdv0bvwd.fsf@boost-consulting.com...
> > hinnant@metrowerks.com (Howard Hinnant) writes:
> >
> > > This is what I would like to see:
> > >
> > > Imho auto_ptr should be deprecated in C++0X.  The "move from lvalues
> > > with copy syntax" is too dangerous / error prone.  In its place (for
> > > C++0X, not TR1) I would like to see an "auto_ptr-like" smart pointer
> > > except that it moves from lvalues with syntax other than copy, supports
> > > deleters, and handles built-in arrays "well".
> >
> > Doesn't supporting deleters make it a bit heavyweight to replace
> > auto_ptr?
> >
>
>    Also, wouldn't it be dangerous to support both custom deleters and the
> release() method in the same class?  Currently, if you have an auto_ptr<X>
> object and you call release() on it you know you will eventually have to
> call delete on the returned pointer.  If auto_ptr supported custom deleters,
> you would not know whether you needed to call delete, delete[], free, some
> class-specific deallocation function, or nothing at all.

In those circumstances where you will usually need to release, the type
of the move_ptr, and thus the type of the deleter is both apparent and
useful.  For example I currently have coded in production code:

template<class T>
template<class Y, class D>
shared_ptr<T>::shared_ptr(Y* p, D d)
    : ptr_(p)
{
    Metrowerks::move_ptr<Y, D&> hold(p, d);
    s_ = new detail::shared_ptr_deleter<Y, D>(p, d);
    hold.release();
    ...
}

One of move_ptr's most useful features is to serve as an aid in writing
exception safe code.  In the above example, the shared_ptr constructor
agressively claims ownership of the raw pointer by using move_ptr (with
a custom deleter).  Even if the shared_ptr ctor fails, deletion of the
raw pointer with the proper custom deleter is assured via the local
move_ptr.

-Howard

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

jgottman@carolina.rr.com ("Joe Gottman") wrote in message news:<N3Okc.135155$04.3167644@twister.southeast.rr.com>...
> "David Abrahams" <dave@boost-consulting.com> wrote in message
> news:uhdv0bvwd.fsf@boost-consulting.com...
> > hinnant@metrowerks.com (Howard Hinnant) writes:
> >
> > > This is what I would like to see:
> > >
> > > Imho auto_ptr should be deprecated in C++0X.  The "move from lvalues
> > > with copy syntax" is too dangerous / error prone.  In its place (for
> > > C++0X, not TR1) I would like to see an "auto_ptr-like" smart pointer
> > > except that it moves from lvalues with syntax other than copy, supports
> > > deleters, and handles built-in arrays "well".
> >
> > Doesn't supporting deleters make it a bit heavyweight to replace
> > auto_ptr?

No, ...

>    Also, wouldn't it be dangerous to support both custom deleters and the
> release() method in the same class?

.. and no. The proposed auto_ptr replacement encodes the deleter as
part of the type. Empty deleters can be optimized out, and it's
possible to invoke the proper deleter on the result of release(),
because it's known at compile time.

So for example, when you need to choose a smart pointer for a factory
function, if you want the client code to be aware of the allocation
details and to retain exclusive ownership over the returned object,
you'd use the new auto_ptr.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Peter Dimov" <pdimov@mmltd.net> wrote in message
news:7dc3b1ea.0405030857.249c4b2e@posting.google.com...
> jgottman@carolina.rr.com ("Joe Gottman") wrote in message
news:<N3Okc.135155$04.3167644@twister.southeast.rr.com>...
> > "David Abrahams" <dave@boost-consulting.com> wrote in message
> > news:uhdv0bvwd.fsf@boost-consulting.com...
> > > hinnant@metrowerks.com (Howard Hinnant) writes:
> > >
> > > > This is what I would like to see:
> > > >
> > > > Imho auto_ptr should be deprecated in C++0X.  The "move from lvalues
> > > > with copy syntax" is too dangerous / error prone.  In its place (for
> > > > C++0X, not TR1) I would like to see an "auto_ptr-like" smart pointer
> > > > except that it moves from lvalues with syntax other than copy,
supports
> > > > deleters, and handles built-in arrays "well".
> > >
> > > Doesn't supporting deleters make it a bit heavyweight to replace
> > > auto_ptr?
>
> No, ...
>
> >    Also, wouldn't it be dangerous to support both custom deleters and
the
> > release() method in the same class?
>
> .. and no. The proposed auto_ptr replacement encodes the deleter as
> part of the type. Empty deleters can be optimized out, and it's
> possible to invoke the proper deleter on the result of release(),
> because it's known at compile time.
>
> So for example, when you need to choose a smart pointer for a factory
> function, if you want the client code to be aware of the allocation
> details and to retain exclusive ownership over the returned object,
> you'd use the new auto_ptr.

   I understand.  But suppose you do have a non-empty deleter.  How would
release() work in the case of an auto_ptr<X, Non_Empty_Deleter_Type>?  I
think auto_ptr should have a get_deleter() method for this situation.  One
corollary to this is that if an auto_ptr owns a deleter, release() should
give up ownership of the owned pointer but not the deleter.

   auto_ptr<X,  Deleter> p = get_auto_ptr();
   X *px = p.release();
   Deleter d = p.get_deleter();
   d(px);

Joe Gottman



---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <vlBlc.504$zq4.49076@twister.southeast.rr.com>,
 jgottman@carolina.rr.com ("Joe Gottman") wrote:

> > So for example, when you need to choose a smart pointer for a factory
> > function, if you want the client code to be aware of the allocation
> > details and to retain exclusive ownership over the returned object,
> > you'd use the new auto_ptr.
>
>    I understand.  But suppose you do have a non-empty deleter.  How would
> release() work in the case of an auto_ptr<X, Non_Empty_Deleter_Type>?  I
> think auto_ptr should have a get_deleter() method for this situation.  One
> corollary to this is that if an auto_ptr owns a deleter, release() should
> give up ownership of the owned pointer but not the deleter.
>
>    auto_ptr<X,  Deleter> p = get_auto_ptr();
>    X *px = p.release();
>    Deleter d = p.get_deleter();
>    d(px);

Agreed.  In fact I believe that there should be const and non-const
get_deleter() overloads that return const and non-const references to
the stored deleter, as opposed to the get_deleter function returning a
copy of the deleter (in the get_allocator() style).  This gives the
necessary flexibility to deal with stateful deleters:

    deleter_reference       get_deleter();
    deleter_const_reference get_deleter() const;

Note also that move_ptr<T>::deleter_type may actually be a reference to
a deleter instead of an actual deleter.  This allows copies of deleters
to be avoided either for optimization purposes, or for correctness
purposes when the copying of a deleter might be problematic.

Note again:

template<class T>
template<class Y, class D>
shared_ptr<T>::shared_ptr(Y* p, D d)
    : ptr_(p)
{
    Metrowerks::move_ptr<Y, D&> hold(p, d);
    s_ = new detail::shared_ptr_deleter<Y, D>(p, d);
    hold.release();
    ...
}

In this case I have no idea how expensive it might be to copy a D.  And
so as an optimization, the move_ptr's deleter_type is a D&, as opposed
to a D.

-Howard

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Howard Hinnant" <hinnant@metrowerks.com> wrote in message
news:hinnant-FC9598.08594726042004@syrcnyrdrs-02-ge0.nyroc.rr.com...
| In article <408b506f$0$4544$afc38c87@news.optusnet.com.au>,
|  nesotto@cs.auc.dk ("Thorsten Ottosen") wrote:

[snip]

| > ok. Do you think the method above could be applied here? Or maybe
| >
| > smart_pointer<T, array_delete > p( new T[sz] );
|
| One of the dangers I see in this approach is that even "experts" often
| forget that derived to base conversions on an array of objects is bad
| news.  So I'm concerned that it is too easy to compile and run:
|
| smart_pointer<Derived, array_delete > p1( new Derived[sz] );
|
| and then later:
|
| smart_pointer<Base, array_delete > p2( p1 );  // run time error!
|
| Encouraging such "cross pollination" makes me a little uneasy.  However
| the following:
|
| smart_pointer<Derived[]> p1( new Derived[sz] );
| smart_pointer<Base[]> p2( p1 );  // compile time error
|
| refuses to compile (which is desired).

I don't see why that compile-error cannot be generated by some TMP
if the second parameter is array_delete.

| > As you say, it is easier to add the size if it is needed, but it might
also
| > be wrong
| > to ask beginners to put together a new smart pointer with the size
stored
| > there.
| > So I hope we can allow experts total freedom and non-experts maximum
| > convinience.
|
| One might argue that smart_pointer<T[]> isn't for beginners in the first
| place.  95% of the time that a beginner is tempted to use smart_pointer
| to array of T, vector<T> is the proper answer.

True. I'm just wondering if that will keep people from doing it. I guess I
need to flip a coin
to make up my mind :-)

br

Thorsten



---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

hinnant@metrowerks.com (Howard Hinnant) writes:

>> That syntax looks really nice, I'm just wondering how you would stuff
>> the array size into those pointers. Would you use a size(), operator[]
>> member + new a constructor
>> that is not implemented for T, but only for T[]? And then have other
>> functions disabled when
>> T is not an array?
>
> This is what I would like to see:
>
> Imho auto_ptr should be deprecated in C++0X.  The "move from lvalues
> with copy syntax" is too dangerous / error prone.  In its place (for
> C++0X, not TR1) I would like to see an "auto_ptr-like" smart pointer
> except that it moves from lvalues with syntax other than copy, supports
> deleters, and handles built-in arrays "well".

Doesn't supporting deleters make it a bit heavyweight to replace
auto_ptr?

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"David Abrahams" <dave@boost-consulting.com> wrote in message
news:uhdv0bvwd.fsf@boost-consulting.com...
> hinnant@metrowerks.com (Howard Hinnant) writes:
>
> > This is what I would like to see:
> >
> > Imho auto_ptr should be deprecated in C++0X.  The "move from lvalues
> > with copy syntax" is too dangerous / error prone.  In its place (for
> > C++0X, not TR1) I would like to see an "auto_ptr-like" smart pointer
> > except that it moves from lvalues with syntax other than copy, supports
> > deleters, and handles built-in arrays "well".
>
> Doesn't supporting deleters make it a bit heavyweight to replace
> auto_ptr?
>

   Also, wouldn't it be dangerous to support both custom deleters and the
release() method in the same class?  Currently, if you have an auto_ptr<X>
object and you call release() on it you know you will eventually have to
call delete on the returned pointer.  If auto_ptr supported custom deleters,
you would not know whether you needed to call delete, delete[], free, some
class-specific deallocation function, or nothing at all.

Joe Gottman

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <uhdv0bvwd.fsf@boost-consulting.com>,
 dave@boost-consulting.com (David Abrahams) wrote:

> hinnant@metrowerks.com (Howard Hinnant) writes:
>
> >> That syntax looks really nice, I'm just wondering how you would stuff
> >> the array size into those pointers. Would you use a size(), operator[]
> >> member + new a constructor
> >> that is not implemented for T, but only for T[]? And then have other
> >> functions disabled when
> >> T is not an array?
> >
> > This is what I would like to see:
> >
> > Imho auto_ptr should be deprecated in C++0X.  The "move from lvalues
> > with copy syntax" is too dangerous / error prone.  In its place (for
> > C++0X, not TR1) I would like to see an "auto_ptr-like" smart pointer
> > except that it moves from lvalues with syntax other than copy, supports
> > deleters, and handles built-in arrays "well".
>
> Doesn't supporting deleters make it a bit heavyweight to replace
> auto_ptr?

Space for "empty" deleters can be optimized away (just like
allocators/containers).  The default deleters can be empty.  So the
overhead for move_ptr<T>/move_ptr<T[]> is exactly the same as for
auto_ptr.

Not to be confused with shared_ptr-like custom deleters.  Because
shared_ptr allows custom deleters without changing the type of the
shared_ptr, there is extra overhead.  I believe this overhead is
justified for shared_ptr, but not for move_ptr.  Therefore I propose
that custom deleters be part of move_ptr's type, leading to zero
overhead.

-Howard

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

nesotto@cs.auc.dk ("Thorsten Ottosen") wrote in message news:<408a0c40$0$20219$afc38c87@news.optusnet.com.au>...
> ""Daniel Kr   gler (nee Spangenberg)"" <dsp@bdal.de> wrote in message
> news:4088C2F6.5000106@bdal.de...
>
> |Note: shared_array does not reflect the actual array size (you mentioned
> |a size() member) or has the
> |most recent proposal changed this?
>
> I don't think so. But my point was that without storing the array size in
> the class, the
> programmer needs to
>
> 1) keep it around manually
> 2) and add extra arguments to function that take a shared_array<T[]>.
> 3) live without (not even debug) checking of operator[]
>
> IMO it seems to be a too error-prone design.
>
> So therefore I would like the normal constuctor to be disabled for T[] and
> replaced by a new one
> like
>
> shared_ptr<T[]> a( new T[sz], sz );
> ..
> for( size_t i = 0; i< s.size(); ++ i )
>      a[i]->foo();

But isn't this so close to shared_ptr< vector<T> > as to make it redundant?

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <408a0c40$0$20219$afc38c87@news.optusnet.com.au>,
 nesotto@cs.auc.dk ("Thorsten Ottosen") wrote:

> But my point was that without storing the array size in
> the class, the
> programmer needs to
>
> 1) keep it around manually
> 2) and add extra arguments to function that take a shared_array<T[]>.
> 3) live without (not even debug) checking of operator[]
>
> IMO it seems to be a too error-prone design.
>
> So therefore I would like the normal constuctor to be disabled for T[] and
> replaced by a new one
> like
>
> shared_ptr<T[]> a( new T[sz], sz );
> ..
> for( size_t i = 0; i< s.size(); ++ i )
>      a[i]->foo();

In the past I have needed two types of smart_pointer<T[]>:

1.  A smart_pointer that knew about the size of the array.
2.  A smart_pointer that did not need to know about the size of the
array.

In the first case I needed a vector-like object but the vector's
capacity in this particular application was redundant information
(size() == capacity() always).  And space was critical.  And so a
smart_pointer<T[]> that knew about its size was just the thing.

In the second case I needed to temporarily take ownership of a pointer
to array and then transfer ownership of that pointer to another type of
object, all in an excpetion safe manner.  The smart_pointer existed in
this application only to ease writing exception safe code, and not to
serve as a vector-like object.  The size of the array was already stored
elsewhere in the code and storing it in the smart_pointer<T[]> would
have just been redundant.

I can imagine applications where storing the size of the array in a
smart_pointer<T[]> would not only be redundant, but also costly.
Consider building a non-resizeable rectangular array with
vector<smart_pointer<T[]>>.  Here you would want to encapsulate this
structure in a class, and store the inner dimension only once, not once
per column.

So imho legitimate needs exist for two types of smart_pointer<T[]>:  one
that knows about its size and one that doesn't.  Here are some options:

1.  We could build a smarter_pointer<T[], Size = ...> where the second
template parameter defaults to an empty class that returns a
compile-time constant when queried.  Clients could ignore this second
parameter and space for it could be optimized away by a good
implementation.  Or clients could supply an integral type for the second
parameter and store the run-time size of the array in via a constructor
argument.  Thus you only pay for the size if you request it.  And yes,
I've actually written such a smart pointer.

2.  We could build smart_pointer<T[]> without knowledge of size and let
clients build size-aware smart pointers out of smart_pointer<T[]> if
they needed one.

3.  We could build smart_pointer<T[]> with knowledge of size.  Those
clients requiring a size-less smart_pointer<T[]> would have to roll
their own from scratch.  (you can more easily add data and functionality
to a class than remove it).

4.  We could supply two distinct types of smart_pointer<T[]> with
cleverly chosen names to distinguish (no suggestions off of the top of
my head).

My current thinking is that 2. is the most reasonable path.  But I allow
the possibility that I could be persuaded otherwise.  However choice 3
seems the most unreasonable to me at the moment.

-Howard

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Thorsten Ottosen"" <nesotto@cs.auc.dk> wrote in message
news:408a0c40$0$20219$afc38c87@news.optusnet.com.au...
.
>
> So therefore I would like the normal constuctor to be disabled for T[] and
> replaced by a new one
> like
>
> shared_ptr<T[]> a( new T[sz], sz );
> ..
> for( size_t i = 0; i< s.size(); ++ i )
>      a[i]->foo();
>
> br
>

   This seems a bit redundant.  Why not allow the shared_ptr<T[]> to take a
single parameter of type size_t?  Then when we call
    shared_ptr<int[]> p(7);
the shared_ptr constructor can call new int[7].

    Another possibility is to have a templated constructor that takes a
pointer to some type U and a size_t.

   template <class U>
     shared_ptr<T[]>::shared_ptr(U *p, size_t sz);

Then the shared_ptr can use the size of U internally to compute
operator[]().  This would allow shared_ptr<T[]> to handle arrays of base
classes polymorphically.

      struct Base {}; // No virtual destructor (we won't need one)
      struct Derived : public Base{
                                int data;  //Derived is bigger than Base;
                            };

      shared_ptr<Base[]> p(new Derived[10], 10);
      Base &b = p[5]; //Internally advances 5 * sizeof(Derived).
      p.reset(); //calls delete[] on stored Derived pointer.

Joe Gottman

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Peter Dimov" <pdimov@mmltd.net> wrote in message
news:7dc3b1ea.0404241142.418de82b@posting.google.com...
| nesotto@cs.auc.dk ("Thorsten Ottosen") wrote in message
news:<408a0c40$0$20219$afc38c87@news.optusnet.com.au>...

[snip]

| > shared_ptr<T[]> a( new T[sz], sz );
| > ..
| > for( size_t i = 0; i< s.size(); ++ i )
| >      a[i]->foo();
|
| But isn't this so close to shared_ptr< vector<T> > as to make it
redundant?

I guess so, but then why were you considering

shared_ptr< T[] >
scoped_ptr< T[] >
auto_ptr< T[] >

in the first place?

br

Thorsten


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Howard Hinnant" <hinnant@metrowerks.com> wrote in message
news:hinnant-3B15E2.09585724042004@syrcnyrdrs-01-ge0.nyroc.rr.com...

| In the second case I needed to temporarily take ownership of a pointer
| to array and then transfer ownership of that pointer to another type of
| object, all in an excpetion safe manner.  The smart_pointer existed in
| this application only to ease writing exception safe code, and not to
| serve as a vector-like object.  The size of the array was already stored
| elsewhere in the code and storing it in the smart_pointer<T[]> would
| have just been redundant.

but then couln't you say

smart_pointer<T> p( new T[sz], array_deleter() );

| I can imagine applications where storing the size of the array in a
| smart_pointer<T[]> would not only be redundant, but also costly.
| Consider building a non-resizeable rectangular array with
| vector<smart_pointer<T[]>>.  Here you would want to encapsulate this
| structure in a class, and store the inner dimension only once, not once
| per column.

ok. Do you think the method above could be applied here? Or maybe

smart_pointer<T, array_delete > p( new T[sz] );

As you say, it is easier to add the size if it is needed, but it might also
be wrong
to ask beginners to put together a new smart pointer with the size stored
there.
So I hope we can allow experts total freedom and non-experts maximum
convinience.

br

Thorsten


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <408b506f$0$4544$afc38c87@news.optusnet.com.au>,
 nesotto@cs.auc.dk ("Thorsten Ottosen") wrote:

> "Howard Hinnant" <hinnant@metrowerks.com> wrote in message
> news:hinnant-3B15E2.09585724042004@syrcnyrdrs-01-ge0.nyroc.rr.com...
>
> | In the second case I needed to temporarily take ownership of a pointer
> | to array and then transfer ownership of that pointer to another type of
> | object, all in an excpetion safe manner.  The smart_pointer existed in
> | this application only to ease writing exception safe code, and not to
> | serve as a vector-like object.  The size of the array was already stored
> | elsewhere in the code and storing it in the smart_pointer<T[]> would
> | have just been redundant.
>
> but then couln't you say
>
> smart_pointer<T> p( new T[sz], array_deleter() );
>
> | I can imagine applications where storing the size of the array in a
> | smart_pointer<T[]> would not only be redundant, but also costly.
> | Consider building a non-resizeable rectangular array with
> | vector<smart_pointer<T[]>>.  Here you would want to encapsulate this
> | structure in a class, and store the inner dimension only once, not once
> | per column.
>
> ok. Do you think the method above could be applied here? Or maybe
>
> smart_pointer<T, array_delete > p( new T[sz] );

One of the dangers I see in this approach is that even "experts" often
forget that derived to base conversions on an array of objects is bad
news.  So I'm concerned that it is too easy to compile and run:

smart_pointer<Derived, array_delete > p1( new Derived[sz] );

and then later:

smart_pointer<Base, array_delete > p2( p1 );  // run time error!

Encouraging such "cross pollination" makes me a little uneasy.  However
the following:

smart_pointer<Derived[]> p1( new Derived[sz] );
smart_pointer<Base[]> p2( p1 );  // compile time error

refuses to compile (which is desired).

I can see another "guideline" coming with smart pointers sporting custom
deleters:

> Never use an array deleter with the singular form of a smart pointer.  Use
> the array form of the smart pointer.  The interfaces of the two forms of
> smart pointers are slightly different in order to encourage safe use.

And I'm trying to avoid a situation where the above guideline is
augmented by:

> Except in the case where you can not afford the overhead of the array form of
> the smart pointer.

---------

> As you say, it is easier to add the size if it is needed, but it might also
> be wrong
> to ask beginners to put together a new smart pointer with the size stored
> there.
> So I hope we can allow experts total freedom and non-experts maximum
> convinience.

One might argue that smart_pointer<T[]> isn't for beginners in the first
place.  95% of the time that a beginner is tempted to use smart_pointer
to array of T, vector<T> is the proper answer.

-Howard

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

nesotto@cs.auc.dk ("Thorsten Ottosen") wrote in message news:<4085d549$0$20219$afc38c87@news.optusnet.com.au>...
> "Pete Becker" <petebecker@acm.org> wrote in message
> news:4085680A.F46E3C54@acm.org...
> | Thorsten Ottosen wrote:
> | >
> | > | 2.2  Smart Pointers                  N1450 03.03.27  Boost Smart
>  Pointers
> | >
> | > only shared_ptr<> and weak_ptr<> survived.
> | >
> |
> | Only shared_ptr and weak_ptr were proposed.
>
> Sorry, my fault. The text just said Boost Smart Pointers. I guess one could
> say the others died really early :-)

Well, not really. They didn't die, they just weren't ready. For
scoped_ptr, it's still not clear, at least for me, whether we need a
full scoped_ptr .. move_ptr .. auto_ptr spectrum in the standard
(move_ptr is like auto_ptr except it only moves from rvalues). Perhaps
only a move_ptr is needed (and perhaps it should even be named
auto_ptr, although the chances are small.)

It's also not clear whether the array versions aren't better spelled
as scoped_ptr<X[]> and shared_ptr<X[]> (and for consistency we
probably should have auto_ptr<X[]> as well.)

intrusive_ptr might be ready, but I'm not sure whether there's enough
demand for it.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Peter Dimov" <pdimov@mmltd.net> wrote in message
news:7dc3b1ea.0404220541.771b9eee@posting.google.com...

| It's also not clear whether the array versions aren't better spelled
| as scoped_ptr<X[]> and shared_ptr<X[]> (and for consistency we
| probably should have auto_ptr<X[]> as well.)

That syntax looks really nice, I'm just wondering how you would stuff
the array size into those pointers. Would you use a size(), operator[]
member + new a constructor
that is not implemented for T, but only for T[]? And then have other
functions disabled when
T is not an array?

br

Thorsten


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Good morning, Thorsten Ottosen!

Thorsten Ottosen schrieb:

>"Peter Dimov" <pdimov@mmltd.net> wrote in message
>news:7dc3b1ea.0404220541.771b9eee@posting.google.com...
>
>| It's also not clear whether the array versions aren't better spelled
>| as scoped_ptr<X[]> and shared_ptr<X[]> (and for consistency we
>| probably should have auto_ptr<X[]> as well.)
>
>That syntax looks really nice, I'm just wondering how you would stuff
>the array size into those pointers. Would you use a size(), operator[]
>member + new a constructor
>that is not implemented for T, but only for T[]? And then have other
>functions disabled when
>T is not an array?
>
>br
>
>Thorsten
> =20
>

Actually its quite simple by means of partial specialization - so you=20
don't need to change anything of
the interface of shared_array by moving to shared_ptr<T[]> (Despite the=20
class template name ;-)).

Note: shared_array does not reflect the actual array size (you mentioned=20
a size() member) or has the
most recent proposal changed this?

Greetings from Bremen,

Daniel Kr=FCgler


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <408867e3$0$4544$afc38c87@news.optusnet.com.au>,
 nesotto@cs.auc.dk ("Thorsten Ottosen") wrote:

> "Peter Dimov" <pdimov@mmltd.net> wrote in message
> news:7dc3b1ea.0404220541.771b9eee@posting.google.com...
>
> | It's also not clear whether the array versions aren't better spelled
> | as scoped_ptr<X[]> and shared_ptr<X[]> (and for consistency we
> | probably should have auto_ptr<X[]> as well.)
>
> That syntax looks really nice, I'm just wondering how you would stuff
> the array size into those pointers. Would you use a size(), operator[]
> member + new a constructor
> that is not implemented for T, but only for T[]? And then have other
> functions disabled when
> T is not an array?

This is what I would like to see:

Imho auto_ptr should be deprecated in C++0X.  The "move from lvalues
with copy syntax" is too dangerous / error prone.  In its place (for
C++0X, not TR1) I would like to see an "auto_ptr-like" smart pointer
except that it moves from lvalues with syntax other than copy, supports
deleters, and handles built-in arrays "well".

Something like:

namespace std
{

namespace detail
{

struct apply_delete
{
    template <class T>
    void operator() (T* ptr) {typedef char incomplete[sizeof(T)]; delete
ptr;}
};

struct apply_array_delete
{
    template <class T>
    void operator() (T* ptr) {typedef char incomplete[sizeof(T)]; delete
[] ptr;}
};

template <class T, bool b = is_array<T>::value>
struct default_delete
{
    typedef apply_delete type;
};

template <class T>
struct default_delete<T, true>
{
    typedef apply_array_delete type;
};

}  // detail

template<class T, class D = typename detail::default_delete<T>::type>
class move_ptr
{
public:
    typedef T element_type;
    typedef D deleter_type;
    typedef ... deleter_reference;
    typedef ... deleter_const_reference;

    explicit move_ptr(T* p = 0);
    move_ptr(T* p, deleter_const_reference d);

    // enable move from rvalue
    move_ptr(move_ptr&& a);

    template <class U, class E>
    move_ptr(move_ptr<U, E>&& a);

    move_ptr& operator=(move_ptr&& a);

    template <class U, class E>
    move_ptr& operator=(move_ptr<U, E>&& a);

    ~move_ptr();

    T& operator*() const throw();
    T* operator->() const throw();
    T* get() const throw();
    T* release() throw();
    void reset(T* p = 0);
    void swap(move_ptr&& a)
    deleter_reference       get_deleter();
    deleter_const_reference get_deleter() const;

    operator int bool_type::*() const;

private:

    // disable copy from lvalue
    move_ptr(const move_ptr& a);
    template <class U, class E>    move_ptr(const move_ptr<U, E>& a);
    move_ptr& operator=(const move_ptr& a);
    template <class U, class E>    move_ptr& operator=(const move_ptr<U,
E>& a);
};

template<class T, class D>
class move_ptr<T[], D>
{
public:
    typedef T element_type;
    typedef D deleter_type;
    typedef ... deleter_reference;
    typedef ... deleter_const_reference;

    explicit move_ptr(T* p = 0);

    move_ptr(T* p, deleter_const_reference d);

    // enable move from rvalue
    move_ptr(move_ptr&& a);
    move_ptr& operator=(move_ptr&& a);

    ~move_ptr();

    T& operator[](size_t i) const;
    T* get() const throw();
    T* release() throw();
    void reset(T* p = 0);
    void swap(move_ptr&& a);
    deleter_reference       get_deleter();
    deleter_const_reference get_deleter() const;

    operator int bool_type::*() const;

private:
    // disable copy from lvalue
    move_ptr(const move_ptr& a);
    move_ptr& operator=(const move_ptr& a);
};

}  // std

Notes:

move_ptr behaves as described in:

http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1377.htm#move_ptr
%20Example

It is movable but not copyable.  It has a custom deleter.  The deleter
can have reference type.  This is handy when you want to create a
move_ptr with a deleter that refers to state outside of the smart
pointer, e.g.

   MyDeleter del;
   move_ptr<T, MyDeleter&> p(new T, del);

Deleter state can be directly referenced via const and non-const
get_deleter() functions.

There are two move_ptr forms:  one for array and one for non-array.  The
interfaces for the two forms differ slightly to accommodate the
different use cases (array vs non-array).  The non-array form is used
like:

move_ptr<int> p1(new int);

The array form looks like:

move_ptr<int[]> p2(new int[3]);

The non-array form handles derived/base conversions (like auto_ptr) and
most of the other familiar auto_ptr-like member functions.  The array
form does not do derived/base conversions.  It lacks operator->() and
operator*() but has operator[](size_t).

A quality implementation would have the same overhead as auto_ptr for
"empty" (or stateless deleters - like the default), say by using
boost::compressed_pair<T*, D> to store the two data members.

Just my .02.

-Howard

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Daniel Kr   gler (nee Spangenberg)"" <dsp@bdal.de> wrote in message
news:4088C2F6.5000106@bdal.de...

|Actually its quite simple by means of partial specialization - so you
|don't need to change anything of
|the interface of shared_array by moving to shared_ptr<T[]> (Despite the
|class template name ;-)).
|
|Note: shared_array does not reflect the actual array size (you mentioned
|a size() member) or has the
|most recent proposal changed this?

I don't think so. But my point was that without storing the array size in
the class, the
programmer needs to

1) keep it around manually
2) and add extra arguments to function that take a shared_array<T[]>.
3) live without (not even debug) checking of operator[]

IMO it seems to be a too error-prone design.

So therefore I would like the normal constuctor to be disabled for T[] and
replaced by a new one
like

shared_ptr<T[]> a( new T[sz], sz );
..
for( size_t i = 0; i< s.size(); ++ i )
     a[i]->foo();

br

Thorsten


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

People often ask me what's in TR1 and where they can go for more
information.  From what I can tell, there is no easy place to point them,
so I put together the following table, based on the April 2004 draft of TR1
(N1647), poking around the standardization web site, and a few guesses.  My
goal here is to summarize what's in TR1, which documents describe the
various TR1 components, and where people can go to get experience with
libraries that are similar to TR1 components.

I welcome all comments on the following, especially corrections.

Thanks,

Scott


TR1
SEC  TOPIC                           DOC#  YY.MM.DD  BASED ON

2.1  Reference Wrapper               N1453 03.04.09  Boost Ref
2.2  Smart Pointers                  N1450 03.03.27  Boost Smart Pointers
3.1  Getting Function Object Return  N1454 03.04.09  ???
3.2  Enhanced Member Pointer Adapto  N1432 03.02.28  Boost Mem_Fn
3.3  Enhanced Binder                 N1455 03.04.10  Boost Bind
3.4  Polymorphic Function Object Wr  N1402 02.10.22  Boost Function
4    Type Traits                     N1424 03.03.03  Boost Type Traits
5.1  Extensible Random Number Facil  N1452 03.04.10  Boost Random Number
5.2  Mathematical Special Functions  N1422 03.02.24  ???
6.1  Tuple Types                     N1403 02.11.08  Boost Tuple
6.2  Fixed Size Array                N1479 03.04.23  Boost Array
6.3  Hash Tables                     N1456 03.04.09  Libs from SGI,
                                                     STLPort,
                                                     MetroWerks,
                                                     Dinkumware
7    Regular Expressions             N1429 03.03.03  Boost RegEx
8    C99 Compatibility               N1568 04.01.30  ???
None Iterator Facade and Adaptor     N1641 04.04.10  Boost Iterator

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Usenet@aristeia.com (Scott Meyers) writes:

> People often ask me what's in TR1 and where they can go for more
> information.  From what I can tell, there is no easy place to point them,
> so I put together the following table, based on the April 2004 draft of TR1
> (N1647), poking around the standardization web site, and a few guesses.  My
> goal here is to summarize what's in TR1, which documents describe the
> various TR1 components, and where people can go to get experience with
> libraries that are similar to TR1 components.
>
> I welcome all comments on the following, especially corrections.
>
> Thanks,
>
> Scott
>
>
> TR1
> SEC  TOPIC                           DOC#  YY.MM.DD  BASED ON
>
> 2.1  Reference Wrapper               N1453 03.04.09  Boost Ref
> 2.2  Smart Pointers                  N1450 03.03.27  Boost Smart Pointers
> 3.1  Getting Function Object Return  N1454 03.04.09  ???
> 3.2  Enhanced Member Pointer Adapto  N1432 03.02.28  Boost Mem_Fn
> 3.3  Enhanced Binder                 N1455 03.04.10  Boost Bind
> 3.4  Polymorphic Function Object Wr  N1402 02.10.22  Boost Function
> 4    Type Traits                     N1424 03.03.03  Boost Type Traits
> 5.1  Extensible Random Number Facil  N1452 03.04.10  Boost Random Number
> 5.2  Mathematical Special Functions  N1422 03.02.24  ???
> 6.1  Tuple Types                     N1403 02.11.08  Boost Tuple
> 6.2  Fixed Size Array                N1479 03.04.23  Boost Array
> 6.3  Hash Tables                     N1456 03.04.09  Libs from SGI,
>                                                      STLPort,
>                                                      MetroWerks,
>                                                      Dinkumware
> 7    Regular Expressions             N1429 03.03.03  Boost RegEx
> 8    C99 Compatibility               N1568 04.01.30  ???
> None Iterator Facade and Adaptor     N1641 04.04.10  Boost Iterator

Hi Scott,

In Sydney we voted to pull that last one, and its companion, the new
iterator concepts, from TR1 in order to give them more time to
gestate.  Too many changes were being made at the last minute and we
didn't feel they were stable enough.  We've resubmitted the papers
with their revisions
(http://www.boost-consulting.com/writing/facade-and-adaptor.html and
http://www.boost-consulting.com/writing/new-iter-concepts.html) for
TR2 or the C++0x WP, whichever comes first.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Scott Meyers wrote:
>
> TR1
> SEC  TOPIC                           DOC#  YY.MM.DD  BASED ON
>
> 2.1  Reference Wrapper               N1453 03.04.09  Boost Ref
> 2.2  Smart Pointers                  N1450 03.03.27  Boost Smart Pointers
> 3.1  Getting Function Object Return  N1454 03.04.09  ???

result_of is an amalgamation of ideas from Boost bind and Boost
function. (Same for reference wrapper, actually)

> 3.2  Enhanced Member Pointer Adapto  N1432 03.02.28  Boost Mem_Fn
> 3.3  Enhanced Binder                 N1455 03.04.10  Boost Bind
> 3.4  Polymorphic Function Object Wr  N1402 02.10.22  Boost Function
> 4    Type Traits                     N1424 03.03.03  Boost Type Traits
> 5.1  Extensible Random Number Facil  N1452 03.04.10  Boost Random Number
> 5.2  Mathematical Special Functions  N1422 03.02.24  ???

Brand new stuff, proposed by folks from Fermi Labs.

> 6.1  Tuple Types                     N1403 02.11.08  Boost Tuple
> 6.2  Fixed Size Array                N1479 03.04.23  Boost Array
> 6.3  Hash Tables                     N1456 03.04.09  Libs from SGI,
>                                                      STLPort,
>                                                      MetroWerks,
>                                                      Dinkumware

Hash tables were in the original STL, but removed by the proposers as
part of shrinking the proposal. There was a later proposal to add them,
but it was too late for C++98.

> 7    Regular Expressions             N1429 03.03.03  Boost RegEx
> 8    C99 Compatibility               N1568 04.01.30  ???

C99 Compatibility is, of course, based on C99. <g>

> None Iterator Facade and Adaptor     N1641 04.04.10  Boost Iterator

Iterator Facade and Adaptor will not be in TR1. They need more work, and
there isn't enough time for it. Look for them (or something derived from
them) in C++0x, or (maybe) TR2.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Scott Meyers" <Usenet@aristeia.com> wrote in message
news:MPG.1aedebc65715b8dd98973e@news.hevanet.com...
[snip]
| TR1
| SEC  TOPIC                           DOC#  YY.MM.DD  BASED ON
|
| 2.1  Reference Wrapper               N1453 03.04.09  Boost Ref
| 2.2  Smart Pointers                  N1450 03.03.27  Boost Smart Pointers

only shared_ptr<> and weak_ptr<> survived.

br

Thorsten


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Tue, 20 Apr 2004 17:42:33 +0000 (UTC), Pete Becker wrote:
> Scott Meyers wrote:
> > TR1
> > SEC  TOPIC                           DOC#  YY.MM.DD  BASED ON
> >
> > 3.1  Getting Function Object Return  N1454 03.04.09  ???
>
> result_of is an amalgamation of ideas from Boost bind and Boost
> function. (Same for reference wrapper, actually)
>
> > 5.2  Mathematical Special Functions  N1422 03.02.24  ???
>
> Brand new stuff, proposed by folks from Fermi Labs.
>
> > 6.3  Hash Tables                     N1456 03.04.09  Libs from SGI,
> >                                                      STLPort,
> >                                                      MetroWerks,
> >                                                      Dinkumware
>
> Hash tables were in the original STL, but removed by the proposers as
> part of shrinking the proposal. There was a later proposal to add them,
> but it was too late for C++98.
>
> > 8    C99 Compatibility               N1568 04.01.30  ???
>
> C99 Compatibility is, of course, based on C99. <g>

I apparently wasn't clear about what I mean by "Based On."  The information
in that column isn't supposed to be historical, it's supposed to tell
people where they can go now to get software that behaves essentially the
same as the corresponding TR1 component.  So if somebody wants to play
around with result_of (even if it isn't called that), the new math
functions, or the new C99 compatibility stuff, where can they go?  For C99,
the place to go would presumbably be a C99 installation, but what about
result_of and the special math functions?  If it's freely downloadable, so
much the better.

I'll have to renname that column...

Scott

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Thorsten Ottosen wrote:
>
> | 2.2  Smart Pointers                  N1450 03.03.27  Boost Smart Pointers
>
> only shared_ptr<> and weak_ptr<> survived.
>

Only shared_ptr and weak_ptr were proposed.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Scott Meyers" <Usenet@aristeia.com> wrote in message
news:MPG.1aef07c33ab9678e98973f@news.hevanet.com...

> I apparently wasn't clear about what I mean by "Based On."  The
information
> in that column isn't supposed to be historical, it's supposed to tell
> people where they can go now to get software that behaves essentially the
> same as the corresponding TR1 component.  So if somebody wants to play
> around with result_of (even if it isn't called that), the new math
> functions, or the new C99 compatibility stuff, where can they go?  For
C99,
> the place to go would presumbably be a C99 installation,

Well, in some part perhaps. The C99 addition to TR1 includes all sorts of
overloads, macro replacements, and other enhancements designed to make
the new C library stuff play better with C++.

>                                                        but what about
> result_of and the special math functions?  If it's freely downloadable, so
> much the better.

I hope to have a brief summary of sources for the special math algorithms,
and code where possible, for the October 2004 C meeting in Redmond.
Meanwhile, you really have to scrounge.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Scott Meyers" <Usenet@aristeia.com> wrote in message
news:MPG.1aedebc65715b8dd98973e@news.hevanet.com...

> People often ask me what's in TR1 and where they can go for more
> information.  From what I can tell, there is no easy place to point them,
> so I put together the following table, based on the April 2004 draft of
TR1
> (N1647), poking around the standardization web site, and a few guesses.
My
> goal here is to summarize what's in TR1, which documents describe the
> various TR1 components, and where people can go to get experience with
> libraries that are similar to TR1 components.
>
> I welcome all comments on the following, especially corrections.
>
> Thanks,
>
> Scott
>
>
> TR1
> SEC  TOPIC                           DOC#  YY.MM.DD  BASED ON
>
> 2.1  Reference Wrapper               N1453 03.04.09  Boost Ref
> 2.2  Smart Pointers                  N1450 03.03.27  Boost Smart Pointers
> 3.1  Getting Function Object Return  N1454 03.04.09  ???
> 3.2  Enhanced Member Pointer Adapto  N1432 03.02.28  Boost Mem_Fn
> 3.3  Enhanced Binder                 N1455 03.04.10  Boost Bind
> 3.4  Polymorphic Function Object Wr  N1402 02.10.22  Boost Function
> 4    Type Traits                     N1424 03.03.03  Boost Type Traits
> 5.1  Extensible Random Number Facil  N1452 03.04.10  Boost Random Number
> 5.2  Mathematical Special Functions  N1422 03.02.24  ???
> 6.1  Tuple Types                     N1403 02.11.08  Boost Tuple
> 6.2  Fixed Size Array                N1479 03.04.23  Boost Array
> 6.3  Hash Tables                     N1456 03.04.09  Libs from SGI,
>                                                      STLPort,
>                                                      MetroWerks,
>                                                      Dinkumware
> 7    Regular Expressions             N1429 03.03.03  Boost RegEx
> 8    C99 Compatibility               N1568 04.01.30  ???
> None Iterator Facade and Adaptor     N1641 04.04.10  Boost Iterator

Nice table.

The C99 Compatibility addition is based on the integration of
C99 and C++ we did at Dinkumware. See our online C99 library
reference for most of the details.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Scott Meyers wrote:
>
> I apparently wasn't clear about what I mean by "Based On."  The information
> in that column isn't supposed to be historical, it's supposed to tell
> people where they can go now to get software that behaves essentially the
> same as the corresponding TR1 component.

Well, be careful. Some of these have changed significantly from the
things they're based on. Regular expressions and random number
generators have probably changed the most, and those are way different.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Pete Becker" <petebecker@acm.org> wrote in message
news:4085680A.F46E3C54@acm.org...
| Thorsten Ottosen wrote:
| >
| > | 2.2  Smart Pointers                  N1450 03.03.27  Boost Smart
Pointers
| >
| > only shared_ptr<> and weak_ptr<> survived.
| >
|
| Only shared_ptr and weak_ptr were proposed.

Sorry, my fault. The text just said Boost Smart Pointers. I guess one could
say
the others died really early :-)

br

Thorsten


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]