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
16  1761 
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!
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
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
"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.
> 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).
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.
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.
"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.
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.
"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
"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.
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.
"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
> 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
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
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Mike Hale |
last post by:
Is it better to use AndAlso and OrElse by default rather than the regual And
& Or?
MikeH
|
by: A Traveler |
last post by:
I was just curious if anyone knows how the combinations of And/AndAlso and
Or/OrElse compare in terms of performance.
Which takes more work for the system, performing two evaluations on an And
or...
|
by: Lior |
last post by:
Hello .
I know that the AndAlso and OrElse statements are short-circuiting And and
Or statements ,
respectively .
Should I always use (I don't like the word "always" ...) AndAlso instead of...
|
by: =?Utf-8?B?UmljaA==?= |
last post by:
Greetings,
If x = y And m = n The
....
End If
If x = y AndAlso m = n Then
....
End If
|
by: Siegfried Heintze |
last post by:
Are there operators in C# that are the counterparts of "OrElse" and
"AndAlso" that I can use when translating the following program from VB.NET
to C#?
Thanks,
Siegfried
Namespace vbtest...
|
by: Euvin |
last post by:
I am kind of confuse as to how these operators work:
AndAlso and OrElse
Anyone care to explain. Some examples would be great!
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |
