|
Apparently, about 18 months ago it took a couple of hours. At this rate, we soon won't be able to run it overnight, as our database doesn't tend to get smaller over time!
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Is the growth in execution time linear or exponential?
Politicians are always realistically manoeuvering for the next election. They are obsolete as fundamental problem-solvers.
Buckminster Fuller
|
|
|
|
|
I don't know yet, I only have 2 data points.
(and one of them is fairly rough - I only know exactly for the latest few runs)
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
At present it kind of works. Our system deals with a number of types of object, if a new type is added, we will need to maintain it. Nobody has been brave enough to tackle the thing, and no one really understands how it works. But apart from that, all is hunky dory.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Just call it magic and back off slowly.  And don't turn your back on it until you're out of sight!! 
|
|
|
|
|
Convert.ToInt32(Int32)[^]
Quote: Returns the specified 32-bit signed integer; no actual conversion is performed.
Most useful method evar....
modified 27-Nov-13 14:00pm.
|
|
|
|
|
What do you expect? Convert.ToInt32(Int32) does nothing, you are trying to point it out as a joke, but its actually quite useful especially when you don't know the type that you are passing into it (which is why Convert has so many ToXXX overloads). Convert.ToDouble(Double) is the same, as well as Convert.ToSingle(Single), etc.
|
|
|
|
|
Hmm... totally missed this usage case, you're right. More often than not though, I use the Convert class to convert objects where I do know what I'm passing in, so it just struck me as odd when I was browsing documentation. I feel like they could have mentioned this in the remarks rather than a 'nothing happened' remark.
|
|
|
|
|
There are even more usage scenarios than that, take for example the following code:
public void SomeDummyMethod(int myNumber)
{
double myDouble = Convert.ToDouble(myNumber);
return myDouble * 1000.1f;
}
Now, lets say later down the line you get somebody who says "wait, myNumber needs to be a signed byte!"...
Well now you only have to change one line of code:
public void SomeDummyMethod(SByte myNumber)
{
double myDouble = Convert.ToDouble(myNumber);
return myDouble * 1000.1f;
}
Then later somebody comes around and says, "no, it should be a double to begin with"...
public void SomeDummyMethod(double myNumber)
{
double myDouble = Convert.ToDouble(myNumber);
return myDouble * 1000.1f;
}
This is an overly simplified case obviously, but imagine if there were 100 or 200 lines of code in the function, if they didn't have Convert.ToDouble(double) the one change at the top would break unknown lines of code below.
Plus, the design strategy for the class was Convert should convert from any numeric type any other numeric type. Oddly enough that also means converting from something back to itself...
On top of all that, it really helps support the IConvertable [^]interface later on, and even says in the documentation:
"The common language runtime typically exposes the IConvertible interface through the Convert class. The common language runtime also uses the IConvertible interface internally, in explicit interface implementations, to simplify the code used to support conversions in the Convert class and basic common language runtime types."
So much more useful than you think 
|
|
|
|
|
public void SomeDummyMethod(double myNumber)
{
double myDouble = Convert.ToDouble(myNumber);
return myDouble * 1000.1f;
}
And after few months someone finds this code and posts it to Weird and Wonderful. 
|
|
|
|
|
What, you can't return a double as void?
|
|
|
|
|
Ron Beyer wrote: public void SomeDummyMethod(int myNumber)
{
double myDouble = Convert.ToDouble(myNumber);
return myDouble * 1000.1f;
}
Apart from the fact that you can't return a value from a void method, why are you multiplying a double by a float constant?
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
He doesn't want it to sink without trace...
|
|
|
|
|
OriginalGriff wrote: He doesn't want it to sink without trace...
...into the void.
Greetings - Jacek
|
|
|
|
|
Best to avoid the Convert class generally; the only useful member is ChangeType.
|
|
|
|
|
Ron Beyer wrote: Convert.ToInt32(Int32) does nothing
but to throw exceptions... Prefer Int32.TryParse instead.
|
|
|
|
|
|
Btw. a method Convert.ToSingle(Double) always makes me feel sad.
Greetings - Jacek
|
|
|
|
|
By M$ logic the point of using that kind of "useful" methods is when you call Convert.ToInt32 with object, dynamic or var variable you will always get Int32 as a result.
P.S. Today i found one more reason to dislike c#. Who the hell had the brilliant idea to make Tuples read only ? And why the elephant ?
Microsoft ... the only place where VARIANT_TRUE != true
|
|
|
|
|
Argonia wrote: Who the hell had the brilliant idea to make Tuples read only ? And why the elephant ?
The design of the System.Tuple classes is more to do with the BCL team than the C# team. Any .NET language which uses these classes will get the same read-only behaviour.
And they're read-only because they originated in functional programming, where pretty much everything is immutable.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Actually, tuples largely come from functional languages where everything is immutable. There are all sorts of benefits - for example immutable objects are guaranteed to be thread-safe, are simpler to reason about, and offer higher security than mutable objects.
Also, importantly, if they were mutable, by definition they wouldn't be tuples. If you want a mutable, ordered collection of elements, write one and call it something else!
Wikiepdia has a good entry on immutable objects[^].
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Take no offense, but you don't know what you're talking about, don't you?
Mutable Tuples are called lists and/or classes.
Having Tuples is great if you need to have a Dictionary which happens to need two keys: you don't need a custom class or some other custom solution, you just use the tuple as key.
Mutable data means the hash will change, so you cannot.
Read Immutable as hashable. It really makes a LOT of sense to have tuples.
You just have to learn why they are there in the first place and you'll discover that the .NET Framework is one of the best around. And IMO the best, period.
My 2 c: Convert is a fossil from 1.0/1.1 era. Never used it since generics went out.
|
|
|
|
|
Actually i do,
So basically i was looking for a way to make a vector with a pair of strings. After some google ing i found about list with Tuples. It was fun when i decided that this list must me modified.
After few hours later i found about KeyValuePair.
And btw everything what M$ sux including c#.
Microsoft ... the only place where VARIANT_TRUE != true
|
|
|
|
|
So you're telling me you needed a screwdriver, but you don't know what a screwdriver is.
So you googled for it and picked up a drill.
Then you found out that it didn't worked to do the job you need.
And you blame Microsoft for this.
I suggest you could read "The Pragmatic Programmer".
Look, I'm not a MS fan boy, I think many libraries MS is pushing (or where pushing) are crap.
But there is a core of consistency and completeness in the .NET framework that I never found out in other core libraries. And an elegance in C# that is unknown to Java.
If you don't agree, tell me a better language to do the same kind of stuff you can do in C#.
Currently, you seem to bash M$ just for the sake of your incompetency (literally: you're not competent regarding the job you do).
I love Python (but it's library is light years lagging on naming conventions), I enjoy JavaScript (but you must know what works and what will break your programs), but the building of the .NET Framework is a major accomplishment.
|
|
|
|
|
Oh, and BTW KeyValuePair is not a vector. It's only a Dictionary item.
You could use it to store two strings, but you probably would be better set implementing a class with two members, x and y.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
