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: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: samedi 16 mai 2015 11:14 To: [email protected] 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 [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel _______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
