www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - portability questions

reply Kevin VR <azra pandora.be> writes:
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
Apr 29 2005
parent reply pragma <pragma_member pathlink.com> writes:
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
Apr 29 2005
parent Kevin VR <azra pandora.be> writes:
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

Apr 30 2005