On 3/4/16 4:30 PM, Yuxuan Shui wrote:
On Friday, 4 March 2016 at 15:18:55 UTC, Steven Schveighoffer wrote:
On 3/3/16 6:58 PM, Yuxuan Shui wrote:
On Thursday, 3 March 2016 at 23:51:16 UTC, Adam D. Ruppe wrote:
On Thursday, 3 March 2016 at 23:46:50 UTC, Yuxuan Shui wrote:
Will typeid(a) is typeid(b) yield different results than typeid(a) ==
typeid(b)?
No. Indeed, opEquals on TypeInfo just calls is itself.
But opEquals also has extra comparison:
auto ti = cast(const TypeInfo)o;
return ti && this.toString() == ti.toString();
This makes me feel they are not the same.
In some cases, for instance using DLLs, the TypeInfo for an object
allocated in one way may be identical, but be a different instance
from the TypeInfo allocated in another way. This is why the string
comparison occurs.
Note that comparing ANY object will first check if they are the same
instance before calling any functions (this is in object.opEquals)
Thanks for answering. But I still don't understand why TypeInfo would
need to be allocated. Aren't typeid() just returning references to the
__DxxTypeInfo_xxxx__initZ symbol?
You misunderstood, I meant the typeinfo *for* an allocated object, not
that the typeinfo was allocated.
In some cases, 2 different objects allocated from different libraries
(usually DLL-land) may reference TypeInfo from different segments, even
though the TypeInfo is identical.
-Steve
