On 30 Mar 2000, Lars Gullik Bj�nnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | This may of course be a function of my using lyxstring
> | rather than STL string? How much would I need to hack the
> | code base to remove those calls to string::clear() I wonder?
Angus get a copy of SGI STL-3.2 (not 3.2.1 or any of the others).
Install this in /usr/local/include/STL and then configure with:
./configure --with-extra-inc=/usr/local/include/STL
This will give you an STL worth using and avoid the problems with the
egcs-1.1.2's STL.
I can compile out of the box with egcs-1.1.2 and gcc-2.95.2 using this STL
implementation. They also use a different string implementation to just
about everyone on the planet (same interface different philosophy).
> I think we have to "bite i det sure eplet"� and ditch lyxstring, it
> has served us well and it was fun to implement. std::string::clear ==
> std::string::erase(), so q tags-query-replace on all the code should
> be enough to fix that one. A harder problem is that on some
> implementations of std::sting (egcs's) the arguments to
> std::string::replace is in the wrong order so this need to be verified
> and investigated.
's/clear/erase/g' by all means but don't ditch lyxstring just yet.
I see none of these alignment issues Angus because ix86 boxes don't give a
hoot. I found a -Wptr-math or something like that and a -Walign something
that I might try compiling with. These supposedly warn against code that
depends on particular alignments or sizeof().
I think xtl probably needs to be made aware of the need for alignment on
alphas. That is, it just writes data in the raw format with no thought as
to the alignment of the first byte of each new element. I'm not sure how
that would be written but Jos� (XTL) will need to be informed.
Allan. (ARRae)
