Re: Would this work as an extension to the language ?
On 29 Nov., 21:19, Timothy Madden <terminato...@gmail.com> wrote:
Thomas Richter wrote:
Timothy Madden schrieb:
Could this be an extension to the language ?
Has something similar been considered ?
I am thinking about inner classes (nested if you want)
whose objects can only be created and can only exist in
the context of an object of the outer class, lets call
it the master object. For most of the times this master
object would be similar in usage to some container concept.
The inner objects have direct access to members of the
master object, by an implied additional argument (kind
of like 'this'), lets call it this_container.
[..]
The master object should be given when inner objects are
created, or should be implied if inner objects are created
by member functions in the master class.
Why do you need a language extension for that? This works, see above.
[...]
Do you think this makes enough sense ?
Yes, but no need to extend C++ for it.
One could say this is syntactic sugar for including
a reference to the master object in the inner class,
but so is operator overloading, and still it is so
powerful.
This is really the only extension.
Not really.
How about nested objects inside nested objects ?
Would you like to be writting
container.container.container.GlobalFlag := true;
for every variable in the object's context ?
Instead of just
GlobalFlag := true;
This idea of context I am talking about is like that of
namespaces, only instead of applying to symbol names it
applys to the very objects you program works with. At
runtime, if you want.
It is like creating an environment that your classes are
designed to work in.
I guess you would like to add a similar extension to C++
which can be found in Java's "non-static inner" classes,
where a (hidden) this-Pointer of the surrounding class
is stored (and available) in the inner class?
This idea does IMO not fit well within C++. The reason
is life-time issues and ownership responsibilities.
Think about that: What would happen, if you would return
such an instance of an inner class from some function?
It's quite easy for programmers to forget, that this
special class has an hidden reference to an outer-scope
class and a source of trouble if this inner class
has a longer life-time than the instance of the outer
class.
Have you worked with nested functions in Pascal ? Such a
function can directly access variables in the enclosing
function, or the enclosing enclosing function...
All inner functions internally have a display, with pointers
to local variables storage (on stack) of the enclosing
functions. Would you ask why Pascal has this feature, saying
that it is not needed ?
I have a long Pascal (and Delphi) tradition, therefore I know
these kind of functions. Honestly, I used them rarely, but
I consider this as a personal taste. But besides my personal
preferences these functions also have some notable restrictions,
e.g. you cannot return pointers of them. The reason is very
similar to the life-time issues mentioned above. If the Pascal
language would allow copying references of these functions (by
means of function pointers), then users would easily experience
similar life-time problems as mentioned above. In this case,
the reference to the external stack frame becomes invalid, but
the consequences are quite the same.
This problem does not exist in Java due to it's different
life-time model.
I don't think, that this lack is a severe limitation for
C++. No one forces you, to use a very long name like
"container" for the reference to the "mother" object.
You can use any short name for it (e.g. if you use a function,
you could choose a single underscore as a name like in "_()").
Finally let my say, that your comparison with namespaces
is incorrect, because the lifetime-problem does not
exist here for all entities within the same translation
unit (except for some tricky constructions).
Anyone thinks nested functions would be good in C++ too ?
As of the current standard draft N2798, they are available
in some special form known as lambda expressions, e.g.:
void foo(long lower_bound) {
std::vector<long> values;
... // Fill the vector with data
const long upper_bound = 42;
std::vector<long>::iterator it =
std::find_if(values.begin(), values.end(),
values.begin(), [&](long item) {
return (item >= lower_bound) && (item <= upper_bound);
});
...
}
By means of the default-capture & used in the lambda-introducer
(this funny thingee [&] which looks like some kind of array)
you say that you want access the function scope of foo by
reference. This is basically the same as if this lambda
closure would have a reference to the stack frame of foo.
The language does say so more explicitly in 5.1.1
[expr.prim.lambda]/12:
"If every name in the effective capture set is preceded by
& and the lambda expression is not mutable, F is publicly
derived from std::reference_closure<R(P)> (20.7.18), where
R is the return type and P is the parameter-type-list of the
lambda expression. Converting an object of type F to type
std::reference_closure<R(P)> and invoking its function call
operator shall have the same effect as invoking the function
call operator of F. [ Note: This requirement effectively
means that such F?s must be implemented using a pair of a
function pointer and a static scope pointer. ?end note]"
HTH & Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]