Connecting Tech Pros Worldwide Forums | Help | Site Map

Conversion operators and ambiguity

rasbury
Guest
 
Posts: n/a
#1: Jul 23 '05
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


Clark S. Cox III
Guest
 
Posts: n/a
#2: Jul 23 '05

re: Conversion operators and ambiguity


On 2005-02-14 12:22:24 -0500, "rasbury"
<dickyrubbish_removethis_@hotmail.com> said:
[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 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.[/color]

This runs as you would expect:
#include <iostream>
using std::cout;


class String {
public:
// ...
operator const char *() const
{
cout << "operator const char *() const\n";
return "Some string";
}

char operator[](size_t i) const
{
cout << "operator[](size_t i) const\n";
return 'a';
}
// ...
};

int main()
{
String s;
size_t index = 0;
s[index];

return 0;
}

[color=blue]
>
> 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]

The problem is likely the type you are using for the index. In a
statement like:

s[5]

where s is an instance of String, the 5 is of type int, not size_t, so
any interpretation of that statement requires one of the following
conversions:

String -> const char*
int -> size_t

So, in response to your statement:[color=blue]
> only attempt to perform conversions if an expression doesn't make sense
> without them.[/color]

That's exactly what the compiler *is* doing.

--
Clark S. Cox, III
clarkcox3@gmail.com

Richard Asbury
Guest
 
Posts: n/a
#3: Jul 23 '05

re: Conversion operators and ambiguity



Clark S. Cox III wrote:[color=blue]
> The problem is likely the type you are using for the index. In a
> statement like:
>
> s[5]
>
> where s is an instance of String, the 5 is of type int, not size_t,[/color]
so[color=blue]
> any interpretation of that statement requires one of the following
> conversions:
>
> String -> const char*
> int -> size_t
>
> So, in response to your statement:[color=green]
> > only attempt to perform conversions if an expression doesn't make[/color][/color]
sense[color=blue][color=green]
> > without them.[/color]
>
> That's exactly what the compiler *is* doing.[/color]

You're absolutely correct - the compiler was happy when I changed the
size_t to an int. Thanks!

Richard

Closed Thread