Implicit conversion is evil?

Discussion in 'C++' started by Russell Reagan, Oct 27, 2003.

  1. 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.
    Russell Reagan, Oct 27, 2003
    #1
    1. Advertising

  2. "Russell Reagan" <> 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
    Victor Bazarov, Oct 27, 2003
    #2
    1. Advertising

  3. "Victor Bazarov" <> 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.
    Russell Reagan, Oct 27, 2003
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jacob
    Replies:
    7
    Views:
    404
    Dale King
    Oct 3, 2003
  2. dmoos AT esigma-systems DOT de

    implicit vs. explicit type conversion for string vs. (char *)

    dmoos AT esigma-systems DOT de, Jun 26, 2003, in forum: C++
    Replies:
    2
    Views:
    2,496
    Default User
    Jun 26, 2003
  3. al
    Replies:
    2
    Views:
    5,591
    Ernst Murnleitner
    Jan 7, 2004
  4. Replies:
    12
    Views:
    1,065
    Ville Vainio
    Feb 17, 2006
  5. rantingrick

    Implicit initialization is EVIL!

    rantingrick, Jul 3, 2011, in forum: Python
    Replies:
    56
    Views:
    1,183
    Steven D'Aprano
    Jul 9, 2011
Loading...

Share This Page