• js.mdnq (13/13) Nov 30 2012 Let O be an object with opCast overridden, then
• Jonathan M Davis (7/25) Nov 30 2012 For the moment, you're probably screwed. Certainly, if you overload opCa...
• Artur Skawina (3/30) Dec 01 2012 *cast(void**)&O // assuming O is a class
• js.mdnq (3/40) Dec 01 2012 Duh! I should have been able to think of that ;/
• Jonathan M Davis (5/9) Dec 01 2012 Are you sure? I'd be _very_ wary of that, because references aren't the ...
• Timon Gehr (4/13) Dec 01 2012 Certainly works now. Another workaround that would keep working if class...
• Jonathan M Davis (4/23) Dec 01 2012 Ah, good point. Using Object would work just fine and doesn't rely on th...
• Artur Skawina (10/33) Dec 01 2012 References not appearing as if they were pointers is less likely than Ob...
• js.mdnq (4/47) Dec 02 2012 I'm not just comparing them but using them as a unique ID for the
• Artur Skawina (14/54) Dec 02 2012 int[typeof(O)] rc;
• Lionello Lunesu (4/7) Dec 25 2013 o.toHash() ??
• Jonathan M Davis (4/6) Dec 01 2012 Is that all that was being done? I obviously missed that one way or anot...

"js.mdnq" <js_adddot+mdng gmail.com> writes:

Let O be an object with opCast overridden, then


writeln(O); //prints string
writeln(cast(void *)O)) // error, works fine if I comment out the 
opCast override
writeln(&O) // address of pointer to O, not what I want.

I want to compare a few objects based on their location. (I know 
this is bad because of the GC, but I will probably pin them if I 
go this route)

It seems I have a difficult time getting the original behavior 
when something is syntactically overridden in D. I understand the 
point of cast(void *) not working when opCast is overridden but I 
then do not know how to still get the address.

Any Ideas?

"Jonathan M Davis" <jmdavisProg gmx.com> writes:

On Saturday, December 01, 2012 03:05:00 js.mdnq wrote:
 Let O be an object with opCast overridden, then
 
 
 writeln(O); //prints string
 writeln(cast(void *)O)) // error, works fine if I comment out the
 opCast override
 writeln(&O) // address of pointer to O, not what I want.
 
 I want to compare a few objects based on their location. (I know
 this is bad because of the GC, but I will probably pin them if I
 go this route)
 
 It seems I have a difficult time getting the original behavior
 when something is syntactically overridden in D. I understand the
 point of cast(void *) not working when opCast is overridden but I
 then do not know how to still get the address.
 
 Any Ideas?

For the moment, you're probably screwed. Certainly, if you overload opCast, 
then none of the normal casts work any more, which is a definite bug:

http://d.puremagic.com/issues/show_bug.cgi?id=5747

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.

- Jonathan M Davis

Artur Skawina <art.08.09 gmail.com> writes:

On 12/01/12 03:48, Jonathan M Davis wrote:
 On Saturday, December 01, 2012 03:05:00 js.mdnq wrote:
 Let O be an object with opCast overridden, then


 writeln(O); //prints string
 writeln(cast(void *)O)) // error, works fine if I comment out the
 opCast override
 writeln(&O) // address of pointer to O, not what I want.

 I want to compare a few objects based on their location. (I know
 this is bad because of the GC, but I will probably pin them if I
 go this route)

 It seems I have a difficult time getting the original behavior
 when something is syntactically overridden in D. I understand the
 point of cast(void *) not working when opCast is overridden but I
 then do not know how to still get the address.

 Any Ideas?

 
 For the moment, you're probably screwed. Certainly, if you overload opCast, 
 then none of the normal casts work any more, which is a definite bug:
 
 http://d.puremagic.com/issues/show_bug.cgi?id=5747
 
 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

artur

"js.mdnq" <js_adddot+mdng gmail.com> writes:

On Saturday, 1 December 2012 at 11:06:02 UTC, Artur Skawina wrote:
 On 12/01/12 03:48, Jonathan M Davis wrote:
 On Saturday, December 01, 2012 03:05:00 js.mdnq wrote:
 Let O be an object with opCast overridden, then


 writeln(O); //prints string
 writeln(cast(void *)O)) // error, works fine if I comment out 
 the
 opCast override
 writeln(&O) // address of pointer to O, not what I want.

 I want to compare a few objects based on their location. (I 
 know
 this is bad because of the GC, but I will probably pin them 
 if I
 go this route)

 It seems I have a difficult time getting the original behavior
 when something is syntactically overridden in D. I understand 
 the
 point of cast(void *) not working when opCast is overridden 
 but I
 then do not know how to still get the address.

 Any Ideas?

 
 For the moment, you're probably screwed. Certainly, if you 
 overload opCast, then none of the normal casts work any more, 
 which is a definite bug:
 
 http://d.puremagic.com/issues/show_bug.cgi?id=5747
 
 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

 artur

Duh! I should have been able to think of that ;/

Thanks.

Jonathan M Davis <jmdavisProg gmx.com> writes:

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

Timon Gehr <timon.gehr gmx.ch> writes:

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

Jonathan M Davis <jmdavisProg gmx.com> writes:

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.

- Jonathan M Davis

Artur Skawina <art.08.09 gmail.com> writes:

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.

artur

"js.mdnq" <js_adddot+mdng gmail.com> writes:

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.

 artur

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.

Artur Skawina <art.08.09 gmail.com> writes:

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

Lionello Lunesu <lionello lunesu.remove.com> writes:

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.)

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Sunday, December 02, 2012 00:57:14 Artur Skawina wrote:
 Seriously though, if one only needs to compare the addresses of class
 objects, "is" may be a better solution.

Is that all that was being done? I obviously missed that one way or another. 
Yeah, that's what the is operator is for.

- Jonathan M Davis