By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,990 Members | 2,279 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,990 IT Pros & Developers. It's quick & easy.

AndAlso & OrElse

P: n/a
I kinda just stumbled across these operators, they seem great, as you can forget the second expression depending on the result of the first, but are there any cons to using these?

From my viewpoint it seems I can pretty much to a find / replace on my existing code and pick up a performance boost, but something seems fishy that I really never see other people using these!

Thanks for any insight!
--Michael
Nov 20 '05 #1
Share this Question
Share on Google+
16 Replies


P: n/a
Raterus,

No consequences at all.

Only it looks so strange that most people forget it.

Cor

I kinda just stumbled across these operators, they seem great, as you can
forget the second expression depending on the result of the first, but are
there any cons to using these?

From my viewpoint it seems I can pretty much to a find / replace on my
existing code and pick up a performance boost, but something seems fishy
that I really never see other people using these!
Nov 20 '05 #2

P: n/a
My two cents - I think they are great operators and I use them all the time.
Like yourself, I stumbled upon them, and was a little cautious at first. I
believe people don't use them because they don't really know they exist.
"Raterus" <ra*****@spam.org> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
I kinda just stumbled across these operators, they seem great, as you can
forget the second expression depending on the result of the first, but are
there any cons to using these?

From my viewpoint it seems I can pretty much to a find / replace on my
existing code and pick up a performance boost, but something seems fishy
that I really never see other people using these!

Thanks for any insight!
--Michael

Nov 20 '05 #3

P: n/a
The con is if the logic in your IF statement depends on all the conditions
being tested.

-Carl
"Raterus" <ra*****@spam.org> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
I kinda just stumbled across these operators, they seem great, as you can
forget the second expression depending on the result of the first, but are
there any cons to using these?

From my viewpoint it seems I can pretty much to a find / replace on my
existing code and pick up a performance boost, but something seems fishy
that I really never see other people using these!

Thanks for any insight!
--Michael

Nov 20 '05 #4

P: n/a

"Raterus" <ra*****@spam.org> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
I kinda just stumbled across these operators, they seem great, as you can
forget the second expression depending on the result of the first, but are
there any cons to using these?


Interesting you shouild mention you just "stumbled across" them, because
they were touted as a new feature of VB.NET. Finally VB got true
short-ciruiting. Perhaps they weren't touted loudly or perhaps you weren't a
VB6 person and therefore never looked into the "new features" news.

The classic example of the main con to using these operators is when you do
something stupid like change the state of your application during a test. In
VB, that would basically mean that your If clause would have to contain a
function call as one of its (second or later) tests and that function call
would "do something," like changing the value of a variable, as opposed to
just testing and returning a result. This is generally considered bad
programming practice anyway, so there is virutally no down side to these
operators.
Nov 20 '05 #5

P: n/a
> Jeff Johnson [MVP: VB]wrote:
"]"Raterus" <ra*****@spam.org> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

I kinda just stumbled across these operators, they seem great, as you can forget the second expression depending on the result of the first, but are there any cons to using these?

Interesting you shouild mention you just "stumbled across" them,
because
they were touted as a new feature of VB.NET. Finally VB got true
short-ciruiting. Perhaps they weren't touted loudly or perhaps you
weren't a
VB6 person and therefore never looked into the "new features" news.

The classic example of the main con to using these operators is when
you do
something stupid like change the state of your application during a
test. In
VB, that would basically mean that your If clause would have to
contain a
function call as one of its (second or later) tests and that function
call
would "do something," like changing the value of a variable, as
opposed to
just testing and returning a result. This is generally considered bad
programming practice anyway, so there is virutally no down side to
these
operators.[/quote:f21cad2431]

They were loudly touted when the operators were still "And" and "Or".
When many old-school VB programmers protested that their 'side-effect'
style of coding would be circumvented, so Microsoft relented and kept
"And" and "Or" behaving as in VB6, i.e., no short-circuiting. Then
the modern programmers protested that they wanted the short
circuiting, so Microsoft relented and added back short circuiting,
but as "AndAlso" and "OrElse" to try to keep everyone happy. (a
classic case illustrating why VB is like it is today).

Nov 20 '05 #6

