From: nmm1 on
In article
<35c20875-6842-4b5c-9386-9499c3858d3b(a)f6g2000yqa.googlegroups.com>,
Howard Hinnant <howard.hinnant(a)gmail.com> wrote:
>On Jul 24, 9:59 am, Dragan Milenkovic <dra...(a)plusplus.rs> wrote:
>>
>> Also, you may describe the concrete problem that bothers you and someone
>> will most likely provide the most clean and effective way to achieve it.
>>
>> Recovery is still possible in the current library, but you have
>> to do it yourself. Does that count as "reasonably possible"? And people
>> _do_ care about time and complexity, it's the standard library... should
>> we all write our own in order to optimize it? You just cannot ask for
>> something that would ruin the library.
>
>Well said.

Eh?

>Many people don't realize that it is relatively easy to add features
>when using a minimal & fast library - making an informed engineering
>tradeoff between features and performance. But when given a feature-
>rich library (without access to a low-level API), one can't make it
>fast when you don't need the features. Doing so is a common mistake
>in library design: forgetting or dismissing the importance of the low-
>level layer.

That is extremely true, but is in flat contradiction to what the
OP asked for, and what I understood Dragan Milenkovic to mean.

The same is true for RAS, only even more so, and yet more for actual
recovery. It is a common and catastrophic mistake to think that
either are features, because they are not, and cannot be built on
top of a design that doesn't have them. They are fundamental
properties of the base design and implementation.

There is NO WAY that a programmer can add recovery facilities to
the current STL. An implementor can - but, to make it usable, has
to specify its properties and constraints - i.e. design an extended
STL standard.


Regards,
Nick Maclaren.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]