Re: SLB vs LuaBind

[Jose Luis Hidalgo <joseluis.hidalgo@...>]

Hi Liam,

On Fri, Jan 7, 2011 at 1:15 PM, liam mail <liam.list@googlemail.com> wrote:

> Jose profiling, looking at the generated assembly just the
> same techniques you would use on any other code; yet with the addition of
> only touching the Lua API when you must. I do use a simple speed comparison
> test[1] and there are more detailed results available[2]. Daniel Wallin did
> say that Luabind has a comparison test for other libraries yet IIRC due to
> dependancies he is unable to make it available.

Of course I know how to profile, but, as I said I'm still willing to
sacrifice speed for
legibility of the wrapped code, I just can't bare having to write
macros to do all the work.

> I have attempted to look at SLB a few times and some things put me off from
> even comparing it with OOLua, mostly the use of a dreaded singleton which I
> am not sure how it effects unrelated Lua states and see it will only close
> onexit.

I suppose you mean the SLB::Manager which used to be a Singleton, well that's no
true anymore, you can now instantiate any number of Manager, and
control which classes
are registered in which managers, thy act as a containers of the
registered classes.

>Then there is the unit tests which I like to consider as the
> documentation, if you do not mind I would like to suggest you rename the
> tests. For example as a none user of the library what actually is
> unit_00X.cpp (replace X with a number) testing, which script does it load?
> Maybe look at using a C++ or Lua testing framework,
> personally I like to see setup, operation, assert, teardown. OOLua did in
> the past did load external scripts and run tests yet it
> separated the code too much so instead it use strings for the Lua code to
> try and help ease the reading of the test units, although
> saying that I sometimes generate the Lua code which makes reading slightly
> harder.

You got the name wrong, and its use. The tests are script driven, from
the scripts
directory in tests/scripts. Each scripts loads one unit to test
(that's the reason to name
unit_00X.cpp) and performs several tests. Maybe is not as structured
as a given unit test framework, but that doesn't mean I'm doing it
wrong.

Anyway, I will take into consideration rename the unit_blha, to avoid
people thinking it's something wrong.

> Beo I could not disagree more. These "samples" should be the unit tests
> which get run all the time and are always correct. Do the SLB examples get
> run by Jose? I have no idea and they could be wrong which is much worse than
> having no examples, personally I do not think the Luabind samples or it's
> unit tests are anything to shout about.

The examples are run, and the tests passed, under linux (with
valgrind), mac os X, and windows, that's for sure.

JL.

-- 
  Jose L. Hidalgo Valiño (PpluX)
  ---- http://www.pplux.com ----