P: n/a
Bob
I got into an argument with someone from MS over why they didn't make
short-circuiting logical operators the default so you didn't need the
longer-to-type, rather goofy-sounding AndAlso/OrElse. They said it would
"break existing code". Yet this rings false to me; when they first released
DotNet they didn't *have* any existing code. And even if there was any, the
only things that would break deserved to break. Or throw an autoreplace
feature in the useless Upgrade Wizard. I can think of no good reason
whatsoever to create code that depends on non-short-circuiting logical
operators. Haven't all languages (aside from pre-NET VB) short-circuited
since the creation of computers? Now that they set it one way, though, we're
probably going to have to live with this (IMHO) asinine VB "feature"
forever.

Bob

"Jeff Johnson [MVP: VB]" <i.***@enough.spam> wrote in message
news:uP**************@TK2MSFTNGP12.phx.gbl...

"Raterus" <ra*****@spam.org> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
I kinda just stumbled across these operators, they seem great, as you can forget the second expression depending on the result of the first, but are there any cons to using these?
Interesting you shouild mention you just "stumbled across" them, because
they were touted as a new feature of VB.NET. Finally VB got true
short-ciruiting. Perhaps they weren't touted loudly or perhaps you weren't

a VB6 person and therefore never looked into the "new features" news.

The classic example of the main con to using these operators is when you do something stupid like change the state of your application during a test. In VB, that would basically mean that your If clause would have to contain a
function call as one of its (second or later) tests and that function call
would "do something," like changing the value of a variable, as opposed to
just testing and returning a result. This is generally considered bad
programming practice anyway, so there is virutally no down side to these
operators.


Nov 20 '05 #7

P: n/a
Bob
I got into an argument with someone from MS over why they didn't make
short-circuiting logical operators the default so you didn't need the
longer-to-type, rather goofy-sounding AndAlso/OrElse. They said it would
"break existing code". Yet this rings false to me; when they first released
DotNet they didn't *have* any existing code. And even if there was any, the
only things that would break deserved to break. Or throw an autoreplace
feature in the useless Upgrade Wizard. I can think of no good reason
whatsoever to create code that depends on non-short-circuiting logical
operators. Haven't all languages (aside from pre-NET VB) short-circuited
since the creation of computers? Now that they set it one way, though, we're
probably going to have to live with this (IMHO) asinine VB "feature"
forever.

Bob

"Jeff Johnson [MVP: VB]" <i.***@enough.spam> wrote in message
news:uP**************@TK2MSFTNGP12.phx.gbl...

"Raterus" <ra*****@spam.org> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
I kinda just stumbled across these operators, they seem great, as you can forget the second expression depending on the result of the first, but are there any cons to using these?
Interesting you shouild mention you just "stumbled across" them, because
they were touted as a new feature of VB.NET. Finally VB got true
short-ciruiting. Perhaps they weren't touted loudly or perhaps you weren't

a VB6 person and therefore never looked into the "new features" news.

The classic example of the main con to using these operators is when you do something stupid like change the state of your application during a test. In VB, that would basically mean that your If clause would have to contain a
function call as one of its (second or later) tests and that function call
would "do something," like changing the value of a variable, as opposed to
just testing and returning a result. This is generally considered bad
programming practice anyway, so there is virutally no down side to these
operators.


Nov 20 '05 #8

P: n/a

"Bob" <no****@nowhere.com> wrote in message
news:Os**************@tk2msftngp13.phx.gbl...
I got into an argument with someone from MS over why they didn't make
short-circuiting logical operators the default so you didn't need the
longer-to-type, rather goofy-sounding AndAlso/OrElse. They said it would
"break existing code". Yet this rings false to me; when they first released DotNet they didn't *have* any existing code. And even if there was any, the only things that would break deserved to break. Or throw an autoreplace
feature in the useless Upgrade Wizard. I can think of no good reason
whatsoever to create code that depends on non-short-circuiting logical
operators. Haven't all languages (aside from pre-NET VB) short-circuited
since the creation of computers?


