I can say this:
int commandTimeout =
Convert.ToInt32(ConfigurationSettings.AppSettings["commandTimeout"]);
but I can't say this:
int commandTimeout =
(int)ConfigurationSettings.AppSettings["commandTimeout"];
Or maybe my VB background has caused brain damage, where I can do this:
Dim i As Integer
i = "123" <-- i is now numeric 123
Is there any cleaner way of doing stuff like this without great big long
expressions twice as wide as the code window?
--
Peace & happy computing,
Mike Labosh, MCSD
"When you kill a man, you're a murderer.
Kill many, and you're a conqueror.
Kill them all and you're a god." -- Dave Mustane 17 1333
Mike,
You are right, it is your VB background that has caused brain damage.
When you do this in VB:
Dim i As Integer
i = "123"
VB will perform a conversion of the string type into a number for you.
In C#, when you do this:
int commandTimeout = (int)
ConfigurationSettings.AppSettings["commandTimeout"];
You are trying to perform a cast from a string to an int, which can't be
done. You need a conversion.
You can always store the setting in a string variable, and convert it on
the next line. Either way, you have to tell C# what to do. Yes, VB will
give you little advantages like this, but ultimately, that "magic" that it
does for you is going to bite you in the ass one day.
Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"Mike Labosh" <ml*****@hotmail.com> wrote in message
news:O$**************@tk2msftngp13.phx.gbl... I can say this:
int commandTimeout = Convert.ToInt32(ConfigurationSettings.AppSettings["commandTimeout"]);
but I can't say this: int commandTimeout = (int)ConfigurationSettings.AppSettings["commandTimeout"];
Or maybe my VB background has caused brain damage, where I can do this:
Dim i As Integer i = "123" <-- i is now numeric 123
Is there any cleaner way of doing stuff like this without great big long expressions twice as wide as the code window? -- Peace & happy computing,
Mike Labosh, MCSD
"When you kill a man, you're a murderer. Kill many, and you're a conqueror. Kill them all and you're a god." -- Dave Mustane
"Mike Labosh" <ml*****@hotmail.com> wrote in message
news:O$**************@tk2msftngp13.phx.gbl... int commandTimeout = Convert.ToInt32(ConfigurationSettings.AppSettings["commandTimeout"]);
This works because it is actually doing a conversion on the object (is it
typed a string? can't remember) returned from AppSettings.
but I can't say this: int commandTimeout = (int)ConfigurationSettings.AppSettings["commandTimeout"];
This is casting - casting requires that the object being casted actually be
of the cast type. Casting does not care (or know about) content of things
like strings, only the fact that it IS a string.
Ex:
string s = "123";
int i = (int)s;
will fail because s is NOT of type int, s is of type string.
You could also use int.Parse() instead of Convert.ToInt32().
string s = "123";
int i = int.Parse(s);
(You may want to put a try-catch around the call to Parse in case the passed
string is not actually an int for some reason, typo or something).
--
Adam Clauss
Hi,
Before you rant about something try to understand why it's happening , also
knowing that there are a large number of people that not only consider it
normal , but being the correct way of doing it should make yoy think twice.
IMO you should get a better understanding of how a strong typed language
works, what is the difference among casting/conversion methods/implicit
conversion and why they exist in the first place.
cheers,
--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
"Mike Labosh" <ml*****@hotmail.com> wrote in message
news:O$**************@tk2msftngp13.phx.gbl... I can say this:
int commandTimeout = Convert.ToInt32(ConfigurationSettings.AppSettings["commandTimeout"]);
but I can't say this: int commandTimeout = (int)ConfigurationSettings.AppSettings["commandTimeout"];
Or maybe my VB background has caused brain damage, where I can do this:
Dim i As Integer i = "123" <-- i is now numeric 123
Is there any cleaner way of doing stuff like this without great big long expressions twice as wide as the code window? -- Peace & happy computing,
Mike Labosh, MCSD
"When you kill a man, you're a murderer. Kill many, and you're a conqueror. Kill them all and you're a god." -- Dave Mustane
Actually, this isn't that far off. You CAN do this:
int commandTimeout =
Convert.ToInt32(ConfigurationSettings.AppSettings["commandTimeout"]);
You CAN'T do this:
int commandTimeout =
(int)ConfigurationSettings.AppSettings["commandTimeout"];
But you CAN do this (note the extra parens):
int commandTimeout =
((int)ConfigurationSettings.AppSettings["commandTimeout"]);
-or-
int commandTimeout =
int.Parse(ConfigurationSettings.AppSettings["commandTimeout"].ToString());
I don't think those are unreasonable stretches... IMO
"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us> wrote
in message news:%2****************@TK2MSFTNGP09.phx.gbl... Hi,
Before you rant about something try to understand why it's happening , also knowing that there are a large number of people that not only consider it normal , but being the correct way of doing it should make yoy think twice.
IMO you should get a better understanding of how a strong typed language works, what is the difference among casting/conversion methods/implicit conversion and why they exist in the first place.
cheers,
-- Ignacio Machin, ignacio.machin AT dot.state.fl.us Florida Department Of Transportation "Mike Labosh" <ml*****@hotmail.com> wrote in message news:O$**************@tk2msftngp13.phx.gbl...I can say this:
int commandTimeout = Convert.ToInt32(ConfigurationSettings.AppSettings["commandTimeout"]);
but I can't say this: int commandTimeout = (int)ConfigurationSettings.AppSettings["commandTimeout"];
Or maybe my VB background has caused brain damage, where I can do this:
Dim i As Integer i = "123" <-- i is now numeric 123
Is there any cleaner way of doing stuff like this without great big long expressions twice as wide as the code window? -- Peace & happy computing,
Mike Labosh, MCSD
"When you kill a man, you're a murderer. Kill many, and you're a conqueror. Kill them all and you're a god." -- Dave Mustane
Hi, But you CAN do this (note the extra parens):
int commandTimeout = ((int)ConfigurationSettings.AppSettings["commandTimeout"]);
Are you sure?
Did you test it before posting ?
-or-
int commandTimeout =
int.Parse(ConfigurationSettings.AppSettings["commandTimeout"].ToString());
You do not need to call ToString() AppSettings["Index"] does return an
string.
But yes, you can use Int.Parse to convert a string to an integer
What is your point anyway?
We are talking (bashing) the VB handling of variables types
chers,
--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
Instead of placing a try-catch around the call to Parse in .NET 2.0 you
can use TryParse and returns a bool whether or not it can be done.
if( int.TryParse(s) )
{
int i = int.Parse(s);
}
The way you won't have to worry about an exception being thrown.
Sorry, one more set of parens needed...
int commandTimeout =
((int)(ConfigurationSettings.AppSettings["commandTimeout"]));
Glad to help!
"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us> wrote
in message news:uJ****************@tk2msftngp13.phx.gbl... Hi, But you CAN do this (note the extra parens):
int commandTimeout = ((int)ConfigurationSettings.AppSettings["commandTimeout"]);
Are you sure? Did you test it before posting ?
-or-
int commandTimeout =
int.Parse(ConfigurationSettings.AppSettings["commandTimeout"].ToString());
You do not need to call ToString() AppSettings["Index"] does return an string.
But yes, you can use Int.Parse to convert a string to an integer
What is your point anyway? We are talking (bashing) the VB handling of variables types
chers,
-- Ignacio Machin, ignacio.machin AT dot.state.fl.us Florida Department Of Transportation
What we're talking about here is a difference in philosophy.
VB.NET carries on in the tradition of languages like PL/I, BASIC and
earlier versions of VB. It says:
"Just assign whatever to whatever and I'll do my best to convert it.
I'll get it right 98% of the time. The other 2%... oh well, sorry."
C# carries on in the tradition of C / C++ / Java and, if I recall,
Pascal. It says:
"There is no magic. You must explicitly state what you want to do."
On the one hand, all of the background magic / help that VB.NET gives
you certainly is convenient. However, what most here are arguing is
that it does not _simplify_ programming. Yes, you have to type fewer
characters, but then you're letting the language make some decisions,
and they're not always obvious decisions or the right decisions.
Ultimately, the overall tone of VB / VB.NET: that the languages do lots
of work for you behind the scenes, leads to sloppy programming
practices, IMHO. VB programmers tend to be prototypers: slap something
together, run some quick tests, throw it into production, deal with any
fallout.
C# is a more exacting language, and C# programmers tend to be
correspondingly pickier and more exacting programmers.
This is _not_ to say that tossing prototypes into production is always
a bad thing. I've seen it work for companies. However, as I said, it's
a difference in philosophy. To a die-hard VB programmer I'm sure that
C#'s pickiness and exactitude looks stupid, just as to a die-hard C#
programmer the sloppy, anything-goes nature of VB.NET looks stupid.
You may add all parens you like, it won't compile.
You simply can't cast a string to int, guess that's what Ignacio meant to
say.
Willy.
"RCS" <rs****@gmail.com> wrote in message
news:Es**************@newssvr30.news.prodigy.com.. . Sorry, one more set of parens needed...
int commandTimeout = ((int)(ConfigurationSettings.AppSettings["commandTimeout"]));
Glad to help!
"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us> wrote in message news:uJ****************@tk2msftngp13.phx.gbl... Hi, But you CAN do this (note the extra parens):
int commandTimeout = ((int)ConfigurationSettings.AppSettings["commandTimeout"]);
Are you sure? Did you test it before posting ?
-or-
int commandTimeout =
int.Parse(ConfigurationSettings.AppSettings["commandTimeout"].ToString());
You do not need to call ToString() AppSettings["Index"] does return an string.
But yes, you can use Int.Parse to convert a string to an integer
What is your point anyway? We are talking (bashing) the VB handling of variables types
chers,
-- Ignacio Machin, ignacio.machin AT dot.state.fl.us Florida Department Of Transportation
Hi Bruce,
I agree with you. However, I will take it one step further. The fact that
VB.Net and other "magic" programming languages allow one to do things which
are technically incorrect, and fix them behind your back, not only makes for
sloppy programmers, but also ignorant ones. Why bother learning the
technical details when you don't have to? Well, I can tell you why: Because,
assuming that one is interested in improving one's lot in life as a
programmer, one will encounter more and more difficult problems, and run
into situations where understanding the technical details is not only
convenient; it's downright necessary. So, languages like C, C++, Java, and
Pascal actually do the developer a favor by being more strict, much like a
strict parent raises disciplined and successful children. You have to learn
more to use these languages, and that knowledge brings you more power. So, I
wouldn't put it down to a simple "difference" in philosophy. 1 is certainly
"different" than 2, but 2 is also "more" than 1. And if I had the
opportunity to receive 2 dollars or 1 dollar, I would rather know which was
more, than just the fact that they were "different." IOW, "different" and
"equal" are 2 different concepts. The philosophy of the "non-magical"
languages can be demonstrated to be qualitatively better overall for the
improvement of the developer's skills.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.
"Bruce Wood" <br*******@canada.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com... What we're talking about here is a difference in philosophy.
VB.NET carries on in the tradition of languages like PL/I, BASIC and earlier versions of VB. It says:
"Just assign whatever to whatever and I'll do my best to convert it. I'll get it right 98% of the time. The other 2%... oh well, sorry."
C# carries on in the tradition of C / C++ / Java and, if I recall, Pascal. It says:
"There is no magic. You must explicitly state what you want to do."
On the one hand, all of the background magic / help that VB.NET gives you certainly is convenient. However, what most here are arguing is that it does not _simplify_ programming. Yes, you have to type fewer characters, but then you're letting the language make some decisions, and they're not always obvious decisions or the right decisions.
Ultimately, the overall tone of VB / VB.NET: that the languages do lots of work for you behind the scenes, leads to sloppy programming practices, IMHO. VB programmers tend to be prototypers: slap something together, run some quick tests, throw it into production, deal with any fallout.
C# is a more exacting language, and C# programmers tend to be correspondingly pickier and more exacting programmers.
This is _not_ to say that tossing prototypes into production is always a bad thing. I've seen it work for companies. However, as I said, it's a difference in philosophy. To a die-hard VB programmer I'm sure that C#'s pickiness and exactitude looks stupid, just as to a die-hard C# programmer the sloppy, anything-goes nature of VB.NET looks stupid.
tdavisjr wrote: Instead of placing a try-catch around the call to Parse in .NET 2.0 you can use TryParse and returns a bool whether or not it can be done.
if( int.TryParse(s) ) { int i = int.Parse(s); }
The way you won't have to worry about an exception being thrown.
You meant if (int.TryParse(s, out i))
"Bruce Wood" wrote: What we're talking about here is a difference in philosophy.
VB.NET carries on in the tradition of languages like PL/I, BASIC and earlier versions of VB. It says:
"Just assign whatever to whatever and I'll do my best to convert it. I'll get it right 98% of the time. The other 2%... oh well, sorry."
C# carries on in the tradition of C / C++ / Java and, if I recall, Pascal. It says:
actually, C and C++ have very lax rules when it comes to type casting. (not
talking about type conversion, but implicit casting) type safety is not
really guarantteed.
you can add another 10 sets, and it still won't work.
there is no implicit or explicit conversion between int and string. and
there's a huge difference between casting and calling methods like
Int32.Parse or Convert.ToInt32. namely it demonstrates the concept of type
safety.
"RCS" wrote: Sorry, one more set of parens needed...
int commandTimeout = ((int)(ConfigurationSettings.AppSettings["commandTimeout"]));
Glad to help!
"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us> wrote in message news:uJ****************@tk2msftngp13.phx.gbl... Hi, But you CAN do this (note the extra parens):
int commandTimeout = ((int)ConfigurationSettings.AppSettings["commandTimeout"]);
Are you sure? Did you test it before posting ?
-or-
int commandTimeout =
int.Parse(ConfigurationSettings.AppSettings["commandTimeout"].ToString());
You do not need to call ToString() AppSettings["Index"] does return an string.
But yes, you can use Int.Parse to convert a string to an integer
What is your point anyway? We are talking (bashing) the VB handling of variables types
chers,
-- Ignacio Machin, ignacio.machin AT dot.state.fl.us Florida Department Of Transportation
Well, yes, but C won't quietly convert a string to an integer for you,
or vice versa. Granted it's not as strict as C#, but it's not VB.NET,
either.
Hi,
"Bruce Wood" <br*******@canada.com> wrote in message
news:11*********************@o13g2000cwo.googlegro ups.com... Well, yes, but C won't quietly convert a string to an integer for you, or vice versa. Granted it's not as strict as C#, but it's not VB.NET, either.
No, C is the opposite of VB: " I assume you know what you are doing even if
it does not looks right to me" :)
cheers,
--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
"Bruce Wood" wrote: Well, yes, but C won't quietly convert a string to an integer for you, or vice versa. Granted it's not as strict as C#, but it's not VB.NET, either.
It doesn't convert string to integer, but it does many things just as
problematic with regards to type safety, and C# is designed to address the
shortcomings of VB as much as the shortcomings of C. It's a stretch to
suggest that C is better than VB when dealing with types.
Oh - yeah, you're right, my mistake - for int and string, it won't convert.
But I think that makes perfect sense, there is no way you could trust that
the supplied string had just numbers in it, that's why there is int.Parse()!
"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:uZ**************@TK2MSFTNGP14.phx.gbl... You may add all parens you like, it won't compile. You simply can't cast a string to int, guess that's what Ignacio meant to say.
Willy.
"RCS" <rs****@gmail.com> wrote in message news:Es**************@newssvr30.news.prodigy.com.. . Sorry, one more set of parens needed...
int commandTimeout = ((int)(ConfigurationSettings.AppSettings["commandTimeout"]));
Glad to help!
"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us> wrote in message news:uJ****************@tk2msftngp13.phx.gbl... Hi, But you CAN do this (note the extra parens):
int commandTimeout = ((int)ConfigurationSettings.AppSettings["commandTimeout"]);
Are you sure? Did you test it before posting ?
-or-
int commandTimeout =
int.Parse(ConfigurationSettings.AppSettings["commandTimeout"].ToString());
You do not need to call ToString() AppSettings["Index"] does return an string.
But yes, you can use Int.Parse to convert a string to an integer
What is your point anyway? We are talking (bashing) the VB handling of variables types
chers,
-- Ignacio Machin, ignacio.machin AT dot.state.fl.us Florida Department Of Transportation
This discussion thread is closed Replies have been disabled for this discussion. Similar topics
16 posts
views
Thread by Thomas G. Marshall |
last post: by
|
25 posts
views
Thread by Skc |
last post: by
|
45 posts
views
Thread by Brett |
last post: by
|
5 posts
views
Thread by Bit byte |
last post: by
|
4 posts
views
Thread by kurt sune |
last post: by
|
20 posts
views
Thread by fniles |
last post: by
|
171 posts
views
Thread by Raman |
last post: by
|
11 posts
views
Thread by test |
last post: by
| | | | | | | | | | |