RE: Candidate 1.4 distributions - bugs

[David N Bertoni/Cambridge/IBM]

Hi Esmond,

Wow, do I get extra points for correcting the compiler writer?  ;-)

Yes, I'm aware of the section in the standard.  I spent mucho time
researching this a while back for an issue with one of the supported
compilers.  It's not a tricky thing, so I'm surprised MSVC 7 doesn't get it
right.

I'm going to try for a workaround for 7.0, since I already have to touch
the sources for something else.  If you see the announcement of the next
candidate, and you get a chance, it would be great if you could try the new
sources out to see if they compile cleanly with 7.0.

I agree with you that things should be consistent with the inline
initializaton ifdefs, and I'm going to fix those as well, with the
exception that I'm going to keep the enum for XalanDOMString::npos, as it's
used heavily, and I'm worried about the performance implications of not
having a compile-time constant.

Thanks!

Dave



                                                                       
                      "Pitt, Esmond"                                   
                      <[EMAIL PROTECTED]>          To:      [EMAIL PROTECTED]
                                               cc:      (bcc: David N 
Bertoni/Cambridge/IBM)
                      09/18/2002 07:16         Subject: RE: Candidate 1.4 
distributions - bugs
                      PM                                               
                      Please respond                                   
                      to xalan-dev                                     
                                                                       
                                                                       



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