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:

Neh, we keep the beer in the fridge. 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.

It is not very special, you just can't use all nice tricks that are
obvious on a normal 1GB workstation with a standard 80GB drive :)

I developed most of my standard C++ library on a machine with 160MB
of disk space (yes, *disk space*, not memory). I had (newer version
of gcc unfortunately broke it) a C++ hello-world which took 4kB
(yes, 4*k*B). I think it is now ~40kB, mostly due to the exception
support I need to include. However, this was in an experimental
branch and not merged into the main library (it was mostly a demo
of what can be done; unfortunately, nobody pays me for actually
doing this to the whole standard C++ library...). With my "normal"
implementation, it indeed takes ~700kB for a hello-world (stripped
executable on an Intel machine).

Anyway, you should realize that STL != "standard C++ library": the
STL is just the generic stuff (containers, iterators, algorithms).
This will have no or at most only very small overhead compared to
manually written code.
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

[Daniel T.]

In article <87************@keizer.soze.com>,
Stefan Arentz <st***********@gmail.com> wrote:

al***@start.no (Alf P. Steinbach) writes:

...

Mayby someone cann tell me why this was not taken into C++

Because 'finally' is rarely needed in C++, and where it is needed it
indicates a redesign/refactoring is called for, and in the extremely
rare cases where that isn't an option, you can easily emulate it.

So how do you emulate it.

In my situation: no templates, no STL, no external libraries. Just bare
C++. GCC extensions are acceptable (3.3).

I've used inner functions (GCC extension) at one point.

void Foo()
{
vars;

void cleanup() {
cleanup vars;
}

try {
}

catch (...) {
cleanup();
throw;
}

cleanup();
}

But still, very yuckie :)

S.

struct Vars {
Vars(): vars() { }
~Vars() {cleanup vars;}
vars;
};

void Foo() {
Vars v;
// do stuff with v.vars;
}

I don't see why you are ignoring the simple and obvious solution...

[Greg Comeau]

In article <84*************************@posting.google.com> ,
Old Wolf <ol*****@inspire.net.nz> wrote:

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

It's said we have proper standard C++ support, and are always
glad to do custom ports, so feel free to email us.
--
Greg Comeau / Comeau C++ 4.3.3, for C++03 core language support
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Richard Herring]

In message <UU*******************@newssvr29.news.prodigy.com> , red floyd
<no*****@here.dude> writes

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.

But if you actually *need* the strict-ownership move-not-copy semantics
of auto_ptr, it's not. If you don't, then boost::scoped_array is another
possibility.
--
Richard Herring

[Tom Widmer]

On 21 Sep 2004 18:23:34 +0200, Stefan Arentz <st***********@gmail.com>
wrote:

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

You don't need 700k. To use the STL you don't need to link any
libraries at all (assuming your allocator implementation is in the
header). If you've got enough resources to have exceptions enabled,
you've certainly got enough for the STL (which requires exception
support ideally), and
std::auto_ptr/scoped_ptr/scoped_array/std::vector/etc.

Remember, with templates, only code that is actually called gets
compiled into your .exe.

Tom