digitalmars.D.learn - 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>
address space.
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
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> address space. 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
Kevin VR <azra pandora.be> 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...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."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> address space. 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).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?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).That's nice :)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.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...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 30 2005