Many languages have different operators for Boolean operations vs. bitwise
operations, for example C[++/#]'s | and ||, and & and &&. VB did not, until
now. I don't have a problem with the new names.
Nov 20 '05 #9

P: n/a
heh, if you search around you will find some other rants on this subject. The
big thing came down to separating the bit-wise and logical operators. In the
early betas, they implemented the BitAnd, BitOr, etc. to replace the old And,
Or, and instead implement those as true Logical operators as they are most
commonly used. However, in the end they gave in to whining from old school VB
programmers (and newbie's who don't know better yet) who have come to rely on
the oftentimes too flexible and vague stuff VB would let you get away with. So
they removed the explicit bit-wise operators and kept them as And/Or/etc. So
even though you are using them as logical, they are really bit-wise. This still
required the addition of the short-circuit operator AndAlso/OrElse.

Personally, I would have much preferred the separation of the operators, and I
know I'm not alone. However, in the end I think we were in the minority.

Gerald

"Bob" <no****@nowhere.com> wrote in message
news:Os**************@tk2msftngp13.phx.gbl...
I got into an argument with someone from MS over why they didn't make
short-circuiting logical operators the default so you didn't need the
longer-to-type, rather goofy-sounding AndAlso/OrElse. They said it would
"break existing code". Yet this rings false to me; when they first released
DotNet they didn't *have* any existing code. And even if there was any, the
only things that would break deserved to break. Or throw an autoreplace
feature in the useless Upgrade Wizard. I can think of no good reason
whatsoever to create code that depends on non-short-circuiting logical
operators. Haven't all languages (aside from pre-NET VB) short-circuited
since the creation of computers? Now that they set it one way, though, we're
probably going to have to live with this (IMHO) asinine VB "feature"
forever.

Bob

"Jeff Johnson [MVP: VB]" <i.***@enough.spam> wrote in message
news:uP**************@TK2MSFTNGP12.phx.gbl...

"Raterus" <ra*****@spam.org> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
I kinda just stumbled across these operators, they seem great, as you can forget the second expression depending on the result of the first, but are there any cons to using these?


Interesting you shouild mention you just "stumbled across" them, because
they were touted as a new feature of VB.NET. Finally VB got true
short-ciruiting. Perhaps they weren't touted loudly or perhaps you weren't

a
VB6 person and therefore never looked into the "new features" news.

The classic example of the main con to using these operators is when you

do
something stupid like change the state of your application during a test.

In
VB, that would basically mean that your If clause would have to contain a
function call as one of its (second or later) tests and that function call
would "do something," like changing the value of a variable, as opposed to
just testing and returning a result. This is generally considered bad
programming practice anyway, so there is virutally no down side to these
operators.

Nov 20 '05 #10

P: n/a
"Raterus" <ra*****@spam.org> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
I kinda just stumbled across these operators, they seem great, as you can forget the second expression depending on the result of the first, but are there any cons to

using these?

Only their obscurity, I guess.

Personally, I use them WAY more than the regular versions. Almost
exclusively, in fact. I might even argue that they should be the default
behavior, same as Bob. I do have a number of cases where evaluating both
sides is desirable, but not very many!

I can understand the MS position on backward compatibility, since before
VB.NET there was VB6, and no shortcut operators. I guess that is the
compatibility they were concerned about. The "feature" dates all the way
back to Dartmouth BASIC - doesn't have much to do with MS, since Bill was in
diapers at the time. :-)

I'm not able to think of a single con against their use.

Best Regards,

Andy
Nov 20 '05 #11

P: n/a

"Bob" <no****@nowhere.com> wrote in message
news:Os**************@tk2msftngp13.phx.gbl...
I got into an argument with someone from MS over why they didn't make
short-circuiting logical operators the default so you didn't need the
longer-to-type, rather goofy-sounding AndAlso/OrElse. They said it would
"break existing code". Yet this rings false to me; when they first released DotNet they didn't *have* any existing code. And even if there was any, the only things that would break deserved to break. Or throw an autoreplace
feature in the useless Upgrade Wizard. I can think of no good reason
whatsoever to create code that depends on non-short-circuiting logical
operators. Haven't all languages (aside from pre-NET VB) short-circuited
since the creation of computers?


