[Ffmpeg-devel] Re: FFMPEG code a mess

[Dave Dodge]

On Mon, Sep 19, 2005 at 11:39:32PM +0200, Michael Niedermayer wrote:
> On Mon, Sep 19, 2005 at 05:56:37PM -0400, Dave Dodge wrote:
> > Lua has a single native numeric type, normally implemented as a C
> > double.  If you need something else, you can change it when you build
> 
> supporting only doubles has a flaw, 64 bit ints cant be converted to doubles
> without loosing the least significant bits

Like I said, good points and bad points.  There are plenty of bad
points, but for some projects the good points are good enough to
override them.

If you need to, you can change the numeric type with a single #define
in a header, which is something many people do (for example when using
Lua on an embedded system with no FPU).  I believe the core language
will adapt to whatever numeric C type you put there, however you could
run into trouble with some add-on libraries that make assumptions
about the type.

One thing to bear in mind about Lua is that making custom changes,
even to the core language itself, is a relatively normal practice.
Many projects that use Lua ship their own [possibly tweaked] copy of
the interpreter as part of their codebase.  Lua changes so much from
version to version that you can't really rely on the system having a
compatible version installed anyway.

> so IMHO if a language supports only one type it should be able to
> store at least 64bit ints and doubles with no loss of precission

Lua is geared to situations that mix C code and scripting code.  If
your C functions need special/precise types, the best solution is to
encapsulate them as "userdata" or "lightuserdata" while they're
passing through Lua.  Lua will treat them as mostly opaque values, but
your C code will be able to see them intact.  This is how I've handled
things like bitfields or 64-bit offsets in my own code.

                                                  -Dave Dodge