By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,271 Members | 1,314 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,271 IT Pros & Developers. It's quick & easy.

Implicit conversion is evil?

P: n/a
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.
Jul 19 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
"Russell Reagan" <rr*****@attbi.com> wrote...
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
Jul 19 '05 #2

P: n/a
"Victor Bazarov" <v.********@comAcast.net> wrote
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.
Jul 19 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.