Re: [Tinycc-devel] OT (Re: modern c++ compiler written in C)

[Jared Maddox]

> Date: Sat, 16 May 2015 13:07:24 +0200
> From: address@hidden
> To: Christian Jullien <address@hidden>
> Cc: address@hidden
> Subject: Re: [Tinycc-devel] OT (Re:  modern c++ compiler written in C)
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> [Continuing on this thread which seems somewhat relevant to tcc even
> though the lanugage discussed is not what tcc implements.]
>
> On Sat, May 16, 2015 at 11:49:57AM +0200, Christian Jullien wrote:
>> What
>> especially annoys me with CFront is that it implements a pre-ISO C++.
>> There is chance that, sooner than later, your program will compile
>> and/or behave correctly only if compiled by CFront.
>
> Agreed, that's bad, the implemented dialect should be ideally a
> strict subset of the standard (unfortunately the standards are also a
> moving target).

I believe that classes (not certain of the level of inheritance),
virtual functions, RTTI, constructors+destructors, and exceptions
would cover most "minimal" use cases.

Note that for exceptions you basically just need type information
(which can be useful anyways), somewhere to store the data (this
really calls for thread-specific memory support: did that get
implemented yet?), and a way to unwind the stack: setjump()/longjmp()
are the stereo-typical way. You can also implement it without library
support by embedding support into the code (place two jumps after each
C++ call: the first jumps over the second, the second jumps to
exception-handling code, throw() stores data and modifies the return
pointer to go to the second jump instead of the first; if you feel
like it you can even implement stack resumption).

Templates are certainly somewhat convenient, but when you get down to
it they're a poorly designed code generation system that has grossly
distorted the language: most of C++'s design problems could likely be
fixed by scraping the old syntax & semantics for a new variant (which
obviously isn't going to happen).

For cases willing to accept non-standard libraries the standard
containers shouldn't be much of a problem: Sglib shows that the C
preprocessor should be capable of handling the container case. A way
to run code at compile time + a small set of code-generation tools
(e.g. improved C string or "rope" functions, generic tree data
structures like in Sglib, probably some other stuff, just so that it
wouldn't need to be reimplemented every time) would be enough to
handle more complex needs. It just needs to provide a rough
approximation of the capabilities of templates, which shouldn't be
THAT difficult.


> On the positive side, a free license for the compiler
> would make is highly probable that one could always compile
> a program by cfront or whatever.
>

Depends on adoption. Gnu-isms are apparently fairly common in
open-source C and Makefile code. Still, the features are certainly
in-demand, so if you build it, someone should come.



> Date: Sat, 16 May 2015 17:20:57 +0300
> From: Sergey Korshunoff <address@hidden>
> To: address@hidden
> Subject: Re: [Tinycc-devel] OT (Re: modern c++ compiler written in C)
> Message-ID:
>         <address@hidden>
> Content-Type: text/plain; charset=UTF-8
>

> PS: there are many good compilers (languages) which compiles to plain
> c. But not having such for c++ is not so good.
>

Such compilers DO exist, you just usually have to pay for them.