Boost logo

Boost :

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2003-12-25 02:09:13

"Nicolas Fleury" <nidoizo_at_[hidden]> wrote in message
> Thorsten Ottosen wrote:
> > Feedback is welcome.
> I just want to tell you that I am very interested in your library.

That's good to hear.

> Right now, when I want a container to have ownership of pointers, I
> basically have the choice between complicate the usage (not that much
> but still)


>and handle the ownership by hand, which can be error-prone,

you have no idea :-)

> particularly if code deleting elements is added.
> I usually choose to
> store shared_ptrs, but it complicates for nothing the creation of all
> added elements in context when the elements are not actually *shared*.
> Your solution would be something very simple to explain to my collegues
> and adds no burden to creation of elements. If it is someday in Boost,
> I would use it right away.

well, you should start to try to use it soon. Even some is of another
I'm certain that all major design decisions are in place.

> I think the const-copy semantic of elements in STL containers is
> basically forcing to use shared_ptrs even when elements are not shared,
> so I think your solution of having equivalent containers for pointers is
> the good solution.

indeed. It's the only way to get the zero-overhead C++ hallmark.

> Like others pointed, I think you example could be more convincing. You
> should show how it simplifies everything in day-to-day work with
> basically all operations.

yes, I should. I'm just wondering if those who said that actually browsed to
the eaxmple section
and viewed the examples.

> About ptr_map, I wonder if a map with the key a pointer should be
> provided (and another with both key and value pointers). Same thing for
> multimap.

So you want three types of maps. Can you give a moivating example? I have
seen use for the
mapped type to be a pointer.

There is a slight problem with two pointers, namely that an exception-safe
insert cannot
take two naked pointer values, it would have to be two auto_ptr's.

> About releasing functions returning auto_ptrs and adopting ones taking
> one, even if I have used this convention before, I feel it is far from
> standard

yeah std::auto_ptr.release() does not return another auto_ptr <g>.

>and I don't remember having seeing it in Boost.

nothing like this is in boost.

> It is however
> more safe.


Thanks for your comments, sorry I not elaborating very much, but I've just
been celebrating christmas for two days without too much sleep.(and I'm
still a biit drunk)

br and merry Christnas


Boost list run by bdawes at, gregod at, cpdaniel at, john at