Prev: [ANN] ACCU 2011 Conference Call for Proposals
Next: Is there any standard/guarantees for exception safety in STL operations?
From: Dragan Milenkovic on 25 Jul 2010 23:48 On 07/25/2010 04:26 PM, nmm1(a)cam.ac.uk wrote: > In article<i2dkhc$idh$1(a)speranza.aioe.org>, > Dragan Milenkovic<dragan(a)plusplus.rs> wrote: >> On 07/23/2010 01:59 AM, Thomas Richter wrote: [snip] >>> Sure, but maybe I need a different recovery strategy. And then I have >>> little means of implementing one. That's what I'm saying. >> >> How about you check the answer Louis Lavery gave? >> >> 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. > > That misses the critical point. The library does not specify enough > behaviour in most exceptional cases, which means that it is impossible > to write portable or reliable recovery code. As I posted, it could > do a lot better, WITHOUT comprimising efficiency, but the design, > specification and implementation efforts are comparable with what > has already been done. Are you sure that it is impossible? Or is it just not trivial? From what I understand on this topic is that the main reason for all of this is that the Standard does not want to force a specific implementation and representation. However, I don't have a strong opinion whether this is good or bad, only that it is fairly reasonable. Of course, wording in the Standars is a horror... :-/ -- Dragan [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |