C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Summary Table for TR1 Goto page 1, 2  Next          C++Talk.NET Forum Index -> C++ language, library and standards View previous topic :: View next topic   Author Message Scott Meyers Guest Posted: Mon Apr 19, 2004 11:03 pm    Post subject: Summary Table for TR1 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 ] Back to top David Abrahams Guest Posted: Tue Apr 20, 2004 2:45 am    Post subject: Re: Summary Table for TR1 [email]Usenet (AT) aristeia (DOT) com[/email] (Scott Meyers) writes: Quote: 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 ] Back to top Pete Becker Guest Posted: Tue Apr 20, 2004 5:42 pm    Post subject: Re: Summary Table for TR1 Scott Meyers wrote: Quote: 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) Quote: 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. Quote: 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. Quote: 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> Quote: 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 ] Back to top Thorsten Ottosen Guest Posted: Tue Apr 20, 2004 6:02 pm    Post subject: Re: Summary Table for TR1 "Scott Meyers" <Usenet (AT) aristeia (DOT) com> wrote [snip] Quote: 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 ] Back to top Scott Meyers Guest Posted: Tue Apr 20, 2004 6:23 pm    Post subject: Re: Summary Table for TR1 On Tue, 20 Apr 2004 17:42:33 +0000 (UTC), Pete Becker wrote: Quote: 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. 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 ] Back to top Pete Becker Guest Posted: Tue Apr 20, 2004 6:23 pm    Post subject: Re: Summary Table for TR1 Thorsten Ottosen wrote: Quote: | 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 ] Back to top P.J. Plauger Guest Posted: Tue Apr 20, 2004 7:18 pm    Post subject: Re: Summary Table for TR1 "Scott Meyers" <Usenet (AT) aristeia (DOT) com> wrote Quote: 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++. Quote: 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 ] Back to top P.J. Plauger Guest Posted: Tue Apr 20, 2004 8:49 pm    Post subject: Re: Summary Table for TR1 "Scott Meyers" <Usenet (AT) aristeia (DOT) com> wrote Quote: 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 ] Back to top Pete Becker Guest Posted: Tue Apr 20, 2004 8:55 pm    Post subject: Re: Summary Table for TR1 Scott Meyers wrote: Quote: 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 ] Back to top Thorsten Ottosen Guest Posted: Wed Apr 21, 2004 7:31 pm    Post subject: Re: Summary Table for TR1 "Pete Becker" <petebecker (AT) acm (DOT) org> wrote Quote: 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 ] Back to top Peter Dimov Guest Posted: Thu Apr 22, 2004 3:12 pm    Post subject: Re: Summary Table for TR1 [email]nesotto (AT) cs (DOT) auc.dk[/email] ("Thorsten Ottosen") wrote in message news:<4085d549$0$20219$afc38c87 (AT) news (DOT) optusnet.com.au>... Quote: "Pete Becker" <petebecker (AT) acm (DOT) org> wrote in message news:4085680A.F46E3C54 (AT) acm (DOT) 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 ] Back to top Thorsten Ottosen Guest Posted: Fri Apr 23, 2004 4:52 am    Post subject: Re: Summary Table for TR1 "Peter Dimov" <pdimov (AT) mmltd (DOT) net> wrote Quote: 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 ] Back to top Daniel Krügler Guest Posted: Fri Apr 23, 2004 11:02 pm    Post subject: Re: Summary Table for TR1 Good morning, Thorsten Ottosen! Thorsten Ottosen schrieb: Quote: "Peter Dimov" <pdimov (AT) mmltd (DOT) net> wrote in message news:7dc3b1ea.0404220541.771b9eee (AT) posting (DOT) 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 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? Greetings from Bremen, Daniel Krügler --- [ 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 ] Back to top Howard Hinnant Guest Posted: Fri Apr 23, 2004 11:09 pm    Post subject: Re: Summary Table for TR1 In article <408867e3$0$4544$afc38c87 (AT) news (DOT) optusnet.com.au>, [email]nesotto (AT) cs (DOT) auc.dk[/email] ("Thorsten Ottosen") wrote: Quote: "Peter Dimov" <pdimov (AT) mmltd (DOT) net> wrote in message news:7dc3b1ea.0404220541.771b9eee (AT) posting (DOT) 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 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 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 ] Back to top Thorsten Ottosen Guest Posted: Sat Apr 24, 2004 9:13 am    Post subject: Re: Summary Table for TR1 ""Daniel Krügler (nee Spangenberg)"" <dsp (AT) bdal (DOT) de> wrote Quote: 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 ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ language, library and standards All times are GMT Goto page 1, 2  Next Page 1 of 2   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.