Conversion operators and ambiguity

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

re: Conversion operators and ambiguity

rasbury wrote:[color=blue]
> If I were to include in the definition of a string class the[/color]
following[color=blue]
> operators:
>
> class String {
> public:
> // ...
> operator const char *() const; // conversion to C-style[/color]
string[color=blue]
> char operator[](size_t i) const; // character indexing
> // ...
> };
>
> I can't use the indexing operator because the compiler doesn't know[/color]
whether[color=blue]
> I mean to index the String object directly or to convert to a const[/color]
char *[color=blue]
> and then index on that. It is clear to me, at least in this case,[/color]
that[color=blue]
> having gone to the trouble of defining an indexing operator for the[/color]
class,[color=blue]
> it is that function I want to call. I would have thought that this[/color]
would be[color=blue]
> obvious to any compiler too - only attempt to perform conversions if[/color]
an[color=blue]
> expression doesn't make sense without them.
>
> Could anyone explain to me why C++ doesn't behave like this? I can't[/color]
think[color=blue]
> of any example where this would be undesirable (although I could[/color]
believe[color=blue]
> they might exist), and it seems that it would be very useful,[/color]
particularly[color=blue]
> when interfacing with C code which expects more primitive types.
>
> Richard[/color]

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-

re: Conversion operators and ambiguity

"rasbury" <dickyrubbish_removethis_@hotmail.com> wrote in message
news:cunmgu$gm5$1@sparta.btinternet.com...[color=blue]
> 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[/color]
whether[color=blue]
> 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[/color]
be[color=blue]
> 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.[/color]

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.

--
David Hilsee