Hi Greg,
I got your note last night and I've changed the header files to cast the
enums to chars:
static bool
isBaseChar(XalanDOMChar c)
{
return theUnicodeTable[c] == char(XML_BC);
}
That will take care of problem, correct?
These changes won't go in until the 1.6 release.
Dave
"Dunko, Greg"
<[EMAIL PROTECTED] To:
"'xalan-c-users@xml.apache.org'" <xalan-c-users@xml.apache.org>
COM> cc: (bcc: David N
Bertoni/Cambridge/IBM)
Subject: RE: Enums/chars and
XMLChar.hpp
05/20/2003 02:10
PM
Sorry I just realized that I misnamed the file. I was referring to
XalanXMLChar.hpp in the PlatformSupport directory.
In any event, any comments about this? Would it help if I posted the fixes
somewhere?
-----Original Message-----
From: Dunko, Greg
Sent: Monday, May 19, 2003 10:29 AM
To: xalan-c-users@xml.apache.org
Subject: Enums/chars and XMLChar.hpp
Hiya folks,
I have run into an issue with this #include that I thought I should share
so
that it can be corrected. The issue has to do with code that is doing
direct comparisons between chars and enums (int). It's a subtle issue but
it's causing us a headache over here.
What's happening is that the compiler is getting stuck on an ambiguous
conversion here because there are other user-defined functions/constructors
that also could be used.
Specifically this has to do with enum "eType" in XMLChar.hpp and the
comparisons made a few lines later with the contents of "theUnicodeTable".
The enums need to be casted to char or the character that is being looked
at
in the table need to be casted up to an int while making these comparisons.
Failure to do so asks the compiler to try to make a guess and that's
causing
problems.
I understand that in general this isn't much of an issue but having this
code in an #include is causing errors for those of us that use other 3rd
party libraries.
Here is a very small sample program that shows the issue. Some compilers
may show more leniency but the VisualAge compiler on AIX does not.
====
struct A
{
A (char) {};
};
bool operator== (char, A)
{
return true;
}
enum {
foo
};
int main ()
{
return (char(0) == foo);
}
====
$ /usr/vacpp/bin/xlC_r /tmp/junk.C
"/tmp/junk.C", line 18.19: 1540-0219 (S) The call to "operator==" has no
best match.
"/tmp/junk.C", line 18.11: 1540-1229 (I) Argument number 1 is an rvalue of
type "char".
"/tmp/junk.C", line 18.22: 1540-1229 (I) Argument number 2 is an rvalue of
type "<unnamed-enum>".
"/tmp/junk.C", line 18.19: 1540-1202 (I) No candidate is better than
"builtin operator==(int, int)".
"/tmp/junk.C", line 18.11: 1540-1231 (I) The conversion from argument
number
1 to "int" uses an integral promotion.
"/tmp/junk.C", line 18.22: 1540-1231 (I) The conversion from argument
number
2 to "int" uses an integral promotion.
"/tmp/junk.C", line 7.6: 1540-1202 (I) No candidate is better than
"operator==(char, A)".
"/tmp/junk.C", line 18.11: 1540-1231 (I) The conversion from argument
number
1 to "char" uses the identity conversion.
"/tmp/junk.C", line 18.22: 1540-1231 (I) The conversion from argument
number
2 to "A" uses an integral conversion followed by the user-defined
conversion
"A::A(char)" followed by an lvalue-to-rvalue transformation.
--
Greg Dunko
Consultant Software Engineer
Fidelity Investments
603.791.8216
