>> Alejandro Aguilar Sierra writes:
AAS> On Fri, 26 Mar 1999, Asger Alstrup Nielsen wrote:
>> The LString in the InsetChunk is private!
AAS> Then, as I suspected from the beginig, all the set of methods
AAS> from LString won't be used.
I really don't get your argument. Why are you against std::string?
Because it has too many methods that will not be used?
We gain absolutely nothings by writing our own container with just the
needed methods. And if you want to make some methods not available
make a wrapper (like wrap_string).
AAS> Let's analize the use cases of the chunk container to see what
AAS> is suitable:
AAS> 1- Editing, only iterator methods are needed.
AAS> 2. Rendering. It's more efficient that each chunk return a C
AAS> string than rendering in one char basis. Here btw appear our
AAS> already discussed problem of the 3 rectangle shape chunk, as
AAS> you called it (so in the worst case we would need one C string
AAS> per row.) Any container that can return a C string from its
AAS> contents is good in this case.
You mix buffer structure with screen structure. (LyXParagraph and LyXText)
AAS> 3. Writing. We never write a chunk directly to disk, currently
AAS> we're using an LString as writting buffer. Anyway sending a C
AAS> string instead of one char each time improves performance but
AAS> it's not much relevant since the slow process would be to write
AAS> directly on disc. Again any container able to return a C string
AAS> is ok.
AAS> 4. Reading. The parsing use to be in a char or word basis
AAS> anyway. If we get some way we can feed new chunks with entire C
AAS> strings, that would improve performance a bit, but again, we
AAS> are not reading directly from disc. Those strings would be
AAS> already in the parser buffer.
AAS> Am I forgetting anything?
perhaps not, but I don't see any of this as an argument for or against
using string in the InsetChunk.
Lgb
