void foo(Bar <&b>) {
b.frag(3); // Call some method
...
}
In this case, foo would either be passed a copy of a
Bar type (pass by value) or a reference to an existing
Bar. The precise choice, of course, would be up to the
implementation. Obviously, the compiler would pick the best
option--making it a good choice for programmers too stupid to know whether
they should use a pointer or not.
Obviously, there are a few complicated cases such as:
The interpretation of this is left as an exercise to the reader (hey, it's good to be a professor).void foo(const Bar *const *<&b>);
Afterwards, the object that x points to is guaranteed to be undeletable--even if a program repeatedly calls delete or free() on it. This effect applies to the object itself, not the pointer (thus, the cast implicitly applies to all other pointers referring to the same object). Furthermore, the cast remains in effect until the program terminates--making this a particularly good way to avoid those pesky memory management problems such as calling delete too many times by accident.Bar *x = survival_cast<Bar *>(y);
The survival cast can be applied to the individual elements of an array or container. However, in this case, the implementation must ensure that deletion of the array or container only deletes those members for which the survival cast has not been applied.
When too many objects have been cast using the survival cast, they may decide to spontaneously delete themselves along with an unspecified number of non-survival objects. This is a feature. However, the precise mechanism and scope of destruction is implementation specific and may depend on the type of objects to which the survival cast has been applied.
In addition, there should be an identifier_case_cast that works similarly, but which looks at the case of the type names. I'm not really sure what purpose these casts would serve, but that doesn't really distinguish them from any of the other casts.Bar *x = identifier_length_cast<Foo *>(y); // Ok FooBar *x = identifier_length_cast<Foo *>(y); // Error
class Foo {
public:
...
bar:
printf("Hello world\n");
... some code here ...
break;
};
int main() {
Foo *f = new Foo;
goto f.bar;
...
}
Obviously, the benefits of this feature are self-evident. However,
there are still a few tricky points. First, the goto should work with
inheritance when the goto label happens to appear in a base-class. Second,
the goto should certainly take advantage of dynamic binding much like virtual
member functions. Finally, I believe that there would be many interesting
possibilities of combining template classes with goto. For example:
Clearly, the number of applications is endless.template class Foo{ public: x: ... some code here ... break; ... };