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.

[Dietmar Kuehl]

Stefan Arentz wrote:

Wrapper classes introduce more code.
I'd rate this as FUD. I just tested the following two translation units
with gcc on a StrongARM (I currently don't have access to gcc on an
Intel machine):

| // file tst1.cpp
| extern void f(int* i);
| void g() {
| int* i = new int(10);
| try { f(i); }
| catch ( ... ) {}
| delete i;
| }

This is as close at "finally" as possible: the try/catch is necessary
or some equivalent is necessary for the finally-clause, too. However,
deleting and rethrowing in the catch-clause would increase the code
even more (see tst3.cpp below).

| // file tst2.cpp
| extern void f(int* i);
| struct ptr {
| ptr(int* p): mp(p) {}
| ~ptr() { delete mp; }
| int* mp;
| };
| void g() {
| ptr p(new int(10));
| f(p.mp);
| }

It is admittedly more code but it can be placed into a header and
reused
in multiple places.

| // file tst3.cpp
| extern void f(int* i);
| void g() {
| int* i = new int(10);
| try { f(i); delete i; }
| catch ( ... ) { delete i; throw;}
| }

This is the manual approach without finally.

| // file tst4.cpp
| extern void f(int* i);
| template <typename T>
| struct ptr {
| ptr(T* p): mp(p) {}
| ~ptr() { delete mp; }
| T* get() { return mp; }
| private:
| ptr(ptr const&);
| void operator= (T const&);
| T* mp;
| };
| void g() {
| ptr p(new int(10));
| f(p.get());
| }

.... and I thought it is instructive to put this follow-blown version
using templates into it, too.

Compiled with "g++ -O4 -c tst*.cpp" I get the following:

| size *.o
| text data bss dec hex filename
| 172 16 0 188 bc tst1.o
| 180 6 0 186 ba tst2.o
| 228 16 0 244 f4 tst3.o
| 180 6 0 186 ba tst4.o