Many languages have different operators for Boolean operations vs. bitwise
operations, for example C[++/#]'s | and ||, and & and &&. VB did not, until
now. I don't have a problem with the new names.
Nov 20 '05 #12

P: n/a
heh, if you search around you will find some other rants on this subject. The
big thing came down to separating the bit-wise and logical operators. In the
early betas, they implemented the BitAnd, BitOr, etc. to replace the old And,
Or, and instead implement those as true Logical operators as they are most
commonly used. However, in the end they gave in to whining from old school VB
programmers (and newbie's who don't know better yet) who have come to rely on
the oftentimes too flexible and vague stuff VB would let you get away with. So
they removed the explicit bit-wise operators and kept them as And/Or/etc. So
even though you are using them as logical, they are really bit-wise. This still
required the addition of the short-circuit operator AndAlso/OrElse.

Personally, I would have much preferred the separation of the operators, and I
know I'm not alone. However, in the end I think we were in the minority.

Gerald

"Bob" <no****@nowhere.com> wrote in message
news:Os**************@tk2msftngp13.phx.gbl...
I got into an argument with someone from MS over why they didn't make
short-circuiting logical operators the default so you didn't need the
longer-to-type, rather goofy-sounding AndAlso/OrElse. They said it would
"break existing code". Yet this rings false to me; when they first released
DotNet they didn't *have* any existing code. And even if there was any, the
only things that would break deserved to break. Or throw an autoreplace
feature in the useless Upgrade Wizard. I can think of no good reason
whatsoever to create code that depends on non-short-circuiting logical
operators. Haven't all languages (aside from pre-NET VB) short-circuited
since the creation of computers? Now that they set it one way, though, we're
probably going to have to live with this (IMHO) asinine VB "feature"
forever.

Bob

"Jeff Johnson [MVP: VB]" <i.***@enough.spam> wrote in message
news:uP**************@TK2MSFTNGP12.phx.gbl...

"Raterus" <ra*****@spam.org> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
I kinda just stumbled across these operators, they seem great, as you can forget the second expression depending on the result of the first, but are there any cons to using these?


Interesting you shouild mention you just "stumbled across" them, because
they were touted as a new feature of VB.NET. Finally VB got true
short-ciruiting. Perhaps they weren't touted loudly or perhaps you weren't

a
VB6 person and therefore never looked into the "new features" news.

The classic example of the main con to using these operators is when you

do
something stupid like change the state of your application during a test.

In
VB, that would basically mean that your If clause would have to contain a
function call as one of its (second or later) tests and that function call
would "do something," like changing the value of a variable, as opposed to
just testing and returning a result. This is generally considered bad
programming practice anyway, so there is virutally no down side to these
operators.

Nov 20 '05 #13

P: n/a
"Raterus" <ra*****@spam.org> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
I kinda just stumbled across these operators, they seem great, as you can forget the second expression depending on the result of the first, but are there any cons to

using these?

Only their obscurity, I guess.

Personally, I use them WAY more than the regular versions. Almost
exclusively, in fact. I might even argue that they should be the default
behavior, same as Bob. I do have a number of cases where evaluating both
sides is desirable, but not very many!

I can understand the MS position on backward compatibility, since before
VB.NET there was VB6, and no shortcut operators. I guess that is the
compatibility they were concerned about. The "feature" dates all the way
back to Dartmouth BASIC - doesn't have much to do with MS, since Bill was in
diapers at the time. :-)

I'm not able to think of a single con against their use.

Best Regards,

Andy
Nov 20 '05 #14

P: n/a
> I got into an argument with someone from MS over why they didn't make
short-circuiting logical operators the default so you didn't need the
longer-to-type, rather goofy-sounding AndAlso/OrElse. They said it would
"break existing code". Yet this rings false to me; when they first released
DotNet they didn't *have* any existing code.


Try to tell that to all the people porting VB6 code. (Just let me get my flame-proof suit on first.)

--
Jonathan Allen

Nov 20 '05 #15

P: n/a
Bob
If MS had made AndAlso/OrElse the non-short-circuiting logical operators, it
would have been simply a question of auto-replacement either manually or
through the upgrade wizard.

But really, most VB6 projects of any significant complexity are junk simply
because there are so many fundamental things missing in the language. IMHO
it all begs to be rewritten.

Bob

"Jonathan Allen" <Jo***********@discussions.microsoft.com> wrote in message
news:C6**********************************@microsof t.com...
I got into an argument with someone from MS over why they didn't make
short-circuiting logical operators the default so you didn't need the
longer-to-type, rather goofy-sounding AndAlso/OrElse. They said it would
"break existing code". Yet this rings false to me; when they first released DotNet they didn't *have* any existing code.
Try to tell that to all the people porting VB6 code. (Just let me get my

flame-proof suit on first.)
--
Jonathan Allen


Nov 20 '05 #16

P: n/a
I have to admit, I would rather rewrite it by hand than try to use the
upgrade wizard.

--
Jonathan Allen
"Bob" <no****@nowhere.com> wrote in message
news:eC**************@TK2MSFTNGP10.phx.gbl...
If MS had made AndAlso/OrElse the non-short-circuiting logical operators, it would have been simply a question of auto-replacement either manually or
through the upgrade wizard.

But really, most VB6 projects of any significant complexity are junk simply because there are so many fundamental things missing in the language. IMHO
it all begs to be rewritten.

Bob

Nov 20 '05 #17

This discussion thread is closed

Replies have been disabled for this discussion.