Re: [Boost-Users] Four Questions on boost::shared_ptr
On 2/3/02 11:54 PM, "Jon Wang" <webmaster@boost.100ok.com> wrote:
1. Mr Stroustrup said that there wasn't a need for auto_array, for "a better solution is to use a vector". So, should we use vector or scoped_array/shared_array?
You should normally use std::vector unless you have some special reason to use boost:: scoped_array and boost::shared_array. Those classes are provided both for completeness, and because occasionally there are such special reasons. But not often.
2. In the document, four implementations are said to have been discussed: Direct detached, Indirect detached, Embedded detached and Placement detached. I've tried to describle them (Are I right? See the attached file), but I don't understand the Placement detached. Could someone please tell me what it's like?
The concept here is that the object is allocated in a special way, which require use of placement, so the count is in a header before the object. This is a form of the "embedded attached" scheme that does not require changes to the original object's class, but it does require a special form of new, so you couldn't just call the normal "new" and then give the object to such a smart pointer. [Note: There was no attached file.]
3. In the file smart_ptr.hpp, we can see the private function shared_ptr::share.
I'm sorry that I don't understand that reason why ++*rpn should be done before dispose(). Would someone please give me an example? Or is it like this?
This function is gone from the latest implementation of shared_ptr slated for the next boost release, so it's probably not worthwhile to discuss this particular aspect of the old implementation in detail. The code you enclosed looks something like the kind of code that caused trouble -- the key is that deleting the old object pointed to can end up deleting the new shared pointer in some cases, and this must not happen before incrementing the reference count. The new implementation avoids this issue by using the well-known "copy and swap" idiom for implementing assignment, and is easier to understand.
4. Why not use policies? I'm afraid that the word "parameterization will discourage users" might not be always true, for we can use default parameters.
We'll probably be using policies in future version, if we can work out all the issues. Andrei Alexandrescu is considering submitting his smart pointer class template from his Loki library to Boost for formal review, which is the most likely candidate for a Boost policy-based smart pointer. If it turns out well enough, it may replace all the existing smart pointer class templates. -- Darin
--- At Mon, 4 Feb 2002 00:28:32 -0800, Darin Adler wrote:
On 2/3/02 11:54 PM, "Jon Wang" <webmaster@boost.100ok.com> wrote:
1. Mr Stroustrup said that there wasn't a need for auto_array, for "a better solution is to use a vector". So, should we use vector or scoped_array/shared_array?
You should normally use std::vector unless you have some special reason to use boost:: scoped_array and boost::shared_array. Those classes are provided both for completeness, and because occasionally there are such special reasons. But not often.
I consider user vector<> often. However there is a cost. For a fixed size allocation of a buffer there is only the data allocated. If you use a vector<> the vector also includes (for most implementations) the current capacity, the current size, and the allocator. I would be interested in finding a class that is somewhere between allocating my own buffers and vector<>. Low overhead for simple allocations; no resizing or growing. Even in this case, in order to support iterator semantics the size is going to be needed. Sigh. I suppose a case like this might be when scoped_array would be used? ...Duane
On 2/4/02 9:03 AM, "Duane Murphy" <duanemurphy@mac.com> wrote:
I would be interested in finding a class that is somewhere between allocating my own buffers and vector<>. Low overhead for simple allocations; no resizing or growing. Even in this case, in order to support iterator semantics the size is going to be needed.
There's a class boost::array that will sometimes meet your requirements. There's another proposed class that will probably show up in a future version of Boost called boost::fixed_capacity_vector that might also meet your requirements. A boost::scoped_array or boost::shared_array is occasionally useful, but not often. But be wary of overestimating the importance of std::vector's low overhead. It's often quite affordable, and not having a fixed capacity limit can be a valuable feature that can help you avoid buffer overrun problems. -- Darin
Hi
You should normally use std::vector unless you have some special reason to use boost:: scoped_array and boost::shared_array. Those classes are provided both for completeness, and because occasionally there are such special reasons. But not often.
I consider user vector<> often. However there is a cost. For a fixed size allocation of a buffer there is only the data allocated. If you use a vector<> the vector also includes (for most implementations) the current capacity, the current size, and the allocator.
There is another sometimes very big overhead incurred by std::vector, and not incurred by by new T[]/ delete[]. Most implementions of std::vector will enter a loop and call a destructor on each element of the array, even if there is no machine code associated with that destructor. At least Borlands implemention of delete[] automatically detects this condition and does not insert a loop to call the destructors. This could be avoided if std::vector used a traits type to determine whether to enter a loop calling destructors. Duane Murphy wrote:
--- At Mon, 4 Feb 2002 00:28:32 -0800, Darin Adler wrote:
On 2/3/02 11:54 PM, "Jon Wang" <webmaster@boost.100ok.com> wrote:
1. Mr Stroustrup said that there wasn't a need for auto_array, for "a
better
solution is to use a vector". So, should we use vector or scoped_array/shared_array?
You should normally use std::vector unless you have some special reason to use boost:: scoped_array and boost::shared_array. Those classes are provided both for completeness, and because occasionally there are such special reasons. But not often.
I consider user vector<> often. However there is a cost. For a fixed size allocation of a buffer there is only the data allocated. If you use a vector<> the vector also includes (for most implementations) the current capacity, the current size, and the allocator.
I would be interested in finding a class that is somewhere between allocating my own buffers and vector<>. Low overhead for simple allocations; no resizing or growing. Even in this case, in order to support iterator semantics the size is going to be needed.
Sigh.
I suppose a case like this might be when scoped_array would be used?
...Duane
Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com>
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
[Non-text portions of this message have been removed]
participants (3)
-
Darin Adler -
Duane Murphy -
hicks