I've been playing with "auto_ptr" and the "Resource Acquisition
Is Initialization" concept. On page 199 of Lippman's book
"Effective C++" he says "All active local class objects of a
function are guaranteed to have their destructors applied
before termination of the function by the exception handling
mechanism.".
I don't think that's true, though. The standard doesn't seem
to require it. Section 15.2 just says that all objects
constructed SINCE ENTERING A TRY BLOCK will be destructed
on transfer of control to a catch block. That's very different
from Lippman's statement.
I wrote this:
#include <iostream>
#include <string>
#include <memory>
#include <cstdlib>
using std::cout;
using std::endl;
class Vogon
{
public:
Vogon(int x) : Jeltz(x) {cout << "In parameterized constructor." << endl;}
~Vogon() {cout << "In destructor." << endl;}
void React ()
{
if (17 == Jeltz) throw 17; // Barf if 17==Jeltz
cout << "You entered " << Jeltz
<< ". (But don't enter \"17\"!)" << endl;
}
void Poetry () {cout << "Oh, furdled gruntbuggly!" << endl;}
private:
int Jeltz;
};
int main(int, char* A[])
{
int X = atoi(A[1]);
std::auto_ptr<Vogon> Vog (new Vogon(X));
Vog->React(); // If user used command-line arg. "17", throw uncaught
exception.
Vog->Poetry(); // Even though the sound of it is somewhat quite atrocious.
return 0; // Release resources???
}
But if you type "auto_ptr-test 17" it barfs without ever calling
the destructor:
wd=C:\RHE\src\test
%auto_ptr-test 45
In parameterized constructor.
You entered 45. (But don't enter "17"!)
Oh, furdled gruntbuggly!
In destructor.
wd=C:\RHE\src\test
%auto_ptr-test 17
In parameterized constructor.
terminate called after throwing an instance of 'i'
Abort!
Exiting due to signal SIGABRT
Raised at eip=0001648e
eax=006dfe6c ebx=00000120 ecx=00000000 edx=00000000 esi=00000000 edi=006dffc4
ebp=006dff18 esp=006dfe68 program=C:\BIN-TEST\AUTO_P~1.EXE
cs: sel=01a7 base=01680000 limit=006effff
ds: sel=01af base=01680000 limit=006effff
es: sel=01af base=01680000 limit=006effff
fs: sel=017f base=0000e150 limit=0000ffff
gs: sel=01bf base=00000000 limit=0010ffff
ss: sel=01af base=01680000 limit=006effff
App stack: [006e0000..00660000] Exceptn stack: [000538c8..00051988]
Call frame traceback EIPs:
0x000163b4
0x0001648e
0x0001335b
0x00009d6b
0x00005338
0x00005362
0x00001e51
0x000016a3
0x00012ab8
wd=C:\RHE\src\test
%
(Interestingly enough, the destructor IS called if I enclose
most of the body of main() in a try block, just like 15.2
says.)
So either Lippman's right, and my compiler is busted... or I'm
misunderstanding something... or the concept that local objects
in a function are always destructed on exception is just wrong.
Anyone here have further knowlege/experience with this matter?
Cheers,
Robbie Hatley
Tustin, CA, USA
email: lonewolfintj at pacbell dot net
web: home dot pacbell dot net slant earnur slant 4 2011
* Robbie Hatley: I've been playing with "auto_ptr" and the "Resource Acquisition Is Initialization" concept. On page 199 of Lippman's book "Effective C++" he says "All active local class objects of a function are guaranteed to have their destructors applied before termination of the function by the exception handling mechanism.".
Note that if the exception is never caught the function is not terminated by
the exception _handling_ mechanism, but rather by an automatic call to (I
think it was) std::terminate. Which in that case doesn't clean up, since its
job is to terminate the program, guaranteed. Second, note the word "active",
which as I read it implies "successfully constructed". Third, the sentence
should be parsed as "local (class objects)", not "(local class) objects".
Presumably nobody makes that error, but it would have been more clear to write
e.g. "All successfully constructed local objects of class type..." -- IMHO.
Btw., the first point is what causes your example program to terminate without
cleaning up.
Add a try-catch in 'main' and you'll get cleanup, or alternatively or
additionally, try out calls to std::terminate, std::exit and std::abort to
check the cleanup (or rather, the lack of cleanup) behavior.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
"Alf P. Steinbach" <al***@start.no> wrote: * Robbie Hatley: I've been playing with "auto_ptr" and the "Resource Acquisition Is Initialization" concept. On page 199 of Lippman's book "Effective C++" he says "All active local class objects of a function are guaranteed to have their destructors applied before termination of the function by the exception handling mechanism.". Note that if the exception is never caught the function is not terminated by the exception _handling_ mechanism, but rather by an automatic call to (I think it was) std::terminate. Which in that case doesn't clean up, since its job is to terminate the program, guaranteed.
Then Lippman's sentence, as written, is incorrect. To make it
a true statement, he'd have to add the following clause to the end:
", provided that the exception-handling mechanism ACTUALLY IS INVOKED."
Second, note the word "active", which as I read it implies "successfully constructed".
Yep, ISO14882 sec 15.2 does specify that only objects that are
fully constructed, and in try blocks, will be destructed on
exception.
Third, the sentence should be parsed as "local (class objects)", not "(local class) objects".
Can you define a class "locally"? (Ie, in a function?) I didn't
think that was possible.
#include <iostream>
double Glunk()
{
class Smatz
{
public:
double Glurtz;
};
Smatz Catz;
Catz.Glurtz = 17.4;
return Catz.Glurtz;
}
int main()
{
std::cout << Glunk() << std::endl;
return 0;
}
Holy cat crap, Batman, that actually compiles and runs!
I didn't even know you could do that.
Presumably nobody makes that error, but it would have been more clear to write e.g. "All successfully constructed local objects of class type..." -- IMHO.
Yah, that, and a warning about the objects having to be in a try block.
Otherwise, the standard doesn't seem to guarantee they'll be destructed
on exception.
Btw., the first point is what causes your example program to terminate without cleaning up.
Yep.
Add a try-catch in 'main' and you'll get cleanup
Did that. Yep, it destructs my Vogon. Wait, that's backwards...
the Vogons are supposed to BE destructors. Never mind, it's getting
late, my humor's getting weird.
or alternatively or additionally, try out calls to std::terminate, std::exit and std::abort to check the cleanup (or rather, the lack of cleanup) behavior.
Good idea. I'll try playing with those in conjunction with objects
to see when the destructors [are | are not] invoked.
RESISTANCE IS FUTILE! YOU WILL BE DESTRUCTED!
Cheers,
Robbie Hatley
Tustin, CA, USA
email: lonewolfintj at pacbell dot net
web: home dot pacbell dot net slant earnur slant
Robbie Hatley wrote: I've been playing with "auto_ptr" and the "Resource Acquisition Is Initialization" concept. On page 199 of Lippman's book "Effective C++" he says "All active local class objects of a function are guaranteed to have their destructors applied before termination of the function by the exception handling mechanism.".
I don't think that's true, though. The standard doesn't seem to require it. Section 15.2 just says that all objects constructed SINCE ENTERING A TRY BLOCK will be destructed on transfer of control to a catch block. That's very different from Lippman's statement.
(Interestingly enough, the destructor IS called if I enclose most of the body of main() in a try block, just like 15.2 says.)
So either Lippman's right, and my compiler is busted... or I'm misunderstanding something... or the concept that local objects in a function are always destructed on exception is just wrong.
Anyone here have further knowlege/experience with this matter?
Local objeccts are destroyed when they are no longer in scope. A thrown
exception caught in one scope will destroy all local objects in the
scopes that lie between it and the point where the exception was
thrown. This process is called "unwinding the stack".
If the exception is not caught or there is some other problem that
prevents execution from resuming within an enclosing scope of the
thrown exception, then the local objects tehnically (at least) remain
in scope and are not destroyed.
Greg
Robbie Hatley wrote: "Alf P. Steinbach" <al***@start.no> wrote:
* Robbie Hatley: I've been playing with "auto_ptr" and the "Resource Acquisition Is Initialization" concept. On page 199 of Lippman's book "Effective C++" he says "All active local class objects of a function are guaranteed to have their destructors applied before termination of the function by the exception handling mechanism.".
Note that if the exception is never caught the function is not terminated by the exception _handling_ mechanism, but rather by an automatic call to (I think it was) std::terminate. Which in that case doesn't clean up, since its job is to terminate the program, guaranteed.
Then Lippman's sentence, as written, is incorrect. To make it a true statement, he'd have to add the following clause to the end: ", provided that the exception-handling mechanism ACTUALLY IS INVOKED."
I forgot to weigh in on the "Lippman controversy" in my earlier post.
Lippman's statement is accurate. In the event of an uncaught exception
or other fatal error, the exception handler does not terminate (that
is, exit) the function. In this case the function does not return
before the program itself aborts execution.
Greg This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Robert Tarantino |
last post by:
Hello,
I am trying to find a way to create a scheduled task or
service that will copy my local profile folders
under "Documents and settings" to a network drive. This
would allow me to restore...
|
by: |
last post by:
Hi,
Why doesnt the runtime set the object to null when the finalizer has been
called? Wouldnt this prevent a slew of bugs?
I just called the obj.__dtor(); from a MC++ wrapper class I made and...
|
by: Markus Elfring |
last post by:
The class "auto_ptr" implements the RAII pattern for pointer types. It
seems that an implementation is not provided for non-pointer values by
the STL so far.
I imagine to use the "acquisition" for...
|
by: Alfonso Morra |
last post by:
I have written the following code, to test the concept of storing
objects in a vector. I encounter two run time errors:
1). myClass gets destructed when pushed onto the vector
2). Prog throws a...
|
by: Timothy Madden |
last post by:
Hello all.
I program C++ since a lot of time now and I still don't know this simple
thing: what's the problem with local functions so they are not part of
C++ ?
There surely are many people...
|
by: Jess |
last post by:
Hello,
I have a program that stores dynamically created objects into a
vector.
#include<iostream>
#include<vector>
using namespace std;
|
by: Veloz |
last post by:
Hiya
My question is whether or not you should associated related objects in
your software using a scheme of id's and lookups, or wether objects
should actually hold actual object references to...
|
by: George2 |
last post by:
Hello everyone,
1. Returning non-const reference to function local object is not
correct. But is it correct to return const reference to function local
object?
2. If in (1), it is correct...
|
by: George2 |
last post by:
Hello everyone,
Such code segment is used to check whether function call or exception-
handling mechanism runs out of memory first (written by Bjarne),
void perverted()
{
try{
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |