|
From: | Stefano Zaglio |
Subject: | Re: [Tinycc-devel] Use tcc to make embedded just-in-time compile/interpreter |
Date: | Tue, 03 Jan 2012 21:18:23 +0100 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 |
I see one reason to avoid C as a scripting language: error handling. Most scripting A user which only gets a SIGSEGV on error may be frustrated.
After 20 years spent to learn and re-learn, write and re-write , how doing the same things with different p. language, I think that using experience to avoid some errors using C, is not so
expensive how we can immagine. Or are you saing that TCC cannot manage signal(SIGSEGV, my_signal_handler) ? and GDB cannot stop on line that has generated the signal? I remember an old Il 19/12/2011 07:24, Basile Starynkevitch ha scritto:
On Sun, 18 Dec 2011 22:01:32 +0100 Benoit Gschwind<address@hidden> wrote:On 17/12/2011 19:33, Basile Starynkevitch wrote:On Fri, 16 Dec 2011 14:31:31 +0100 Benoit Gschwind<address@hidden> wrote:Hello, I would like to create an embedded C interpreter/compiler.[...]Other have answered about libtcc.h, but why do you want the user to write code in C specifically (as opposed to some higher-level scripting language)?Why not? for performance, for lightness, for sport. Why use some new language when everything is ok with an existing good language?I see one reason to avoid C as a scripting language: error handling. Most scripting language gives you a toplevel loop and return to it on error, this is not so easily possible in C (unless the C is generated by your language implementation). A user which only gets a SIGSEGV on error may be frustrated. Cheers.
[Prev in Thread] | Current Thread | [Next in Thread] |