> Date: Sat, 16 May 2015 13:07:24 +0200 > From: [email protected] > To: Christian Jullien <[email protected]> > Cc: [email protected] > Subject: Re: [Tinycc-devel] OT (Re: modern c++ compiler written in C) > Message-ID: <[email protected]> > 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 <[email protected]> > To: [email protected] > Subject: Re: [Tinycc-devel] OT (Re: modern c++ compiler written in C) > Message-ID: > <cakg6wnzxa32lvrfbfk5xzfdk1ve+r8ar1g4zfqmcy+0i6zv...@mail.gmail.com> > 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. _______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
