The 'finally' debate

[Stefan Arentz]

I was just reading through some old articles in the 'Why not develop new
language' thread and came across the finally debate.

Everytime I mention 'finally' to C++ programmers I get almost emotional
responses about why it is not needed in C++. I don't get that.

For example, consider the following code. Please note, I can only use
heap allocated objects in my current project (new/delete).

//
// Foo - Tries to foo. Can throw a FooException
//

void Foo()
{
try {
// Do your foo business that could throw a FooException
}

catch (...) {
// Cleanup your business
throw;
}

// Cleanup your business
}

Now, with finally I could do this:

void Foo()
{
try {
// Do your foo business that could throw a FooException
}

finally {
// Cleanup your business
}
}

Which I find *much* cleaner than the other example as there is no
need to do the cleanup twice.

Anyway, the debate is useless because we don't have finally. So my question
really is, how do people refactor the above to something nicer?

S.

[Andre Kostur]

Ioannis Vranos <iv*@guesswh.at .grad.com> wrote in
news:ci******** **@ulysses.noc. ntua.gr:

Jeff Flinn wrote:

It is "mandatory" if you want exception safe code. The above, without
"=0" is equivalent to:

char* my_ptr = rand();

Not exactly, but anyway.

Close enough.....

What happens if/when new throws?

What happens?

How about later in the catch block where my_ptr is attempted to be deleted?
If the variable is initialized to 0 first, then the catch block will be
able to delete it. Without the initialization, the delete would be
performed on an uninitialized pointer, resulting in UB.

[Nemanja Trifunovic]

> Well, it is code for firmware of a small device. Not very small, but small

enough that something like STL or Boost is not an option.

Not "all" Boost. Just look at the "scoped" smart pointers - two header
files. They are small, efficient, and any decent compiler will
optimize away all the overhead of using them.

BTW, long time ago I missed "finally" just as you do. Now, I consider
it a flaw in a programming language :)

[Ioannis Vranos]

Andre Kostur wrote:

How about later in the catch block where my_ptr is attempted to be deleted?
If the variable is initialized to 0 first, then the catch block will be
able to delete it. Without the initialization, the delete would be
performed on an uninitialized pointer, resulting in UB.

I assume, you mean that you perform many new operations in a large try
block with one catch (std::bad_alloc ) for all of them.

Too messy approach anyway.
What about definition upon use like:
char *p=new char[30];
// ...

char *something=new char[40];
In this case you can't make assumptions what has already been allocated
or not.

Both approaches above are not preferable. The best one is use a standard
library container on the stack when you want many objects and an object
alone in the stack if you want one object.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[red floyd]

Rolf Magnus wrote:

Imho, an auto_ptr for
arrays should be part of the standard library.

Agreed. There should be something like std::auto_array <>, with
essentially identical semantics to auto_ptr, but using delete[] instead
of delete.

[red floyd]

Rolf Magnus wrote:

Imho, an auto_ptr for
arrays should be part of the standard library.

I guess that the Committee decided that that the auto_ptr for arrays is
std::vector.

[Andre Kostur]

Ioannis Vranos <iv*@guesswh.at .grad.com> wrote in
news:ci******** **@ulysses.noc. ntua.gr:

Andre Kostur wrote:

How about later in the catch block where my_ptr is attempted to be
deleted? If the variable is initialized to 0 first, then the catch
block will be able to delete it. Without the initialization, the
delete would be performed on an uninitialized pointer, resulting in
UB.

I assume, you mean that you perform many new operations in a large try
block with one catch (std::bad_alloc ) for all of them.

.... or just one.
Too messy approach anyway.
Granted, we are assuming operations on plain pointers. Smart pointers
would probably be preferable. Helps to hide away this sort of
complexity.
What about definition upon use like:
char *p=new char[30];
Not exception safe (in the total context). Rewrite to:

char * p = 0;

p = new char[30];
// ...

