Connecting Tech Pros Worldwide Help | Site Map

Conversion operators and ambiguity

 
LinkBack Thread Tools Search this Thread
  #1  
Old July 23rd, 2005, 12:50 AM
rasbury
Guest
 
Posts: n/a
Default 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



  #2  
Old July 23rd, 2005, 12:50 AM
Shezan Baig
Guest
 
Posts: n/a
Default 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-

  #3  
Old July 23rd, 2005, 12:51 AM
David Hilsee
Guest
 
Posts: n/a
Default 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


 

Bookmarks

Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On

Popular Articles

What is Bytes?

We are a network of experts and professionals in IT and software development that help one another with answers to tough questions and share insights. Get the best answers to your questions from over 220,840 network members.