[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] Extension to C language
From: |
Rob |
Subject: |
Re: [Tinycc-devel] Extension to C language |
Date: |
Fri, 1 Jun 2012 09:02:01 +0100 |
On 1 June 2012 06:33, Jared Maddox <address@hidden> wrote:
>> Date: Wed, 30 May 2012 05:53:04 +0000
>> From: Paulo Henrique Torrens <address@hidden>
>> To: <address@hidden>
>> Subject: Re: [Tinycc-devel] Extension to C language
>> Message-ID: <address@hidden>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>
>> No, they don't. C11's _Generic can be used... :)
>>
>
> To the best of my knowledge, C11's Generics are strictly a
> preprocessor feature.
It's handled by the compiler - the preprocessor can't parse types, nor
expressions.
> This is required in order to maintain compatibility with already
> existing C code & compilers, which expect specific function names to
> accept specific argument sets.
The compatibility is maintained by calling it _Generic - a keyword that
has been reserved since a previous standard.
> Generics could presumably make it easier to deal with the multiple
> argument sets required for overloading, but the overloading itself
> would inherently require either Decorated Names or Dynamic Dispatch,
> and I'm not certain that Dynamic Dispatch should be considered a valid
> way of implementing Operator Overloading in a low-level language like
> C. It's an implementation thing.
There is no need for decorated names, nor dynamic dispatch.
void myfunc_int( int i){ printf("%d\n", i); }
void myfunc_float(float f){ printf("%f\n", f); }
#define myfunc(arg) _Generic(arg, int: myfunc_int, float: myfunc_float)(arg)
It looks like a preprocessor feature because its main use is in a macro
definition, but the _Generic expression itself is parsed by the
compiler. The preprocessor replaces myfunc() with _Generic(...), which
the compiler then replaces with the correct function call, without name
decoration/dynamic dispatch.
> As separate extension thoughts:
>
> 1) is there a TCC Make? I haven't found any sign of one, but I might
> be overlooking it. If there isn't one then I might try my hand at
> implementing one. I'm thinking a max of 255 rules, max 255 variables
> (including the ones local to targets), max post-expansion command
> length of 255 characters (seeing a pattern?), and some GNUish 'if'
> statements. Thoughts? Would the -run switch for this need to switch to
> internal-only commands (in case of e.g. tcc-boot)?
Seems like an interesting idea, but would tcc make then tag on a call to
tcc -run? I don't see how this can offer advantages over the standard
make.
> 2) How about preprocessor extensions? I've thought about two types of
> loops (for code generation purposes, e.g. for switches):
Some of this seems like coming up with extensions for the sake of it.
They're decent ideas, I just think they should stay in the tcc-extended
branch or something.
Thanks,
Rob