tinycc-devel
[Top][All Lists]
Advanced

[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



reply via email to

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