Why integer and int32

[Dan Barclay]

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

[Mark Jerde]

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

[Rob Teixeira]

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

[Dan Barclay]

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

[Rob Teixeira]

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

[Dan Barclay]

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

[Dan Barclay]

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

[Dan Barclay]

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

[Michael Culley]

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

[Kunle Odutola]

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

[Michael Culley]

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

[Dan Barclay]

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

[Michael Culley]

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

[Michael Culley]

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

[Kunle Odutola]

"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