Anton, In my life, I participated to different normalization process (C, C++, and most notably ISLISP). Here, I'm not saying that C is bad or good, I let committees decide and, as everybody you're welcome to participated. I'm saying that with the language we are using as it is currently normalized (C), very often (not to say all the time) you *must* take decision at compile time and this decision depends on many parameters (OS, processor architecture, word size, compiler vendor, compiler name...).
Since compilers evolve over versions, the bare minimum we need is a way to know version at compile time. It 'would be better to ..' does not apply and I don't want to discuss if it is better or worse in Rebol because I use C and your syntax is not currently defined by the standard. I'm just asking something that I can't currently achieve. Since we already have (__TINYC__ == 1) I don't see why it can't be instead the version number VVRRPP as (poorly defined if you like) with other implementations? Just another example (not the case with tcc): Sometimes my own ISLISP implementation must define a variable volatile with broken C optimizer. Tell me how I can achieve this today? #if defined(__TINYC__) && (__TINYC__ < 925) volatile int x = 0; #else int x 0; #endif Ok, I can leave without it. I can make my own configure script that parse tcc -v to get version then set -DTCC=925 in my makefile but, be honest, __TINYC__ = 925 is easier and does not depend on tcc -v output format. C. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Anton Rolls Sent: Saturday, May 23, 2009 20:05 To: [email protected] Subject: Re: Versioning (was Re: [Tinycc-devel] TCC 0.9.25 is out) Hi Christian, and I continue to partially disagree with you. :) Christian Jullien wrote: > I fully disagree with you because we often *must* make decision at compile > time. There's nothing wrong with needing that information, but I think the difficulty in handling version numbers points to a deficiency in C. Your solution (and the solution of most people) to this problem is to learn to speak computer, whereas the real solution (much harder to do) is to improve the language to support a natural representation of tuple values directly in C. In the Rebol language there is a tuple type which allows you to write tuples directly. Very handy. I can see C evolving to support this type without much problem. Eg. in C it might be nice to write: #define TCC_VERSION 0.9.25 and declare and initialise tuples in C like this: tuple my_version = 1.2.3; tuple your_version = 2.1.0; various operators would be defined to add, subtract, do comparisons < = > etc. To imagine your example using such a tuple type: #if defined(TINY_CC_VERSION) #if (TINY_CC_VERSION < 0.9.25) /* XXX feature was missing, use YYY instead but with ... */ #elif (TINY_CC_VERSION >= 0.9.26 || TINY_CC_VERSION <= 0.9.28) /* XXX was implemented but ... */ #else /* XXX is fixed for good */ #endif #else /* ANSI C default behaviour */ #endif I suppose, internally, tuples could just be stored as a fixed-length array of integers. The C operators would need to be defined so that tuples with different numbers of elements can still be compared etc. Anyway, just trying to point the finger at the real problem, while recognizing that the more pragmatic thing by far is, unfortunately, to continue with the old ways. :) Regards, Anton. _______________________________________________ Tinycc-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/tinycc-devel ---------------------------------------------------------------------------- ----------- Orange vous informe que cet e-mail a ete controle par l'anti-virus mail. Aucun virus connu a ce jour par nos services n'a ete detecte. _______________________________________________ Tinycc-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/tinycc-devel
