Hi lemon head. I'm interested in nested classes being able to access "this". In one of your posts you told that the nested object doesn't need to store a reference, that "this can be achieved using the barton-nackmann trick and multi-inheritance, but that's not a nice solution".

[quote]Hi lemon head. I'm interested in nested classes being able to access "this". In one of your posts you told that the nested object doesn't need to store a reference, that "this can be achieved using the barton-nackmann trick and multi-inheritance, but that's not a nice solution".

Can you give a brief example of the involved technique?[/quote]

I am trying to remember :)I had already given up on the idea, after seeing that noone is interested in it (including Mr. Bj. Str. in persona - but maybe this is because he gets tons of messages a day)I hope my C++ is not too rusty in the meantime.

You can use this trick, but then it will no longer be a "nested object", but a "parent class".

I saw also some pages discussing the difference between CRTP and barton-nackmann's trick.

I'll analyze it depth but it seems that it isn't what I was looking for: I'd prefer to avoid the inversion "nested object" to "parent class". Despite, I thought of using it with several nested classes/structs, so I'd say that that rules out this approach.

Maybe storing a pointer to 'this' is the only safe way to do this; which is, put it simply, what Java does.

I'm also considering some way of calculating outer's 'this' from within the nested class. In principle having nested's 'this' and the field offset it could be achieved. Something like

You are right, it is absolutely possible via offset calculations. Usually we can assume that the compiler will use the same offset for every object. But still it's stinky...

My proposal was to provide a native syntax for this offset trick, and let the compiler guarantee that it works correctly.

About the Java way: In Java you HAVE to store the reference to 'this', because the nested object is not statically nested in the enclosing object, but dynamically. In C++ we have the nested and enclosing object in the same block of memory.

The static nesting gives a memory benefit, and also reduces indirection. This is usually not worth the trouble, but it can make a lot of sense when programming large data structures with very small atomic objects.

In my opinion two most important additions to C++ would be:1) Compile time meta information (Something like Daveed Vandevoorde's metacode).2) Standard modules - C++ version of Java class files or .net assemblies.

These two features could revolutionize C++ once again.

Compile time meta information.Although template metaprogramming is a very cool and interesting way of getting some things done, It looks too complicated and has certain limitations that are direct consequence of the lack of the type information during the compilation. Some metadata can be obtained using quite indirect and unnatural tricks, but anyway, that approach is too limited.Even if it's too difficult to implement all Daveed's ideas, at least some way to iterate over class/template's members/member functions and their types would be very useful.Something resembling .net attributes but available during the compile time instead of (or in addition to - optionally) runtime - would be awesome. This would enable a whole gamut of new powerful techniques.All this additions revolving around the metadata issue would greatly reduce the need for code generation tools for C++ resulting in more portable elegant and generic solutions.

Optionally, making this rich metadata (extended RTTI) available during the runtime would be also handy, but I'm not a big fan of that idea because it might encourage structurally simple but inefficient Java/C# style solutions.

2) Standard modules.This would make possible to share C++ binaries across different OSes and platforms as long as the CPU instruction set is the same. Platform specific code could be isolated in platform specific binaries with the same C++ interfaces.Ability to include those modules would also be nice. This is already implemented in MSVC:#import "some.dll"Just make it something portable and standard.

3) I agree that access to host class members/functions from the nested class could be useful in some cases and not too difficult to implement. I believe implementation complexity would be similar in a way to multiple (virtual) inheritance.From the conceptual point of view it's no uglier than MI itself or friends for example.

multiple levels could be handled with either scope resolution operator, or additional keyword (host?):