nested class inheritance

Benjamin Thaut code at benjamin-thaut.de
Sun Jul 15 04:35:02 PDT 2012


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



More information about the Digitalmars-d mailing list