Legacy Issue Number: 5807
This e-mail addresses three CORBA C++ Revision Task Force issues:
It also addresses section 6.10.2 of your book, "Advanced CORBA
Programming with C++" ((C) 1999).
Starting with 6.10.2 of your book, p. 164, you show an example where a
CORBA::String_var is implicitly converted to 'const char *' in a
function call, with the conversion operators as defined on p. 157 (sect.
However, the C++ language won't choose the 'const char *() const'
operator as you (and I) would think. Instead, since the String_var
isn't const in the call's scope, the 'char *()' (i.e., non-const)
operator is chosen.
Aparently, the conversion path
String_var -> char * -> const char *
Is considered "better" than the conversion path we'd expect, namely
String_var -> const String_var -> const char *
Further, updating String_var with the resolutions of Issues 3796 and
3797 (as found in http://cgi.omg.org/issues/cxx_revision.html), namely
removing 'operator char *()' and adding 'operator char *&()' now leads
to the conversion path
String_var -> char *& -> const char *
The 'const char *' operator is still bypassed, and with 'operator char
*&()' in the picture, it seems trouble is more likely.
For reference, take a look at the USENET newsgroup comp.std.c++, the
thread of "Subject: Implicit conversion of g++", starting 2000/03/02 (I
know that long URL's don't e-mail well, but...
For reference, I've attached a little source-code. Imagine that the
class is String_var. This program produces identical results under two
- Microsoft's Visual C++ 6.0 (SP3)
- CygWin's gcc v3.2
Though the String_var implementations I've seen aren't adversely
affected, I wanted to bring this compiler behavior to your attention. I
think the CORBA & C++ folks should eventually know, too, since CORBA and
C++ seem to miss each other here.
Reported: CPP 1.1 — Fri, 10 Jan 2003 05:00 GMT
Disposition: Resolved — CPP 1.2
Updated: Fri, 6 Mar 2015 20:57 GMT