The following comment has been added to this issue:
Author: Robert Buck
Created: Thu, 13 May 2004 9:55 AM
Body:
Yes, but namespaces is not at issue - the C preprocessor is. The issue specifically is
that many C libraries use #define. This particular one (fdlibm) does the following:
#define UNKNOWN 5
That is the issue. The only way around this is to change the definition, or change the
name of the enum in Xerces. The latter is preferable.
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/XERCESC-1212?page=comments#action_35527
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/XERCESC-1212
Here is an overview of the issue:
---------------------------------------------------------------------
Key: XERCESC-1212
Summary: Xerces-C Conflicts with fdlibm: enum names too common
Type: Bug
Status: Unassigned
Priority: Major
Project: Xerces-C++
Components:
Utilities
Validating Parser (DTD)
Validating Parser (Schema) (Xerces 1.5 or up only)
Versions:
2.5.0
Assignee:
Reporter: Robert Buck
Created: Thu, 13 May 2004 8:46 AM
Updated: Thu, 13 May 2004 9:55 AM
Environment: ALL
Description:
For those developers that use the freely distributable math library, or fdlibm, a
conflict exists between the definition of UNKNOWN. Specifically, if you include fdlibm
headers prior to xerces-c headers, xerces-c user applications will not compile.
Choosing common names such as UNKNOWN is not helpful to those of us that link in many
third-party libraries, since the likelihood that a conflict will exist with such a
name is greatly increased. Please prefix the names with something that distinguishes
the enum value as being from Xerces-C. In the very least, set it as a standard
practice in future enum types to use more conspicuous names. It would be nice if you
changed these before these names get entrenched in C++ user code.
I do have a work-around, but it's rather ugly. I just raise this to your attention,
mostly to suggest the adoption of such a coding practice.
Thanks
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
