Prev: Is comparison of doubles stable?
Next: What are requirements for allocator destructor?
From: Mathias Gaunard on 26 Jul 2010 07:18
On Jul 26, 3:05 pm, Dragan Milenkovic <dra...(a)plusplus.rs> wrote:
> On 07/23/2010 01:55 AM, Thomas Richter wrote:
>
> > Mathias Gaunard wrote:
>
> >> Then the only reason the container can throw is because it is out of
> >> memory, which doesn't work reliably on modern operating systems anyway
> >> due to memory overcommit.
>
> > IOW, I cannot use the STL in embedded applications? Or memory
> > constrained applications? Not everything is a windows or a Linux.
> > Doesn't that conflict with the design principles of C++?
>
> I'm confused now... Why a conclusion that it cannot be used in
> embedded applications when Mathias said that it _will_ throw
> an exception?

It won't throw on operating systems with overcommit.
Anyway I just meant to say it may not be worth worrying too much about
certain exceptional situations in certain cases.


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

From: nmm1 on 26 Jul 2010 13:35
In article <99994720-44b5-4ae5-a3f2-4a5bed71add6(a)d8g2000yqf.googlegroups.com>,
Mathias Gaunard <loufoque(a)gmail.com> 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.
>
>"Exceptions caused by asynchronous signals"?
>I don't know what you're talking about, but that seems quite outside
>the scope of C++.

Quite probably, but I would regard that as being more a deficiency
of C++'s scope than anything else. Such situations are extremely
common, extremely important and not actually as hard to handle as
most people seem to think. Been there - done that.

>C++ exceptions are synchronous, and Unix signals are asynchronous, but
>one doesn't cause the other.
>Maybe you're talking about Windows Structured Exceptions?

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.


Regards,
Nick Maclaren.

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

From: Mathias Gaunard on 26 Jul 2010 13:41
On Jul 26, 11:16 pm, Thomas Richter <t...(a)math.tu-berlin.de> wrote:

> Oh please, come on. How applicable is that in an embedded application?
>
> And, even worse, if it is "that trivial", why doesn't the STL provide
> this "trivial" extension? A "safe_vector<..>" might come handy in cases,
> and you can surely implement it much better than *that*.

I said it was trivial to do, not that it was a cheap operation.
The reason std::vector doesn't do it is precisely because it is
costly. The design of the C++ standard library is to provide the best
guarantee that can be provided without incurring any significant cost.


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

From: Kenneth 'Bessarion' Boyd on 28 Jul 2010 10:23
On Jul 28, 3:24 pm, n...(a)cam.ac.uk wrote:
> In article
> <026b4825-5ec6-4dff-944b-5dd6b6ca5...(a)t19g2000vbf.googlegroups.com>,
> Kenneth 'Bessarion' Boyd <zaim...(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.

We shall have to agree to disagree on this point.

> 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.

And returning EXIT_SUCCESS/EXIT_FAILURE is itself I/O....

Let's try the weaker constraint "well-formed for all conformant hosted
implementations" (as free-standing implementations are not required to
have signals.h/csignals). [support.runtime]/7 (C++0X n3090)
specifically indicates (both directly and in an associated footnote)
that a C++ signal handler not only shall have C linkage, but that any
feature not in the common subset of C and C++ is an implementation
extension. C++ exception handling is mentioned in the footnote as
"very likely to have problems", as is calling std::exit.

> 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.]


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

From: Kenneth 'Bessarion' Boyd on 29 Jul 2010 09:48
On Jul 29, 5:10 pm, Dragan Milenkovic <dra...(a)plusplus.rs> wrote:

> I already asked in another post... Why would you put in a vector
> something that can throw on copy or move? There are other types
> of containers that would seem more appropriate. There is also
> shared_ptr or at least a pointer (to a well managed object).

Converting to std::vector, from a more appropriate container in O()
terms, is an implementation-specific optimization I have used to
improve speed by reducing memory manager overhead with the MingW32
port of GCC. It's good to know in advance when this might cause
problems.

And, unlike most code-tweaking, it's a very quick compile-test.


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

First  |  Prev  | 
Pages: 1 2
Prev: Is comparison of doubles stable?
Next: What are requirements for allocator destructor?