Two things I'd like to see in C++ 2009

[J. Smith]

I know about RAII and BS's response to previous requests, but I'd really
love to see 'finally' available in C++ exception handling. Yes, we can
live without 'finally' but it means a bit more typing (more classes) for
simple scenarios (like calling LeaveCriticalSe ction() before a function
returns). It would also make porting other languages to C++ a bit more
simple.

Another thing I'd like to see is a 'reentrant' keyword that can be
applied to functions and methods. The compiler should have all the info
necessary to complain when a non-reentrant function is labeled as reentrant.

[Joe Seigh]

J. Smith wrote:

Another thing I'd like to see is a 'reentrant' keyword that can be
applied to functions and methods. The compiler should have all the info
necessary to complain when a non-reentrant function is labeled as
reentrant.

So how would the compiler identify a non-reentrant function?

--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

[Mercator]

Joe Seigh wrote:

J. Smith wrote:

Another thing I'd like to see is a 'reentrant' keyword that can be
applied to functions and methods. The compiler should have all the info
necessary to complain when a non-reentrant function is labeled as
reentrant.

So how would the compiler identify a non-reentrant function?

It uses no static or global variables. But a new keyword is
'disproportiona te'.

[Mercator]

J. Smith wrote:

I know about RAII and BS's response to previous requests, but I'd really
love to see 'finally' available in C++ exception handling.

You probably don't know (enough) about RAII. Otherwise you wouldn't
want a 'finally'.

[Ian]

Joe Seigh wrote:

J. Smith wrote:

Another thing I'd like to see is a 'reentrant' keyword that can be
applied to functions and methods. The compiler should have all the
info necessary to complain when a non-reentrant function is labeled as
reentrant.

So how would the compiler identify a non-reentrant function?

Use of a non-local object maybe?

Ian

[verec]

On 2005-07-17 00:08:31 +0100, "Mercator" <me********@spa mbob.com> said:

Joe Seigh wrote:

J. Smith wrote:

Another thing I'd like to see is a 'reentrant' keyword that can be
applied to functions and methods. The compiler should have all the info
necessary to complain when a non-reentrant function is labeled as
reentrant.
So how would the compiler identify a non-reentrant function?

It uses no static or global variables.

.... And only calls functions themselves labelled as "reentrant" ...
.... And doesn't dereference any pointer ...

file super_safe.cpp

void f(int *p) reentrant {
*p = 0 ;
}
file subvert_it_anyw ay.cpp

int global ;
int main() {
f(&global) ;
return 0 ;
}
But a new keyword is 'disproportiona te'.
.... or the idea, itself, inappropriate ? :)
but I'd really
love to see 'finally' available in C++ exception handling.

That one seems more readily implementable, but C++ politics will
probably vote it down :(
--
JFB

[verec]

On 2005-07-17 00:10:43 +0100, "Mercator" <me********@spa mbob.com> said:

J. Smith wrote:

I know about RAII and BS's response to previous requests, but I'd really
love to see 'finally' available in C++ exception handling.

You probably don't know (enough) about RAII. Otherwise you wouldn't
want a 'finally'.

You probably don't know (enough) about finally. Otherwise you would
see RAII as just a special hackish case of the more general finally
construct.
--
JFB

[benben]

> You probably don't know (enough) about finally. Otherwise you would

see RAII as just a special hackish case of the more general finally
construct.
--
JFB

Ok, fair to say, RAII binds to class, and finally block binds to procedure.
If you are lazy designing proper classes, you'd want finally. If you are
doing a huge project, where a lot of classes and procedures are concerned,
binding to classes is instantaneous.

Regards,
Ben

[verec]

On 2005-07-17 01:56:00 +0100, "benben" <be******@hotma il.com> said:

You probably don't know (enough) about finally. Otherwise you would
see RAII as just a special hackish case of the more general finally
construct.

Ok, fair to say, RAII binds to class, and finally block binds to procedure.
If you are lazy designing proper classes, you'd want finally. If you are
doing a huge project, where a lot of classes and procedures are concerned,
binding to classes is instantaneous.

How so ?!?! Instantenous??? ?

in a finally block, you only have to clean-up whatever it is
that needs cleaning, whether _you_ acquired it or not.

With RAII, not only do you _have to_ define extra classes, but
also cope with the communication between the point you're about
to (re) throw and the said class(es) to deal with the case that
the "resource" that wasn't for you to acquire in the first place,
nor to release in nornal circumstances, are for you to release
in the exceptional case.
--
JFB

[benben]

"verec" <ve***@mac.co m> wrote in message
news:42******** *************** @news.aaisp.net .uk...

On 2005-07-17 01:56:00 +0100, "benben" <be******@hotma il.com> said:

You probably don't know (enough) about finally. Otherwise you would
see RAII as just a special hackish case of the more general finally
construct.

Ok, fair to say, RAII binds to class, and finally block binds to procedure. If you are lazy designing proper classes, you'd want finally. If you are
doing a huge project, where a lot of classes and procedures are concerned, binding to classes is instantaneous.

How so ?!?! Instantenous??? ?

in a finally block, you only have to clean-up whatever it is
that needs cleaning, whether _you_ acquired it or not.

With RAII, not only do you _have to_ define extra classes, but
also cope with the communication between the point you're about
to (re) throw and the said class(es) to deal with the case that
the "resource" that wasn't for you to acquire in the first place,
nor to release in nornal circumstances, are for you to release
in the exceptional case.
--
JFB

With good design, all clean ups are affiliated with a class.

Let's say we have a huge project in which finally blocks are intensively
used. Class A is one of many classes the project consists of. Now you are
asked to update A's implementation and the change requires a differently
clean up scheme. You now face a large number of finally blocks needed to be
rewritten.

On the other hand, had all the necessary clean up operations encapsulated by
class A, we only have to update the clean up code once, inside A. RAII will
take care of everything else.

Regards,
Ben