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: Christian Jullien
Subject: RE: Versioning (was Re: [Tinycc-devel] TCC 0.9.25 is out)
Date: Sat, 23 May 2009 21:05:10 +0200

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: address@hidden
[mailto:address@hidden On Behalf Of
Anton Rolls
Sent: Saturday, May 23, 2009 20:05
To: address@hidden
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
address@hidden
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.









reply via email to

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