In general, I hate to change perfectly good source code to work-around bugs
in implementations. I'd rather the implementations be fixed to be
standard. Note that this code is not a problem on any other compiler, nor
is it a problem using the standard STLport 4.0 distribution.
Another question is why you're using STLport with Visual C++, when it has
its own implementation. Yes, it's a bit out of date, but it's what we
build and test with. If you were trying to use our pre-built binaries with
STLport, it's no wonder you needed to rebuild things -- I can't see how
that would every work if you didn't.
We have the same problem with using STD allocators on AIX, where we use
STLport. We don't have the same problem other platforms, so I'm not sure
whether it's a bug in our code, or a problem with STLport.
Dave
Samar Abbas
Lotia To: "'[EMAIL PROTECTED]'"
<[EMAIL PROTECTED] <[EMAIL PROTECTED]>
om> cc: (bcc: David N
Bertoni/CAM/Lotus)
Subject: Compile problems with STLPort
4.0 and MSVC 6 SP4
10/23/2001 02:05
PM
Please respond
to xalan-dev
I ran into some minor problems while trying to compile Xalan-C 1.2 on MSVC
6 using STLPort 4.0. The problems were most likely related to my particular
configuration of STLPort, however IMHO, the changes would make the Xalan
source code more portable (although marginally) across STL
implementations/configurations.
My particular problems were seen in the following files:
XSLT/NamespacesHandler.cpp (lines 111 and 120)
XSLT/OutputContextStack.cpp (lines 108 and 134)
XSLT/ResultNamespacesStack.cpp (line 179)
XSLT/StylesheetHandler.cpp (lines 1870 and 1873)
PlatformSupport/ArenaAllocator.hpp (line 201)
PlatformSupport/ReusableArenaAllocator.hpp (lines 135 and 178)
The problem was always related to using the operator != for comparing STL
iterators. Changing this to (IMHO more portable) !(x == y) fixed my
problems.
I was wondering what the opinions of the Xalan dev community were regarding
such issues with STL compatibility and what, if anything, should be done to
address these. My comment is biased totally towards not having to modify
Xalan source code when I get a fresh release in order to compile it for my
uses :-)
Also, the reason I recompiled Xalan was to turn off the STD allocators
which were causing trouble in my case when mixed with (my configuration of)
STLPort 4.0.
Thanks,
Samar