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

[u-tcc-uepj]

On Tue, Nov 03, 2015 at 09:16:01AM +0100, Christian JULLIEN wrote:
> Hum, sorry I still don't understand quite well your exact motivation with 
> Cfront.

I think you put it down quite nicely. There are different motivations
and some of them can be valid for different people, to different degrees.

> motivation-1) POC to make Cfront usable with TCC toolchain.
> - A funny toy project. Change Cfront so that it compiles with TCC *and 
> possibliy* change CFront C code generator so that unmodified TCC can compile 
> and run Cfront valid programs (nowhere here I use C++ term or I speak about 
> speed)
> 
> motivation-2) produce the world fastest CFront compiler ever.
>  - change Cfront so that it compiles with gcc -O3  *and possibliy* 
> change 
> CFront C code generator so that unmodified TCC can compile and run 
> Cfront valid programs (nowhere here I use C++ term). For sure, this is the 
> fastest way to produce Cfront programs that execute something.
> 
> motivation-3) have an object oriented C extension on top of TCC
> - Cfront is an object oriented C extension which allows a kind of OOP 
> programming (sometimes very close to ISO C++). Btw why do you need this as, 
> due to license limitation, you will not be able to ship anything unless you 
> limit yourself to the common subset of both 'modern c++' and Cfront, even 
> stream ios are different.
> 
> motivation-4) have a modern c++ compiler written in C.
> - Cfront is definitely not a modern c++, it will take age to make it c++ 
> compliant, even with C++98

> other motivation?

As for (m-3), this still can be useful. As I wrote earlier, I like and
depend on a couple of projects written in C++ (Coda and FLTK) which seem
to still be compatible with Cfront.

It would defintitely save a lot of time and probably also expose/fix
some extra bugs, if I could use cfront for rebuilds.

(As you also noted, the license can not stop anyone from doing historic
research by developing any project with cfront, as long as you use some
other compiler for production builds. I assume if AT&T would remember
about cfront existence and become concerned, they would be rather
motivated to relax the license and gain goodwill than to litigate)

For new projects this could also be a nice tool, if the project
would be willing to consequently use the "Cfront C++ subset".
Of course this is a matter of taste but it looks to me like a usable
OOP language. The full modern C++ is much more heavyweight.

[For clarity: I am motivated enough to comment on, but not enough
to contribute to Subj.]

Regards,
Rune