Am 16.02.2011 00:03, schrieb spir: > On 02/15/2011 10:40 PM, Daniel Gibson wrote: >> In general I think that you just have to define how you serialize data to >> disk/net/whatever (what endianess, what exact types) and you won't have >> problems. Just dumping the data to disk isn't portable anyway. > > How do you, in general, cope with the issue that, when using machine-size > types, > programs or (program+data) combinations will work on some machines and not on > others? This disturbs me a lot. I prefere having a constant field of > applicability, even if artificially reduced for some set of machines. > Similar reflexion about "infinite"-size numbers. >
I'm not sure I understand your question correctly.. 1. You can't always deal with it, there may always be platforms (e.g. 16bit platforms) that just can't execute your code and can't handle your types. 2. When handling data that is exchanged between programs (that may run on different platforms) you just have to agree on a format for that data. You could for example serialize it to XML or JSON or use a binary protocol that defines exactly what types (what size, what endianess, what encoding) are used and how. You can then decide for your applications data things like "this array will *never* exceed 65k elements, so I can store it's size as ushort" and so on. You should enforce these constraints on all platforms, of course (e.g. assert(arr.length <= ushort.max); ) This also means that you can decide that you'll never have any arrays longer than uint.max so they can be read and written on any platform - you just need to make sure that, when reading it from disk/net/..., you read the length in the right format (analog for writing). Or would you prefer D to behave like a 32bit language on any platforms? That means arrays *never* have more than uint.max elements etc? Such constraints are not acceptable for a system programming language. (The alternative - using ulong for array indexes on 32bit platforms - is unacceptable as well because it'd slow thing down to much). > Note this is different from using machine-size (unsigned) integers on the > implementation side, for implementation reasons. This could be done, I guess, > without having language-side issues. Meaning int, for instance, could be on > the > implementation side the same thing as long on 64-bit machine, but still be > semantically limited to 32-bit; so that the code works the same way on all > machines. > > Denis Cheers, - Daniel
