Hello,
I'm quite new to D (but I'm extremely enthusiastic about it :)
I have a few questions about portability in D and in general.


1. When do I have to use size_t and ptrdiff_t, what does this really mean, and why is is nessecary?
The portability guide in the D specs says this:
<quote>
# Use size_t as an alias for an unsigned integral type that can span the address space.
# Use ptrdiff_t as an alias for a signed integral type that can span the address space.
</quote>
I understand these sentences, but I don't understand what they actually _mean_.
Is ssize_t in C the same as ptrdiff_t in D?



2. When I have some C code like this:

    ssize_t write(int fd, const void *buf, size_t count);

could I write this in D like this:

    int write(int fd, const void[] buf);

and use the .length field of buf in stead of the extra count parameter, or is it a bad idea to assume that the programmer never wants to use a raw pointer when calling a low level function like this (it is a direct assembler wrapper for a linux system call)?



3. Can I assume that every D implementation will keep an int 32bit, a long 64bit, etc (unlike C)? And if not, how do these things usually get solved?
<quote>
Integral types will remain the same sizes between 32 and 64 bit code.
</quote>


4. Are there any other things I should keep in mind (that are not mentioned in the portability guide) to maximize code portability (not nesessarily limited to D)?


I am asking these questions because I think D has very interesting features concerning a nice, clean and elegant code base that can be compiled for a large set of systems, whereas C seems to be a disaster with it's ugly #ifdefs and the like. I'd like to check out these things some more.

Thanks for reading,
Kevin

In article <d4tokv$170g$1@digitaldaemon.com>, Kevin VR says...
>
>Hello,
>I'm quite new to D (but I'm extremely enthusiastic about it :)
>I have a few questions about portability in D and in general.

Welcome to D!

>
>
>1. When do I have to use size_t and ptrdiff_t, what does this really
>mean, and why is is nessecary?
>The portability guide in the D specs says this:
><quote>
># Use size_t as an alias for an unsigned integral type that can span the
>address space.
># Use ptrdiff_t as an alias for a signed integral type that can span the
>address space.
></quote>
>I understand these sentences, but I don't understand what they actually
>_mean_.
>Is ssize_t in C the same as ptrdiff_t in D?
>

I think the gist of size_t and ptrdiff_t in D is that they're 32-bits wide, with ptrdiff_t being signed.  This would make them identical to ssize_t in C, for the most part (compiler options and target platform not withstanding).

>2. When I have some C code like this:
>
>     ssize_t write(int fd, const void *buf, size_t count);
>
>could I write this in D like this:
>
>     int write(int fd, const void[] buf);
>
>and use the .length field of buf in stead of the extra count parameter, or is it a bad idea to assume that the programmer never wants to use a raw pointer when calling a low level function like this (it is a direct assembler wrapper for a linux system call)?

You're on the right track.  Its very common in D to use an array as a buffer anyway.  If a developer doesn't have their data in an array, they can cobble one together easily enough.

In my experience, when a D program has pointers and buffer lengths, usually its a symptom of integration wtih a C library.  Pure D programs almost never have that kind of code (thankfully).


>3. Can I assume that every D implementation will keep an int 32bit, a
>long 64bit, etc (unlike C)? And if not, how do these things usually get
>solved?
><quote>
>Integral types will remain the same sizes between 32 and 64 bit code.
></quote>

AFAIK, that's the idea.  No more INT or WORD #defines like in windows code.

>4. Are there any other things I should keep in mind (that are not mentioned in the portability guide) to maximize code portability (not nesessarily limited to D)?

Yes.  Read the documentation on dlls at least five times (not kidding).  They're a little tricky.  Also, familiarize yourself with the limitations to the version() statement, as this is the single most important D construct for porting code.

Other than that, you're down to the semantics of any given platform (Win32,
posix, etc).  Good luck.

- EricAnderton at yahoo

Hi,
Thanks for responding!
I think it's great the way you guys help eachother out!

pragma wrote:
> In article <d4tokv$170g$1@digitaldaemon.com>, Kevin VR says...
> 
>>Hello,
>>I'm quite new to D (but I'm extremely enthusiastic about it :)
>>I have a few questions about portability in D and in general.
> 
> 
> Welcome to D!
> 
> 
>>
>>1. When do I have to use size_t and ptrdiff_t, what does this really mean, and why is is nessecary?
>>The portability guide in the D specs says this:
>><quote>
>># Use size_t as an alias for an unsigned integral type that can span the address space.
>># Use ptrdiff_t as an alias for a signed integral type that can span the address space.
>></quote>
>>I understand these sentences, but I don't understand what they actually _mean_.
>>Is ssize_t in C the same as ptrdiff_t in D?
>>
> 
> 
> I think the gist of size_t and ptrdiff_t in D is that they're 32-bits wide, with
> ptrdiff_t being signed.  This would make them identical to ssize_t in C, for the
> most part (compiler options and target platform not withstanding).  

If they're 32bits, just like int and uint, how can I tell when to use size_t or ptrdiff_t in stead of uint and int, so that I won't break anything in the future?
Or to ask my question in a different way: how can I tell when my variable "can span the address space."

>>2. When I have some C code like this:
>>
>>    ssize_t write(int fd, const void *buf, size_t count);
>>
>>could I write this in D like this:
>>
>>    int write(int fd, const void[] buf);
>>
>>and use the .length field of buf in stead of the extra count parameter, or is it a bad idea to assume that the programmer never wants to use a raw pointer when calling a low level function like this (it is a direct assembler wrapper for a linux system call)?
> 
> 
> You're on the right track.  Its very common in D to use an array as a buffer
> anyway.  If a developer doesn't have their data in an array, they can cobble one
> together easily enough.
> 
> In my experience, when a D program has pointers and buffer lengths, usually its
> a symptom of integration wtih a C library.  Pure D programs almost never have
> that kind of code (thankfully).

I agree that it's a lot better the way D does it. That's why I was experimenting a little with writing my own D wrapper for the linux system calls.
I have only one concern: what if the programmer recieves some sort of stream of which he does not know the size in advance, and he has to count the number of incomming bytes on the fly (I'm just making this up, I'm not even sure if this is a realistic possibility).
Can D convert a raw datastream to an array without copying the entire buffer or some other sort of heavy overhead?

>>3. Can I assume that every D implementation will keep an int 32bit, a long 64bit, etc (unlike C)? And if not, how do these things usually get solved?
>><quote>
>>Integral types will remain the same sizes between 32 and 64 bit code.
>></quote>
> 
> 
> AFAIK, that's the idea.  No more INT or WORD #defines like in windows code.

That's nice :)

>>4. Are there any other things I should keep in mind (that are not mentioned in the portability guide) to maximize code portability (not nesessarily limited to D)?
> 
> 
> Yes.  Read the documentation on dlls at least five times (not kidding).  They're
> a little tricky.  Also, familiarize yourself with the limitations to the
> version() statement, as this is the single most important D construct for
> porting code.

The version() stuff looks very nice on paper. I wonder if it's as nice in practice too. Say for some heavy duty stuff, like something like glibc or kernel programming...

> Other than that, you're down to the semantics of any given platform (Win32,
> posix, etc).  Good luck.
> 
> - EricAnderton at yahoo