>> 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 _REALLY_ like this philosophy. In my experience, the time spent in C
functions far out weigh the time spent transitioning through the
Lua/C-API. There's also a lot to be said for simplicity/readability:
at the very least, agility. For example, SLB has been ported to 5.2; I
don't know of any efforts to port luabind to 5.2.
>> 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.
Something may have been misunderstood here. My comment was in
reference to documentation, not unit-testing. I.e., there's a general
concern that SLB lacks documentation -- and in my experience, that's
not a big deal -- a few sample code snippets here & there is more than
enough to figure out what's going on.
Cheers!
