Re: xtl, LyX and a small patch

[Allan Rae <allan.rae@mailbox.uq.edu.au>]

On Wed, 15 Mar 2000, Jose Orlando Pereira wrote:

> Allan Rae wrote:
> > Additionally, I want to pass a memory buffer as a char *.  That way we can
> > use the same function to handle inputs from scripts and other external
> > applications.  It seems I should be able to externalize the
> > mem_buffer<raw_format> variable to get a buffer I can recreate at the
> > other end when it's internalized.  This however complicates the work that
> > script writers would have to do since they don't have the benefit of xtl.
> > I was thinking of just directly modifying the buf[] before passing it as a
> > parameter to our function-dispatcher but this is ugly and format
> > dependent.
> > 
> > Instead, I was considering making an automem_buffer<>::c_str() function
> > that would prepend the buffer size to the buffer and return it as a char*.
> > This is potentially leaky but then so is using an ordinary mem_buffer<> in
> > this way (passing a char* as an arguement).
> 
> I dont't know if I completely understood you. The mem_buffer is not supposed
> to be an encapsulated data container. It is designed as an adapter between XTL 
> and a char*. After outputing some data using a mem_buffer you're supposed to
> directly use the char* you have previously supplied. At the other end, just
> create a new mem_buffer with the same data and the size obtained from the
> first mem_buffer. mem_buffers are not intended to be reused and the space
> is assumed to be managed elsewhere.

What I'm trying to avoid is the need to pass the size of the buffer
(char*) separately by suggesting an automem_buffer<> add the size as the
first element of the array.  This introduces its own problems of course.
Hmmm... I think I should probably just use a default arguement for the
size of the array which would allow me to keep the same signature for the
pre-existing function I'm trying to extend to also use xtl.

> If you see automem_buffer as an encapsulated container it makes perfect
> sense to have something like automem_buffer<>::c_str(). Even if 
> automem_buffer is not encapsulated but a smart adapter to an iovec,
> it would also be nice to provide a simple way to flatten it.

This is closer to what I had in mind.

Allan. (ARRae)