|
Ok I'm bored so I'm going to argue anyway.
jschell wrote: Since the vast majority of programming in the world does not involve that it isn't a significant problem.
Not sure what world you're living in. Every time a vector or a int128 (or larger) is needed, Java will make your life a hell by insisting on manual cloning and writing verbose a.Multiply(b) and the like, for no reason other than that operator overloading can and is abused. Frankly it's none of their busyness whether I choose to abuse their language or not.
But then again maybe you're working for some boring company just maintaining even more boring applications (as they call them, versus actual programs) - you know, the kind of program that doesn't actually do anything but just glues some stuff together.
jschell wrote: And it is not accidental.
Of course it isn't. I was referring to overloading methods in Java, which you can do accidentally because it doesn't require any syntax. It also will happen sooner or later and that's a nasty bug which is hard to find.
You can also override some method (accidentally even, in Java) and have it completely break the Liskov substitution principle.
People will do it, on purpose too. So lets ban virtual methods.
In fact, let's ban strings and IO and arrays and dictionaries and floating point numbers and abstract classes and definitely reflection, all of which are frequently abused.
|
|
|
|
|
David1987 wrote: Not sure what world you're living in. Every time a vector or a int128 (or larger) is needed, Java will make your life a hell by insisting on manual cloning and writing verbose a.Multiply(b) and the like, for no reason other than that operator overloading can and is abused. Frankly it's none of their busyness whether I choose to abuse their language or not.
Presumably you mean 'vector' in terms of mathematics and not in terms of the java class.
Based on that, the point is meaningless. In terms of lines of code in the world the code that requires vectors is so small as to be unmeasurable.
David1987 wrote: But then again maybe you're working for some boring company just maintaining even more boring applications (as they call them, versus actual programs) - you know, the kind of program that doesn't actually do anything but just glues some stuff together
Not sure what that means but most of the applications I write do glue things together. And they also make a lot of money both directly and indirectly.
I will admit that getting a regular paycheck and being able to pay bills is in fact 'boring' compared to the alternative. Applications that make money lead to that sort of boredom.
David1987 wrote: Of course it isn't. I was referring to overloading methods in Java, which you can do accidentally because it doesn't require any syntax. It also will happen sooner or later and that's a nasty bug which is hard to find.
I don't recall it happening to me. I do recall hundreds, thousands, perhaps hundreds of thousands of logic errors of which many are in fact hard to diagnose and sometimes very hard to solve. So I suspect the one of which you speak is lost in the noise.
David1987 wrote: People will do it, on purpose too. So lets ban virtual methods.
I haven't seen many problems with that in java. I can't recall any. I saw more of that sort of problem in C++ with people not understanding such things as the role of a virtual dtor.
And working around the lack of virtual methods can be done but is much harder.
David1987 wrote: In fact, let's ban strings and IO and arrays and dictionaries and floating point numbers and abstract classes and definitely reflection, all of which are frequently abused.
Which again ignores my point.
Operator overloading is often misused. And misused despite there being alternatives.
That isn't true for your examples.
1. Situations exist which those are the only solution. And alternatives are hard or impossible.
2. The incorrect usage compared to correct usage is much more reasonable than versus operator overloading.
|
|
|
|
|
Strings and floats and reflection are very often abused. Enough so that I see such abuses pop up in the C# forum about every few weeks or so.
But operator overloading abuse? Never in C#.. sometimes in C++, which sets the wrong example with their << on streams - and still less often than string-abuse.
String abuse is especially bad since it causes performance trouble real quick - as does Object abuse, which I hadn't even previously mentioned (some people seem to think that you have to wrap everything in an object).
jschell wrote: Based on that, the point is meaningless. In terms of lines of code in the world the code that requires vectors is so small as to be unmeasurable.
Sure, you can put everything on one line.. which is a different kind of abuse, also made possible by java, but easily defeatable with auto-formatting.
The raytracer we had to write in University became a horror of tangles Subtract's and Multiply's that in no way looked like the actual formula's. It sucked. With operator overloading it wouldn't have been such a pain.
jschell wrote: Operator overloading is often misused.
Prove it. I've never seen it.
|
|
|
|
|
David1987 wrote: Strings and floats and reflection are very often abused. Enough so that I see such abuses pop up in the C# forum about every few weeks or so.
That is not evidence that in total lines of code that it occurs 'often'.
And you see Strings misused?
David1987 wrote: String abuse is especially bad since it causes performance trouble real quick
I have seen claims of that. And hypothetical arguments about it. I have never seen it occur in a real application.
Presumably you have. Could you describe the nature of that problem and the impact on the application performance pre and post?
David1987 wrote: Sure, you can put everything on one line.. which is a different kind of abuse, also made possible by java, but easily defeatable with auto-formatting.
That isn't what I meant.
Given a count of lines of code in the world for all languages, the number of lines of code involving vectors (mathematical) is so small that one is unlikely to be able to measure it enough to get it above the error rate of the measurement process itself.
David1987 wrote: The raytracer we had to write in University became a horror of tangles Subtract's and Multiply's that in no way looked like the actual formula's. It sucked. With operator overloading it wouldn't have been such a pain.
Since most of OO programming involves method calls why is this different than any other OO programming task?
Or misusing some other OO idiom such as method chaining.
And how many total code lines were in the application? And how many code lines were specific to vector arithmetic operations?
David1987 wrote: Prove it. I've never seen it.
Then here you go...
http://thedailywtf.com/Comments/Yet-Another-Operator-Overloading-Abuse.aspx?pg=4[^]
|
|
|
|
|
jschell wrote:
Presumably you have. Could you describe the nature of that problem and the impact on the application performance pre and post?
No.
All programs I've actually worked on were written either by just myself or me and a bunch of friends all of whom are not noobs who use strings for everything. There was no operator overloading abuse either.
See here[^] for the worst string abuse I can remember from this forum.
jschell wrote: Then here you go...
Yes, it's C++.
Argument dismissed.
C++ has operator overloading abuse built-in with their << on streams.
And besides, we were talking about C#.
jschell wrote: Given a count of lines of code in the world for all languages, the number of lines of code involving vectors (mathematical) is so small that one is unlikely to be able to measure it enough to get it above the error rate of the measurement process itself.
That doesn't matter (though there are definitely a lot in scientific code - if we ignore the Boring Code that becomes a lot more significant). Vectors aren't the only thing that should behave like a mathematical type instead of objects.
jschell wrote: Since most of OO programming involves method calls why is this different than any other OO programming task? Or misusing some other OO idiom such as method chaining.
Because a vector shouldn't be modeled as an object. A vector is a value, so that's exactly what it should be modeled as.
|
|
|
|
|
David1987 wrote: All programs I've actually worked on were written either by just myself or me
and a bunch of friends all of whom are not noobs who use strings for everything.
You were using that as analogy for abuse which was comparable to the abuse in operator overloading.
Your very statement here however suggests that you yourself do not consider it an apt analogy.
David1987 wrote: Yes, it's C++.
Argument dismissed.
C++ has operator overloading abuse
built-in with their << on streams.
And besides, we were talking about
C#.
First I can provide a quote from Stroustrup that says that he specifically thinks that the operator overloading in streams is an excellent use.
Second C++ has been around much longer than C# and has a larger base of code. Thus one can judge the impact better.
Third C# does not limit operator overloading in such a way to make it incompatible with the problems that one might experience from abusing the idiom. Just as with C++.
Fourth I am not now nor have I ever been discussing this in terms of only C#. I am referring the realm of possibilities for operator overloading of which the two languages, C# and C++, have sufficient user bases to evaluate usage. There are other languages which support operator overloading as well. It is possible some of the more esoteric ones might be a better fit for the idiom due to the nature of the language. But neither C# nor C++ is.
David1987 wrote: That doesn't matter (though there are definitely a lot in scientific code - if
we ignore the Boring Code that becomes a lot more significant). Vectors aren't
the only thing that should behave like a mathematical type instead of
objects.
Yes it does matter.
C#, Java and C++ are general purpose languages. They were designed and have evolved to support a wide range of problems. They are NOT designed to be ideal tools for specific problem domains.
There are languages specifically designed to support a narrow range of problems. Such languages would be designed to support idioms specific to the nature of the domain they are targeted at. And there are languages specifically targeted to support scientific and mathematical problems which not only support the features that you are touting but do so at the native level.
It is a matter of using the right tool for the right job.
David1987 wrote: Because a vector shouldn't be modeled as an object. A vector is a value, so
that's exactly what it should be modeled as.
And when I want to use nails that use a 22 caliber shot then I select a nail gun that can deliver that appropriately rather than attempting to use a hammer.
And in the same way if your primary purpose is vector arithematic then I suggest you select a tool appropriate for that. As an example Mathmatica.
http://reference.wolfram.com/mathematica/tutorial/VectorsAndMatrices.html[^]
|
|
|
|
|
Your own argument defeats yourself. C# is a general purpose language and so should be able to deal with it if some calculations are required. It would be pretty silly to have a language that can't calculate (XSTL?)
But then, in a ray tracer the majority of the code isn't mathematics - just a lot of it. Building a ray tracer in mathematica or maple is kind of silly.
Operators exist for built-in types, not allowing them on "everything else" makes the built-in types more special. In Java they are even more special and that sucks even more. It's not "nice" or "elegant" and it has bitten almost everyone who learned the language.
jschell wrote:
Third C# does not limit operator overloading in such a way to make it incompatible with the problems that one might experience from abusing the idiom. Just as with C++.
It is impossible to do so anyway. Just don't abuse it then. C# also does not limit method overloading and virtual methods and strings in such a way that you can't abuse them. Nor should it try to, you'd end up with a language that you'd have to fight at every turn to get something done. (like Haskell? and even haskell, for all its 'purity' has unsafePerformIO - and is not immune to string abuse, which is probably impossible to ban)
jschell wrote: First I can provide a quote from Stroustrup that says that he specifically thinks that the operator overloading in streams is an excellent use.
Well of course, why else would he have done it that way. That doesn't mean that I'm going to agree with him though. << and >> should be used for bitwise shifts, any other use is abuse at least in my opinion, and I'm reasonably sure that a lot of people agree with that.
|
|
|
|
|
David1987 wrote: Your own argument defeats yourself. C# is a general purpose language and so
should be able to deal with it if some calculations are required.
I see no problem with creating a vector library in Java. So no it doesn't defeat my point.
And a general purpose language is NOT intended to be able to solve all problems and is certainly NOT intended to solve all of them in an ideal way either.
David1987 wrote: Operators exist for built-in types, not allowing them on "everything else" makes
the built-in types more special. In Java they are even more special and that
sucks even more. It's not "nice" or "elegant" and it has bitten almost everyone
who learned the language.
I have seen a lot of code in a lot of languages.
Some elegant some not.
But nothing in that statement has anything to do with operator overloading.
David1987 wrote: It is impossible to do so anyway. Just don't abuse it then. C# also does not
limit method overloading and virtual methods and strings in such a way that you
can't abuse them. Nor should it try to, you'd end up with a language that you'd
have to fight at every turn to get something done. (like Haskell? and even
haskell, for all its 'purity' has unsafePerformIO - and is not immune to string
abuse, which is probably impossible to ban)
To make it specifically clear - I do not accept your analogy of strings/virtuals as equivalent to operator overloading.
A better analogy would be inheritance which is abused a great deal.
However eliminating inheritance does not leave one with an alternative. That isn't true for operator overloading.
|
|
|
|
|
Ok, then I accept none of your arguments and you are simply wrong. Case closed. Troll.
|
|
|
|
|
David1987 wrote: Ok, then I accept none of your arguments and you are simply wrong. Case closed.
Troll.
Pretty sure I said early on that you were expressing nothing but a personal opinion.
|
|
|
|
|
Whatever. I don't give a shït. This useless discussion is far past the time that it was ever useful. Just go away.
|
|
|
|
|
jschell wrote: Having seen some truly hideous usages of operator overloading
You cannot blame the language if users abuse it. A poor programmer will always be a poor programmer. It's all about design, style and discipline.
|
|
|
|
|
Niklas Lindquist wrote: You cannot blame the language if users abuse it. A poor programmer will always
be a poor programmer. It's all about design, style and discipline.
As with many others, here and on the java site (who complain about operator overloading) you either missed or ignored the point.
The point is not that it can be misused.
The point is that it does get misused.
And I have seen no evidence that does not suggest that there are far more examples of misuse than correct usage.
As well your view applies equally to pointers and explicit memory management. And certainly I have seen uses of that which are in fact elegant and which cannot be implement by other stategies. Unlike operator overloading.
Yet I don't see people insisting that Java/C# should have those.
|
|
|
|
|
Niklas Lindquist wrote: Coming from C++, I overloaded operator== et al, to compare the actual values
I am taking that to mean that you are overloading others besides equality.
Coming from C++ I almost never used operator overloading. At two C++ shops it was specifically forbidden to use it.
Excluding the comments about equality there can be specific circumstances where operators (all of them) might be appropriate to use.
Numeric representation are example of this. Thus Length might be a suitable candidate.
Angle on the other hand is less clear. But possible.
But hypothetically does a "geometry primitives" include a circle, square and rectangle?
If so please explain, objectively, how one implements less than for a square. And how one represents it for a square and rectangle. And a square and circle.
And once you have that if someone else can come up with a different interpretation then - don't use operator overloading because the operation is not in fact clear and well defined.
As an example of this what does less than mean for an Angle? Seems obvious that 60 degrees is less than 90 degrees. However is 60 degrees less than 300 degrees? And if you think that is obvious then draw a 60 degree angle in a circle and explain what the 'angle' measures on both sides of the line.
|
|
|
|
|
jschell wrote: But hypothetically does a "geometry primitives" include a circle, square and rectangle?
Not in my problem domain. They all consist of a single double value. Maybe physics primitives would have been a better description.
jschell wrote: However is 60 degrees less than 300 degrees?
My angles does not wrap around. 0 and 360 are different values and they might go well beyond a full turn. I think you might confuse this with a normalized angle. But I see your point. If there can be confusion, there probably will.
Thanks.
|
|
|
|
|
Hello Everybody,
I want to know that how to use UML in c# for designing.
Thanks
If you can think then I Can.
|
|
|
|
|
That's not really a C# question. You're just asking how you can use UML to design code. The language choice is, effectively, irrelevant to designing with UML. Get yourself a UML design application, I use Enterprise Architect, but you can get StarUML[^] for free. Then, as long as you know UML, you are good to go.
|
|
|
|
|
Is google not available in your country?
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
modified on Wednesday, April 13, 2011 5:49 PM
|
|
|
|
|
no
Joking...
If you can think then I Can.
|
|
|
|
|
use joke icon, if its a joke.
Looks like you original question was a bad joke too.
♫ 99 little bugs in the code,
99 bugs in the code
We fix a bug, compile it again
101 little bugs in the code ♫
|
|
|
|
|
Use the question icon, then you can earn Enquirer points!
"Life should not be a journey to the grave with the intention of arriving safely in a pretty and well preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming "Wow! What a Ride!"
— Hunter S. Thompson
|
|
|
|
|
Doesn't work. 
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
|
I changed the icon to the question icon, and my enquirer score didn't go up. On this message, I started out with the question icon, so let's see what happened.
(after checking)
It looks like you have to set the correct icon when you originally post the message. If you change it after the message is posted, your points don't increase.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
This is a test of the answer icon.
(after checking the results)
Uh oh... I wonder if Chris knows about this...
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
