Date: Fri, 1 Jun 2012 09:02:01 +0100
From: Rob robpill...@gmail.com
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Extension to C language
Message-ID:
CAPQ98VU=c+ugcorsgf43vcozsvycfannbao_u7ugm3zzler...@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
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.
No, I was talking about functions their names, not _Generic. I
consider _Generic to only be a mechanism in this case, rather than a
subject in it's own right.
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.
Okay... except that I consider myfunc)_int and myfunc_float in this
case to be decorated names for myfunc. Decorated names are simply
names that have a little extra bit tacked on to differentiate
otherwise identical names from each other.
Looking back though, was this about Operator Overloading the entire
time? For some reason I thought it was a discussion of more generic
Function overloading. What I've said about overloading requiring
either decorated names or dynamic dispatch still holds for that,
though. And if Operator Overloading is implemented with functions,
then it applies to that by extension. You can't have overloaded
functions in C without adding something (either name decoration, or
dynamic dispatch, or something equivalent), because the C language
simply does not provide the facilities for Function Overloading on
it's own.
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?
Huh? What are you trying to say? Are you referring to a problem with
the number of arguments you can pass in a sha-bang? Because that could
plausibly be solved with a -runmake flag.
I don't see how this can offer advantages over the standard
make.
I'm thinking specifically of the old compile-linux-at-boot-time
gimmick. I think it (and anything similar) would probably be easier to
support with a build-system actually built into TCC. Also, given that
make is so ubiquitous within compiler systems that even Microsoft
provides a version (seriously, they do, go look it up), it really does
seem to me that it makes sense for TCC as well. Make is essentially a
standard compile tool.
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.
Actually, I thought of the two preprocessor loops maybe a year (or
more) ago, I just haven't bothered to try implementing them. The
design has some specific reasons behind it: the reason why there
weren't loops in the preprocessor in the first place was to avoid the
risk of infinite loops, which these two are designed to also avoid.
Is there currently a tcc-extended branch? I didn't notice one on the
git repo yesterday.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
