On Mon, 3 Apr 2000, Angus Leeming wrote:
> Illuminating, I think. We do indeed use raw_format.
>
> Allan, if we assume that raw_format will be removed from
> xtl at some stage, does that make life harder?
Not really. I wasn't planning on using raw_format forever. Only until
someone found time to make a text_format or xml_format that could be input
as well as output -- this would also be more easily read/written by
scripts and other LyXServer apps.
> Angus
>
> ---------- Forwarded Message ----------
> Subject: Re: Unaligned access errors running LyX with XTL
> Date: Mon, 03 Apr 2000 16:50:25 +0100
> From: Jose Orlando Pereira <[EMAIL PROTECTED]>
> > LyX uses it's own class lyxstring rather than the STL
> > string and its pretty certain that this is the root cause of
> > the problem. The current consensus is that with lyxstring,
> > the beginning of the string may not be aligned on 8-byte
> > boundaries. Is this likely to cause xtl problems? Any ideas
> > what we can do about it?
>
> I don't think so, unless it stores anyting other than single
> byte characters.
I agree with José. Lyxstring is not the culprit. The raw_format doesn't
do any alignments at all. So if a string is an unaligned length any
accesses to simple data types after it in the format will be unaligned.
I was looking at writing a small patch to test this theory but if José
wants to remove raw_format then we/I should probably concentrate to
writing a simple readable gui_format.
My plan at present is to use a xml-like format extended from the existing
text_format. Something like <int="123" string="a string"> and so on. I
know it be nice to have the name of the appropriate variable in place of
the data-type but it a heck of lot easier to write the data-type using xtl
in it current form. I could alternately overload the method simple(T*) to
be simple(string const & field_name, T*data) instead so we can pass the
name of the field for an xml-like output.
Allan. (ARRae)
