Allan Rae <[EMAIL PROTECTED]> writes:
| No it's not quite what you were expecting from the subject.
|
| I have an almost compiling implementation that uses a new:
| bool LyXFunc::Dispatch(int action, int size, char * buf)
|
| where size and buf are the memory buffer filled with the externalized data
| to be passed to/from the new lyxfuncs: LFUN_BUFFER_PRINT and
| LFUN_PRINTER_PARAMS_GET.
|
| It's not quite as neat as I'd like but okay for a first generation.
|
| The "vs string" part of the title is caused by xtl's use of exceptions.(*)
| When compiled --with-included-string by gcc-2.95.2 using gcc's STL there
| is a problem. <stdexcept> #includes <string> which of course tries to
| typedef basic_string<...> string; even though we've already done a typedef
| lyxstring string;. Naturally, the compiler complains bitterly at this
| point and refuses to compile any more code until this problem is fixed.
|
| If I compile with SGI's STL-3.2 the problem doesn't arise mainly because
| of the stl_string_fwd.h wrapper I added a couple of months ago. If we
| want to use xtl + --with-included-string + gcc-2.95.2's STL we need to fix
| one or more of the following:
|
| 1. XTL -- so it doesn't require exceptions but can use them if they're
| available. Not impossible but I've only looked at objio.h so far.
| 2. <string> -- by using a wrapper similar to the stl_string_fwd.h wrapper
| I already wrote. This shouldn't be too difficult.
| 3. Is there a 3? ("Don't use xtl!" Who said that? Such impertinence will
| not be tolerated ;-)
The 3. is of course to not use lyxstring. However then we will have
some problems with different non-conforming string implementations.
and we need to investigate what each of them does that makes them
non-conforming.
Lgb
|
|
| Allan. (ARRae)
|
| (*) Using xtl means we can through away those -fno-rtti and
| -fno-exceptions compiler options as LyX won't compile if you use them.
