Re: [Tinycc-devel] Extension to C language

[Jared Maddox]

> Date: Tue, 29 May 2012 07:10:58 +0000
> From: Paulo Henrique Torrens <address@hidden>
> To: <address@hidden>
> Subject: Re: [Tinycc-devel] Extension to C language
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
>> An extended TCC (eTCC) compiler might be nice (some people have> suggested
>> adding some sort of support for objects, which combined with> your tracked
>> structures would be similar to Vala, and I myself intend> to finish a pet
>> language & add an interface to TCC once I finish> debugging my tree
>> implementation...), but such a project should be> separate from the TCC C
>> compiler in the same way that the TCC> assembler is.
> The TCC assembler is? :s
>

Yes, it is, TCC's C compiler doesn't use the assembler, it compiles
directly to byte code. Similarly, the assembler doesn't use the C
compiler. They're both contained inside the same executable, but
that's a different matter.


> Date: Tue, 29 May 2012 05:25:07 -0400
> From: "Rick C. Hodgin" <address@hidden>
> To: address@hidden
> Subject: Re: [Tinycc-devel] Extension to C language
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> All,
>
> I had mentioned a while back wanting to add the class to TCC, creating
> essentially a very simple C++ extension to TCC.
>
> Maybe it's time to introduce an official fork of TCC which is maintained
> alongside TCC, but with these other extensions added.
>
> TCCX could accommodate extensions to the base TinyCC by introducing some
> simple C/C++ extensions (I am literally only interested in adding the
> class, no inheritance, no polymorphism, but a simple one-layer class to
> be used for encapsulation). Additions like the ones in this thread might
> be very desirable.
>
> TCCX? Anybody have any thoughts?
>
> Best regards,
> Rick C. Hodgin

I don't think it would necessarily need to be completely separate from
TCC, nor a complete fork. I think that having a "Extended C" directory
+ a few patches for individual TCC-proper files is all that would
actually be needed

 And that's assuming that Grishka/Thomas/etc. want such a thing
definitively outside of the main TCC project. Grishka/Thomas, what
expectations do you guys have on that front?

Alternatively, it could simply use the library-form, in which case
inside or outside of TCC doesn't matter to the same extent.


> Date: Tue, 29 May 2012 08:32:10 -0400
> From: "Rick C. Hodgin" <address@hidden>
> To: Christian JULLIEN <address@hidden>, address@hidden
> Subject: Re: [Tinycc-devel] RE :Re:  Extension to C language
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=utf-8
>
> I believe the class mandates new, delete and I agree with overloading. Would
> like to completely bypass decorated names, however. :-P
>
> Best regards,
> Rick C. Hodgin
>

Overloading requires decorated names, it's a both/neither type of
thing.  You can use dynamic dispatch INSTEAD of overloading, but that
has it's own downsides (if you want to keep the C function abi, then
you have to add some sort of type identifier info... such as
printf-style format strings, or additional arguments for type-info
pointers), though admittedly member-functions would realistically need
to add an argument for the object pointer anyways, so extra arguments
would practically be assured. Also, dynamic dispatch has some run-time
overhead whenever those functions are used.

At any rate, I've been working on a type-info system for my own
language, so I can donate that (be warned that utility type-comparison
functions still need a working tree implementation, which I haven't
finished). It has built-in support for basic types, structures/unions,
and I was planning to add some pointers for standard functions (such
as copy, move, & destruct) so adding them for this isn't an issue.

Incidentally, if you actually go for the objects, I would argue
against strict C++ style (even if a reduced subset). Better that you
do something that can be duplicated in pure C and doesn't have as much
mess, especially since then interfacing to it from C++ would just
involve wrappers (regardless of C++ compiler).