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

[Christian Jullien]

Ok Rune, I give up :o)

However, I want to add that, by design and Bjarne especially insisted on
that while normalizing C++, that you pay only what you use. As such, C++ -
even C++14, is a "one size fits" all language.
You can perfectly well write C++ a programs without template, namespace,
exceptions, RTTI or any standard C++ lib and have NO performance penalty at
all compared to C. Without virtual methods, a class is just a POD.

This way, you can define your own C++ subset based on standard C++. 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.

In a sense, it is the same as if you were saying that, for simple things,
there is a need for K&R only C subset, for example not supporting prototypes
or const.

In order to not pollute this list, I'll probably stop to comment on this
thread.

Christian

P.S. This thread is however very interesting and be sure I'll read all posts
with a great attention.

-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of
address@hidden
Sent: samedi 16 mai 2015 11:14
To: address@hidden
Subject: Re: [Tinycc-devel] OT (Re: modern c++ compiler written in C)

On Sat, May 16, 2015 at 08:11:21AM +0200, Christian Jullien wrote:
> Sorry to insist

:) nice to see your devotion to the topic

> > cfront showed us a usable C++ dialect and also a proof that such a 
> > dialect
> can be efficiently implemented by a translator to C.
> 
> Nobody doubt it's true. Cfront has been the de facto standard for 
> years so it is clearly usable and you can do reasonable code with it. 
> However, I recalled it was a pain to use C++ at that time on big to 
> medium size project.

You are looking from a certain perspective. It is totally valid but not the
only valid one. E.g. my perspective as a casual C++ user and packager is
that I'd love cfront for the scale and the kind of development which I do.

I guess there exist more small scale projects than big and medium ones, so
why would we ignore them?

> > - would be useful, as a compact and extremely fast compiler  for a
> practical subset of C++
> 
> I've more trouble with this sentence. Useful for what these days?

See above.

> - to do some personal and simple work. Yes, but who wants to create a 
> program that don't compile with g++ (streams work differently now - 
> jus as an example).

Some things are certainly fixable, others may be tolerable.
Streams are easier than exceptions which you also mention.

> Do you really want to program without exceptions?

Yes, and there are reasons to.

> - do you really want to forget about nice C++ standard containers and 
> algorithms that greatly simplify your life these days? Are you happy 
> to

Not that I exactly feel that C++ brings a "great simplification" to my
projects, because both the language and the needed tools are complex and
hence in some way add complexity.

I do not pretend that my perspective is worth more than yours.
It is just that you would not use cfront but someone else would, for
different tasks than yours.

IOW, cfront or a similar subset would fill a niche where C is too limited,
modern C++ too complex/heavy and "C with classes" just right.

> Btw, if tcc compiles fast, it runs not so fast. If the Cfront and its 
> associated libraries are compiled with tcc, there is a chance that it 
> will be slower to compile than g++. When used with -O0 g++ is fast to 
> compile even on my Rasberry Pi using a SD card.

This does not make sense to discuss without actually testing and also
excluding the unrelated bottlenecks.

I doubt otherwise that compilation with tcc can make cfront _that_ much
slower ;D (kidding, I do not have the actual numbers at hand either)

> even it works no so bad, nobody will use it because of the LICENSE.

The license or the need for reimplementation stands of course in our way.
This first, any potential advantage then.

Regards,
Rune


_______________________________________________
Tinycc-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/tinycc-devel