Re: Needed features in upcoming standards
On Jan 6, 12:13 pm, Blake McBride <bl...@mcbride.name> wrote:
1. Computed goto
[snip]
The labels should not have to appear before the assignment, and there
should be a way of making this runtime assignment to labels once.
I would assume that this is easier said than done but I am not an
expert on C++ compiling. Would you find forward declarations of labels
acceptable? E.g.:
void somewhere () {
// Forward declarations.
jump_label lbl1;
jump_label lbl2;
computed_goto_t labels[] = {lbl1, lbl2};
goto labels[x];
lbl1:
...
lbl2:
...
}
2. Function goto instead of call
When you call a function (typically) a call stack is created. When the
function returns the return goes to the calling function. Some C
compilers can do tail call elimination in certain circumstances but it
is never guaranteed to support tail calls in all obvious conditions. C
is often used as an intermediate language for other languages compilers
(like Lisp, Scheme, etc.). Languages such as Scheme require tail call
optimization. Coding in assembler is very un-portable. Using C as a
portable assembler is great but not being able to eliminate tail calls
is a big problem. Scheme compilers often use a set of tricks to make C
eliminate tail calls but these tricks are very slow compared to what is
really needed.
If C had the ability to "goto" a function rather than
"call" a function, other compiler writers can take advantage of this
feature to give their languages tail call elimination without costly
tricks or having to resort to assembler.
In C++, say you have the following:
class MyClass {
public:
~MyClass () { }
};
void function1 () {
do_things();
}
void function2 () {
MyClass mc;
do_some_stuff();
function_goto function1;
}
In this behavior, where would you have the destructor of mc be called?
Particularly, would it be before or after the call to do_things()?
If you would have function2's stack unwinding occur at the
function_goto, then means function_goto has significantly different
semantics than a simple function call. Is this OK? The way you
described it made it sound like you intended it to behave as a drop-in
replacement for a simple function call.
If you would have function2's stack unwinding occur when function1
returns, this significantly complicates the implementation of
function1 and/or function_goto, as function1 must now conditionally
unwind function2 stack constructs when it returns depending on whether
or not it was entered from function2.
It may be possible to solve these problems by placing a constraint on
the use of function_goto and only allowing it to jump out of scopes
that do not require objects to be cleaned up during stack unwinding.
Personally I find this constraint too limiting, but would you find it
acceptable?
Here is another example of a troublesome case:
void function1 () {
}
void function2 () {
try {
function_goto function1;
} catch (...) {
}
}
What happens here? Do exceptions thrown by function1 get handled in
function2, or do they escape the try...catch block? If they escape,
how far do they escape? E.g., consider:
void function2 () {
try {
try {
function_goto function1;
} catch (...) {
// caught here?
}
} catch (...) {
// caught here?
}
}
// unhandled?
If they go unhandled, can only the caller of function2() catch
exceptions thrown by function1()?
Jason