I've managed to compile the new and improved rae branch.
(Ie, including Allan's patch arrae-20000331.patch.gz, see
http://www.mail-archive.com/[email protected]/msg10122.html)

On the DEC Alpha running Digital Unix 3.2, compiled using
egcs-1.1.2/GNU STL:

with lyxstring: code compiles perfectly. Print dialog still
produces unaligned access errors, but the dialog now
prints. Congratulations, Allan.

with STL string: code compilation fails. No method
string::clear()

On the DEC Alpha running LinuxAlpha, compiled using
gcc-2.95.2/GNU STL:

with lyxstring: code compiles and runs perfectly. NO
unaligned access errors.

with STL string: code compilation fails. No method
string::clear()

So. What conclusions can be drawn?
1. gcc-2.95.2/GNU STL and lyx/xtl CAN be perfectly compatible.
2. egcs-1.1.2/GNU STL and lyx/xtl require a little work.

To do.
1. Inform the xtl mailing list of these unaligned access
errors.

Lars would like to ditch lyxstring for whatever reason, yet
at the moment it works a lot better than GNU's STL string.
Three ways forward present themselves.
1. Force the world to use SGI's STL. This isn't going to
happen IMO.
2. As I understand it, Lars is suggesting that
we hack the code so that it uses only those bits of the
standard string container that are common to all supported
STLs. This seems very limiting.
3. Instead of having
        typedef lyxstring string;
as we have at the moment, have
        typedef string lyxstring;
IF string is standards compliant. If it isn't, then make
lyxstring a derived class of string and add the extra
functionality (clear() etc). This would have the additional
benefit of making the source code clearer. It's immediately
obvious that 
        lyxstring  strng;
is LyX specific, whereas
        string strng;
suggests (falsely) that we're using the STL container.

Just my two pen'th worth.
Angus

Reply via email to