On 12/02/12 14:25, js.mdnq wrote:
> On Saturday, 1 December 2012 at 23:57:27 UTC, Artur Skawina wrote:
>> On 12/01/12 20:26, Jonathan M Davis wrote:
>>> On Saturday, December 01, 2012 18:43:22 Timon Gehr wrote:
>>>> On 12/01/2012 06:23 PM, Jonathan M Davis wrote:
>>>>> On Saturday, December 01, 2012 12:05:49 Artur Skawina wrote:
>>>>>>> So, unless there's a way to do it without a cast, you're stuck. And I
>>>>>>> have
>>>>>>> no idea how you could possibly do it without a cast.
>>>>>>>
>>>>>>     *cast(void**)&O // assuming O is a class
>>>>>
>>>>> Are you sure? I'd be _very_ wary of that, because references aren't the same as pointers. I don't believe that there's any guarantee whatsoever that that will work, even if it happens to work now (which it may or may not).
>>>>>
>>>>> - Jonathan M Davis
>>>>
>>>> Certainly works now. Another workaround that would keep working if class references were not pointers is:
>>>>
>>>> ((Object o)=>cast(void*)o)(O) // assuming O is the class object
>>>
>>> Ah, good point. Using Object would work just fine and doesn't rely on the implementation details of references.
>>
>> References not appearing as if they were pointers is less likely than Object growing an opCast...
>>
>> Another workaround (for both non-empty classes and structs) would be
>>
>>   cast(void*)&O.tupleof[0]-O.tupleof[0].offsetof
>>
>> which will let you not worry about that kind of potential changes to the core of the language. :)
>>
>>
>> Seriously though, if one only needs to compare the addresses of class objects, "is" may be a better solution.
> 
> I'm not just comparing them but using them as a unique ID for the objects in an algorithm to prevent computing over the same object more than once.

  int[typeof(O)] rc;
  rc[O] = 42;
  auto O2 = O;
  // [...]
  if (auto r = O2 in rc)
     return *r;
  else
     return rc[O2] = compute(O2);

IOW explicitly taking the address may not be necessary when doing that kind of things. Of course sometimes it /is/ necessary. This is is d.learn, and the how-to-get-class- -instance-address subthread could have pointed somebody into the wrong direction, that's all.

artur

On 12/2/12, 21:25, js.mdnq wrote:
> I'm not just comparing them but using them as a unique ID for the
> objects in an algorithm to prevent computing over the same object more
> than once.

o.toHash() ??

(Which incidentally just casts the reference to a hash_t, exactly what you want to do.)