Do I need a typecast here?

Discussion in 'C++' started by mike3, Feb 27, 2008.

  1. mike3

    mike3 Guest

    Hi.

    I heard that in C++ typecasts are "evil". However, what does one do
    with this thing?:

    ---
    /* Figure out how many digits of fraction we'll get.
    * We add 1 to the lengths of a and b to take into account
    * the hidden bits.
    */
    int fracObtained(((aLength + 1) - (bLength + 1)));
    std::size_t bufExtra(0);
    if((fracObtained < rLength) || (fracObtained < MIN_PRECISION))
    <---- yuck :(
    {
    /* We need more */
    bufExtra = rLength - fracObtained;
    }
    ---

    But if I simply do

    ---
    /* Figure out how many digits of fraction we'll get.
    * We add 1 to the lengths of a and b to take into account
    * the hidden bits.
    */
    int fracObtained(((aLength + 1) - (bLength + 1)));
    std::size_t bufExtra(0);
    if(fracObtained < rLength) <--- nice :) but doesn't work due to
    signed/unsigned comparison :(
    {
    /* We need more */
    bufExtra = rLength - fracObtained;
    }
    ---

    it fails when "fracObtained" is negative, because rLength is also of
    type std::size_t, which
    is an unsigned type. The former code uses no typecast, the latter
    doesn't either, but the
    former works however it having that goofy extra check in there may be
    confusing while
    the latter, simply comparing it to rLength seems clearer and more
    natural. But for the latter to work,
    you need a typecast of rLength to int. But is the "evil" here
    necessary if one wants to
    write good code for this?
    mike3, Feb 27, 2008
    #1
    1. Advertising

  2. mike3 wrote:
    >
    > I heard that in C++ typecasts are "evil".
    >


    Even if someone says that typecasts are "evil", they are normally
    referring to the conversions of class types along the class hierarchy.
    While even that is questionable, it is not relevant to your case. In
    your case you are thinking about simple arithmetical typecast. This is a
    completely different thing. There's absolutely nothing "evil" about
    arithmetical typecasts. If you need one, then you need one. Although in
    some cases a solution without typecast might prove to be more elegant
    than one with a typecast. On the second thought, the reverse is also
    possible.

    --
    Best regards,
    Andrey Tarasevich
    Andrey Tarasevich, Feb 27, 2008
    #2
    1. Advertising

  3. mike3

    mike3 Guest

    On Feb 27, 2:52 pm, Andrey Tarasevich <>
    wrote:
    > mike3 wrote:
    >
    > > I heard that in C++ typecasts are "evil".

    >
    > >

    >
    > Even if someone says that typecasts are "evil", they are normally
    > referring to the conversions of class types along the class hierarchy.
    > While even that is questionable, it is not relevant to your case. In
    > your case you are thinking about simple arithmetical typecast. This is a
    > completely different thing. There's absolutely nothing "evil" about
    > arithmetical typecasts. If you need one, then you need one. Although in
    > some cases a solution without typecast might prove to be more elegant
    > than one with a typecast. On the second thought, the reverse is also
    > possible.
    >


    Thanks for the answer.
    mike3, Feb 28, 2008
    #3
  4. mike3

    James Kanze Guest

    On Feb 27, 10:44 pm, mike3 <> wrote:

    > I heard that in C++ typecasts are "evil".


    Sometimes a necessary evil. And even...

    > However, what does one do with this thing?:


    > ---
    > /* Figure out how many digits of fraction we'll get.
    > * We add 1 to the lengths of a and b to take into account
    > * the hidden bits.
    > */
    > int fracObtained(((aLength + 1) - (bLength + 1)));
    > std::size_t bufExtra(0);
    > if((fracObtained < rLength) || (fracObtained < MIN_PRECISION))
    > <---- yuck :(
    > {
    > /* We need more */
    > bufExtra = rLength - fracObtained;
    > }
    > ---


    > But if I simply do


    > ---
    > /* Figure out how many digits of fraction we'll get.
    > * We add 1 to the lengths of a and b to take into account
    > * the hidden bits.
    > */
    > int fracObtained(((aLength + 1) - (bLength + 1)));
    > std::size_t bufExtra(0);
    > if(fracObtained < rLength) <--- nice :) but doesn't work due to
    > signed/unsigned comparison :(
    > {
    > /* We need more */
    > bufExtra = rLength - fracObtained;
    > }
    > ---


    > it fails when "fracObtained" is negative, because rLength is
    > also of type std::size_t, which is an unsigned type.


    Comparing a signed integral type with an unsigned is evil in
    C++. There will be an implicit conversion, but not necessarily
    in the way you want.

    > The former code uses no typecast, the latter doesn't either,
    > but the former works however it having that goofy extra check
    > in there may be confusing while the latter, simply comparing
    > it to rLength seems clearer and more natural.
    >But for the latter to work, you need a typecast of rLength to
    >int. But is the "evil" here necessary if one wants to write
    >good code for this?


    The evil is that you're mixing signed and unsigned integral
    types:). Depending on what you are doing, it may be an
    unavoidable evil---you can't change the type of sizeof, and you
    can't change the types returned by std::vector<>::size() and
    others. If you can't avoid mixing signed and unsigned, then
    telling the compiler (and the reader) explicity which way you
    want the conversions to be done is good. (In many ways,
    implicit conversions are even more evil than casts. But again,
    it depends on the context.)

    Of course, if there are no other constraints, the "correct"
    solution is to make rLength an int. (In C++, int is the
    default integral type, and should always be used for integral
    values unless there is some constraint which makes it
    impossible, or at least unreasonable.)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Feb 28, 2008
    #4
    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. Mark Fitzpatrick

    Re: typecast error!

    Mark Fitzpatrick, Feb 1, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    1,670
    Lau Lei Cheong
    Feb 8, 2006
  2. Joe Van Meer

    Re: typecast error!

    Joe Van Meer, Feb 1, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    417
    Bob Lehmann
    Feb 2, 2006
  3. Otis Mukinfus

    Re: typecast error!

    Otis Mukinfus, Feb 3, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    365
    Terry Burns
    Feb 4, 2006
  4. Tomba

    generics typecast

    Tomba, Jan 9, 2006, in forum: Java
    Replies:
    8
    Views:
    1,327
  5. Venkat

    typecast int to string

    Venkat, Jan 7, 2004, in forum: C++
    Replies:
    9
    Views:
    17,844
    Martijn Lievaart
    Jan 8, 2004
Loading...

Share This Page