nested class inheritance

[Gor Gyolchanyan]

On Sun, Jul 15, 2012 at 3:35 PM, Benjamin Thaut <code at benjamin-thaut.de>wrote:

> Am 15.07.2012 13:24, schrieb Gor Gyolchanyan:
>
>> On Sun, Jul 15, 2012 at 1:41 PM, Benjamin Thaut <code at benjamin-thaut.de
>>
>> <mailto:code at benjamin-thaut.de**>> wrote:
>>
>>     Am 15.07.2012 02:02, schrieb Timon Gehr:
>>
>>         On 07/15/2012 12:55 AM, Benjamin Thaut wrote:
>>
>>             Am 14.07.2012 19:30, schrieb Gor Gyolchanyan:
>>
>>                 On Sat, Jul 14, 2012 at 9:23 PM, Benjamin Thaut
>>                 <code at benjamin-thaut.de <mailto:code at benjamin-thaut.de**>
>>                 <mailto:code at benjamin-thaut.de
>>
>>                 <mailto:code at benjamin-thaut.de**>__>> wrote:
>>
>>                 Am 14.07.2012 19:21, schrieb kenji hara:
>>
>>                 2012/7/15 Benjamin Thaut <code at benjamin-thaut.de
>>                 <mailto:code at benjamin-thaut.de**>
>>                 <mailto:code at benjamin-thaut.de
>>                 <mailto:code at benjamin-thaut.de**>__>>:
>>
>>
>>                 The only problem about this is:
>>
>>                 class Fruit
>>                 {
>>                 class Seed {
>>                 void SetFruit(Fruit fruit)
>>                 {
>>                 this.outer = fruit;
>>
>>
>>                 Setting to pseudo variable 'outer' should be rejected in
>>                 compilation.
>>                 Please report it to bugzilla.
>>
>>                 }
>>                 }
>>                 }
>>
>>                 class Apple: Fruit
>>                 {
>>                 void AppleOnlyMethod(){ ... }
>>
>>                 class AppleSeed: Fruit.Seed {
>>                 void DoSomething()
>>                 {
>>                 AppleOnlyMethod();
>>                 }
>>                 }
>>
>>                 auto GetNewSeed() { return new AppleSeed(); }
>>                 }
>>
>>                 auto apple = new Apple();
>>                 auto seed = apple.GetNewSeed();
>>                 seed.SetFruit(new Fruit());
>>                 seed.DoSomething(); //what happens here?
>>
>>                 Kind Regards
>>                 Benjamin Thaut
>>
>>
>>                 Kenji Hara
>>
>>
>>                 I will not report this, beacuse it will break my custom
>>                 new operator
>>                 (template) for inner classes ;-)
>>
>>                 Kind Regards
>>                 Benjamin Thaut
>>
>>
>>                 That's most unwise, because if it's not supposed to be
>>                 like that it will
>>                 get fixed anyway, so you better start replacing your
>>                 custom new
>>                 operator.
>>
>>                 --
>>                 Bye,
>>                 Gor Gyolchanyan.
>>
>>
>>             Replacing my custom new operator exactly by what?
>>             Overloading the build
>>             in new is deprecated...
>>
>>
>>         class C{
>>               class D{
>>
>>               }
>>         }
>>         void main(){
>>               auto c = new C;
>>               auto buf = new void[__traits(__**classInstanceSize, C.D)];
>>
>>               (cast(byte[])buf)[] = typeid(C.D).init[];
>>               auto d = cast(C.D)buf.ptr;
>>               static if(is(typeof(d.__ctor()))) d.__ctor();
>>               enum offset=d.outer.offsetof;
>>               static assert(offset%C.sizeof==0);
>>               (cast(C[])buf)[offset/C.__**sizeof]=c;
>>
>>               assert(d.outer is c);
>>         }
>>
>>
>>     Yes of course I can assign the reference by computing the address
>>     and then using that to assign it. But the point here is, that this
>>     is currently the only bug that is hepling me in what I'm doing, and
>>     I rather want the 7 other bugs I reported so far to be fixed, rather
>>     then the one that helps me.
>>
>>     Kind Regards
>>     Benjamin Thaut
>>
>>
>> Not being able to assign is not about some sort of authoritative
>> forbidding. It's about not breaking a working mechanism. You can't cast
>> a function pointer into a class object not because the type system says
>> so (which it does), but because that'll result in an undefined behavior,
>> which will result in an immediate crash in the best scenario. Go ahead
>> and change the outer via those hacks. But then don't get surprised when
>> your program crashes for no reason (because the compiler assumed it not
>> to change and ended up being wrong).
>>
>> --
>> Bye,
>> Gor Gyolchanyan.
>>
>
> Before your change suggestion it was absolutley save to assign to outer.
> Thats the whole point why I posted this here. I very well know that the bug
> will get fixed some time. But before your change suggestion it was not even
> a bug.
>
> Kind Regards
> Benjamin Thaut
>
>
A bug remains a bug whether it was discovered or not. If it wasn't - it
would never get discovered. Even if the bug didn't get discovered for a
long time, making designs around bugs is a very bad idea precisely for this
reason. But it's not entirely your fault, because there's no reliable
reference to D at the moment, so it's very hard to determine what is and is
not supposed to work. That's one of the problems, that drive new commers
away: lack of a reference material.

-- 
Bye,
Gor Gyolchanyan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120715/76143067/attachment-0001.html>