Re: C binding strategy

[Martijn van Buul <martijn.van.buul@...>]

On 8/14/2012 11:00 AM, Alex Queiroz wrote:
> Hallo,
>
> On Tue, Aug 14, 2012 at 10:52 AM, Martijn van Buul
> <martijn.van.buul@ellips.nl> wrote:
> > The overhead in terms of "amount of boilerplate code" is limited, the actual
> > *runtime* overhead is acceptable, but what causes some concern is memory
> > usage. The userdata only contains a refcounted pointer, irregardless of the
> > size of the data pointed at by that pointer. Simply put, the garbage
> > collection fails to realise that there is a difference between a "Point" and
> > an "Image", and only "sees" the memory burden of the pointer. It simply
> > doesn't realise that the memory footprint of a userdata may be bigger than
> > the size of the userdata itself, and when left to its own devices will
> > quickly cause memory to run out - even though the memory 'consumed' by the
> > lua state will remain low.
>
>       Have you tried using placement new for solving this?

That would change the semantics considerably - it would destroy the "You 
can easily transfer data from- and to a lua state without doing a full 
copy" property which is very important in our specific case. Also, the 
lifetime of an object would suddenly depend on lua's view of it, which 
is unacceptable as well. It may have been differently if we were writing 
something from scratch, but we're not.

Finally, it doesn't really fix the issue for non-POD. Consider a 
rudimentary Image class:

class Image
{
  public:
    Image( int pWidth, int pHeight, int pPitch)
       : mWidth(pWidth)
       , mHeight(pHeight)
       , mPitch(pPitch)
    {
      mData = new uchar[pPitch * pHeight];
    }

    ~Image()
    {
      delete[] mData;
    }

    // Assignment operator and copy constructor omitted for brevity

    uchar *mData;
    int mWidth;
    int mHeight;
    int mPitch;
};

placement new wouldn't fix the problem, as it wouldn't address the new[] 
in the constructor.

I suppose the underlying questions are "Do you have to deal with an 
existing codebase" and "Are you embedding an application into lua, or 
are you embedding lua into an application?". We're doing the latter.

For some background info: We're doing machine vision using a data flow 
paradigm, and lua can be one of the "operators". Using it that way, you 
end up with a hybrid between dataflow and procedural programming, which 
turns out to be quite powerful. One of my coworkers wrote an article for 
a Dutch hi-tech magazine a while ago. Google translate does a (barely) 
passeable job at translating it:

http://www.bits-chips.nl/nieuws/achtergrond/bekijk/artikel/dataflow-vereenvoudigt-maatwerk-in-fruit-sorteren.html

Google translate link: http://preview.tinyurl.com/bw3ffxt