Why integer and int32 - Page 2


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 2 of 11 FirstFirst 1234 ... LastLast
Results 16 to 30 of 155

Thread: Why integer and int32

  1. #16
    Dan Barclay Guest

    Re: Why integer and int32

    On 15 Apr 2002 13:39:54 -0800, "Jason"
    <jason@creative_nospam_corp.com> wrote:

    >
    >The answer is: because VB defines it that way.
    >
    >In VB6, an integer is 16 bits.
    >
    >This does not make much sense on modern machines, so VB7 dropped the 16 bit
    >Integer and went to the 32 bit Integer.


    Uh... what happened when they went to the "modern" DOS, then the
    modern...

    Platform Native size Integer size
    CP/M 8 16
    TRSDOS 8 16
    DOS 16 16
    Win16 16 16
    Win32 32 16

    >This is defined by the language, not the machine.


    You are correct, the language defines data types and their usage, not
    the machine (or os/platform). The language documentation for MS Basic
    has *always* defined Integer as 16 bits. Some other languages define
    data types only with their minimum size, but that is not the case with
    MS Basic.

    >Why is that important? When 64 bit machines arrive, an Integer in VB7 will
    >be 32 bits across all machines, from WinCE machines, to PCs, to Itaniums.


    If they needed a SystemInteger they should have included one. They
    could have done this without breaking anything at all. A new type of
    data requires a new data type.

    > You will be able to run the same code on all three machines without having
    >to worry about the difference in what the machine considers to be an "Integer."


    "without having to worry about the difference"???? You have *got* to
    be kidding!

    The only effect this would have would be on performance and API calls.
    API (clue: I=Interface) will be different for different platforms.

    In this case, people have believed the docs for years, and there is
    likely code that will break with the change. Something like:

    Do
    For bitnum = 0 To 15
    FlagSet = FlagSet Or CheckStatus(bitnum)
    Next
    Loop While Not FlagSet

    will likely hang simply because of the extra leading bits. But, I
    guess they shouldn't worry about it.

    >An Integer in VB will henceforth be 32 bits, until the next major overhaul
    >of the language.


    LOL. Yup. But, then, who knows what *else* will change as well.

    Dan
    Language Stability is a *feature* I wish VB had!
    (#6)
    Error 51
    Error 3
    Error 9
    ....

  2. #17
    Mark Jerde Guest

    Re: Why integer and int32

    Dnb,

    > I don't have my IBM 1620 programming card anymore, but I think that one
    > might have been 12 bits. I know it was something weird (by today's
    > standards, anyway :-)
    >
    > OR was that the PDP-8, sigh...


    IIRC the Control Data Corp. 6400 my college had in 1982 had 60-bit words:
    10 six-bit bytes. The in-memory character set was wierd. Lower-case
    letters took two bytes, a "^" followed by the upper-case letter.
    S^H^E ^S^A^I^D "H^E^L^L^O." for She said "Hello."

    Mark Jerde
    Biometrics - www.idtechpartners.com



  3. #18
    Rob Teixeira Guest

    Re: Why integer and int32


    Dan Barclay <Dan@MVPs.org> wrote:
    >
    > Do
    > For bitnum = 0 To 15
    > FlagSet = FlagSet Or CheckStatus(bitnum)
    > Next
    > Loop While Not FlagSet
    >


    That code has the potential to fail regardless of how many bits the integer
    is, because an integer value is being used in place of a boolean expression
    at the end

    The essense of good is say *exactly* what you mean, don't infer or assume.

    There was a day when BASIC only had three data types: REAL numbers, INTEGER
    numbers, and STRINGS. We're not there anymore

    -Rob

  4. #19
    Dan Barclay Guest

    Re: Why integer and int32

    On 16 Apr 2002 06:10:43 -0800, "Rob Teixeira" <RobTeixeira@@msn.com>
    wrote:

    >> Do
    >> For bitnum = 0 To 15
    >> FlagSet = FlagSet Or CheckStatus(bitnum)
    >> Next
    >> Loop While Not FlagSet
    >>

    >
    >That code has the potential to fail regardless of how many bits the integer
    >is, because an integer value is being used in place of a boolean expression
    >at the end


    The problem is in the unexpected high-end bits when you're doing
    bitlevel operations. It had no potential to fail in any version of MS
    Basic since Do/Loop was added. This is how it works
    http://www.mvps.org/vb/tips/truth.htm


    But, have it your way (though the code won't be written this way in
    the legacy libraries):

    Dim WeBeDone as Boolean
    Do
    For bitnum = 0 To 15
    FlagSet = FlagSet Or CheckStatus(bitnum)
    Next
    If FlagSet=-1 Then
    WeBeDone = True
    End If
    Loop While Not WeBeDone

    The point is that there is code that will convert incorrectly unless
    they mask every subexpression they run across during conversion. If
    they mask every subexpression by rote it'll probably work, but you'd
    never be able to maintain the mess that was left.

    As for using Boolean, yea sometimes you can (though in this case it
    wouldn't have mattered). OTOH, a lot of legacy code was written
    before there *was* a Boolean.

    >The essense of good is say *exactly* what you mean, don't infer or assume.


    I said *exactly* what I meant in the first version of it. I neither
    inferred nor assumed... everything in that fragment was documented to
    work. ****, if I'd used While/Wend instead of Do/Loop it would have
    worked for versions as far back as QB2, as documented.

    >There was a day when BASIC only had three data types: REAL numbers, INTEGER
    >numbers, and STRINGS. We're not there anymore


    There was a day when you could look at a BASIC data type and know ***
    it was! We're not there anymore :{

    Dan
    Language Stability is a *feature* I wish VB had!
    (#6)
    Error 51
    Error 3
    Error 9
    ....

  5. #20
    Rob Teixeira Guest

    Re: Why integer and int32


    Dan Barclay <Dan@MVPs.org> wrote:
    >On 16 Apr 2002 06:10:43 -0800, "Rob Teixeira" <RobTeixeira@@msn.com>
    >wrote:
    >
    >>> Do
    >>> For bitnum = 0 To 15
    >>> FlagSet = FlagSet Or CheckStatus(bitnum)
    >>> Next
    >>> Loop While Not FlagSet
    >>>

    >>
    >>That code has the potential to fail regardless of how many bits the integer
    >>is, because an integer value is being used in place of a boolean expression
    >>at the end

    >
    >The problem is in the unexpected high-end bits when you're doing
    >bitlevel operations.


    Exactly - because
    1) you're *assuming* the datatype size.
    2) you're *assuming* the result of an implicit Number-Boolean conversion
    in the expression

    >It had no potential to fail in any version of MS
    >Basic since Do/Loop was added.


    It very well could have failed in any "MS basic". Nowhere is Flagset declared,
    so for all we know, Flagset could be 32-bit. More assumptions.

    >This is how it works


    I know exactly how it works. I'm explaining it to you

    >http://www.mvps.org/vb/tips/truth.htm


    Posting that (again) won't solve the problem.

    >But, have it your way (though the code won't be written this way in
    >the legacy libraries):


    > Dim WeBeDone as Boolean
    > Do
    > For bitnum = 0 To 15
    > FlagSet = FlagSet Or CheckStatus(bitnum)
    > Next
    > If FlagSet=-1 Then
    > WeBeDone = True
    > End If
    > Loop While Not WeBeDone


    You still missed it. The problem lies in your last line of (original) code,
    not in the other stuff, which is doing correct bitwise math (not boolean
    operations).

    Loop While Flagset <> 0

    Notice the *unimplied* boolean expression. *That* would have worked in ANY
    version. See the difference?

    >The point is that there is code that will convert incorrectly unless
    >they mask every subexpression they run across during conversion. If
    >they mask every subexpression by rote it'll probably work, but you'd
    >never be able to maintain the mess that was left.
    >
    >As for using Boolean, yea sometimes you can (though in this case it
    >wouldn't have mattered). OTOH, a lot of legacy code was written
    >before there *was* a Boolean.


    I think I just showed you the way to handle it without all the added complication
    you seem to infer is necessary.

    >>The essense of good is say *exactly* what you mean, don't infer or assume.

    >
    >I said *exactly* what I meant in the first version of it. I neither
    >inferred nor assumed...


    Read statement at top of post.

    >everything in that fragment was documented to work.


    How so?

    >****, if I'd used While/Wend instead of Do/Loop it would have
    >worked for versions as far back as QB2, as documented.


    The loop isn't the problem.

    >>There was a day when BASIC only had three data types: REAL numbers, INTEGER
    >>numbers, and STRINGS. We're not there anymore

    >
    >There was a day when you could look at a BASIC data type and know ***
    >it was! We're not there anymore :{


    Really? We didn't always have an "As [datatype]" clause in basic, and variables
    had limited character count (like 2 chars in some versions). Given that in
    your program, the variable Z could be a REAL one minute and a STRING the
    next, how would you look at the code variable in any given subroutine and
    know *** it was? Methinks you be using the rose-colored glasses again

    -Rob

  6. #21
    Dan Barclay Guest

    Re: Why integer and int32

    On 16 Apr 2002 13:18:30 -0800, "Rob Teixeira" <RobTeixeira@@msn.com>
    wrote:

    >
    >Dan Barclay <Dan@MVPs.org> wrote:
    >>On 16 Apr 2002 06:10:43 -0800, "Rob Teixeira" <RobTeixeira@@msn.com>
    >>wrote:
    >>
    >>>> Do
    >>>> For bitnum = 0 To 15
    >>>> FlagSet = FlagSet Or CheckStatus(bitnum)
    >>>> Next
    >>>> Loop While Not FlagSet
    >>>>
    >>>
    >>>That code has the potential to fail regardless of how many bits the integer
    >>>is, because an integer value is being used in place of a boolean expression
    >>>at the end

    >>
    >>The problem is in the unexpected high-end bits when you're doing
    >>bitlevel operations.

    >
    >Exactly - because
    >1) you're *assuming* the datatype size.


    Uhhh... because it was documented? Is it safe to assume the datatype
    isn't floating point???? You're beginning to scare me now!

    >2) you're *assuming* the result of an implicit Number-Boolean conversion
    >in the expression


    There is no "number-boolean" conversion. Zero is false, everything
    else is true. That's even the case in C/C++! What's more, logical
    operations are bitwise on numeric values and results are the bitwise
    numeric result.

    >>It had no potential to fail in any version of MS
    >>Basic since Do/Loop was added.

    >
    >It very well could have failed in any "MS basic". Nowhere is Flagset declared,
    >so for all we know, Flagset could be 32-bit. More assumptions.


    Right. Somehow, since the discussion was about Integers I made the
    assumption you understood that. To provide Clarity for the Confused,
    add

    Dim FlagSet as Integer

    at the top of each example.

    >>This is how it works

    >
    >I know exactly how it works. I'm explaining it to you
    >
    >>http://www.mvps.org/vb/tips/truth.htm

    >
    >Posting that (again) won't solve the problem.


    It won't help a thing if you don't read and understand it. You can
    lead a horse to water...

    >>But, have it your way (though the code won't be written this way in
    >>the legacy libraries):

    >
    >> Dim WeBeDone as Boolean
    >> Do
    >> For bitnum = 0 To 15
    >> FlagSet = FlagSet Or CheckStatus(bitnum)
    >> Next
    >> If FlagSet=-1 Then
    >> WeBeDone = True
    >> End If
    >> Loop While Not WeBeDone

    >
    >You still missed it. The problem lies in your last line of (original) code,
    >not in the other stuff, which is doing correct bitwise math (not boolean
    >operations).
    >
    >Loop While Flagset <> 0
    >
    >Notice the *unimplied* boolean expression. *That* would have worked in ANY
    >version. See the difference?


    This is the wrong test and it would loop forever unless all bits are
    set to 0! The objective is to loop until all 16 of the Status bits
    (checked with CheckStatus()) are 1. Or, make up another example that
    uses bitflags if you like.

    The point is that to make this code work you have to rewrite the logic
    of it, not just do a rote translation.

    I take that back, there are rote conversions you can use by adding
    masks to the subexpressions. Unfortunately, a converter wouldn't know
    where the masks were not needed so it would add them all over the
    place. The result would be a nearly impossible to read code fragment.

    >>The point is that there is code that will convert incorrectly unless
    >>they mask every subexpression they run across during conversion. If
    >>they mask every subexpression by rote it'll probably work, but you'd
    >>never be able to maintain the mess that was left.
    >>
    >>As for using Boolean, yea sometimes you can (though in this case it
    >>wouldn't have mattered). OTOH, a lot of legacy code was written
    >>before there *was* a Boolean.

    >
    >I think I just showed you the way to handle it without all the added complication
    >you seem to infer is necessary.


    Your code, unfortunately, is every bit as useful as the translator.
    It won't work. It isn't a matter of "can I make it work differently".
    I can rewrite any code I want. The issue is whether code will work
    the same when it's moved. The answer is: maybe it will, maybe it
    won't.

    >>>The essense of good is say *exactly* what you mean, don't infer or assume.

    >>
    >>I said *exactly* what I meant in the first version of it. I neither
    >>inferred nor assumed...

    >
    >Read statement at top of post.
    >
    >>everything in that fragment was documented to work.

    >
    >How so?


    In every prior version of VB (or DOS versions of MS Basic for that
    matter) documented the data types, operator behavior, and logical
    tests that were used. I made no use of undocumented side-effects.

    >>****, if I'd used While/Wend instead of Do/Loop it would have
    >>worked for versions as far back as QB2, as documented.

    >
    >The loop isn't the problem.


    I agree. The point is that the rest of it would work in versions back
    at least as far as QB2. The logical and bitlevel expressions would
    work in CP/M and TRSDOS versions (though I couldn't have a called
    function CheckStatus() in those versions).

    >>>There was a day when BASIC only had three data types: REAL numbers, INTEGER
    >>>numbers, and STRINGS. We're not there anymore

    >>
    >>There was a day when you could look at a BASIC data type and know ***
    >>it was! We're not there anymore :{

    >
    >Really? We didn't always have an "As [datatype]" clause in basic, and variables
    >had limited character count (like 2 chars in some versions).


    Yup. You knew what the data type by the ending character. Clear as a
    bell. How can you be confused by that??? What do *limitations* have
    to do with clarity??? Nothing!

    >Given that in
    >your program, the variable Z could be a REAL one minute and a STRING the
    >next,


    What are you talking about??? Z$ is a string! If you decide to make
    a Z# then it's a double. Sorry, but I don't know how to make a Z$
    that isn't a string.

    >how would you look at the code variable in any given subroutine and
    >know *** it was? Methinks you be using the rose-colored glasses again


    If you know the language, it (was) easy. You're right that now you
    don't know what it is... even if it's declared!

    Dim MyInt as Integer

    What is that data type????

    Dan
    Language Stability is a *feature* I wish VB had!
    (#6)
    Error 51
    Error 3
    Error 9
    ....

  7. #22
    Dan Barclay Guest

    Re: Why integer and int32

    On Wed, 17 Apr 2002 12:27:39 +1000, "Michael Culley"
    <mike@vbdotcom.com> wrote:

    >> There is no "number-boolean" conversion. Zero is false, everything
    >> else is true. That's even the case in C/C++! What's more, logical
    >> operations are bitwise on numeric values and results are the bitwise
    >> numeric result.

    >
    >There definately is an implied number to boolean conversion.


    It's not *implied*, it's *defined*. That is the definition of "truth"
    (lower case) in these two languages. For tests of truth, zero is
    false, nonzero is true.

    http://www.mvps.org/vb/tips/truth.htm

    or look it up in the docs.

    Dan

    Language Stability is a *feature* I wish VB had!
    (#6)
    Error 51
    Error 3
    Error 9
    ....

  8. #23
    Dan Barclay Guest

    Re: Why integer and int32

    On Wed, 17 Apr 2002 03:49:12 +0100, "Kunle Odutola"
    <kunle.odutola@<REMOVETHIS>okocha.freeserve.co.uk> wrote:

    >> This is the wrong test and it would loop forever unless all bits are
    >> set to 0! The objective is to loop until all 16 of the Status bits
    >> (checked with CheckStatus()) are 1. Or, make up another example that
    >> uses bitflags if you like.

    >
    >Ooooooooooohh. So that what it's supposed to be doing....**** I'm better
    >than the upgrade wizard (as is Rob clearly)


    Right, and you still missed it, even though it's only a few lines and
    behavior is clearly defined in all previous versions of the language.
    That's exactly the point. When you have to revisit old code you're as
    likely to break it as convert it correctly.

    >but, I'd hate to spend so much
    >time figuring out code that could have been better written.


    Any code can be better written, what's your point? My points are that

    (1) there is code out there that will behave differently with
    different data sizes, and you won't know which code it is ahead of
    time.
    (2) the upgrade wizard (and apparently programmers who fancy
    themselves as competent) is likely to muck it up.

    I don't know how you could have made my point any better.

    >;-)


    Indeed.

    >So the test is "FlagTest = -1". Still clearer than the original code
    >fragment and your intentionally obtuse second version.


    The world is full of obtuse code that works. In fact, there is a lot
    of it that deserves to never be touched again simply because it's so
    ugly. That's why MS would die if we somehow changed their own
    language. Sources tell me there is code inside Office as well as OS
    products that folks may never figure out if they have to go back into
    it.

    Dan
    Language Stability is a *feature* I wish VB had!
    (#6)
    Error 51
    Error 3
    Error 9
    ....

  9. #24
    Michael Culley Guest

    Re: Why integer and int32

    > There is no "number-boolean" conversion. Zero is false, everything
    > else is true. That's even the case in C/C++! What's more, logical
    > operations are bitwise on numeric values and results are the bitwise
    > numeric result.


    There definately is an implied number to boolean conversion.

    --
    Michael Culley
    www.vbdotcom.com



    "Dan Barclay" <Dan@MVPs.org> wrote in message
    news:874pbu81pjkjmkq7uucn7do9h5p9hi5gis@4ax.com...
    > On 16 Apr 2002 13:18:30 -0800, "Rob Teixeira" <RobTeixeira@@msn.com>
    > wrote:
    >
    > >
    > >Dan Barclay <Dan@MVPs.org> wrote:
    > >>On 16 Apr 2002 06:10:43 -0800, "Rob Teixeira" <RobTeixeira@@msn.com>
    > >>wrote:
    > >>
    > >>>> Do
    > >>>> For bitnum = 0 To 15
    > >>>> FlagSet = FlagSet Or CheckStatus(bitnum)
    > >>>> Next
    > >>>> Loop While Not FlagSet
    > >>>>
    > >>>
    > >>>That code has the potential to fail regardless of how many bits the

    integer
    > >>>is, because an integer value is being used in place of a boolean

    expression
    > >>>at the end
    > >>
    > >>The problem is in the unexpected high-end bits when you're doing
    > >>bitlevel operations.

    > >
    > >Exactly - because
    > >1) you're *assuming* the datatype size.

    >
    > Uhhh... because it was documented? Is it safe to assume the datatype
    > isn't floating point???? You're beginning to scare me now!
    >
    > >2) you're *assuming* the result of an implicit Number-Boolean conversion
    > >in the expression

    >
    > There is no "number-boolean" conversion. Zero is false, everything
    > else is true. That's even the case in C/C++! What's more, logical
    > operations are bitwise on numeric values and results are the bitwise
    > numeric result.
    >
    > >>It had no potential to fail in any version of MS
    > >>Basic since Do/Loop was added.

    > >
    > >It very well could have failed in any "MS basic". Nowhere is Flagset

    declared,
    > >so for all we know, Flagset could be 32-bit. More assumptions.

    >
    > Right. Somehow, since the discussion was about Integers I made the
    > assumption you understood that. To provide Clarity for the Confused,
    > add
    >
    > Dim FlagSet as Integer
    >
    > at the top of each example.
    >
    > >>This is how it works

    > >
    > >I know exactly how it works. I'm explaining it to you
    > >
    > >>http://www.mvps.org/vb/tips/truth.htm

    > >
    > >Posting that (again) won't solve the problem.

    >
    > It won't help a thing if you don't read and understand it. You can
    > lead a horse to water...
    >
    > >>But, have it your way (though the code won't be written this way in
    > >>the legacy libraries):

    > >
    > >> Dim WeBeDone as Boolean
    > >> Do
    > >> For bitnum = 0 To 15
    > >> FlagSet = FlagSet Or CheckStatus(bitnum)
    > >> Next
    > >> If FlagSet=-1 Then
    > >> WeBeDone = True
    > >> End If
    > >> Loop While Not WeBeDone

    > >
    > >You still missed it. The problem lies in your last line of (original)

    code,
    > >not in the other stuff, which is doing correct bitwise math (not boolean
    > >operations).
    > >
    > >Loop While Flagset <> 0
    > >
    > >Notice the *unimplied* boolean expression. *That* would have worked in

    ANY
    > >version. See the difference?

    >
    > This is the wrong test and it would loop forever unless all bits are
    > set to 0! The objective is to loop until all 16 of the Status bits
    > (checked with CheckStatus()) are 1. Or, make up another example that
    > uses bitflags if you like.
    >
    > The point is that to make this code work you have to rewrite the logic
    > of it, not just do a rote translation.
    >
    > I take that back, there are rote conversions you can use by adding
    > masks to the subexpressions. Unfortunately, a converter wouldn't know
    > where the masks were not needed so it would add them all over the
    > place. The result would be a nearly impossible to read code fragment.
    >
    > >>The point is that there is code that will convert incorrectly unless
    > >>they mask every subexpression they run across during conversion. If
    > >>they mask every subexpression by rote it'll probably work, but you'd
    > >>never be able to maintain the mess that was left.
    > >>
    > >>As for using Boolean, yea sometimes you can (though in this case it
    > >>wouldn't have mattered). OTOH, a lot of legacy code was written
    > >>before there *was* a Boolean.

    > >
    > >I think I just showed you the way to handle it without all the added

    complication
    > >you seem to infer is necessary.

    >
    > Your code, unfortunately, is every bit as useful as the translator.
    > It won't work. It isn't a matter of "can I make it work differently".
    > I can rewrite any code I want. The issue is whether code will work
    > the same when it's moved. The answer is: maybe it will, maybe it
    > won't.
    >
    > >>>The essense of good is say *exactly* what you mean, don't infer or

    assume.
    > >>
    > >>I said *exactly* what I meant in the first version of it. I neither
    > >>inferred nor assumed...

    > >
    > >Read statement at top of post.
    > >
    > >>everything in that fragment was documented to work.

    > >
    > >How so?

    >
    > In every prior version of VB (or DOS versions of MS Basic for that
    > matter) documented the data types, operator behavior, and logical
    > tests that were used. I made no use of undocumented side-effects.
    >
    > >>****, if I'd used While/Wend instead of Do/Loop it would have
    > >>worked for versions as far back as QB2, as documented.

    > >
    > >The loop isn't the problem.

    >
    > I agree. The point is that the rest of it would work in versions back
    > at least as far as QB2. The logical and bitlevel expressions would
    > work in CP/M and TRSDOS versions (though I couldn't have a called
    > function CheckStatus() in those versions).
    >
    > >>>There was a day when BASIC only had three data types: REAL numbers,

    INTEGER
    > >>>numbers, and STRINGS. We're not there anymore
    > >>
    > >>There was a day when you could look at a BASIC data type and know ***
    > >>it was! We're not there anymore :{

    > >
    > >Really? We didn't always have an "As [datatype]" clause in basic, and

    variables
    > >had limited character count (like 2 chars in some versions).

    >
    > Yup. You knew what the data type by the ending character. Clear as a
    > bell. How can you be confused by that??? What do *limitations* have
    > to do with clarity??? Nothing!
    >
    > >Given that in
    > >your program, the variable Z could be a REAL one minute and a STRING the
    > >next,

    >
    > What are you talking about??? Z$ is a string! If you decide to make
    > a Z# then it's a double. Sorry, but I don't know how to make a Z$
    > that isn't a string.
    >
    > >how would you look at the code variable in any given subroutine and
    > >know *** it was? Methinks you be using the rose-colored glasses again

    >
    > If you know the language, it (was) easy. You're right that now you
    > don't know what it is... even if it's declared!
    >
    > Dim MyInt as Integer
    >
    > What is that data type????
    >
    > Dan
    > Language Stability is a *feature* I wish VB had!
    > (#6)
    > Error 51
    > Error 3
    > Error 9
    > ...




  10. #25
    Kunle Odutola Guest

    Re: Why integer and int32


    "Dan Barclay" <Dan@MVPs.org> wrote in message
    news:874pbu81pjkjmkq7uucn7do9h5p9hi5gis@4ax.com...



    > >>But, have it your way (though the code won't be written this way in
    > >>the legacy libraries):

    > >
    > >> Dim WeBeDone as Boolean
    > >> Do
    > >> For bitnum = 0 To 15
    > >> FlagSet = FlagSet Or CheckStatus(bitnum)
    > >> Next
    > >> If FlagSet=-1 Then
    > >> WeBeDone = True
    > >> End If
    > >> Loop While Not WeBeDone

    > >
    > >You still missed it. The problem lies in your last line of (original)

    code,
    > >not in the other stuff, which is doing correct bitwise math (not boolean
    > >operations).
    > >
    > >Loop While Flagset <> 0
    > >
    > >Notice the *unimplied* boolean expression. *That* would have worked in

    ANY
    > >version. See the difference?

    >
    > This is the wrong test and it would loop forever unless all bits are
    > set to 0! The objective is to loop until all 16 of the Status bits
    > (checked with CheckStatus()) are 1. Or, make up another example that
    > uses bitflags if you like.


    Ooooooooooohh. So that what it's supposed to be doing....**** I'm better
    than the upgrade wizard (as is Rob clearly) but, I'd hate to spend so much
    time figuring out code that could have been better written.
    ;-)

    So the test is "FlagTest = -1". Still clearer than the original code
    fragment and your intentionally obtuse second version.

    Kunle

    --------------------------------------------------------------
    "...understandability is next to godliness...."
    - Martin Fowler (www.refactoring.com)



  11. #26
    Michael Culley Guest

    Re: Why integer and int32

    > It's not *implied*, it's *defined*.

    What's defined, the number to boolean conversion? A minute ago there was no
    conversion:

    > >> There is no "number-boolean" conversion.


    --
    Michael Culley
    www.vbdotcom.com



    "Dan Barclay" <Dan@MVPs.org> wrote in message
    news:dulpbucusn9u84ahi9pj1naq3ql9mdnp7l@4ax.com...
    > On Wed, 17 Apr 2002 12:27:39 +1000, "Michael Culley"
    > <mike@vbdotcom.com> wrote:
    >
    > >> There is no "number-boolean" conversion. Zero is false, everything
    > >> else is true. That's even the case in C/C++! What's more, logical
    > >> operations are bitwise on numeric values and results are the bitwise
    > >> numeric result.

    > >
    > >There definately is an implied number to boolean conversion.

    >
    > It's not *implied*, it's *defined*. That is the definition of "truth"
    > (lower case) in these two languages. For tests of truth, zero is
    > false, nonzero is true.
    >
    > http://www.mvps.org/vb/tips/truth.htm
    >
    > or look it up in the docs.
    >
    > Dan
    >
    > Language Stability is a *feature* I wish VB had!
    > (#6)
    > Error 51
    > Error 3
    > Error 9
    > ...




  12. #27
    Dan Barclay Guest

    Re: Why integer and int32

    On Wed, 17 Apr 2002 13:25:48 +1000, "Michael Culley"
    <mike@vbdotcom.com> wrote:

    >> It's not *implied*, it's *defined*.

    >
    >What's defined, the number to boolean conversion? A minute ago there was no
    >conversion:


    What do you consider boolean? FWIW, boolean logic is only
    *represented* in computers. Various methods are used for this, but
    what is "true" and what is "false" is defined.

    MS Basic tests for "true" by observing a numeric value. That value is
    tested "true" if it is nonzero, "false" if it is zero. There is no
    conversion of the number.

    Oh, wait. When they created the Boolean *data type* the definition of
    that was that it would represent a *numeric* value of -1 or a
    *numeric* value of zero when set, so there is a conversion from
    Boolean to numeric. Still, the definition of "true" in MS Basic is
    based on numeric comparisons.

    Again, I recommend http://www.mvps.org/vb/tips/truth.htm

    >> >> There is no "number-boolean" conversion.


    Correct for the example I posted. Everything is numeric in that
    example.

    Dan

    Language Stability is a *feature* I wish VB had!
    (#6)
    Error 51
    Error 3
    Error 9
    ....

  13. #28
    Michael Culley Guest

    Re: Why integer and int32

    > MS Basic tests for "true" by observing a numeric value. That value is
    > tested "true" if it is nonzero, "false" if it is zero. There is no
    > conversion of the number.


    Are you talking about MS basic as in Visual basic 5 or 6? If so when you
    assign an integer to a boolean variable it converts it from whatever value
    it has to either 0 or -1. You can copymem a value into and out of a boolean
    and it will retain its full value and vb will continue to work, but when you
    assign an integer to a boolean there is definately a conversion.

    > Correct for the example I posted. Everything is numeric in that
    > example.


    This sample?

    --
    Michael Culley
    www.vbdotcom.com


    "Dan Barclay" <Dan@MVPs.org> wrote in message
    news:0sspbu4tedsm2ngg4o1c2e5dbmm33jg3k0@4ax.com...
    > On Wed, 17 Apr 2002 13:25:48 +1000, "Michael Culley"
    > <mike@vbdotcom.com> wrote:
    >
    > >> It's not *implied*, it's *defined*.

    > >
    > >What's defined, the number to boolean conversion? A minute ago there was

    no
    > >conversion:

    >
    > What do you consider boolean? FWIW, boolean logic is only
    > *represented* in computers. Various methods are used for this, but
    > what is "true" and what is "false" is defined.
    >
    > MS Basic tests for "true" by observing a numeric value. That value is
    > tested "true" if it is nonzero, "false" if it is zero. There is no
    > conversion of the number.
    >
    > Oh, wait. When they created the Boolean *data type* the definition of
    > that was that it would represent a *numeric* value of -1 or a
    > *numeric* value of zero when set, so there is a conversion from
    > Boolean to numeric. Still, the definition of "true" in MS Basic is
    > based on numeric comparisons.
    >
    > Again, I recommend http://www.mvps.org/vb/tips/truth.htm
    >
    > >> >> There is no "number-boolean" conversion.

    >
    > Correct for the example I posted. Everything is numeric in that
    > example.
    >
    > Dan
    >
    > Language Stability is a *feature* I wish VB had!
    > (#6)
    > Error 51
    > Error 3
    > Error 9
    > ...




  14. #29
    Michael Culley Guest

    Re: Why integer and int32

    ****, hit control-enter while pasting, I hate that!

    > > Correct for the example I posted. Everything is numeric in that
    > > example.

    >
    > This sample?


    Do
    For bitnum = 0 To 15
    FlagSet = FlagSet Or CheckStatus(bitnum)
    Next
    Loop While Not FlagSet


    Assuming that everything is defined as integer there is still a conversion
    from integer to boolean on the last line.

    --
    Michael Culley
    www.vbdotcom.com



  15. #30
    Kunle Odutola Guest

    Re: Why integer and int32


    "Dan Barclay" <Dan@MVPs.org> wrote in message
    news:h3mpbuoo5i4dqakl5gqr5tbl94qupmn87r@4ax.com...

    > >Ooooooooooohh. So that what it's supposed to be doing....**** I'm better
    > >than the upgrade wizard (as is Rob clearly)

    >
    > Right, and you still missed it,


    No. I didn't miss. I just didn't bother trying to figure it out. There are
    better ways to write it and you chose a style that was compatible with
    [hasn't been changed since?] a language you used 20 years ago. See Micheal's
    comments about boolean/integral datatypes and conversions in VB to see what
    options you've had for years.

    I see your sarcasm sensor array odule is offline today. My comments were
    about the [lack of] "understandability" qualities in the code fragment....

    > even though it's only a few lines and
    > behavior is clearly defined in all previous versions of the language.
    > That's exactly the point. When you have to revisit old code you're as
    > likely to break it as convert it correctly.


    *Some* old code Dan. Ony _some_ old code might not convert correctly. Even
    flesh & blood developers might miss the logic you've [intentionally]
    obscured in your code. What chance an automated tool hey? [Although this
    would be converted correctly]

    > >but, I'd hate to spend so much
    > >time figuring out code that could have been better written.

    >
    > Any code can be better written, what's your point? My points are that


    If your code assets are so valuable, why not spend the time writing them
    better?. It doesn't make them run any faster but it reduces the cost of
    maintaining them [clue: programs are read by people not machines, people
    need to understand it before they can fix, upgrade, enhance, replace,
    optinmize....].

    > (1) there is code out there that will behave differently with
    > different data sizes, and you won't know which code it is ahead of
    > time.


    It will behave differently in VB.NET than VB6. It has changed and this
    change of behaviour is *defined* too, so what your point?

    Incidentally, if that was declared as an "Integer". The wizard will have
    upgraded it correctly to "Short". Result, code still works.

    > (2) the upgrade wizard (and apparently programmers who fancy
    > themselves as competent) is likely to muck it up.


    Obsfucated C programmers don't complain when no-one understands their code.
    In fact they're proud of it. Why aren't you?

    > I don't know how you could have made my point any better.
    >
    > >;-)


    Or you mine.
    ;-)


    > Indeed.
    >
    > >So the test is "FlagTest = -1". Still clearer than the original code
    > >fragment and your intentionally obtuse second version.

    >
    > The world is full of obtuse code that works. In fact, there is a lot
    > of it that deserves to never be touched again simply because it's so
    > ugly. That's why MS would die if we somehow changed their own
    > language. Sources tell me there is code inside Office as well as OS
    > products that folks may never figure out if they have to go back into
    > it.


    I can well believe [some of] that giving the copious amounts of C/C++ and
    assembler employed in those products. But writing obtuse code in BASIC?. Get
    outta here........no really, I mean it. And don't come back until you've
    cleaned up your code <g>

    Kunle



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