Conversion operators and ambiguity

[rasbury]

If I were to include in the definition of a string class the following
operators:

class String {
public:
// ...
operator const char *() const; // conversion to C-style string
char operator[](size_t i) const; // character indexing
// ...
};

I can't use the indexing operator because the compiler doesn't know whether
I mean to index the String object directly or to convert to a const char *
and then index on that. It is clear to me, at least in this case, that
having gone to the trouble of defining an indexing operator for the class,
it is that function I want to call. I would have thought that this would be
obvious to any compiler too - only attempt to perform conversions if an
expression doesn't make sense without them.

Could anyone explain to me why C++ doesn't behave like this? I can't think
of any example where this would be undesirable (although I could believe
they might exist), and it seems that it would be very useful, particularly
when interfacing with C code which expects more primitive types.

Richard

 

[Shezan Baig]

If I were to include in the definition of a string class the following
operators:

class String {
public:
// ...
operator const char *() const; // conversion to C-style string
char operator[](size_t i) const; // character indexing
// ...
};

I can't use the indexing operator because the compiler doesn't know whether
I mean to index the String object directly or to convert to a const char *
and then index on that. It is clear to me, at least in this case, that
having gone to the trouble of defining an indexing operator for the class,
it is that function I want to call. I would have thought that this would be
obvious to any compiler too - only attempt to perform conversions if an
expression doesn't make sense without them.

Could anyone explain to me why C++ doesn't behave like this? I can't think
of any example where this would be undesirable (although I could believe
they might exist), and it seems that it would be very useful, particularly
when interfacing with C code which expects more primitive types.

Richard

I tried your code with the Comeau compiler
(http://www.comeaucomputing.com/tryitout/). It compiles fine. You are
probably using a buggy compiler.

Hope this helps,
-shez-

 

[David Hilsee]

If I were to include in the definition of a string class the following
operators:

class String {
public:
// ...
operator const char *() const; // conversion to C-style string
char operator[](size_t i) const; // character indexing
// ...
};

I can't use the indexing operator because the compiler doesn't know whether
I mean to index the String object directly or to convert to a const char *
and then index on that. It is clear to me, at least in this case, that
having gone to the trouble of defining an indexing operator for the class,
it is that function I want to call. I would have thought that this would be
obvious to any compiler too - only attempt to perform conversions if an
expression doesn't make sense without them.

Could anyone explain to me why C++ doesn't behave like this? I can't think
of any example where this would be undesirable (although I could believe
they might exist), and it seems that it would be very useful, particularly
when interfacing with C code which expects more primitive types.

As was said before, the compiler shouldn't consider anything ambiguous when
you invoke operator[], so it sounds like your compiler has a bug.

My suggestion would be to do something similar to std::string's approach and
avoid an implicit conversion, preferring to use a member function that
resembles std::string::c_str(). You'd have to type a few extra characters
to convert it to a const char *, but being explicit about the conversion can
help prevent accidental bugs.