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

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

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

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

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