chCR, chLF, and other character constants

[Jesse Pelton <js...@PKC.com>]

We're compiling with Xerces-C and a third-party class library that also
defines constants for chCR and chLF.  Unfortunately, the definitions
conflict (theirs is a char).  XMLUni.hpp, where the constants are defined,
clearly recognizes the potential for conflict, as there's a comment to the
effect that a namespace can't be used because some target compilers don't
support namespaces.  Given the generic nature of these names, I'd suggest
changing the prefix used in XMLUni.hpp from "ch" to something more likely to
be unique - perhaps "XMLch" or "xch".  We'll contribute the changes if
there's agreement on a better prefix.

Use of a namespace would be a better solution, of course.  What are the
compilers that don't support namespaces yet, and what are the prospects for
versions that do have support?  (In other words, does anyone have any idea
how long we have to live with this?)

Under MSVC 6, at least, there's an intermediate solution.  I don't know how
it'll work with other compilers, but it seems safe enough to me.  The idea
is to use a namespace where supported.  In the case of XMLUni.hpp, the code
would be something like:

#ifdef XML_NAMESPACE
#define XMLNamespace XercesC
namespace XercesC
{
#else
#define XMLNamespace
#endif
const XMLCh chNull                  = 0x00;
:
:
const XMLCh chWonSign               = 0x20A9;
#ifdef XML_NAMESPACE
}
#endif

In the code, references to constants would look like XMLNamespace::chNull.
If XMLNamespace is empty, of course, this expands to ::chNull, which
explicitly (rather than implicitly) names the appropriate scope.  Or
XMLNamespace could be a function-like macro:

#ifdef XML_NAMESPACE
#define XMLNamespace(x) XercesC::x
#else
#define XMLNamespace(x) x
#endif

in which case references in the code would look like XMLNamespace(chNull),
which would expand to chNull, exactly as it currently does.

Is there some reason not to do something like this?  The only compiler I'm
familiar with these days is MSVC (sigh), so I may well be missing something
that would cause another compiler to choke.  I realize that this is opening
a can of worms, because if you use namespaces in one context, you probably
should use 'em in all cases.  But we can keep the worm population down, I
think, by realizing that these constants are conceptually quite distinct
from, say, the classes, and so it might make sense to use namespaces only in
this and similar contexts.

In any case, we can't proceed until this name conflict is resolved, so I'm
looking forward to what y'all have to say!

Jesse Pelton
PKC Corporation

Re: chCR, chLF, and other character constants

[Andy Heninger <an...@jtcsv.com>]

Another solution to this problem would be to get all includes of
XMLUni.hpp out of any public Xerces header file.  All but two of the
existing uses are in various .cpp files, and these can't cause a problem
because they wont ever be compiled with other non-xerces code.

The two remaining uses are in XMLException.hpp and SAXException.hpp, and
it doesn't look like it would be very hard to get them of it there.


Andy Heninger
IBM XML Technology Group, Cupertino, CA
heninger@us.ibm.com



----- Original Message -----
From: "Jesse Pelton" <js...@PKC.com>
To: <xe...@xml.apache.org>
Sent: Tuesday, July 25, 2000 9:59 AM
Subject: chCR, chLF, and other character constants


> We're compiling with Xerces-C and a third-party class library that also
> defines constants for chCR and chLF.  Unfortunately, the definitions
> conflict (theirs is a char).  XMLUni.hpp, where the constants are
defined,
> clearly recognizes the potential for conflict, as there's a comment to
the
> effect that a namespace can't be used because some target compilers
don't
> support namespaces.  Given the generic nature of these names, I'd
suggest
> changing the prefix used in XMLUni.hpp from "ch" to something more
likely to
> be unique - perhaps "XMLch" or "xch".  We'll contribute the changes if
> there's agreement on a better prefix.
>
> Use of a namespace would be a better solution, of course.  What are the
> compilers that don't support namespaces yet, and what are the prospects
for
> versions that do have support?  (In other words, does anyone have any
idea
> how long we have to live with this?)
>
> Under MSVC 6, at least, there's an intermediate solution.  I don't know
how
> it'll work with other compilers, but it seems safe enough to me.  The
idea
> is to use a namespace where supported.  In the case of XMLUni.hpp, the
code
> would be something like:
>
> #ifdef XML_NAMESPACE
> #define XMLNamespace XercesC
> namespace XercesC
> {
> #else
> #define XMLNamespace
> #endif
> const XMLCh chNull                  = 0x00;
> :
> :
> const XMLCh chWonSign               = 0x20A9;
> #ifdef XML_NAMESPACE
> }
> #endif
>
> In the code, references to constants would look like
XMLNamespace::chNull.
> If XMLNamespace is empty, of course, this expands to ::chNull, which
> explicitly (rather than implicitly) names the appropriate scope.  Or
> XMLNamespace could be a function-like macro:
>
> #ifdef XML_NAMESPACE
> #define XMLNamespace(x) XercesC::x
> #else
> #define XMLNamespace(x) x
> #endif
>
> in which case references in the code would look like
XMLNamespace(chNull),
> which would expand to chNull, exactly as it currently does.
>
> Is there some reason not to do something like this?  The only compiler
I'm
> familiar with these days is MSVC (sigh), so I may well be missing
something
> that would cause another compiler to choke.  I realize that this is
opening
> a can of worms, because if you use namespaces in one context, you
probably
> should use 'em in all cases.  But we can keep the worm population down,
I
> think, by realizing that these constants are conceptually quite distinct
> from, say, the classes, and so it might make sense to use namespaces
only in
> this and similar contexts.
>
> In any case, we can't proceed until this name conflict is resolved, so
I'm
> looking forward to what y'all have to say!
>
> Jesse Pelton
> PKC Corporation
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>