D - Version
- marvin_at_slartibart.com (32/32) Nov 22 2003 Hi
- Walter (2/2) Nov 22 2003 You raise some good issues. Some of them are addressed by std.compiler, ...
Hi Currently the Versioning system is starting to get as messy as it's C counterpart it is supposed to replace (and improve uppon). The problem lies in naming conventions, and what versions are defined by various compilers (just two yeat, but there's no point assuming there won't be more). This might not be a big problem now as there is only one major compiler defining the standard, but as different people start writing new compilers with their own opinions on what to name things, it will get messy. A suggestion how to organize things: Create a "subgroup" for important system/compiler specific versions. These subrgoups can be exclusive, eg only one of the versions in that group might be set: system.compiler.DigitalMars //code is compiled by only one compiler system.endian.little //a system have either little or big endian system.platform.linux //we run (compile to run) on one platform This also makes it possible to make an "version( .. ) .. else" statement, but this goes on the "might be handy" list :) Other groups might have many versions set: system.features.InlineASM system.features.ASM_MMX system.features.ASM_SSE .etc How to differ exlusive groups from non-exclusive ones.. well.. we'll just have to trust the specification I guess. The current status is that "Others will be added as they make sense and new implementations appear" and says nothing of what they will be called. Besides new compilers will have it own set of versions set, making it a nightmare for people that write code that can compile on loads of platforms/compiler combinations. (This is what I call the "problem" with C. There's at least 5 different ways of checking (all exclusive for its compiler/platform combination) of just checking for little/big endian). - Marvin
Nov 22 2003
You raise some good issues. Some of them are addressed by std.compiler, and std.system.
Nov 22 2003