char *something=new char[40];
Same here.
In this case you can't make assumptions what has already been
allocated or not.
With the appropriate re-writes, you don't care. You would only need:

catch( /* whatever */ )
{
delete[] something;
delete[] p;
}

Since in both cases, the pointers are initialized to 0 first (a nothrow
operation), whether the first new failed or the second new failed, it
doesn't matter. The pointers will either be a valid pointer (becuase the
new succeeded), or 0. In either case, calling delete[] on the pointer is
safe.
Both approaches above are not preferable. The best one is use a
standard library container on the stack when you want many objects and
an object alone in the stack if you want one object.

Not necessarily, as you may not have the stack space available to spare,
so heap allocations may be required. Or, there may be a requirement that
the objects be allocated in shared memory somewhere.

[Phlip]

red floyd wrote:

Rolf Magnus wrote:

> Imho, an auto_ptr for
arrays should be part of the standard library.

I guess that the Committee decided that that the auto_ptr for arrays is
std::vector.

At one time std::vector did not need to guarantee that its controlled
objects were contiguous - hence inside an array. I don't know what loopholes
or changes have emerged since the Standard came out.

(However, semantically, you should only use arrays at an interface that
requires contiguity, and vector for everything else...)

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

[Ioannis Vranos]

Phlip wrote:

At one time std::vector did not need to guarantee that its controlled
objects were contiguous - hence inside an array. I don't know what loopholes
or changes have emerged since the Standard came out.

(However, semantically, you should only use arrays at an interface that
requires contiguity, and vector for everything else...)

Yes, although there is such a guarantee now. However prior to that, you
could still use iterators and operator[] to have a "sequential " access,
as with the rest containers.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Dietmar Kuehl]

Ioannis Vranos wrote:

Dietmar Kuehl wrote:

Correct, it is not mandatory. However, this "personal" style
reduces the potential for errors dramatically (not only in C++). As I have told many times in clc++, not really.
Well for starters, it would in the original code (corrected to
use appropriate delete operators):

char***my_ptr;
// at this point, my_ptr contains a random value
**try
**{
****my_ptr*=*ne w*char[987]; // if this new throws...
// other stuff
****delete[] my_ptr
**}
**catch(MyExec* &exc)
**{
// clean-up
****delete[]*my_ptr; // this expression is undefined
** // error handling goes here
}

Especially in the presence of hard to predict execution paths
uninitialized variables are hard to handle.
It also makes certain, IMO ill-advised, programming approachs,
like e.g. use of "try"-blocks, quite inattractive :-)

May you expand on that?

In general, it is easier to initialize a variable just once rather
than to assign it and later just change it without having read the
value. After all, the initialization would be wasted. If you attempt
to fold initialization with the assignment, i.e. initialize the
variable with the final value, in the above case with the value
returned from 'new', you will realize that you cannot do so prior to
the try-block (after all, it can throw and you want to handle the
error) nor within the try-block because you need the variable to do
the clean-up. The only viable approach becomes the use of a resource
management class - a good think, IMO.
--
<mailto:di***** ******@yahoo.co m> <http://www.dietmar-kuehl.de/>
<http://www.contendix.c om> - Software Development & Consulting

[Old Wolf]

Stefan Arentz <st***********@ gmail.com> wrote:

"Gernot Frisch" <[e-mail] > writes:

I'm on a device that is too small to even include STL :)

The device is a MIPS based device
with not too much RAM/Flash. Think <= 8MB. which needs to be shared
with a kernel, libraries some tools.

8MB ?! Here I was debating whether to use C++ (with STL) in a
device with 128K ram and 256K flash. Unfortunately the only
available C++ compilers were old, so they would not have proper
standard C++ support, and probably would be bad optimisers.
If the platform supported one of the 'mainstream' C++ compilers
(eg. Gnu, Intel, MS) it would have been a more serious option
(But I probably still would have stuck to C so that the code
could port to other devices which didn't have a good C++ compiler).