www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Are class references pointers?

reply Sean Kelly <sean f4.ca> writes:
Currently, they clearly are.  But I can't find anything in the spec that
guarantees this.  Basically, I want to be able to store class references in
thread local storage and I need to know how to do this portably.  If the
pertinent C function has this calling convention:

pthread_setspecific(pthread_key_t key, const void *value);

Will it always be legal to call it like so?

class MyClass {}
pthread_key_t key;
pthread_key_create( &key );
pthread_setspecific( key, new MyClass() );

Obviously, I don't want to use an extra indirection if it's unnecessary.


Sean
Sep 14 2005
parent reply pragma <pragma_member pathlink.com> writes:
In article <dg9ofl$1l81$1 digitaldaemon.com>, Sean Kelly says...

Currently, they clearly are.  But I can't find anything in the spec that
guarantees this.  Basically, I want to be able to store class references in
thread local storage and I need to know how to do this portably.  If the
pertinent C function has this calling convention:

pthread_setspecific(pthread_key_t key, const void *value);

Will it always be legal to call it like so?

class MyClass {}
pthread_key_t key;
pthread_key_create( &key );
pthread_setspecific( key, new MyClass() );

Obviously, I don't want to use an extra indirection if it's unnecessary.


As far as I know know, you should be fine by doing this.  Aside from problems
with D moving into 64-bit territory, I can't think of a reason why this
shouldn't port.  The most "exotic" platform that D supports is G4/G5 Apples and
they're fully 32-bit machines, so "void*" should be the same there as on X86.

The only problem I can spot is with premature collection of references since
you're passing a D reference to a C-level library... unless you have a
GC-visible way to track eveything that winds up in TLS, at which point you're
okay (at which point you may as well implement your own TLS scheme in D).

- EricAnderton at yahoo
Sep 14 2005
parent reply Sean Kelly <sean f4.ca> writes:
In article <dg9rg0$1poj$1 digitaldaemon.com>, pragma says...

The only problem I can spot is with premature collection of references since
you're passing a D reference to a C-level library... unless you have a
GC-visible way to track eveything that winds up in TLS, at which point you're
okay (at which point you may as well implement your own TLS scheme in D).


Not an issue in this case, but noted :)  I just wanted to make sure some D
compiler couldn't implement D references using a structure larger than
sizeof(void*) (perhaps a pointer plus a reference counter?).  Since D class
handles have no pointer qualifier, it wouldn't violate the spec to do this so
far as I can tell.


Sean
Sep 14 2005
parent reply pragma <EricAnderton youknowthedrill.yahoo> writes:
Sean Kelly wrote:

 In article <dg9rg0$1poj$1 digitaldaemon.com>, pragma says...
 

The only problem I can spot is with premature collection of references since
you're passing a D reference to a C-level library... unless you have a
GC-visible way to track eveything that winds up in TLS, at which point you're
okay (at which point you may as well implement your own TLS scheme in D).


 
 
 Not an issue in this case, but noted :)  I just wanted to make sure some D
 compiler couldn't implement D references using a structure larger than
 sizeof(void*) (perhaps a pointer plus a reference counter?).  Since D class
 handles have no pointer qualifier, it wouldn't violate the spec to do this so
 far as I can tell.


::sigh:: I guess we'll get to throw that on the heap of reasons why the 
(de-facto) ABI needs to be documented, even if D is yet incomplete.

If you look at src\phobos\interal\cast.d, there are all kinds of places 
that objects are directly cast to void*, maniupated and cast back to 
Object again (_d_dynamic_cast).  Granted, it doesn't guarantee that the 
spec won't change, but it at least guarantees that you're not doing 
anything that phobos isn't... which is about as standard as you get.

-- 
- EricAnderton at yahoo
Sep 14 2005
parent Sean Kelly <sean f4.ca> writes:
In article <dgacrm$2cbp$1 digitaldaemon.com>, pragma says...

Sean Kelly wrote:

 In article <dg9rg0$1poj$1 digitaldaemon.com>, pragma says...
 

The only problem I can spot is with premature collection of references since
you're passing a D reference to a C-level library... unless you have a
GC-visible way to track eveything that winds up in TLS, at which point you're
okay (at which point you may as well implement your own TLS scheme in D).


 
 Not an issue in this case, but noted :)  I just wanted to make sure some D
 compiler couldn't implement D references using a structure larger than
 sizeof(void*) (perhaps a pointer plus a reference counter?).  Since D class
 handles have no pointer qualifier, it wouldn't violate the spec to do this so
 far as I can tell.


::sigh:: I guess we'll get to throw that on the heap of reasons why the 
(de-facto) ABI needs to be documented, even if D is yet incomplete.


Well, classes could always be changed to match the static/pointer semantics of
all other types in D.  Then the spec would cover this issue as-is ;-).


If you look at src\phobos\interal\cast.d, there are all kinds of places 
that objects are directly cast to void*, maniupated and cast back to 
Object again (_d_dynamic_cast).  Granted, it doesn't guarantee that the 
spec won't change, but it at least guarantees that you're not doing 
anything that phobos isn't... which is about as standard as you get.


True enough.  I just try not to take chances when the code would break silently
if I'm wrong.  As classes violate the otherwise standard pointer semantics in D
(as I mentioned above), I wanted to make sure this wasn't done with the express
purpose of allowing class handles to be something other than pointers.


Sean
Sep 15 2005