View mode: basic / threaded / horizontal-split · Log in · Help
December 01, 2012
get address of object if opCast is overridden
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?
December 01, 2012
Re: get address of object if opCast is overridden
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
December 01, 2012
Re: get address of object if opCast is overridden
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
December 01, 2012
Re: get address of object if opCast is overridden
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.
December 01, 2012
Re: get address of object if opCast is overridden
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
December 01, 2012
Re: get address of object if opCast is overridden
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
December 01, 2012
Re: get address of object if opCast is overridden
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
December 01, 2012
Re: get address of object if opCast is overridden
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
December 02, 2012
Re: get address of object if opCast is overridden
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
December 02, 2012
Re: get address of object if opCast is overridden
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.
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home