Is there any standard/guarantees for exception safety in STL operations?
in [C++]
|
Prev: Is there any standard/guarantees for exception safety in STL operations?
Next: why aren't comparators passed as refs or c-refs in algorithms?
From: nmm1 on 26 Jul 2010 23:45 In article <i2kiki$ju0$1(a)news.belwue.de>, Thomas Richter <thor(a)math.tu-berlin.de> wrote: > >Let's stick to this example, because it is an excellent one. I don't >think asking for the strong guarantee, i.e. that insertions or deletions >are either done completely or not at all. This is probably asking for >too much. But what I'm asking for is exactly what you mention below, >namely either a method to sanitize the container, or at least *some* >information *how* to sanitize it. > >Consider for example an implementation that ensures that on insertion, >the first N of a total of M elements make it into the container; by that >I mean that after an exception, there is an N such that the elements >1,2,.. to N have been inserted and are now members of the container, and >all I would need to do would be to remove them again. > >Thus, I would need to find out N after an exception, and the guarantee >that insertions always happens in element increasing order from the >source. Is this asking for too much? As far as I know, the STL doesn't >even give me that. Actually, I should have used a different example, because the STL gives guarantees for insertion under many circumstances - not all, though. As you seem to understand, my assertion is that it could be specified for all circumstances - including when exceptions are raised in the currently forbidden methods - though it would not be easy to do. However, despite the claims, it would NOT lead to a significant loss of performance - and that is based on having done a reasonable amount of it. Whether the C++ standard SHOULD specify such guarantees is another question - it definitely increases the implementation costs - which I have not taken sides on. It is certainly needed when writing complicated, high-RAS applications, and there is a lot of experience that such designs repay their investment in effort many times over. But the current zeitgeist is different .... >> It is even possible to specify that containers are robust against >> a limited amount of data corruption - that starts getting extremely >> hairy, so I doubt that anyone would want to go there! But it could >> be done. > >Maybe - it would probably require completely different design >principles, and the costs might be high, but I don't really know. >Something simpler would be sufficient. Your speculation is entirely correct :-) Regards, Nick Maclaren. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: nmm1 on 28 Jul 2010 05:24 In article <026b4825-5ec6-4dff-944b-5dd6b6ca591c(a)t19g2000vbf.googlegroups.com>, Kenneth 'Bessarion' Boyd <zaimoni(a)zaimoni.com> wrote: >On Jul 26, 11:35 pm, n...(a)cam.ac.uk wrote: > >> Sigh. No. Think mainframes - systems where the architecture >> allowed you to recover from system-generated interrupts - events >> that, in Unix and Microsoft systems, are mapped into signals. >> >> In C++, a signal handler can raise an exception - that generates >> an asynchronous exception. The principle is easy, but the devil is >> in the detail, as usual. > >Throwing C++ exceptions from signal handlers is an implementation- >specific extension to the standards; strictly conformant code won't >use such extensions. It's not disallowed, but I wouldn't be >complaining about defects in the C++ standard for this. Please do not misrepresent me. If you had read what I said, you would have seen that I did not do that. And it's wrong, anyway. Firstly, "strictly conforming" is a C concept and not a C++ one, and is a complete nonsense in itself, because there are TWO such programs! They do nothing and return EXIT_SUCCESS and EXIT_FAILURE, respectively. The reason for this is that all external actions (including I/O) are at least implementation-dependent, and strictly conforming programs are not allowed to produce output depending on implementation-dependent behaviour. Secondly, I did not refer to this as a defect. I made it VERY clear, repeatedly, that this was an objective that C++ had deliberately not selected. I pointed out that it could be done and, again repeatedly, stated that the performance impact is negligible but the design, specification and implementation efforts are considerable. I have referred to defects in the C++ standard, but this is not one of them. It is something that the C++ standard could support, arguably should support, but does not. Regards, Nick Maclaren. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: nmm1 on 28 Jul 2010 05:24 In article <6fe3b051-f3cd-4fd2-86b8-9d041df12f5a(a)g21g2000prn.googlegroups.com>, Joshua Maurice <joshuamaurice(a)gmail.com> wrote: >On Jul 27, 2:13 pm, Michael Kilburn <crusader.m...(a)gmail.com> wrote: >> Anyway -- since I am reading standard on regular basis, my point was >> to find these guarantees there. Which is turned out to be non-trivial >> task -- whoever was documenting these definitely did not want anyone >> to find them out... Even though Daniel cleared some fog for me >> (thanks!), it seems there are still black holes in standard with >> respect to this. > >I agree this is a serious problem. I suspect it's due to the nature of >the international standardization process. It's quite refreshing to >read the Java standard as compared to the C++ standard. It's an >entirely different approach to standard writing. The Java standard is >amazingly clear, and it cuts right to the issues. The C++ standard is >amazingly unclear. No, it's not inherent in the international standardization process. Fortran is very much better, though it has the same fault in a good many places. While Fortran is a simpler language than C++, and so the task is easier, modern Fortran has equivalents to most of the major features of C++. MPI was designed by an informal international standardization process (i.e. by an ad-hoc committee) and is also very much better. POSIX was, too, and is very much worse. I don't know Java well enough to judge the quality of its standard, and most of the other ISO standards I know well are very much simpler (e.g. Pascal). It's a big problem, probably unavoidable, and can at best be partially alleviated by a LOT of effort. It's easy to avoid when designing from scratch, but not at all easy to avoid when extending standards by large numbers of people over many decades. Regards, Nick Maclaren. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Bo Persson on 28 Jul 2010 17:52 Thomas Richter wrote: > nmm1(a)cam.ac.uk wrote: >> >> As an example of what can be specified, consider a container. It >> is possible to specify that insertions, deletions etc. are either >> nullified or completed, even when interrupted by exceptions caused >> by asynchronous signals. That is tricky to implement efficiently, >> so another approach is that any container where an operation is >> interrupted in some way must be sanitised by calling a special >> method before being used again, and then the same applies. And, >> similarly, interrupted sorting never loses or duplicates elements, >> or adds junk. All of that is known technology, but is in no sense >> a trivial extension. > > Let's stick to this example, because it is an excellent one. I don't > think asking for the strong guarantee, i.e. that insertions or > deletions are either done completely or not at all. This is > probably asking for too much. But what I'm asking for is exactly > what you mention below, namely either a method to sanitize the > container, or at least *some* information *how* to sanitize it. > If it was easy to "sanitize", the library would already do that. The example with a multi-object insert into a vector has the problem that the already existing objects will have to be moved around to make room for the new ones. If the object type then have a copy constructor or a copy assignment that throws, the "move around" can fail. To restore the original state, you would have to move them back again. But that can also fail, if the copy constructor or copy assignment throws another exception. Now what do you do? Bo Persson -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: nmm1 on 29 Jul 2010 00:05
In article <82f5f5f7-b72f-4e27-9049-1f751e244f0d(a)x21g2000yqa.googlegroups.com>, Kenneth 'Bessarion' Boyd <zaimoni(a)zaimoni.com> wrote: > >> Secondly, I did not refer to this as a defect. I made it VERY clear, >> repeatedly, that this was an objective that C++ had deliberately not >> selected. I pointed out that it could be done and, again repeatedly, >> stated that the performance impact is negligible but the design, >> specification and implementation efforts are considerable. > >In sufficient detail that there is no question that this *is* >operationally claimed to be a defect, and no hint that the time and >effort required were so excessive that remediation in in C++1X is >impractical. [It certainly is not excessive effort to remediate while >reimplementing the standard library.] The mind boggles. I shall not respond to this misrepresentation any further. If anyone is interested in what I said, I refer them to what I posted. If anyone is interested in how to do this, please contact me by Email. Regards, Nick Maclaren. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |