tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Tinycc-devel] Re: Tinycc-devel Digest, Vol 85, Issue 7


From: Jared Maddox
Subject: [Tinycc-devel] Re: Tinycc-devel Digest, Vol 85, Issue 7
Date: Sat, 22 May 2010 22:03:57 -0500

Sorry for the late reply, I don't read e-mail a lot.

On Monday 10 May 2010 10:40:21 mobi phil
>> On Saturday 08 May 2010 17:05:32 mobi phil wrote:
>>> Hello,
>>>
>>> the most useless question on this list:
>>> did anybody think about adding basic C++ extensions to tcc, eventually
>>> trivial form of templates?
>
>> tcc misses at least one thing for C++: exception handling. I plan to
>> implement it but I won't start the implementation before mid june so
>> don't be too in a hurry. :)
>
> I presume setjmp/longjmp, isn't it? Hm... and unwinding, calling
> destructors... indeed.. bit of work :)

[snipped]

> for from me to define your schedule :), but in my opinion, the
> following would be the priority list:
>
> 1. class + inheritance
> 2. template
> 3. operators
> 4. exceptions
> 5. lambda !! :)
>
> I think exceptions are not the the most important things, as they
> can be simulated with macros. (well you need sthg like endtry macro
> after the exceptions). Based on my experience templates are of higher
> added value, than operators. Calling convention: would not work with
> what is already there? It is not strictly necessary, at least at the
> begining to be binary compatible with libraries, etc. or?
>
> rgrds,
> mobi phil

I disagree. I consider the appropriate order to be:

1. Exceptions
2. Classes + Inheritance
3. Templates
4. Operators
5. Lambda (by way of Local Classes or whatever those are)

The reason for Exceptions to be moved so far up the list is that
they're one of the more inconvenient issues, and yet can be easily
implemented with standard C, by writing a library using
setjmp/longjmp, as you mentioned.

However, all of this should be done as a pre-processor, and none of it
as a proper compiler. I would personally love to be able to compile
C++ with TCC, and I would love one extra feature for TCC (the revival
of the old, discarded 'entry' keyword), but even I think that TCC
shouldn't DIRECTLY implement C++.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]