Why integer and int32 - Page 3


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 3 of 11 FirstFirst 12345 ... LastLast
Results 31 to 45 of 155

Thread: Why integer and int32

  1. #31
    Rob Teixeira Guest

    Re: Why integer and int32


    Dan Barclay <Dan@MVPs.org> wrote:
    >
    >Uhhh... because it was documented?


    So is the current behavior.

    >There is no "number-boolean" conversion. Zero is false, everything
    >else is true. That's even the case in C/C++!


    Wait a minute now
    C/C++ has numeric types that periodically change size. Comparing that aspect
    to VB's datatype is "bad". But somehow comparing how both treated boolean=number
    is "good"?
    Seems a bit too convenient, don't you think?

    >What's more, logical
    >operations are bitwise on numeric values and results are the bitwise
    >numeric result.


    Because they're not logical operations in this case, they are bitwise operations.
    Basic obscures some operations behind a common operator. For example, equasion
    and assignment have the same operator in basic, yet clearly they are not
    performing the same operation.

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


    I know exactly what you're saying, i just don't entirely agree with it.

    >What are you talking about???


    You know precisely what i'm talking about.

    > Dim MyInt as Integer
    >
    >What is that data type????


    An Integer, obviously

    Look Dan, this point has gone around and around hundreds of times.
    You're not making any more headway than any of the previous attempts.
    It's obvious nobody's going to change your mind either, and by now all points
    made are obvious to everyone - so, se la vie. Move on.

    -Rob


  2. #32
    Larry Serflaten Guest

    Re: Why integer and int32

    "Dan Barclay" <Dan@MVPs.org> wrote
    > Again, I recommend http://www.mvps.org/vb/tips/truth.htm


    You keep recommending that page, and I keep wondering why you
    recommend complicating an issue. VB has used bitwise evaluation
    since day one, regaurdless of whether it is in and If statement or not.

    Your statement:

    "First, understand that logical operations and tests are two different things. "

    While true, is misleading.

    From that you attempt to explain that VB makes a distinction between the two.
    You continue on about a 'value-level' comparison that you never define, which
    further complicates the issue, more than is necessary;

    "Enter the Boolean data type. If you are trying to accomplish value-level
    Boolean expression evaluation you can assure you stick with the proper values
    (zero and minus one) by using Boolean variables. In fact, if you do you will
    find that the bitwise operators behave as value level Boolean operators."

    The logical operators (And, Or, Xor, and Not) operate exactly as defined by
    the Intel instruction set. Your 'value-level' operators are imaginary. VB
    operates in a bitwise fashion for all logical operations, regaurdless of the
    variables used, Boolean variables 'behave' no differently.

    That whole page may be an attempt to help answer a few questions, but in
    my opinion it does a better job of confusing the issue. For that reason, I
    would not refer anyone to go read it, even while you bring it up every chance
    you get.

    For an example of VB using bitwise operations, regaurdless of the variables
    used, try this bit of code that shows VB doing bitwise operations on Boolean
    variables:

    Private Declare Sub CopyMem Lib "kernel32" Alias "RtlMoveMemory" _
    (lpTo As Any, lpFrom As Any, ByVal lLen As Long)

    Private Sub Form_Load()
    Dim blnA As Boolean
    Dim TmpA As Integer
    Dim blnB As Boolean
    Dim TmpB As Integer
    Dim lngVar As Long

    Show

    lngVar = 5
    CopyMem blnA, lngVar, 4
    lngVar = 10
    CopyMem blnB, lngVar, 4

    Print blnA; " And "; blnB; " = "; blnA And blnB
    ' True And True = False (Wrong)

    Print blnA; " Or "; blnB; " = "; blnA Or blnB
    ' True Or True = True (Better)

    Print blnA; " Xor "; blnB; " = "; blnA Xor blnB
    ' True Xor True = True (Wrong again)

    End Sub
















  3. #33
    Jason 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.


    No, True is True and False is False. There are no other states in boolean
    logic. C/C++ did what they did because C is essentially a high-level assembler,
    with complete access to everything, straight to the metal.

    In C/C++, logical operators are most definitely NOT bitwise.

    >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????


    Well, heck, that is something you can't even answer in C/C++! What is an
    "int"? The answer is that it changes based on the machine.

    The other answer(s) is that for VB7, it is a 32 bit number. This is actually
    documented too.

    VB7 does not have to be backward compatible with QB2 to be useful. It doesn't
    even have to be backward compatible with VB6 to be useful. In fact, it's
    a whole heck of a lot cleaner as a language if it isn't backward compatible.

    On the other hand, if you think that other people feel as strongly about
    this as you do, why not make a VB6-compatible .NET compiler? You could make
    a bloody fortune, as long as people are willing to pay big bucks to migrate
    their code, rather than maintaining it in VB6 or rewriting.

  4. #34
    Jason Guest

    Re: Why integer and int32


    >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.


    1 is True. Correct? Correct.

    NOT 1 is equivalent to NOT 0000000000000001, or 1111111111111110, or -2.

    -2 is True. Correct?

    So NOT True = True.

    The VB6 way of defining Boolean has caused more subtle errors in code than
    I care to count. I have had long-time programmers tell me there was a bug
    in VB because they came up with a situation where False = True in practice,
    and they had not figured out that it was because of a silly integer error.


    False is False. True is True. Boolean values should be dealt with in a
    Boolean data type, not as an Integer.

  5. #35
    Larry Triezenberg Guest

    Re: Why integer and int32

    -1
    (HTH, you can do the rest of the math)....

    "Jason" <jason@creative_nospam_corp.com> wrote in message
    news:3cbdf2eb$1@10.1.10.29...
    > 1 is True. Correct? Correct.





  6. #36
    Cali LaFollett Guest

    Re: Why integer and int32

    > No, in C and VB6, any integer that is not 0 is True. Therefore, 1 is
    True.
    > So is -1. You CAN use the Boolean data type in VB6, but you are under no
    > obligation to do so. In VB.NET, this situation is rectified.


    With one caveat, Option Strict must be turned On...

    Cal



  7. #37
    Jason Guest

    Re: Why integer and int32


    "Larry Triezenberg" <ltriezenberg@pathsys.com> wrote:
    >-1
    >(HTH, you can do the rest of the math)....
    >
    >"Jason" <jason@creative_nospam_corp.com> wrote in message
    >news:3cbdf2eb$1@10.1.10.29...
    >> 1 is True. Correct? Correct.


    No, in C and VB6, any integer that is not 0 is True. Therefore, 1 is True.
    So is -1. You CAN use the Boolean data type in VB6, but you are under no
    obligation to do so. In VB.NET, this situation is rectified.

  8. #38
    Larry Triezenberg Guest

    Re: Why integer and int32

    Zero is false, anything else is true, the defined value for true being -1
    Sorry to misunderstand your point...

    "Jason" <jason@creative_nospam_corp.com> wrote in message
    news:3cbef75d$1@10.1.10.29...
    > No, in C and VB6, any integer that is not 0 is True. Therefore, 1 is

    True.
    > So is -1. You CAN use the Boolean data type in VB6, but you are under no
    > obligation to do so. In VB.NET, this situation is rectified.




  9. #39
    Dan Barclay Guest

    Re: Why integer and int32

    On Wed, 17 Apr 2002 20:24:45 +1000, "Michael Culley"
    <m_culley@hotmail.com> wrote:

    >> 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?


    MS Basic from CP/M versions and TRSDOS versions. DOS versions
    including IBM Compiled Basic (by MS), QuickBasic, Basic PDS, VB for
    DOS, VB1,2,3,4,5,6.

    Again, I refer you to: http://www.mvps.org/vb/tips/truth.htm

    >If so when you
    >assign an integer to a boolean variable it converts it from whatever value
    >it has to either 0 or -1.


    Correct, if you're using a Boolean *variable*.

    >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.


    Yes, I understand you can copymem into the boolean and it'll retain
    the integer value though I haven't fooled with that. It is what I
    would expect, however.

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

  10. #40
    Dan Barclay Guest

    Re: Why integer and int32

    On Wed, 17 Apr 2002 20:27:36 +1000, "Michael Culley"
    <m_culley@hotmail.com> wrote:

    >****, 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.


    No, the last line does *not* do a conversion from integer to boolean.
    It does a bitwise Not on the integer FlagSet. The result is a
    *number*. The test for True in Basic (as well as C, by the way) is
    that if the *number* is zero the test fails, if it is nonzero, the
    test succeeds (truth).

    Do not be confused by this or you may find yourself making a mistake
    with mixed-bit values (flag values like the example).

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

  11. #41
    Dan Barclay Guest

    Re: Why integer and int32

    On Wed, 17 Apr 2002 10:28:44 -0500, "Larry Serflaten"
    <serflaten@usinternet.com> wrote:

    >"Dan Barclay" <Dan@MVPs.org> wrote
    >> Again, I recommend http://www.mvps.org/vb/tips/truth.htm

    >
    >You keep recommending that page, and I keep wondering why you
    >recommend complicating an issue. VB has used bitwise evaluation
    >since day one, regaurdless of whether it is in and If statement or not.
    >
    >Your statement:
    >
    >"First, understand that logical operations and tests are two different things. "
    >
    >While true, is misleading.


    Misleading? If you don't understand this you are very likely to
    create logical behavior that you do not understand. Tests use the
    "nonzero is true, zero is false" on the numeric *value*, not on the
    bit level (always). Operations are on a bitlevel (always).

    Man, if developers don't get that then they need not go any farther.

    >From that you attempt to explain that VB makes a distinction between the two.
    >You continue on about a 'value-level' comparison that you never define, which
    >further complicates the issue, more than is necessary;


    OK, maybe I can clear that up. "Value level" refers to the value of
    the entire number (variable or literal)... as opposed to bit level.

    >"Enter the Boolean data type. If you are trying to accomplish value-level
    >Boolean expression evaluation you can assure you stick with the proper values
    >(zero and minus one) by using Boolean variables. In fact, if you do you will
    >find that the bitwise operators behave as value level Boolean operators."
    >
    >The logical operators (And, Or, Xor, and Not) operate exactly as defined by
    >the Intel instruction set. Your 'value-level' operators are imaginary. VB
    >operates in a bitwise fashion for all logical operations, regaurdless of the
    >variables used, Boolean variables 'behave' no differently.


    Exactly! All the Boolean data type does is help you (in your brain)
    not worry so much about each bit... simply because all the bits are
    the same. Let me know how I can make this more clear.

    >That whole page may be an attempt to help answer a few questions, but in
    >my opinion it does a better job of confusing the issue. For that reason, I
    >would not refer anyone to go read it, even while you bring it up every chance
    >you get.


    If you have some specific suggestions I'd be glad to get them. I'll
    look the thing over again when things die down a bit here. I don't
    profess to be an author (ain't my gig), but I did get it reviewed by a
    few folks before I posted. It is technically accurate. Still, I'll
    have another look when I get a chance.

    >For an example of VB using bitwise operations, regaurdless of the variables
    >used, try this bit of code that shows VB doing bitwise operations on Boolean
    >variables:
    >
    >Private Declare Sub CopyMem Lib "kernel32" Alias "RtlMoveMemory" _
    > (lpTo As Any, lpFrom As Any, ByVal lLen As Long)
    >
    >Private Sub Form_Load()
    >Dim blnA As Boolean
    >Dim TmpA As Integer
    >Dim blnB As Boolean
    >Dim TmpB As Integer
    >Dim lngVar As Long
    >
    > Show
    >
    > lngVar = 5
    > CopyMem blnA, lngVar, 4
    > lngVar = 10
    > CopyMem blnB, lngVar, 4
    >
    > Print blnA; " And "; blnB; " = "; blnA And blnB
    > ' True And True = False (Wrong)
    >
    > Print blnA; " Or "; blnB; " = "; blnA Or blnB
    > ' True Or True = True (Better)
    >
    > Print blnA; " Xor "; blnB; " = "; blnA Xor blnB
    > ' True Xor True = True (Wrong again)
    >
    >End Sub


    Whoa, Bubba. You're thinking I'm making it confusing? <g> This was
    targeted at people trying to understand the *language*, not all the
    things you can do to get around the language with API <gg>.

    I was talking about logical expressions in context of pure Basic
    Language. This paper was originally written when VB.net had a
    different definition of logical expression evaluation and was for the
    purpose of defining the historical (all, untill then) behavior.

    When you use CopyMem to tweak Booleans to values they're not supposed
    to contain within the language context they're outside the context of
    what I was writing.

    I confess it's an interesting issue and maybe there is some way to put
    that in there, as a sidebar or something.

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

  12. #42
    Dan Barclay Guest

    Re: Why integer and int32

    On Thu, 18 Apr 2002 14:20:58 -0400, "Larry Triezenberg"
    <ltriezenberg@pathsys.com> wrote:

    >Zero is false, anything else is true, the defined value for true being -1


    Now there is something that's confused more than one developer and I
    think a little clarification would help (I know you understand this...
    it's just the presentation).

    "the defined value for true being -1" should read "the defined value
    of True being -1" or "the defined value of the constant True being
    -1".

    Dan

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

  13. #43
    Dan Barclay Guest

    Re: Why integer and int32

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

    >
    >"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.


    Isn't that what I said? I didn't say you couldn't understand it, I
    said you missed it. Do you think someone hired by the hour to convert
    3 megs of code is going to recognize he should "figure it out"?

    That's *exactly* the point... your post indicated you'd looked at it
    and *thought* you understood what it was doing. Yea, if you'd looked
    harder you'd have figured it out... but you didn't.

    >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 chose to post a sample that you're likely to find in code that's
    been around since even VB3 or before. Perhaps even code that was
    migrated from DOS. When you say "a language you used 20 years
    ago...", **** I was using this language *one* year ago as well.

    If you'd just started programming *last* year in VB6 and were doing
    bit level operations, this is the kind of code you'd use... integers
    with boolean operators. The fact that it *also* happened to work 20
    years ago doesn't make code written last year "old fashioned" or "out
    of date" or "in need of rewrite".

    >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]


    Yea, the problem is figuring out *which* old code. Here is one you
    thought (or acted as if) you knew. How many bytes of total code was
    that? How many more bytes to go? Which fragments matter and which
    don't?

    >> >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?.


    This, in fact, is an *excellent* example for that question. You'd
    have found this code (not that ugly, btw) and rewritten it. Before
    rewrite:working. After rewrite:broken.

    > 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....].


    Well, frankly, I didn't have any trouble reading that code. It's
    straight-up MS Basic that would have worked in versions dating back
    many years.

    >> (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?


    The original point I responed to was the statement that having the
    data type change with the OS caused *less* compatibility problems than
    having it stay the same. Check up the message stack.

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


    Really? Would it have known that fragment was VB6 code and not VB.Net
    code? How so?

    >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>


    Give that code a rewrite yourself, and assume it originated as late as
    VB3 (clue: there is a bunch of code originating well before that).

    Dan

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

  14. #44
    Dan Barclay Guest

    Re: Why integer and int32

    On 17 Apr 2002 06:42:48 -0800, "Rob Teixeira" <RobTeixeira@@msn.com>
    wrote:

    >
    >Dan Barclay <Dan@MVPs.org> wrote:
    >>
    >>Uhhh... because it was documented?

    >
    >So is the current behavior.


    Yea, it's a different language. It's not Basic.

    >>There is no "number-boolean" conversion. Zero is false, everything
    >>else is true. That's even the case in C/C++!

    >
    >Wait a minute now
    >C/C++ has numeric types that periodically change size. Comparing that aspect
    >to VB's datatype is "bad". But somehow comparing how both treated boolean=number
    >is "good"?


    (1) the issue we were discussing was the definition of "truth" in the
    language. You contended there was a number-boolean conversion. There
    isn't, in either C or Basic. Both test a numeric value for zero.

    (2) C/C++ has numeric types that are *defined* as changeable. They
    are defined by their *minimum* size only. MS Basic data types have
    always been defined as specific sizes.

    >Seems a bit too convenient, don't you think?


    Yea, that's what you get when C/C++ programmers redefine an existing
    language that they seldom use and do not clearly understand. I've
    offered to help clean up C/C++. Now *there* is a language screaming
    to be cleaned up. I'm certain I could make it almost usable.

    >>What's more, logical
    >>operations are bitwise on numeric values and results are the bitwise
    >>numeric result.

    >
    >Because they're not logical operations in this case, they are bitwise operations.


    Sorry, but you obviously went to a different school than I did. The
    term "bitwise" only defines the scope of the logical operations...
    unless you think And/Or/Xor/etc are arithmetic ops?

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

    >
    >I know exactly what you're saying, i just don't entirely agree with it.


    Sorry you don't agree, but that's the way it's worked in the language.

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

  15. #45
    Dan Barclay Guest

    Re: Why integer and int32

    On 17 Apr 2002 15:01:50 -0800, "Jason"
    <jason@creative_nospam_corp.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.

    >
    >No, True is True and False is False.


    In a perfect world, yea. In computer languages we only *represent*
    the values of true and false.

    >There are no other states in boolean logic.


    Correct. What's left is how (and where) those states are represented.

    > C/C++ did what they did because C is essentially a high-level assembler,
    >with complete access to everything, straight to the metal.


    Sorry, Jason, but *every* language has a defined way of testing for
    truth. Basic and C happen to have the same definition. In *tests*,
    zero is false and everything else is true.

    >In C/C++, logical operators are most definitely NOT bitwise.


    C and C++ have both value-level *and* bitwise operators. Basic has
    only bitwise operators.

    >>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????

    >
    >Well, heck, that is something you can't even answer in C/C++! What is an
    >"int"? The answer is that it changes based on the machine.


    An "int" is defined in those languages only by its minimum size. It
    does *not* change based on machine it changes based on implementation.
    I'd have to dig deeper on this (perhaps some else here knows offhand)
    but I believe the Borland C++ compiler uses 16bits for int even with
    their 32bit compiler. What's more there are constants and sizeof
    functions to determine the size at runtime.

    >The other answer(s) is that for VB7, it is a 32 bit number. This is actually
    >documented too.


    Yea, and the documentation conflicts with earlier documentation of the
    language dating back many years. Unfortunate but true.

    >VB7 does not have to be backward compatible with QB2 to be useful.
    >It doesn't even have to be backward compatible with VB6 to be useful. In fact, it's
    >a whole heck of a lot cleaner as a language if it isn't backward compatible.


    Hey, you should be in charge of the next round as well!

    >On the other hand, if you think that other people feel as strongly about
    >this as you do, why not make a VB6-compatible .NET compiler? You could make
    >a bloody fortune, as long as people are willing to pay big bucks to migrate
    >their code, rather than maintaining it in VB6 or rewriting.


    That's been brought up. The question was even asked of MS if it was
    OK and if they'd keep the legal dogs off the door. Wanna guess the
    answer?

    If the door was open, maybe somebody would do that. Not me though.
    Developer tools aren't my business. My interest is in having a stable
    language I can count on for my business.

    You clearly don't think that's important based on your comment "In
    fact, it's a whole heck of a lot cleaner as a language if it isn't
    backward compatible." If you do create a serious application perhaps
    you can reflect on that when the next crew has new ideas about what "a
    lot cleaner" means.

    If you think everyone believes VB.net is "clean" then you're sadly
    mistaken... there is a long way to go before that happens. Heck, I
    can point to warts all over the place. Enjoy the ride!

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

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