«

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

Beeeeeep!
No templates but bare C++? That's like "a tree, but without a trunk,
twigs and leaves". Only the bugs remain...

* Stefan Arentz:
> (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.

One way: you exit the inner block by throwing an exception so that all exits
are via exceptions. In the common catch handler you clean up (this is the
'finally' part) and then check whether the exception corresponds to a normal
return. If so, you do a normal return, otherwise you rethrow. I think this
should perhaps be tought in programming classes because it makes the cost of
'finally', what goes on behind the scenes, very explicit. On the other hand
there is the risk that what students know about they will use...

Another way: you pass references to things to be cleaned up to an object of a
locally declared class where the destructor implements the 'finally'.

But generally, use smart-pointers, RAII and exception-transparent code to
avoid the need for 'finally' handling: whenever you find yourself thinking
that 'finally' would be nice here, think about how much nicer if 'finally'
weren't needed here at all, i.e. if the code was refactored/redesigned! )



PS: No need to use gcc extension to define an inner function; where you
need it you can use a local class.

--
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?

Nicolas Pavlidis wrote:

> "John Harrison" <> 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
>
> but what's about this:
>
> void bar()
> {
> char * my_ptr;
> try
> {
> SomeObject instace;
> my_ptr = new char[987];
> // do something
> instace.doSomehting() // throws an exception let's say MyExec
> // work with pointer
> delete my_ptr
> }
> catch(MyExec &exc)
> {
> delete my_ptr;
> // error handling
> }
> }
>
> Here it's necessary to duplicate code, another example would be file
> handling.

That's what std::auto_ptr is for:

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

See? You don't need to cleanup twice. You actually don't need to cleanup at
all. The destructor does the work for you, and that's how it's supposed to
be in C++.

> Sometimes a finally - block can help.

It rather looks to me like a workaround for a design problem. In most cases,
you shouldn't need to deal with raw memory (and for those, you have
auto_ptr). In any other cases, the objects should do the cleanup themselves
on destruction. This is btw. a big advantage over GC languages that lack a
destructor (or at least lack one which is called at points that are exactly
defined)

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

Probably nobody saw a need for it.

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

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.

Niels Dybdahl

Tom Widmer <> writes:

> On 21 Sep 2004 14:32:39 +0200, Stefan Arentz <>
> 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, but I've had no reason to use them yet and I would have to look into
object code size first.

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? 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?

S.

"Gernot Frisch" <> writes:

> >
> > I'm on a device that is too small to even include STL
>
> If you design your classes with nice d'tors and only use classes
> instead of new/malloc allocations, the problem is void. If you seem to
> have a small device (WTF is this - a fridge?), then write optimized
> code. The 'final' keyword would not do anything else than wrap your
> code in a gargabe collector, which _is_ available as template classes
> for those who cannot remember what they allocate.
> A good compiler will produce smal code from a template library, though
> the source code might be big. And don't tell me you're compiling the
> program _on_ the fride.

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

S.

Stefan Arentz wrote:

> (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

Why don't the destructors of your "vars" do the cleanup? Anyway, you can
still use RAII:

void Foo()
{
struct whatever
{
// your variables

~whatever()
{
// cleanup
}
} vars;

// something that throws - or not.
}

No try, no catch, no finally needed. I admit that finally would be slightly
more convenient, but in my experience the cases where something like that
is needed are rare.

In article <>,
Stefan Arentz <> wrote:
>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, but I've had no reason to use them yet and I would have to look into
>object code size first.

Are you actually aware of a constraint using STL or Boost will
impose upon you, or are you just assuming they will? It might
be worth actually seeing which parts are acceptable. You may
also find something like Dinkumware's embedded STL extensions
a practical compromise.
--
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?

"Stefan Arentz" <> wrote in message
news:...
> Tom Widmer <> writes:
>
> > On 21 Sep 2004 14:32:39 +0200, Stefan Arentz <>
> > 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?

Jeff F

"Stefan Arentz" <> skrev i en meddelelse
news:...
> "Peter Koch Larsen" <> writes:
>
> > "Stefan Arentz" <> skrev i en meddelelse
> > news:...
> > >
> > [snip]
> > > 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.
> >
> > Hi Stefan
> >
> > John Harrison has already answered your question. I just want to add
that
> > you could check out boost for some of the smart pointers there. There is
> > also "scopeguard" for more special stuff.
>
> 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.

/Peter