lua-users home
lua-l archive

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


lhf wrote:
> But this is simpler, and does not affect the code, because lua.h is always
> included after the standard headers and before all Lua internal headers
> (this is on purpose, so that you can add/change things in lua.h and
> they'll affect only Lua code).
>
> diff -r lua/include/lua.h lua-int/include/lua.h
> 17a18,19
> > #define double long

The issue I have with this method is that I can't verify it (short of wading
through preprocessor output).  If some header is in the wrong order or
omitted then you end up with the wrong types.

Another type issue I have with the Lua implementation is indiscriminate use
of explicit longs (as oppesed to lint32, Instruction etc).  The "int" type
in C is meant to be the reasonably efficient word size for holding an
integer on a given platform.  long's should only be used when there is good
reason (such as a specific word size or max value is required) and only then
indirectly through typedefs (int32, bigint, etc) so that they can be easily
changed as needed for other platforms. (Fortunatly C99 will be giving us
some standard typedefs for this purpose in the future.)

The platform I work on has 64 bit longs, and by replacing all longs with
ints in the Lua implementation I got a 5x speedup in my app.  (Oddly
changing the Instruction size alone had no speed benefit... I didn't have
time to investigate exactly where the 5x came from... possibly
string-related functions.)  Of course this may be saying more about the
sickness of my platform than any problem with Lua, but the point is that
having type control comes in handy.

I have modified Lua to give me control of the Lua number type and "longs",
but it's an awful lot of modified lines to maintain (as I found out when I
merged 4.0 final).

As Reuben requested I hope the type issues can be cleared up in the future.

Regards,
-John