comparing pointers passed to and returned from funcs

[spir]

On 03/02/2011 02:24 PM, Steven Schveighoffer wrote:
> On Tue, 01 Mar 2011 18:11:00 -0500, bearophile <bearophileHUGS at lycos.com> wrote:
>
>> http://d.puremagic.com/issues/show_bug.cgi?id=5678
>
> I think there is a general bug where any time the compiler uses an enum, it
> simply replaces the expression declared for the enum.
>
> So basically
>
> enum TRUE = new DElement(true);
>
> void main()
> {
> auto delem1 = TRUE;
> auto delem2 = TRUE;
> assert(delem1 is delem2); // fails
> }
>
> gets morphed into this:
>
> void main()
> {
> auto delem1 = new Delement(true);
> auto delem2 = new Delement(true);
> assert(delem1 is delem2); // fails
> }
>
> Obviously this works great when the enum is a value type or a string literal
> (which is created at compile time). However, it is not so great for things like
> AAs, array literals, objects, or structs.
>
> I think there are a few of these bugs in bugzilla, and there should be at least
> a tracker, and if not, they should all be combined. This is a serious problem
> in D, and really creates havoc (both performance-wise and semantically). I
> don't anticipate there is an easy fix.
>
> Essentially, I'd say enum is completely useless except for builtin types and
> strings.

Thank you Steven & Bearophile. This solves my problem.
I first did not get Bearophile's answer about run/compile-time constants (I 
mean enums). I thought the time when they are created is irrelevant, isn't it?
Anyway, placing the constant defs inside a module's <static this () {...}> 
block does what I mean. It does, in fact, ensure *unicity*. But I don't really 
understand the relation with Steven's explanation above: why/how does the fact 
that a constant's def is inside static this() prevent the compiler to rewrite 
it like shown above? Also, I basically don't understand why dmd does that 
anyway: it's obviously un-ecological ;-)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com