Boost logo

Boost :

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2003-12-29 18:18:18


"Jonathan Turkanis" <technews_at_[hidden]> wrote in message
news:bsphu3$k79$1_at_sea.gmane.org...
>
[snip]
> I'm not sure I follow you here. I was just suggesting that you could
> demonstrate the exception safety of your implementation by arranging for
> some exceptions to be thrown, as a test, and inspecting the state of the
> containers afterward.

yeah, it is a good idea.

[snip]
> Perhaps the benefits are not worth the costs of implementation or the cost
> of explaining the interface. What I mean is this: sometimes you do not
want
> the container to manage the lifetime of your objects -- perhaps they occur
> in several containers at once -- but you could still benefit from the
> syntactic conveniences you describe, such as having built-in derefencing
> iterators.
>
> >
> > I think we need to see some use for this. I cannot forsee how much it
will
> > complicate
> > the implementation. There is also the concern about how the interface
> should
> > be changed
> > to allow sharing of the pointers to work (I assume that is still
wanted).
> >
>
> I expect that in some cases it might double the size of the
implementation,
> since there will be essentially two independent implementations under the
> hood. So I can see why you would not find this appealing. And I am not
sure
> exactly what interface changes would be requires (as I said I had not the
> idea through fully.) The main idea is this: introducing a new family of
> containers is a major undertaking, not just for the implementor, but for
> users.

Is it more diffucult than any other library?

>The library should be as comprehensive as it reasonably can be. One
> of the major rationales of the library is (3), which applies in a broader
> range of situations than addressed by the library. So if the library can
be
> extended to cover the the other cases, other things being equal, it should
> be.

Let's think about it for a while :-)

br

Thorsten


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk