View mode: basic / threaded / horizontal-split · Log in · Help
April 29, 2005
portability questions
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
April 29, 2005
Re: portability questions
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
April 30, 2005
Re: portability questions
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
Top | Discussion index | About this forum | D home