Re: Suggestion: Lua 5.3 -- a facility for creating and manipulting Lua file handles (C API)

[steve donovan <steve.j.donovan@...>]

On Sat, Nov 16, 2013 at 9:32 AM, Sir Pogsalot <sir.pogsalot@gmail.com> wrote:
> I definitely need to get rid of all my abusive #defines, I've been forced to
> take C++ classes at my college and I'm sure it would look nicer if I make
> this a little more object-oriented and cleanly with inline functions.  When
> I wrote my project I was madly in love with C89 -- base denominator and all
> that. :]

I'm still very much into C89 (and C99 if I can safely get away with
it).  The good old principles of hiding tricky stuff in separate
compilation modules can keep the ugly #ifdefs in their own place,
otherwise the clear narrative flow of code gets interrupted. (And at
this level, a little extra function call is nothing compared to the
system call overhead).

As for C++: well, I'm not a fan of it for _infrastructure_ work -
there's always a penalty:

http://steved-imaginaryreal.blogspot.com/2013/10/c-some-consequences-of-design-decision.html

E.g. suddenly on Windows/mingw you have 100s of kbs of bloat just to
support the standard strings and iostreams. For MSVC, part of the
runtime, but then you have to ship that as well, and so forth.

It _is_ harder to write C as clear as C++, but I really do think it's
worth it, especially for Lua extensions. The more idiomatic the C++
is, the further away it is from the Lua API, requiring bridging or
even bulky automatic translation.  You lose the ability to use FFI to
directly call your own API.

And, absolutely, as Sean says earlier: abstractions leak.  In
particular, there is no unified way to integrate C and Lua IO across
5.1, 5.2 and LuaJIT.