tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Versioning (was Re: [Tinycc-devel] TCC 0.9.25 is out)


From: Anton Rolls
Subject: Re: Versioning (was Re: [Tinycc-devel] TCC 0.9.25 is out)
Date: Sun, 24 May 2009 04:04:58 +1000
User-agent: Thunderbird 2.0.0.6 (X11/20071008)

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]