Prev: Isn't this a conversion bug in gcc?
Next: [ANN] ACCU 2011 Conference Call for Proposals
From: Dragan Milenkovic on 25 Jul 2010 23:05
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?

--
Dragan

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

From: Alf P. Steinbach /Usenet on 26 Jul 2010 02:48
* Michael Kilburn, on 18.07.2010 05:24:
>
> I have checked C++ standard and did not find requirements imposed on
> library implementation with respect to exception safety. But this is
> as important of other parts of contract between library and client set
> in standard. E.g. if program relies on strong guarantee provided by
> some operation and another STL implementation provides only basic --
> this program is not C++ program (in a sense that compiled in different
> standard-compliant environment it will behave differently).
> Did I miss some standard addendum or followup papers? Can someone
> point me to right direction, please?

Have you tried googling for "exception safety in the stl"?

Disclaimer: I haven't.

But I believe that was the paper (by Dave Abrahams) where e.g. the term
"strong
guarantee" originated.

You might also take a look at the third appendix, I believe it was, to
Bjarne
Stroustrup's The C++ Programming Language, 3rd edition.

It's available in PDF from his web pages.


Cheers & hth.,

- Alf

--
blog at <url: http://alfps.wordpress.com>

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

From: Thomas Richter on 26 Jul 2010 07:18
Dragan Milenkovic 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?

Now consider it would throw due to an out of memory exception. What
would I do to recover from it? Can I find out *which* of the objects
made it into the container and which didn't? Can I somehow restore the
original container state, then throw the exception up by several levels
where it could be handled? On the other hand, if I *always* had to copy
the container over to make a *safe* insertion possible I could recover
from, this renders the STL rather useless, doesn't it?

So long,

Thomas

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

From: Dragan Milenkovic on 26 Jul 2010 13:39
On 07/27/2010 12:18 AM, Thomas Richter wrote:
> Dragan Milenkovic wrote:
[snip]

If I may first make a reminder of the current context:
user copy-ctor and assignment will not throw...

> Now consider it would throw due to an out of memory exception. What
> would I do to recover from it? Can I find out *which* of the objects
> made it into the container and which didn't? Can I somehow restore the
> original container state, then throw the exception up by several levels
> where it could be handled? On the other hand, if I *always* had to copy
> the container over to make a *safe* insertion possible I could recover
> from, this renders the STL rather useless, doesn't it?

But if you use a list and splice, then you can do this reliably.

If you still need to use a vector, then...

vec.reserve(vec.size() + n);
vec.insert(bla bla of size n);

.... and there is your guarantee...

I would say - far from useless.

And why would a copy-ctor or assignment of an object that one would
want to put inside a vector throw? Could I get a real-world example
of it?

--
Dragan

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

From: Andre Kaufmann on 26 Jul 2010 23:43
Mathias Gaunard wrote:
> On Jul 26, 11:16 pm, Thomas Richter <t...(a)math.tu-berlin.de> wrote:
> [...]
> 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.
>

That doesn't apply to filestream and other iostreams - IMHO.

Andre


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

 | 
Pages: 1
Prev: Isn't this a conversion bug in gcc?
Next: [ANN] ACCU 2011 Conference Call for Proposals