CoW and reference counting in the STL
in [C++]
|
From: Mathias Gaunard on 2 May 2010 22:02 On 1 mai, 21:25, �� Tiib <oot...(a)hot.ee> wrote: > 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. Neither is these are simple "writing to memory" operations. Plus std::map operator[] may only throw in a particular case; and it's easy to avoid if you just use find instead. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Alexander Terekhov on 3 May 2010 16:43 Mathias Gaunard wrote: [...] > Plus std::map operator[] may only throw in a particular case; and it's > easy to avoid if you just use find instead. Sez who? ... Chapter and verse? ... regards, alexander. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Alexander Terekhov on 3 May 2010 16:59 Andre Kaufmann wrote: > > 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. Potentially any function/callee without throw() ES (upcoming noexcept aside for a moment) can emit an exception on caller from callee's body (lack of stack memory to make a function call aside for a moment). And the caller shall be prepared either to handle it or document the path-through unwinding initiated by callee to caller's caller. > operator[] doesn't necessarily be lightweight. At least there is > no promise for it to be. IIRC non-const operator[] of std::string doesn't promise to throw-nothing either. So the interface is okay. > > > 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. Seconded. regards, alexander. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andre Kaufmann on 3 May 2010 16:59 Mathias Gaunard wrote: > 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 Well, it's your opinion. > that there is no "100% exception safe C++ application". It's my opinion that RAII helps to write exception safe code, but neither makes it trivial nor 100% perfect. There are many other pitfalls, code I have to use which I haven't written by myself or new technologies like parallel loops which make it hard to write exception safe code. 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 6 May 2010 05:26
�� Tiib wrote: > On 3 mai, 16:02, Mathias Gaunard <loufo...(a)gmail.com> wrote: > [...] > Makes sense? For me it makes. Writing into such copies becomes > actually less and less likely the more it scales and the more > processors and threads there work in parallel. CoW will therefore > lower memory consumption by a lot in perspective. I've the same opinion. Though things may change the code is multi threaded. There's a shift to immutability, meaning that all data is copied generally. Although that is not due to performance reasons, but rather to decouple code / data to be able to parallelize the code more easily. Anyways I think it's a good idea to use resources / memory only if required. COW doesn't pay out always and may sometimes be slower. I think it's like in the STL. There's no general list that matches all requirements. There are always pros and cons. Regarding strings, I think COW isn't generally good to use, especially for small strings. However if these strings are held 1000 times in a list, the situation may change and COW would be faster for that application. Or if a huge string is held, then surely COW will be faster and the memory footprint will be much lower if the string is held at several locations. Andre -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |