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

[verec]

The maybe the ScopeGuard of Andrei Alexandescu is worth a look for you.

Cool!

I googled it down to:
http://www.cuj.com/documents/s=8000/cujcexp1812alexandr/alexandr.htm

The irony, of course, is that I can now:

#define finally ON_BLOCK_EXIT

Many thanks for the pointer.

 

[Steven T. Hatton]

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

This is my current letter to Santa:

1) A new concept of resource location to replace #include. Rather than
#including simple text files into a concatanated monolithic text file called
a translation unit, it should be possible to import named resources. The
mapping from fully qualified identifier to the resource will be the
responsibility of the implementation. This is similar to the Java `import',
the Mathematica `Needs', or the ELisp `requires' directives.

If the resource is available in compiled form, then the public interface
declaration should be extracted from from the module, or otherwise made
available to the compiler with the expectation that the resource would be
available for linking. If the resource is not compiled, it should be
compiled automatically if needed by the linker.

2) A language construct that maps to a compiled entity with a clearly
defined,
self-describing interface. This would be similar to the Mathematica notion
of a package, and might be accomplished by leveraging the existing namespace
construct. The compiled module should be capable of communicating its
public
interface in terms of source-code declarations. Similar to the way the
Mathematica package system provides comments, or the Java javap mechanism
returns an interface description of a class.

The module identifier could serve as the name to be used for resource
location
in the previously described replacement for #include.

3) A formalization of the notion of a class _interface_ which we currently
express as a class definition in a "header file" and _implementation_ with
the member function implementations defined elsewhere (in a "source file").
Whether the class interface is contained in the same file as the
implementation is irrelevant. This division between interface and
implementation could be extended to encompass namespace local functions as
well as classes. This would further obviate the need for the #include
directive.

4) A local context text extrating mechanism which could be used to preserve
class, namespace, function, etc., textual information in the form of const
member variables, or function call parameter initializations. The purpose
of
this feature would be to provide the kind of functionality currently
provided
by Cpp token pasting and stringification, but in such a way as to respect
the
scoping and type rules of C++.

5) A built-in conditional compilation block structure which would be
controlled by setting constants at the appropriate scope before compiling.

6) A clear specification of the conceptual organization of resources such as
identifiers, declarations, definitions, etc., so that the same steps can be
carried out to locate any resource within the working code base. IOW, treat
the code base as a database with some kind of deterministic organization.