digitalmars.D.learn - Attributes not propagating to objects via typeinfo?
- rsw0x (17/17) Aug 12 2015 Sample code:
- rsw0x (2/20) Aug 13 2015 bump, is this working as intended?
- Steven Schveighoffer (16/32) Aug 13 2015 That is definitely a bug. It's because typeid is looking up the derived
- Steven Schveighoffer (15/18) Aug 13 2015 Actually, now that I think about it, I'm not sure how the compiler can
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (4/23) Aug 14 2015 If it yields invalid results, it should at least be forbidden, if
- Steven Schveighoffer (9/37) Aug 14 2015 I think it's really a limitation of the runtime. If we can eliminate
- Timon Gehr (6/20) Aug 14 2015 Can't the shared typeinfo be constructed for all superclasses of C at
- Steven Schveighoffer (13/36) Aug 14 2015 I don't think it can do this at compile time. It would have to do it at
- rsw0x (4/7) Aug 15 2015 It appears that this was suggested already after a bit of digging
Sample code:
class C{}
struct S{}
void main(){
import std.stdio;
auto c = new shared C();
auto s = new shared S();
writeln(typeid(c)); //modulename.C
writeln(typeid(s)); //shared(modulename.S)*
writeln(typeid(c).next); //null
writeln(typeid(s).next); //shared(modulename.S)
writeln(typeid(typeid(s).next) is typeid(TypeInfo_Shared));
//true
writeln(typeid(typeid(c)) is typeid(TypeInfo_Shared)); //false
}
What's the reason that the shared propagates to the typeinfo for
the struct, but not for the class declaration?
Aug 12 2015
"rsw0x" <anonymous anonymous.com>
On Thursday, 13 August 2015 at 03:46:19 UTC, rsw0x wrote:
Sample code:
class C{}
struct S{}
void main(){
import std.stdio;
auto c = new shared C();
auto s = new shared S();
writeln(typeid(c)); //modulename.C
writeln(typeid(s)); //shared(modulename.S)*
writeln(typeid(c).next); //null
writeln(typeid(s).next); //shared(modulename.S)
writeln(typeid(typeid(s).next) is typeid(TypeInfo_Shared));
//true
writeln(typeid(typeid(c)) is typeid(TypeInfo_Shared));
//false
}
What's the reason that the shared propagates to the typeinfo
for the struct, but not for the class declaration?
bump, is this working as intended?
Aug 13 2015
On 8/12/15 11:46 PM, rsw0x wrote:
Sample code:
class C{}
struct S{}
void main(){
import std.stdio;
auto c = new shared C();
auto s = new shared S();
writeln(typeid(c)); //modulename.C
writeln(typeid(s)); //shared(modulename.S)*
writeln(typeid(c).next); //null
writeln(typeid(s).next); //shared(modulename.S)
writeln(typeid(typeid(s).next) is typeid(TypeInfo_Shared)); //true
writeln(typeid(typeid(c)) is typeid(TypeInfo_Shared)); //false
}
What's the reason that the shared propagates to the typeinfo for the
struct, but not for the class declaration?
That is definitely a bug. It's because typeid is looking up the derived
type via the vtable, but the compiler should rewrap it with 'shared'
afterwards.
This is enough to make me think it's a bug:
class C{}
void main(){
auto c1 = new C;
auto c2 = new shared(C);
assert(typeid(c1) is typeid(c2));
assert(!is(typeof(c1) == typeof(c2)));
pragma(msg, typeof(c1)); // C
pragma(msg, typeof(c2)); // shared(C)
}
I don't think it's shared-specific.
-Steve
Aug 13 2015
On 8/13/15 11:59 AM, Steven Schveighoffer wrote:That is definitely a bug. It's because typeid is looking up the derived type via the vtable, but the compiler should rewrap it with 'shared' afterwards.Actually, now that I think about it, I'm not sure how the compiler can figure this out. There would have to be a way to construct a TypeInfo_Shared at runtime, which the compiler shouldn't be doing. Alternatively, it could proactively create a TypeInfo_Shared (and all the other flavors) for each class type in the runtime, and then look it up using some hash mechanism. This likely isn't fixable. What you CAN do, however, is: typeid(typeof(c)) Which should get the *static* type (and that should be TypeInfo_Shared in both struct and class instances). So likely this is not a bug, or at the best, a wontfix. -Steve
Aug 13 2015
On Thursday, 13 August 2015 at 16:05:19 UTC, Steven Schveighoffer wrote:On 8/13/15 11:59 AM, Steven Schveighoffer wrote:If it yields invalid results, it should at least be forbidden, if it can't be fixed.That is definitely a bug. It's because typeid is looking up the derived type via the vtable, but the compiler should rewrap it with 'shared' afterwards.Actually, now that I think about it, I'm not sure how the compiler can figure this out. There would have to be a way to construct a TypeInfo_Shared at runtime, which the compiler shouldn't be doing. Alternatively, it could proactively create a TypeInfo_Shared (and all the other flavors) for each class type in the runtime, and then look it up using some hash mechanism. This likely isn't fixable. What you CAN do, however, is: typeid(typeof(c)) Which should get the *static* type (and that should be TypeInfo_Shared in both struct and class instances). So likely this is not a bug, or at the best, a wontfix.
Aug 14 2015
On 8/14/15 4:22 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>" wrote:On Thursday, 13 August 2015 at 16:05:19 UTC, Steven Schveighoffer wrote:I think it's really a limitation of the runtime. If we can eliminate TypeInfo from the purview of the compiler, we could do some kind of solution where the result of typeid could be some sort of wrapper struct in this case. But I don't know if it's a good idea to forbid this, you would probably break a lot of code. -SteveOn 8/13/15 11:59 AM, Steven Schveighoffer wrote:If it yields invalid results, it should at least be forbidden, if it can't be fixed.That is definitely a bug. It's because typeid is looking up the derived type via the vtable, but the compiler should rewrap it with 'shared' afterwards.Actually, now that I think about it, I'm not sure how the compiler can figure this out. There would have to be a way to construct a TypeInfo_Shared at runtime, which the compiler shouldn't be doing. Alternatively, it could proactively create a TypeInfo_Shared (and all the other flavors) for each class type in the runtime, and then look it up using some hash mechanism. This likely isn't fixable. What you CAN do, however, is: typeid(typeof(c)) Which should get the *static* type (and that should be TypeInfo_Shared in both struct and class instances). So likely this is not a bug, or at the best, a wontfix.
Aug 14 2015
On 08/13/2015 06:05 PM, Steven Schveighoffer wrote:On 8/13/15 11:59 AM, Steven Schveighoffer wrote:Can't the shared typeinfo be constructed for all superclasses of C at the point where shared(C) is used? (Think: template instantiation.)That is definitely a bug. It's because typeid is looking up the derived type via the vtable, but the compiler should rewrap it with 'shared' afterwards.Actually, now that I think about it, I'm not sure how the compiler can figure this out. There would have to be a way to construct a TypeInfo_Shared at runtime, which the compiler shouldn't be doing. Alternatively, it could proactively create a TypeInfo_Shared (and all the other flavors) for each class type in the runtime, and then look it up using some hash mechanism. ...This likely isn't fixable. ...I don't understand. It is evidently fixable. E.g. if TypeInfo was just a template without the mostly redundant additional compiler support, this would be a trivial fix.
Aug 14 2015
On 8/14/15 11:39 AM, Timon Gehr wrote:On 08/13/2015 06:05 PM, Steven Schveighoffer wrote:I don't think it can do this at compile time. It would have to do it at link time, since it doesn't know what subclasses of C will exist. If it's a dynamically-linked library, it would have to construct them on library load. Optionally, it could allocate the necessary TypeInfo_Shared on the heap when needed. I don't like that idea either.On 8/13/15 11:59 AM, Steven Schveighoffer wrote:Can't the shared typeinfo be constructed for all superclasses of C at the point where shared(C) is used? (Think: template instantiation.)That is definitely a bug. It's because typeid is looking up the derived type via the vtable, but the compiler should rewrap it with 'shared' afterwards.Actually, now that I think about it, I'm not sure how the compiler can figure this out. There would have to be a way to construct a TypeInfo_Shared at runtime, which the compiler shouldn't be doing. Alternatively, it could proactively create a TypeInfo_Shared (and all the other flavors) for each class type in the runtime, and then look it up using some hash mechanism. ...I mean, it's not likely fixable without a drastic redesign of the typeinfo system. I'd prefer having typeinfo simply not exist as far as the compiler is concerned, and have typeid call a template with the type as the parameter. We have RTInfo, we should make the whole darned thing done that way. -SteveThis likely isn't fixable. ...I don't understand. It is evidently fixable. E.g. if TypeInfo was just a template without the mostly redundant additional compiler support, this would be a trivial fix.
Aug 14 2015
On Friday, 14 August 2015 at 15:39:39 UTC, Timon Gehr wrote:I don't understand. It is evidently fixable. E.g. if TypeInfo was just a template without the mostly redundant additional compiler support, this would be a trivial fix.It appears that this was suggested already after a bit of digging but nobody cares to fix it. IMO, compiler handles far too much stuff that should be in the runtime.
Aug 15 2015