CoW and reference counting in the STL
in [C++]
|
From: Andre Kaufmann on 1 May 2010 05:23 Bo Persson wrote: > Andre Kaufmann wrote: > [...] > No? > What about > char& c = b[3]; // operator[](int) -> Can't alloc -> throw > I would be pretty concerned about this one! Sure, but potentially any function can throw. operator[] doesn't necessarily be lightweight. At least there is no promise for it to be. > As others have mentioned, COW is perhaps not evil in itself, but combined with the std::string interface it just doesn't work. Perhaps you wouldn't run into insufficient memory conditions, if COW would be used. Anyways each function call may throw, where is the difference ? > Bo Persson Andre -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andre Kaufmann on 1 May 2010 05:24 Mathias Gaunard wrote: > On Apr 30, 6:28 pm, Andre Kaufmann <akfmn...(a)t-online.de> wrote: >> There is IMHO no 100% exception safe application. > Sure there is, it's trivial to achieve if you just use RAII. > By just exception-safe, I mean the basic guarantee. It's for example not trivial if you have to use code, which doesn't use RAII. The world just isn't perfect. >> Another exception during stack unwinding and your application blows up. >> [...] >> Which doesn't prevent exceptions during stack unwinding > Which is why people make destructors nothrow, even if they don't > enforce it. > Not enforcing it means that if it still happens, the program aborts > instantly with an error message. Not a serious issue. I think an abort is a serious issue, but commonly the best thing to do. You indirectly agree to my argument, that there aren't 100% exception safe C++ applications, by agreeing that there are many dos and dont's to get exception safe code. Just 2 examples: Which developer / code is (in !every! class) prepared: a) For the destructor not be called if a constructor throws ? Effectively there mustn't be any code in a destructor anyway. If you use RAII you don't need code in the destructor. Now have a look at your or other code. Are all destructors empty ? Is the developer prepared for this code not to be called ? b) Which code has all destructors made nothrow ? Basically under low memory conditions all operations may fail even a simple string1 + string2 when you write a log entry in the destructor. I think to be an experienced C++ developer, but anyways how hard I try a make failures and miss something and don't write 100% perfect code, since I'm always under pressure to deliver just in time. Nobody (sales department and customer) doesn't care about exception safe code, if the applications runs well. And as I wrote low memory conditions will result in slow OS and much slower applications, before the memory allocations will fail. I totally agree that RAII is a must and I'm not arguing that exceptions are evil. I'm only prepared that the world isn't perfect. > [...] I have no idea what you're talking about there. What is a huge > difference? It's IMHO easier to recover from operator new(10.000.000) than from for(int i.....) map[i] = element Because most developers are prepared the first example to fail and will explicitly handle it. Additionally more allocations will fail if you reached the memory barrier with small allocations. Which reduces the predictability to be able to recover from such a situation. Insufficient memory conditions cause by allocating small chunks of memory increases the likelihood that constructors may throw and that destructors may throw too. So IMHO a "huge difference". > [...] RAII ensures the code provides the basic guarantee, but not more. It's just like code safety: The line if ((a + b) <= max_size) is potentially a security issue. But same as RAII, even a experiences developer either might miss such a line, does not use RAII in all conditions or use a library which isn't 100% perfect, which simply converts 100% perfect code to be imperfect too. Which developer for example wraps (any time) code like: class Foo { Foo() : ... { } ~Foo() { FreeSystemResources (); } }; in an RAII object, which potentially must have access to all elements of class Foo. Laziness and time pressure will IMHO most developers simply to continue with such code and not think all the time, if the destructor might potentially not be called. > [...] > If an operation as basic as writing to memory could throw, then there > is no way you could do much. operator[] is as any other function able to throw In this case writing to memory doesn't throw, it's the memory allocation before the write. If you use exceptions, you must be prepared that any function/operator might throw. You wrote that RAII is able to handle this, do you make an "exception" for this case ? Andre -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Öö Tiib on 1 May 2010 05:25 On Apr 30, 11:26 pm, Mathias Gaunard <loufo...(a)gmail.com> wrote: > Writing exception-safe code requires that a set of operations be > nothrow, since they're the operations you're going to perform in case > of error -- or in case of stack unwinding as you were talking about -- > to rollback to some previous or just safe state. > If an operation as basic as writing to memory could throw, then there > is no way you could do much. Yes. So calling std::map operator[] can throw. Not a crime for you. Calling some theoretical (since string is not suitable) cow_container operator[] can throw. Crime, bad crime for you. But i fail to see that slightest difference between the two criminals. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andre Kaufmann on 1 May 2010 05:23 joe wrote: > Andre Kaufmann wrote: > [...] b[3] = 'c'; > what would make you think this would allocate? Arrays dont, vectors COW strings must allocate. > joe Andre -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Mathias Gaunard on 2 May 2010 22:02
On 1 mai, 21:24, Andre Kaufmann <akfmn...(a)t-online.de> wrote: > You indirectly agree to my argument, that there aren't 100% exception safe C++ applications, by agreeing that there are many > > dos and dont's > > to get exception safe code. No, I do not agree. The fact you need to code in a specific way does not allow to conclude that there is no "100% exception safe C++ application". -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |