www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - get address of object if opCast is overridden

reply "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?
Nov 30 2012
next sibling parent "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
Nov 30 2012
prev sibling next sibling parent reply 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
Dec 01 2012
parent "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.
Dec 01 2012
prev sibling next sibling parent reply 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
Dec 01 2012
parent reply 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
Dec 01 2012
next sibling parent 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
Dec 01 2012
prev sibling parent reply 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
Dec 01 2012
parent reply "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.
Dec 02 2012
next sibling parent 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
Dec 02 2012
prev sibling parent 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.)
Dec 25 2013
prev sibling parent 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
Dec 01 2012