Implicit conversion is evil?

[Russell Reagan]

In a newer version of a chess program I am writing, I have created classes
that are (more or less) drop in replacements for things that used to be
plain old integer or enumerated variables (colors, piece types, squares,
etc.). To accomplish this, I used implicit conversions. For instance, a
color used to be:

typedef int Color;
// and a few constants...

Now a color is (paraphrased):

class Color {
private:
int color;
public:
// ...
operator int () { return color; }
// ...
};

The reason for moving to these simple classes (which are just int wrappers)
was so that I could verify the validity of the data. For instance:

operator int () { assert(color == white || color == black); return color; }

However, I've been told by several people that implicit conversions are
"evil". I can see how they could be the source of very nasty bugs for a more
hefty class, but what about for something as simple as these classes which
are nothing more than int wrappers? The way I'm using them, they kind of
_are_ int's, so how could it cause bugs if there is an implicit conversion?

Would it be possible for an instance of Color to be implicitly converted and
not validate its internals any longer? If that is possible, I could foresee
a potentially hard to find bug. That would give a sense of false security,
and I'd probably look for the bug elsewhere, assuming (incorrectly) that my
color was still valid since the assert didn't fail.

 

[Victor Bazarov]

In a newer version of a chess program I am writing, I have created classes
that are (more or less) drop in replacements for things that used to be
plain old integer or enumerated variables (colors, piece types, squares,
etc.). To accomplish this, I used implicit conversions. For instance, a
color used to be:

typedef int Color;
// and a few constants...

Now a color is (paraphrased):

class Color {
private:
int color;
public:
// ...
operator int () { return color; }
// ...
};

The reason for moving to these simple classes (which are just int wrappers)
was so that I could verify the validity of the data. For instance:

operator int () { assert(color == white || color == black); return color; }

However, I've been told by several people that implicit conversions are
"evil". I can see how they could be the source of very nasty bugs for a more
hefty class, but what about for something as simple as these classes which
are nothing more than int wrappers? The way I'm using them, they kind of
_are_ int's, so how could it cause bugs if there is an implicit conversion?

Would it be possible for an instance of Color to be implicitly converted and
not validate its internals any longer? If that is possible, I could foresee
a potentially hard to find bug. That would give a sense of false security,
and I'd probably look for the bug elsewhere, assuming (incorrectly) that my
color was still valid since the assert didn't fail.

Let me start with this statement: no feature in the language is
"evil" per se. Implicit conversions are features of the language,
therefore they are not "evil" by themselves. They, just like many
other features of the language, carry some responsibility and can
be mis-used.

Let me continue with this question: there is nothing in your post
that demonstrates the need to have the conversion operator. Do you
use the value to do arithmetic? If not, why would you need to have
the conversion to an arithmetic type? Do you use those "Color",
"Piece", etc., types to index anything? Then usually you don't
need to convert to int in those types, you _could_ limit such
conversion to the module (function, method) where the numeric
value of an object is used. In all other places it should be enough
to use the enumerated values (symbolic constants).

As soon as you can answer this question, you will be on your way to
better understanding of the conversion necessities and probably that
they are unneeded in your model.

Victor

 

[Russell Reagan]

Do you use those "Color",
"Piece", etc., types to index anything?

Yes. I use colors and piece types to index piece lists by color and piece
type, and squares are nothing but indexes into the board.

you _could_ limit such
conversion to the module (function, method) where the numeric
value of an object is used.

I've been considering writing an explicit conversion member function and
letting the other functions call it as needed. This is probably best since
there really isn't any need for implicit conversion, especially at the costs
of unforeseen bugs. The implicit conversion was more of a syntactic sugar
than anything.