(I couldn't paste the results as they are on my PDA which is not
connected
to the machine I'm typing at).

Although the memory wasted by the non-automatic version is not too bad,
the automatic release is shorter, at minimum two bytes - not much but
you complained about use less code. Of course, if you want the correct
semantics, i.e. the exception shall not be swallowed, you have no
choice but go with automatic resource release if you don't want to
waste memory...
I would like to use less code. I also
think it is a workaround and not a structural solution.
I disagree: the idiom of handling resources is essential to effective
C++ programming.
The above would simply move the exception handling and my finally problem to a different place but it would still be present.
Where does the resource management class need a "finally"? All
exception
handling code is entirely generated by the compiler which will probably
generate something akin to finally but there is no need to care at all.
Also, resource management is centralized in one place. There is no
chance
of forgetting to clean up allocated resource (well, you can have a
plain
new but you shouldn't) because the finally clause is omitted. The code
is
not littered with clean-up code which is irrelevant to the actual
business
logic.
I like it that you as
a user of the class don't have to deal with it anymore, but that is more visual/convenience.

I disagree. Actually, if you are ever doing template programming you
will
appreciate that you don't have to know how to clean-up the objects you
are handling. You don't even need to care whether they need clean-up:
it
is the object's business, not yours. It is a logical step toward
encapsulation.
--
<mailto:di***** ******@yahoo.co m> <http://www.dietmar-kuehl.de/>
<http://www.contendix.c om> - Software Development & Consulting

[Dietmar Kuehl]

Nicolas Pavlidis wrote:

void bar()
{
char * my_ptr;
Object should always be initialized, i.e. the above line shall be
replaced
by something like this if used at all:

| char * my_ptr = 0;
try
{
my_ptr = new char[987];
// do something
delete my_ptr
You allocated an array object you shall release an array object or
suffer
the effects of undefined behavior. The only correct way to delete an
array
object is using array delete:

| delete[] my_ptr;

This is explicit in 5.3.5 (expr.delete) paragraphs 2 and 3 of the
standard.
If you disagree with my statement, please provide a quote from the
standard
supporting your view.
Here it's necessary to duplicate code, another example would be file
handling.
Sometimes a finally - block can help.

Resource handling classes foster encapsulation and provide a better
approach
than a finally block could do. This was considered sufficient reason
for not
having finally blocks.
--
<mailto:di***** ******@yahoo.co m> <http://www.dietmar-kuehl.de/>
<http://www.contendix.c om> - Software Development & Consulting

[Dietmar Kuehl]

Dietmar Kuehl wrote:

I just tested the following two translation units...

| ^^^

As it turns out, there are three kinds of persons: those who can count
and those who can't... I wrote this sentence when I wanted to post
just two translation units but it turned out to be reasonable to have
a total of four.
--
<mailto:di***** ******@yahoo.co m> <http://www.dietmar-kuehl.de/>
<http://www.contendix.c om> - Software Development & Consulting

[red floyd]

Rolf Magnus wrote:

That's what std::auto_ptr is for:

void bar()
{
try
{
SomeObject instace;
std::auto_ptr<c har> my_ptr(new char[987]);
// do something
instace.doSomeh ting() // throws an exception let's say MyExec
}
catch(MyExec &exc)
{
// error handling
}
}

That's double-plus-ungood Rolf. As I understand it, std::auto_ptr<> 's
destructor calls delete, not delete[]. So you invoked UB.

I suspect that with an array of char, it's probably OK (but not
necessarily), but suppose you did that with some class that had a
nontrivial destructor?

[Stefan Arentz]

"Jeff Flinn" <NO****@nowhere .com> writes:

"Stefan Arentz" <st***********@ gmail.com> wrote in message
news:87******** ****@keizer.soz e.com...

Tom Widmer <to********@hot mail.com> writes:

On 21 Sep 2004 14:32:39 +0200, Stefan Arentz <st***********@ gmail.com>
wrote:

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

So your current project isn't in standard C++, but rather a
company/personal dialect? I'm not sure we can help much with that...

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

probably

Is this because your compiler doesn't support STL/Boost? Or that you "think"
STL\Boost will require more memory?

It is because both memory and flash is sparse. And I know for a fact that it
does not fit.

S.

[Stefan Arentz]

"Peter Koch Larsen" <pk*****@mailme .dk> writes:

....

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

S.

I do not understand what you're saying. STL - or templates - does not
necessarily use more ressources than handwritten code. In your case it
should be safe.

Templates, yes probably. But including a 700K library in the firmware is
simply not an option.

S.

[Richard Herring]

In message <87************ @keizer.soze.co m>, Stefan Arentz
<st***********@ gmail.com> writes

Tom Widmer <to********@hot mail.com> writes:

On 21 Sep 2004 14:32:39 +0200, Stefan Arentz <st***********@ gmail.com>
wrote:

>
>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).
So your current project isn't in standard C++, but rather a
company/personal dialect? I'm not sure we can help much with that...

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. Templates probably
are,

??? Both STL and Boost _are_ mostly templates.
but I've had no reason to use them yet and I would have to look into
object code size first.
Unlikely to be significantly more than whatever you code manually.
Btw, I am very happy with the choise of C++ for this project. It has made
the code more robust and organized.

>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?
void Foo()
{
//Do your foo business that could throw a FooException
}

where the foo business uses stack based objects whose destructors do
the cleanup. If your company doesn't allow that, then your company is
using mackled C++, and might be better off with C# or Java. At the
very least you can use std::auto_ptr.

So that would mean stack based objects and references? Get rid of all
pointers?

Not necessarily. Your stack based objects can still contain pointers,
but they take care of all the pointer management for you.
It would probably mean a complete redesign of some things,
but I am willing to look into it. Is this the RAII stuff other people
were talking about?

Just so.

--
Richard Herring

[Ioannis Vranos]

Dietmar Kuehl wrote:

Object should always be initialized, i.e. the above line shall be
replaced
by something like this if used at all:

| char * my_ptr = 0;

Why? This is a personal style and not mandatory.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Richard Herring]

In message <87************ @keizer.soze.co m>, Stefan Arentz
<st***********@ gmail.com> writes

"John Harrison" <jo************ *@hotmail.com> writes:

...

Simple use a class with a destructor (it's because Java doesn't have
destructors that it needs finally)

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

The FooBusiness destructor does the cleanup. This way you do not even need a
try/catch
I don't buy this for two reasons.

Wrapper classes introduce more code. I would like to use less code. I also
think it is a workaround and not a structural solution.

The above would simply move the exception handling and my finally problem
to a different place but it would still be present.

No, there _is_ no exception handling code. Your destructor just
contains the normal cleanup code that you'd need anywhere.
I like it that you as
a user of the class don't have to deal with it anymore, but that is more
visual/convenience.

S.

--
Richard Herring

[Peter Koch Larsen]

"Stefan Arentz" <st***********@ gmail.com> skrev i en meddelelse
news:87******** ****@keizer.soz e.com...

"Peter Koch Larsen" <pk*****@mailme .dk> writes:

...

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

S.

I do not understand what you're saying. STL - or templates - does not
necessarily use more ressources than handwritten code. In your case it
should be safe.

Templates, yes probably. But including a 700K library in the firmware is
simply not an option.

S.

700K? What do you mean? I really would like to know how you get these
numbers. The stuff that could take up some space is iostreams - if there is
a lot of locale support, but you could skip that or trim it. Apart from that
you should be in the clear.

/Peter