Not strictly a bug, but it caught me by surprise
-
Kevin McFarlane wrote:
I expected VB .NET to behave as C#. But I guess VB .NET is following VB 6.
VB.NET is weakly typed - an int turns magically into a float. C# will keep the type of the number on the RHS. 3/2.0 is 1.5.
Kevin McFarlane wrote:
In VB .NET locals are initialised to their defaults. In C# they're not and the compiler forces you to initialise.
How do you mean ? Do you mean if I have int i in a function without giving it a value, it will have a random value ? I'd never write that, so I'm not sure. That's because I come from C++, where int i creates space, but assigns no value, so the value is random.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
Christian Graus wrote:
Do you mean if I have int i in a function without giving it a value, it will have a random value ?
No, in C# you just get a compiler error if you don't subsequently assign to it.
Kevin
-
Christian Graus wrote:
Do you mean if I have int i in a function without giving it a value, it will have a random value ?
No, in C# you just get a compiler error if you don't subsequently assign to it.
Kevin
Ah... I agree with this, in that I agree that you should always give a variable a value at the point of creation. I have seen this, actually, when I've written code like string s; switch(someenum) { case oneenumvalue: s = " Fried fish and gravy"; break; case theONLYOTHERPOSSIBLEVALUE: s = " bananas and cream"; break; } and the compiler has screamed that not all paths assign a value, as I've not put a default: in there. I hate C# switch statements. They remind me that C# thinks I am stupid.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
-
Ah... I agree with this, in that I agree that you should always give a variable a value at the point of creation. I have seen this, actually, when I've written code like string s; switch(someenum) { case oneenumvalue: s = " Fried fish and gravy"; break; case theONLYOTHERPOSSIBLEVALUE: s = " bananas and cream"; break; } and the compiler has screamed that not all paths assign a value, as I've not put a default: in there. I hate C# switch statements. They remind me that C# thinks I am stupid.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
Christian Graus wrote:
Ah... I agree with this, in that I agree that you should always give a variable a value at the point of creation.
Yes. In C++ (which I haven't done any of for nearly 2 years now!) I used to hate the not uncommon style of declaring a variable without initialising it and then assigning to it some time later. I also used to hate not initially zeroing all elements of an array. It makes for a rather unpleasnt debugging experience when you're watching variable contents. You don't know whether you're just looking at uninitialised stuff or variables that have been corrupted.
Kevin
-
Most of my .NET experience has been in C# but I 've been on a VB .NET contract for the past 8 months. I was caught out by this: Integer division. In VB .NET, 3/2 = 1.5 In C#, 3/2 = 1 I expected VB .NET to behave as C#. But I guess VB .NET is following VB 6. Another difference... In VB .NET locals are initialised to their defaults. In C# they're not and the compiler forces you to initialise. Again, VB is following VB 6. Actually in this case I think VB is right and C# (and Java, which does the same) are wrong. What do the other OO languages (beside C++) do? Eiffel does the same as VB. What about Delphi?
Kevin
The integer division operator in VB (6 or .NET) is
\, not/. The CLR initialises all locals to their defaults, but it is an error in C# to use an uninitialised value.Stability. What an interesting concept. -- Chris Maunder
-
Kevin McFarlane wrote:
I expected VB .NET to behave as C#. But I guess VB .NET is following VB 6.
VB.NET is weakly typed - an int turns magically into a float. C# will keep the type of the number on the RHS. 3/2.0 is 1.5.
Kevin McFarlane wrote:
In VB .NET locals are initialised to their defaults. In C# they're not and the compiler forces you to initialise.
How do you mean ? Do you mean if I have int i in a function without giving it a value, it will have a random value ? I'd never write that, so I'm not sure. That's because I come from C++, where int i creates space, but assigns no value, so the value is random.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
Christian Graus wrote:
if I have "int i" in a function without giving it a value, it will have a random value
All types have a default value that is assigned by the Compiler. Some languages don't do any work, in their case it will atleast contain NULL. Also, in type strict languages; int/int = int If it were me: float f; f = 3/2; // you may even need to cast it to: f = (float)3/2; People love to code without knowing a language. It always pays to read a book on a language you are coding in, no mater how much it is like another language you know. Tip: Keep your statements on seperate lines, yeahhh, it's not as cool as writing all on one line, and seems to save time, but in fact you will save time in debugging when the Error message points you to the exact cause.
-
Christian Graus wrote:
if I have "int i" in a function without giving it a value, it will have a random value
All types have a default value that is assigned by the Compiler. Some languages don't do any work, in their case it will atleast contain NULL. Also, in type strict languages; int/int = int If it were me: float f; f = 3/2; // you may even need to cast it to: f = (float)3/2; People love to code without knowing a language. It always pays to read a book on a language you are coding in, no mater how much it is like another language you know. Tip: Keep your statements on seperate lines, yeahhh, it's not as cool as writing all on one line, and seems to save time, but in fact you will save time in debugging when the Error message points you to the exact cause.
VC++ does *not* assign any value by default in release builds. Here the value of i will be random. In debug builds all variables are initalized to their zero element (0 in the case of ints, NULL in the case of pointers).
Cheers Steen. "Are you gonna check your makeup when you're done whining?" John Simmons, 05/31/2006
-
VC++ does *not* assign any value by default in release builds. Here the value of i will be random. In debug builds all variables are initalized to their zero element (0 in the case of ints, NULL in the case of pointers).
Cheers Steen. "Are you gonna check your makeup when you're done whining?" John Simmons, 05/31/2006
heh, this is over my head :sigh: I think I remember; In C++ a variable is defined/initialized (damn can never remember which comes first:-O) e.g. int i; ... well it is given a memory location. That location will most likely still contain bits from previous use. I'm guessing the compiler doesn't auto assign a value due to the language being a speed demon. Saving a millisecond. IMO, VC++ is good for scientists with lots of time on their hands heheh ;)
-
Christian Graus wrote:
if I have "int i" in a function without giving it a value, it will have a random value
All types have a default value that is assigned by the Compiler. Some languages don't do any work, in their case it will atleast contain NULL. Also, in type strict languages; int/int = int If it were me: float f; f = 3/2; // you may even need to cast it to: f = (float)3/2; People love to code without knowing a language. It always pays to read a book on a language you are coding in, no mater how much it is like another language you know. Tip: Keep your statements on seperate lines, yeahhh, it's not as cool as writing all on one line, and seems to save time, but in fact you will save time in debugging when the Error message points you to the exact cause.
From my personal experience I like to "compress" (ie. condense in an absolutely one single line of ";"-delimited instructions) pieces of code I am ABSOLUTELY SURE that works in itself. And I'm absolutely sure only after I've tested the ie. function for all kinds of situations I expect to have variables sent there (including, but not limited to, margin-style variables... what with Excel's 00. January 1900 (or 1901) bug being caused by a date of 0...) Still, I like to do that only when I'm sure this will be sent to wherever it has to be sent in that exact form, and I don't expect anyone to look into the code. I try to keep a fully-clearly-formatted-and-indented version somewhere on one of my backups, just to be on the safe side.
-
From my personal experience I like to "compress" (ie. condense in an absolutely one single line of ";"-delimited instructions) pieces of code I am ABSOLUTELY SURE that works in itself. And I'm absolutely sure only after I've tested the ie. function for all kinds of situations I expect to have variables sent there (including, but not limited to, margin-style variables... what with Excel's 00. January 1900 (or 1901) bug being caused by a date of 0...) Still, I like to do that only when I'm sure this will be sent to wherever it has to be sent in that exact form, and I don't expect anyone to look into the code. I try to keep a fully-clearly-formatted-and-indented version somewhere on one of my backups, just to be on the safe side.
Egon_Freeman wrote:
I am ABSOLUTELY SURE that works in itself
Egon_Freeman wrote:
I'm absolutely sure only after I've tested
Egon_Freeman wrote:
I like to do that only when I'm sure
Egon_Freeman wrote:
just to be on the safe side
:laugh: I feel like filling this page up with these little guys, ":laugh:" Who could you be to be absolutely sure there are no bugs, or you predict exactly what will happen in the future, :omg: heh, you must be the best beta tester in the world. Like you said before, bugs popup in applications (e.g. Excel), language compilers or hardware will change in the future, and Software Users always find a way to make life difficult for the developer of the "absolutely perfect bug free code." "Just to be on the safe side", I wouldn't do that then. But hey, maybe your application needs to run as fast as possible, maybe you are coding new 3d graphic engines in C++ for id software, then I can understand it. But for my purposes, I stay away from it, almost always. The closest I get is to use (expression**?iftrue:**iffalse), heheh. But that's about it. We (me and you) would work on completely different apps, so no need to compare, but just laying down my general rules that I work with.;)
-
Egon_Freeman wrote:
I am ABSOLUTELY SURE that works in itself
Egon_Freeman wrote:
I'm absolutely sure only after I've tested
Egon_Freeman wrote:
I like to do that only when I'm sure
Egon_Freeman wrote:
just to be on the safe side
:laugh: I feel like filling this page up with these little guys, ":laugh:" Who could you be to be absolutely sure there are no bugs, or you predict exactly what will happen in the future, :omg: heh, you must be the best beta tester in the world. Like you said before, bugs popup in applications (e.g. Excel), language compilers or hardware will change in the future, and Software Users always find a way to make life difficult for the developer of the "absolutely perfect bug free code." "Just to be on the safe side", I wouldn't do that then. But hey, maybe your application needs to run as fast as possible, maybe you are coding new 3d graphic engines in C++ for id software, then I can understand it. But for my purposes, I stay away from it, almost always. The closest I get is to use (expression**?iftrue:**iffalse), heheh. But that's about it. We (me and you) would work on completely different apps, so no need to compare, but just laying down my general rules that I work with.;)
Mindflow wrote:
Who could you be to be absolutely sure there are no bugs, or you predict exactly what will happen in the future, heh, you must be the best beta tester in the world.
By being sure, I mean that the code runs well enough for the task I plan to assign to it. If my code does small number approximation, I needn't build it so that it can accept all weird inputs and make it a bloated all-around function. I need one simple functionality - I do it. That's it. Then again, what I meant mostly wasn't exactly obfuscation, rather 'compression' - it doesn't take that much space then (with all the formatting and the like removed). But then again I do obfuscate sometimes (putting computations in the 3rd for() clause, for example). But, like I said, I try to limit myself to simple, small blocks of code (things I can easily debug if I need to - to keep things manageable). Its all built from small blocks becoming bigger blocks becoming apps, isn't it? :) (I mean, just look at Linux ;P) I'm not trying to write perfect code and certainly not trying to be smarter than I am. :) I'd hate myself for that 3 montsh later. :P