Option Strict - picky, but why?


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 14 of 14

Thread: Option Strict - picky, but why?

  1. #1
    Greg Brunet Guest

    Option Strict - picky, but why?

    With "Option Strict On" why do I get a "Option Strict On disallows =
    implicit conversions from 'Integer' to 'Short'." error on the last 2 =
    lines? I don't see any Int's that aren't there in the first 2 =
    assignment statements! Thanks,

    Const TWIPS_IN_INCH As Short =3D 1440S
    Dim NewTabPos As Short

    NewTabPos =3D TWIPS_IN_INCH \ 2
    NewTabPos =3D NewTabPos
    NewTabPos =3D NewTabPos + (TWIPS_IN_INCH \ 2)
    NewTabPos +=3D (TWIPS_IN_INCH \ 2)


    --=20
    Greg



  2. #2
    PWilmarth Guest

    Re: Option Strict - picky, but why?


    That's one of the new things in VB.NET . . . strong data types. If you have
    OPTION STRICT ON, which is recommended, then you have to be extremely careful
    with your data types. You have to declare your data type correctly at the
    outset, or you will need to recast your data type inline with CTYPE. If you
    set OPTION STRICT OFF, then the compiler will be more forgiving.

  3. #3
    PWilmarth Guest

    Re: Option Strict - picky, but why?


    Shorts are int16
    Integers are int32
    You are using Integer division, which will return an Integer, not a Short.

    Once again, you have to be very careful about how you declare your numbers
    with OPTION STRICT ON. You can either declare your variables as integers
    or do an inline recast to Short.

  4. #4
    Karl E. Peterson Guest

    Re: Option Strict - picky, but why?

    PWilmarth wrote:
    > Shorts are int16
    > Integers are int32
    > You are using Integer division, which will return an Integer, not a
    > Short.
    >
    > Once again, you have to be very careful about how you declare your
    > numbers with OPTION STRICT ON. You can either declare your variables
    > as integers or do an inline recast to Short.


    The implication here isn't pretty. Does that mean you can't do integer division with
    Long (Int64) variables? Or you can, but the results will always overflow the
    intermediate result? Or...?
    --
    [Microsoft Basic: 1976-2001, RIP]


  5. #5
    Phil Weber Guest

    Re: Option Strict - picky, but why?

    > You are using Integer division, which will return
    > an Integer, not a Short.


    P: Then why doesn't VB complain about the following line?

    NewTabPos = TWIPS_IN_INCH \ 2

    The above is OK, but:

    NewTabPos = NewTabPos + TWIPS_IN_INCH \ 2

    ....causes an error? Changing it to:

    NewTabPos = NewTabPos + CShort(TWIPS_IN_INCH \ 2)

    ....avoids the error. Looks like a bug to me.
    --
    Phil Weber



  6. #6
    Karl E. Peterson Guest

    Re: Option Strict - picky, but why?

    Phil Weber wrote:
    >> You are using Integer division, which will return
    > > an Integer, not a Short.

    >
    > P: Then why doesn't VB complain about the following line?
    >
    > NewTabPos = TWIPS_IN_INCH \ 2
    >
    > The above is OK, but:
    >
    > NewTabPos = NewTabPos + TWIPS_IN_INCH \ 2
    >
    > ...causes an error? Changing it to:
    >
    > NewTabPos = NewTabPos + CShort(TWIPS_IN_INCH \ 2)
    >
    > ...avoids the error. Looks like a bug to me.


    Much better rationalization! :-)
    --
    [Microsoft Basic: 1976-2001, RIP]


  7. #7
    PWilmarth Guest

    Re: Option Strict - picky, but why?


    You very well could be right. I was looking at the nature of the question
    in terms of data types with OPTION STRICT ON. The compiler is going to be
    unforgiving if you mix up your data types.

  8. #8
    Guest

    Re: Option Strict - picky, but why?


    You know, I know that very long debates have been conducted on these message
    boards about the different data types, esp when it comes to numbers. I'm
    retrieving this answer from another message board, so the content is not
    mine, but it does come from MSDN.


    "For numbers, literals without any decimal portion are automatically treated
    as Integers (Int32 or Int64, depending on the size), while values with a
    decimal portion are treated as Doubles. Now, this is just how the literal
    is treated, because the compiler needs to store literal values before they
    are used in equations or, in this case, assigned to a constant. Because of
    this, if your literal exceeds the capabilities of Int64, but is still within
    the valid range for a Decimal value, then appending the type declaration
    character will allow the declare to be handled correctly by the compiler.
    "



  9. #9
    Greg Brunet Guest

    Re: Option Strict - picky, but why?

    "Phil Weber" <pweber@nospam.fawcette.com> wrote in message =
    news:3d878d9a$1@10.1.10.29...
    > > You are using Integer division, which will return=20
    > > an Integer, not a Short.

    >=20
    > P: Then why doesn't VB complain about the following line?
    >=20
    > NewTabPos =3D TWIPS_IN_INCH \ 2
    >=20
    > The above is OK, but:=20
    >=20
    > NewTabPos =3D NewTabPos + TWIPS_IN_INCH \ 2
    >=20
    > ...causes an error? Changing it to:
    >=20
    > NewTabPos =3D NewTabPos + CShort(TWIPS_IN_INCH \ 2)
    >=20
    > ...avoids the error. Looks like a bug to me.
    > --=20
    > Phil Weber
    >=20
    >=20


    Exactly! I have been going thru the pain of keeping everything in it's =
    proper declaration (even to the point that I had to add the "s" to my =
    declaration:
    Const TWIPS_IN_INCH As Short =3D 1440S

    And if I try to use "/" instead of "\", then I know that I need to =
    typecast. However, the docs say that:

    The data type of the result is Byte, Short, Integer, or Long. Any =
    fractional portion is truncated.

    which sounds like it should return the corresponding datatype. I also =
    had tried the CShort() wrapper around the "\" operation in the last two =
    lines, but since the first assignment works, I really shouldn't have to.

    I agree - looks like a bug to me.

    --=20
    Greg



  10. #10
    Greg Brunet Guest

    Re: Option Strict - picky, but why?

    "PWilmarth" <pwilmarth80231@msn.com> wrote in message =
    news:3d87a3e3$1@10.1.10.29...
    >=20
    > You very well could be right. I was looking at the nature of the =

    question
    > in terms of data types with OPTION STRICT ON. The compiler is going to =

    be
    > unforgiving if you mix up your data types.


    Yes - I know about that - and I want that, else I'd leave it out or turn =
    it off. I should have indicated in the subject line that it was =
    (apparently) behaving incorrectly - not that I misunderstood what it was =
    supposed to do.

    --=20
    Greg



  11. #11
    Greg Brunet Guest

    Re: Option Strict - picky, but why?


    <vb.@127.0.0.1> wrote in message news:3d87a64d$1@10.1.10.29...
    >=20
    > You know, I know that very long debates have been conducted on these =

    message
    > boards about the different data types, esp when it comes to numbers. =

    I'm
    > retrieving this answer from another message board, so the content is =

    not
    > mine, but it does come from MSDN.=20
    >=20
    >=20
    > "For numbers, literals without any decimal portion are automatically =

    treated
    > as Integers (Int32 or Int64, depending on the size), while values with =

    a
    > decimal portion are treated as Doubles. Now, this is just how the =

    literal
    > is treated, because the compiler needs to store literal values before =

    they
    > are used in equations or, in this case, assigned to a constant. =

    Because of
    > this, if your literal exceeds the capabilities of Int64, but is still =

    within
    > the valid range for a Decimal value, then appending the type =

    declaration
    > character will allow the declare to be handled correctly by the =

    compiler.
    > "


    Interesting - I think I follow. I changed the statement and now either =
    version works without errors:

    NewTabPos =3D NewTabPos + CShort(TWIPS_IN_INCH \ 2)
    NewTabPos =3D NewTabPos + TWIPS_IN_INCH \ 2S
    NewTabPos +=3D CShort(TWIPS_IN_INCH \ 2)
    NewTabPos +=3D TWIPS_IN_INCH \ 2S

    Now the curious thing is, why does the first statement not need a "2S"?

    NewTabPos =3D TWIPS_IN_INCH \ 2


    --=20
    Greg




  12. #12
    Paul Mc Guest

    Re: Option Strict - picky, but why?


    G'day.


    >P: Then why doesn't VB complain about the following line?
    > NewTabPos = TWIPS_IN_INCH \ 2
    >The above is OK, but:
    > NewTabPos = NewTabPos + TWIPS_IN_INCH \ 2
    >....causes an error? Changing it to:
    > NewTabPos = NewTabPos + CShort(TWIPS_IN_INCH \ 2)
    >....avoids the error. Looks like a bug to me.


    No, because dividing any Short integer by any whole number will give you
    an integer that is in the range of a short.

    Adding a short to an integer (even if it is the result of such a division)
    will potentially overflow the short, thus the error.

    Think that the compiler is just a little more sophisticated than expected,
    sometimes...

    HTH,
    Cheers,
    Paul

  13. #13
    PWilmarth Guest

    Re: Option Strict - picky, but why?


    Course you probably aren't going to believe this, but:

    The compiler automatically treats 2 as an integer.
    Don't exactly know why when you switch to += that it fusses, but you have
    to cast 2 as a short.It might have something to do with the potential for
    trying to stuff a long number into a short. It probably doesn't fuss as much
    the with division because the number will get smaller, not larger. Since
    you are adding twips to newTabPos, this potential exists, and with OPTION
    STRICT ON, the compiler will bark.

    It's a subtle little point about OPTION STRICT ON, it disallows narrowing
    conversions, but allows widening conversions. So, I don't think it's a bug.

  14. #14
    Rune Bivrin Guest

    Re: Option Strict - picky, but why?

    "Greg Brunet" <GBrunet@NOSPAMSemperSoft.com> wrote in
    news:3d87a7e9$1@10.1.10.29:

    >
    > <vb.@127.0.0.1> wrote in message news:3d87a64d$1@10.1.10.29...
    >>
    >> You know, I know that very long debates have been conducted on these

    > message
    >> boards about the different data types, esp when it comes to numbers.

    > I'm
    >> retrieving this answer from another message board, so the content is

    > not
    >> mine, but it does come from MSDN.
    >>
    >>
    >> "For numbers, literals without any decimal portion are automatically

    > treated
    >> as Integers (Int32 or Int64, depending on the size), while values
    >> with

    > a
    >> decimal portion are treated as Doubles. Now, this is just how the

    > literal
    >> is treated, because the compiler needs to store literal values before

    > they
    >> are used in equations or, in this case, assigned to a constant.

    > Because of
    >> this, if your literal exceeds the capabilities of Int64, but is still

    > within
    >> the valid range for a Decimal value, then appending the type

    > declaration
    >> character will allow the declare to be handled correctly by the

    > compiler.
    >> "

    >
    > Interesting - I think I follow. I changed the statement and now
    > either version works without errors:
    >
    > NewTabPos = NewTabPos + CShort(TWIPS_IN_INCH \ 2)
    > NewTabPos = NewTabPos + TWIPS_IN_INCH \ 2S
    > NewTabPos += CShort(TWIPS_IN_INCH \ 2)
    > NewTabPos += TWIPS_IN_INCH \ 2S
    >
    > Now the curious thing is, why does the first statement not need a
    > "2S"?
    >
    > NewTabPos = TWIPS_IN_INCH \ 2
    >
    >


    Probably because the compiler does constant folding. It will evaluate the
    expression in compile time, and see that the result is withing Short
    range.

    Rune

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center