Hi Dave,
I just downloaded 1.6 and searched through the code...
the XALAN_CLASSIC_IOSTREAMS only controls which headers are included.
(i.e. <blah.h> vs <blah>)
The application of the namespace "std" is still controlled by a single
macro, XALAN_NO_STD_NAMESPACE whether it be IO classes or STL container
classes.
For example, from DOMStringHelper.hpp(1090):
XALAN_PLATFORMSUPPORT_EXPORT_FUNCTION(void)
OutputString(
#if defined(XALAN_NO_STD_NAMESPACE)
ostream& theStream,
#else
std::ostream& theStream,
#endif
const CharVectorType& theString);
and from DOMSupport\XalanNamespacesStack.hpp(127)
#if defined(XALAN_NO_STD_NAMESPACE)
typedef deque<value_type> NamespaceCollectionType;
#else
typedef std::deque<value_type> NamespaceCollectionType;
#endif
In order to use HP's older C++ support library (-AP) ostream is not in the std
namespace. In order to use STLport, deque is in the 'std' namespace.
Hence, I need a different macro for controlling the application of the std namespace
for, say 'ostream' than I do for the container deque.
NOTE: If STLport was out of the picture, then the single macro is sufficient since
both the io and the STL containers are either in or not in the std namespace
together.
i.e.
#if defined( using-STLport )
#undef XALAN_NO_STD_NAMESPACE
#endif
#if !defined( _HP_NAMESPACE_STD )
#define XALAN_NO_STD_NAMESPACE
#endif
#if defined(XALAN_NO_STD_IO_NAMESPACE)
ostream& theStream,
#else
std::ostream& theStream,
#endif
...
#if defined(XALAN_NO_STD_NAMESPACE)
typedef deque<value_type> NamespaceCollectionType;
#else
typedef std::deque<value_type> NamespaceCollectionType;
#endif
Am I still on the right track?
Cheers,
John.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 08, 2004 5:14 PM
To: [email protected]
Subject: RE: Building Xalan 1.2 on HP/UX with aCC A.03.33 and STLport
4.5
Hi John,
Your assumption is correct -- we wouldn't retrofit Xalan 1.2. But thanks
for asking!
I understand the issues with upgrading, but you should really consider
putting in the effort to move things up. I'm not sure how much code you
will need to change, but those versions of Xerces and Xalan are long since
past their useful lifespan, and you will likely run across more issues that
will require an upgrade to fix. Also, once you've settled on the latest
versions, I think you'll find the APIs will be much more stable.
Thanks!
Dave
"Bossom, John"
<[EMAIL PROTECTED] To: "'[email protected]'" <[email protected]>
nos.COM> cc: (bcc: David N Bertoni/Cambridge/IBM)
Subject: RE: Building Xalan 1.2 on HP/UX with aCC A.03.33 and STLport 4.5
01/08/2004 01:57
PM
Please respond
to xalan-c-users
Thanks Dave,
At present we are unable to upgrade due to the fact that we
have other components that directly depend up on Xerces 1.5.2...
Since the API for Xerces 1.5.2 has changed, the domino affect
is quite large (i.e. Xalan depends on Xerces, Xercees depends on ICU...)
hence, we need to upgrade all three at the same time, timing it
between product releases... (ugh!)
I'll take a look at the latest code...
May I assume that since Xalan 1.2 is soooo old, there is no requirement
for me to submit my changes back?
Thanks,
John.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 08, 2004 4:42 PM
To: [email protected]
Subject: Re: Building Xalan 1.2 on HP/UX with aCC A.03.33 and STLport
4.5
Hi John,
You can look at what we've done in the latest code, but it's pretty much
what you've concluded. We now have a macro called XALAN_CLASSIC_IOSTREAMS
to differentiate between using the std namespace and any particular
IOstreams implementation.
By the way, you really should plan an upgrade to a later version of Xalan
sometime soon. Version 1.2 is quite long in the tooth, and has a number of
bugs.
Hope that helps...
Dave
"Bossom, John"
<[EMAIL PROTECTED] To:
"'[email protected]'" <[email protected]>
nos.COM> cc: "Rasmussen, Glenn"
<[EMAIL PROTECTED]>, "Bossom, John"
<[EMAIL PROTECTED]>,
(bcc: David N Bertoni/Cambridge/IBM)
01/08/2004 01:05 Subject: Building Xalan 1.2
on HP/UX with aCC A.03.33 and STLport 4.5
PM
Please respond
to xalan-c-users
Xalan 1.2 has only one macro to enable or disable the use of namespaces...
i.e. XALAN_NO_NAMESPACES
This is all fine when building on HP/UX with either -AP (classic STL) or
-AA (standard STL) by defining XALAN_NO_NAMESPACES for -AP and undefining
it for -AA...
However, the combination of using -AP with STLport 4.5 (configured to use
old iostreams from the OS) results in the a mix.
Basically, the STL containers are all in the "std" namespace as defined by
STLport,
however, the IO entities are not, as they come directly from the OS...
As a result, the only way I can think of to get this to build is to
introduce
a new macro, XALAN_NO_IO_NAMESPACES to control the use of the namespace std
on io streams, etc...
By default XALAN_NO_IO_NAMESPACES is defined if XALAN_NO_NAMESPACES is
defined.
For HP-UX, if _HP_NAMESPACE_STD is defined, then -AA was used and
everything is
in the namespace 'std'; otherwise -AP is used (the default) and nothing is
in 'std'
as far as the os is concerned. If STLport is subsequently used, then I
#undef XALAN_NO_NAMESPACES
#define XALAN_NO_IO_NAMESPACES
I had to go through many of the files to change the use of
XALAN_NO_NAMESPACES to
XALAN_NO_IO_NAMESPACES in order to affect this change.
Question: is there a better way? I am stuck with Xalan 1.2 and HP/UX 3.33
with -AP
and I'm using STLport in order to work around old issues from the
OS' STL...
Comments?
Thanks,
John E. Bossom
[EMAIL PROTECTED]
COGNOS Incorportated
This message may contain privileged and/or confidential information. If
you have received this e-mail in error or are not the intended recipient,
you may not use, copy, disseminate or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so. Thank you.
This message may contain privileged and/or confidential information. If
you have received this e-mail in error or are not the intended recipient,
you may not use, copy, disseminate or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so. Thank you.
This message may contain privileged and/or confidential information. If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it; do not open any attachments, delete it immediately from your system and notify the sender promptly by e-mail that you have done so. Thank you.
