RE: Bitflags

["John Passaniti" <jpass@...>]

> Sorry, can't pass up some snitty comments =)

Snit happens!

> Bit manipulation would seem to be, honestly,
> to be the complete counter-definition of "fluff".  
> Integers and bits, these are the fundamental 
> building blocks of, um, everything.

No, it depends on the application and how effectively one uses the
abstractions Lua provides.

According to www.lua.org/about.html, "Lua is a powerful light-weight
programming language designed for extending applications."  In the
applications I've used Lua in, the end users are writing high-level
scripts to control an embedded system.  If they are manipulating bits,
then I probably haven't done my job well-- I didn't provide a
sufficiently high-level abstraction for them to use!

> I kid, I kid.  Well, I don't kid really, but I jest.
> I respect Lua and the team, this is just something 
> that recently bit me in the ass trying to port some 
> C code to Lua, and the C code is rather performance 
> intensive and requires lots of bit manipulation.  
> Enough that this is a bottleneck.

Sounds like you're trying to jam a square C peg into a round Lua hole.
I'm currently looking at porting a layout manager that was originally
written in C to Lua.  Part of the C code (naturally) used bit
manipulation to represent attributes.  For example, an "attach this to
the top of the rendered area" had a value of 0x0001 and a "center this
item in the rendered area" attribute had a value of 0x0100.  Lots of bit
manipulation later, things get rendered nicely on a screen.

The most obvious way to port this to Lua would be to use the bitlib.
But that's not effectively using the abstractions that Lua provides.  In
Lua, using a table as a container for named attributes is more natural,
and that's what I'll be doing.  

My point is that when porting code between languages, one can simply
transliterate code to the target language or they can look at ways to
exploit the target language's abstractions and features.  I obviously
don't know the details of what code you're porting, but consider it.  Or
better yet, provide some examples to us.  At the minimum, you might get
someone here give you a new perspective in how to efficiently implement
the code in Lua.  Or, it might illustrate a hole that needs to be
plugged in Lua that the Lua authors might want to address.