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.

[Ioannis Vranos]

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

8MB? C++ programs can execute in DOS systems with <= 640 KB RAM. And
that is too much too.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Jeff Flinn]

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

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.

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

char* my_ptr = rand();

What happens if/when new throws?

Jeff F

[Dietmar Kuehl]

Ioannis Vranos wrote:

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.

Correct, it is not mandatory. However, this "personal" style
reduces the potential for errors dramatically (not only in C++).
It also makes certain, IMO ill-advised, programming approachs,
like e.g. use of "try"-blocks, quite inattractive :-)
--
<mailto:di***** ******@yahoo.co m> <http://www.dietmar-kuehl.de/>
<http://www.contendix.c om> - Software Development & Consulting

[Ioannis Vranos]

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.

What happens if/when new throws?

What happens?

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ioannis Vranos]

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.
It also makes certain, IMO ill-advised, programming approachs,
like e.g. use of "try"-blocks, quite inattractive :-)

May you expand on that?

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Phlip]

Niels Dybdahl wrote:

Cleanup code are not part of the program logic, so it is very nice to avoid it in the middle of the main code by putting it away in a destructor.
In addition the destructor approach prevents programmers from forgetting
cleanup code which leads to more stable applications.
So it is not a workaround but a significant improvement.

Totally.

Designs should not duplicate behaviors. If two functions have the same lines
in their finally blocks, they duplicate those lines. Moving these to a
non-deterministic destructor simplifies the design.

Java's reason to exist is C++ memory leaks. Then they solved the wrong
problem. Non-deterministic destructors cause all kinds of trouble, leading
to klutzy work-arounds.

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

[Stefan Arentz]

Ioannis Vranos <iv*@guesswh.at .grad.com> writes:

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

8MB? C++ programs can execute in DOS systems with <= 640 KB RAM. And
that is too much too.

Yes, you can run C++ programs on a AVR with 16K flash too, but that is
not the point.

Sorry but no more smart ass answers on this one please. I *know* what
kind of memory constraints I have in my project.

S.

[Jeff Flinn]

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

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

Please adequately define "it"?

In the context of using std facilities in lieu of "finally", you'd only use
boost::scoped_a rray_ptr, or just use std::vector. With an optimizing
compiler, the size differences should be insignificant. Or by chance are you
looking at debug mode builds?

Jeff F

[Tom Widmer]

On 21 Sep 2004 16:03:38 +0200, Stefan Arentz <st***********@ gmail.com>
wrote:

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?

Rather, make sure any pointers are controlled by objects.

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?

Yes. Basically, rather than:

Foo* f = 0;
try
{
f = new Foo();
f->bar();
}
catch(...)
{
delete f;
throw;
}
delete f;
You would do:
Foo f;
f.bar();

or, if necessary,

std::auto_ptr<F oo> f(new Foo);
f->bar();
Tom

[Rolf Magnus]

red floyd wrote:

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.

Yes, I realized that after posting. I cancelled the posting, but it seems it
was too late already. Anyway, you could still write some auto_ptr
equivalent for arrays, or use something from boost. Imho, an auto_ptr for
arrays should be part of the standard library.