Dave Thanks. I am a compiler writer, and now that I've delved deep into the C++ standard, it is clear that MS is at fault: see ISO/IEC 14882:1998 �9.4.2(4). As MS mis-implement inline initializers, the solution must therefore be to undefine XALAN_INLINE_INITIALIZATION for MSVC7 (_MSC_VER=1300) in Include/VCPPDefinitions.hpp. I have tried this and it compiles OK as one would expect.
There are still three different styles for defining npos in the Xalan source, of which only the XalanDOMString one causes MSVC7 problems (BTW a duplication-definition link error). At the very least the usages should all be the same. Regards EJP -----Original Message----- From: David N Bertoni/Cambridge/IBM [mailto:[EMAIL PROTECTED]] Sent: Thursday, 19 September 2002 11:31 AM To: [EMAIL PROTECTED] Subject: RE: Candidate 1.4 distributions - bugs The latter is indeed _not_ incorrect, nor is it necessarily pointless. It is only necessary if code referencing XalanDOMString::npos provokes a "use" of npos, like this: const XalanDOMString::size_type& foo = XalanDOMString::npos; You could argue that we shouldn't allow this, but the real reason the definition of npos is in the cpp file is because the Intel compiler, which is supposedly "fully compatible" with Visual C++, requires it -- go figure. There was a complaint that the code wouldn't build on the Intel compiler, so the definition was added. This is a bug with Visual C++ 7.0, as this code compiles with no complaints on Linux and all of the Unix platforms. What is illegal is this: In hpp: static const size_type npos = ~0u; In cpp: const XalanDOMString::size_type XalanDOMString::npos = ~0u; At some point, when I can afford to spend ~$400 on a copy of Visual C++.Net, I'll try to make sure the code compiles cleanly. But it's going to be next to impossible to support both the Intel Windows compiler and the Microsoft Windows compiler, unless the two companies get together and fix this. Dave "Pitt, Esmond" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: (bcc: David N Bertoni/Cambridge/IBM) 09/18/2002 06:00 Subject: RE: Candidate 1.4 distributions - bugs PM Please respond to xalan-dev I have built this with MSC7. The only compile-time problem I found was in XalanDOM/XalanDOMString.hpp, which has: #if defined(XALAN_INLINE_INITIALIZATION) static const size_type npos = ~0u; #else enum { npos = -1 }; #endif XalanDOMString.cpp has this: #if defined(XALAN_INLINE_INITIALIZATION) const XalanDOMString::size_type XalanDOMString::npos; #endif The latter is both incorrect & pointless if XALAN_INLINE_INITIALIZATION is defined. It should be this in the hpp: #if defined(XALAN_INLINE_INITIALIZATION) static const size_type npos = ~0u; #else static const size_type npos; #endif and this in the cpp: #if !defined(XALAN_INLINE_INITIALIZATION) const XalanDOMString::size_type XalanDOMString::npos = ~0u; #endif thus agreeing with XPath/NodeRefListBase.?pp and PlatformSupport/Writer.?pp. Alternatively the original form of the hpp file can be kept and the cpp stuff completely eliminated. PlatformSupport/FormatterListener.cpp has a related problem in that the condition leg should be empty if XALAN_INLINE_INITIALIZATION is defined, i.e. the same solution applies. For symmetry this can also be applied to XPath/XPathExpression.?pp. I have a set of VC7 project files if anyone wants them. Regards Esmond Pitt -----Original Message----- From: David N Bertoni/Cambridge/IBM [mailto:[EMAIL PROTECTED]] Sent: Thursday, 19 September 2002 2:49 AM To: [EMAIL PROTECTED] Subject: Candidate 1.4 distributions Hi all, The candidate distributions for the 1.4 release are available in: http://xml.apache.org/dist/xalan-c/candidate/ We'll be doing some smoke-testing on the distributions tomorrow. I encourage anyone who's interested to download the distributions and report and problems you may have. If our testing doesn't uncover anything by tomorrow evening, we'll consider the release official, I'll move them to the main distribution directory, and I'll archive the 1.3 distributions. Dave
