C# Irritation
-
They aren't type modifiers - C# doesn't have any type modifiers (unless you count array brackets [] or the nullable ?). Modifiers in C# apply to a type member, not to the member's return type. Even in parameters, "ref" is meant to modify the parameter itself, not the parameter's type. Additionally having type modifiers in the language would make the already complex overload resolution and type inference even more complex. C#'s type system is WAY less powerful: - C++ templates, partial specialisation etc. - all together much more powerful than C#'s generics - type modifiers - not existant in C# - multiple inheritance - not existant in C# - constructor/deterministic destructor semantics - not existant in C# (but it's possible with managed code, as C++/CLI demonstrates) - operator overloading - C++'s implementation is way more powerful (operators can have reference arguments, you can overload the assignment operator, ...) So what? They're two different languages. Get over it.
-
They aren't type modifiers - C# doesn't have any type modifiers (unless you count array brackets [] or the nullable ?). Modifiers in C# apply to a type member, not to the member's return type. Even in parameters, "ref" is meant to modify the parameter itself, not the parameter's type. Additionally having type modifiers in the language would make the already complex overload resolution and type inference even more complex. C#'s type system is WAY less powerful: - C++ templates, partial specialisation etc. - all together much more powerful than C#'s generics - type modifiers - not existant in C# - multiple inheritance - not existant in C# - constructor/deterministic destructor semantics - not existant in C# (but it's possible with managed code, as C++/CLI demonstrates) - operator overloading - C++'s implementation is way more powerful (operators can have reference arguments, you can overload the assignment operator, ...) So what? They're two different languages. Get over it.
Yes, the rationale for C++ is increasingly "if you can't do it in anything else, you can do it in C++." And IMO C++ ought to be relegated to such uses.
Kevin
-
Good points :) If they want C++, WTF are they using C#? ;P
xacc.ide - now with TabsToSpaces support
IronScheme - 1.0 alpha 4a out now (29 May 2008)leppie wrote:
If they want C++, WTF are they using C#?
In this particular case, WPF. And to be honest, I'd rather be using Haskell or Python :-)
-
leppie wrote:
If they want C++, WTF are they using C#?
In this particular case, WPF. And to be honest, I'd rather be using Haskell or Python :-)
Stuart Dootson wrote:
Python
Python and WxWidgets, awesome combination :cool:
Don't forget to vote if the response was helpful
Sig history "You're an idiot." John Simmons, THE Outlaw programmer "I realised that all of my best anecdotes started with "So there we were, pissed". Pete O'Hanlon Unix is a Four Letter Word, and Vi is a Two Letter Abbreviation
-
leppie wrote:
If they want C++, WTF are they using C#?
In this particular case, WPF. And to be honest, I'd rather be using Haskell or Python :-)
-
So.....I want to write some C# code like this (using
constas an indicator of intent, as I would in C++):enumOf course, as I've already discovered[^],
constdoesn't work this way - it needs a compile-time constant expression. So I replace it withreadonly, as suggested by many and varied splendid CP members, only to get this error:The modifier 'readonly' is not valid for this item
Wuh? So I investigate
readonly. It can only be used on fields. What the flip? So, Microsoft, you 'design' this language with two (not one) type modifiers indicating a design intent; that an item will not be modified after initialisation. One of them (const) requires the programmer to know what the compiler will be able to calculate at compile time (something the compiler already knows, as it'll quite happily point out to you when you get it wrong), while the other (readonly) has what seems to be a purely arbitrary usage limitation. This is crazy - if I call somethingconstin C++, the compiler knows what I mean and *DOES THE RIGHT THING*. OK, it's only a very small part of the language, I know. I can just use a variable instead. It just ticks me off. Anyway rant over.I came from a heavy C++ background into C#, and things went a lot smoother for me when I leaped the metal hurdle of "C# ain't C++". I agree, C++ lets you do a lot of things that make sense, but c# simply isn't *that* similar to C++.
"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
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
So.....I want to write some C# code like this (using
constas an indicator of intent, as I would in C++):enumOf course, as I've already discovered[^],
constdoesn't work this way - it needs a compile-time constant expression. So I replace it withreadonly, as suggested by many and varied splendid CP members, only to get this error:The modifier 'readonly' is not valid for this item
Wuh? So I investigate
readonly. It can only be used on fields. What the flip? So, Microsoft, you 'design' this language with two (not one) type modifiers indicating a design intent; that an item will not be modified after initialisation. One of them (const) requires the programmer to know what the compiler will be able to calculate at compile time (something the compiler already knows, as it'll quite happily point out to you when you get it wrong), while the other (readonly) has what seems to be a purely arbitrary usage limitation. This is crazy - if I call somethingconstin C++, the compiler knows what I mean and *DOES THE RIGHT THING*. OK, it's only a very small part of the language, I know. I can just use a variable instead. It just ticks me off. Anyway rant over.I think you are fighting OO and trying to write old style c/c++. Just let go and do what MS calls OO and you will get it.
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway -
I don't think it's fair to blame C# for the misspelling; it's really the fault of the framework. Any language targetting the framework would have the same problem. Having said that ... if I was writing the language I'd make seamlessly correcting human-language mismatches a part of the spec. :-\
Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
Phil J Pearson wrote:
Having said that ... if I was writing the language I'd make seamlessly correcting human-language mismatches a part of the spec. [Shucks]
"Ph'nglui mglw'nafh Nagus Plain'English wgah'nagl fhtagn"
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
-
I think you are fighting OO and trying to write old style c/c++. Just let go and do what MS calls OO and you will get it.
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest HemingwayEnnis Ray Lynch, Jr. wrote:
I think you are fighting OO
You could well be right - I used to be an OO true believer, but I saw another way[^] and have strayed :-)
-
They still haven't produced a coordinate system where Y increases as you go up. This means that polar coordinates rotate the wrong way around the origin. How difficult can it be? They don't have X increasing to the left so why have Y increasing downwards? It's not difficult, other systems (e.g. RiscOS) have done it the right way up for years.
Steve_Harris wrote:
They still haven't produced a coordinate system where Y increases as you go up.
And they are probably not going to. Very few, if any desktop windowing systems use a left/bottom origin point. I'm pretty sure a big part of that is text layout, since text, for the most commonly used languages anyways (English, romance languages, slavic languages, etc), lays out left to right, top to bottom. The only desktop system I've seen doing this is NeXTStep/Cocoa, and even there you have the option of telling the framework you want the coordinates flipped for a specific view/control.
¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! VCF Blog
-
So.....I want to write some C# code like this (using
constas an indicator of intent, as I would in C++):enumOf course, as I've already discovered[^],
constdoesn't work this way - it needs a compile-time constant expression. So I replace it withreadonly, as suggested by many and varied splendid CP members, only to get this error:The modifier 'readonly' is not valid for this item
Wuh? So I investigate
readonly. It can only be used on fields. What the flip? So, Microsoft, you 'design' this language with two (not one) type modifiers indicating a design intent; that an item will not be modified after initialisation. One of them (const) requires the programmer to know what the compiler will be able to calculate at compile time (something the compiler already knows, as it'll quite happily point out to you when you get it wrong), while the other (readonly) has what seems to be a purely arbitrary usage limitation. This is crazy - if I call somethingconstin C++, the compiler knows what I mean and *DOES THE RIGHT THING*. OK, it's only a very small part of the language, I know. I can just use a variable instead. It just ticks me off. Anyway rant over.Oh yeah. Easily one of the more bone-headed things they did with C#. Until you remember that C# was designed for VB programmers, who are used to just making copies of everything they don't want modified... ;)
Citizen 20.1.01
'The question is,' said Humpty Dumpty, 'which is to be master - that's all.'
-
A readonly local would be pointless. the value has got to be stored, so still takes up the same amount of memory. Adding const wouldn't actually change anything. The only benefit it would give is a compiler warning if you tried to change the value. But you shouldn't be changing the value anyway if you want it to be readonly. Once compiled, the const/readonly tag wouldn't make any difference, it would compile to the same thing anyway (just a normal local variable).
Simon
Simon Stevens wrote:
Adding const wouldn't actually change anything. The only benefit it would give is a compiler warning if you tried to change the value. But you shouldn't be changing the value anyway if you want it to be readonly.
Scenario: Method returns reference to internal object. This object represents a fundamental type in the domain of this particular app; there are hundreds of thousands of unique instances and they're used all over the place. At one point in its lifetime, it was mutable - special loader classes pulled data into it from many disparate sources, checking and double-checking, correcting and re-correcting. Therefore, it has public mutator methods. But at this point, it is to be considered immutable. C++: method would return a const reference. Any naive caller attempting to modify it would trigger a compiler error. C#: method must return interface rather than direct object reference, or rely on callers to Do The Right Thing, or set some dodgy "done changing state" flag internal to the object itself and implement const checking at runtime.
Citizen 20.1.01
'The question is,' said Humpty Dumpty, 'which is to be master - that's all.'
-
So.....I want to write some C# code like this (using
constas an indicator of intent, as I would in C++):enumOf course, as I've already discovered[^],
constdoesn't work this way - it needs a compile-time constant expression. So I replace it withreadonly, as suggested by many and varied splendid CP members, only to get this error:The modifier 'readonly' is not valid for this item
Wuh? So I investigate
readonly. It can only be used on fields. What the flip? So, Microsoft, you 'design' this language with two (not one) type modifiers indicating a design intent; that an item will not be modified after initialisation. One of them (const) requires the programmer to know what the compiler will be able to calculate at compile time (something the compiler already knows, as it'll quite happily point out to you when you get it wrong), while the other (readonly) has what seems to be a purely arbitrary usage limitation. This is crazy - if I call somethingconstin C++, the compiler knows what I mean and *DOES THE RIGHT THING*. OK, it's only a very small part of the language, I know. I can just use a variable instead. It just ticks me off. Anyway rant over.My background is just plain C and I never used
constthere so I have no trouble understandingconstandreadonlyin C#. Additionally, in the snippet you show, I wouldn't declare the local variable in the loop at all. I'd rework the entire thing to be more like:private void PerformTests()
{
ActiveEvents actualEvent ;do { switch ( actualEvent = WaitForEvent ( ActiveEvents.ShouldStart ) ) { ... } } while ( actualEvent != ActiveEvents.ShouldExit ) ; return ;}
-
If we're turning this into a 'bitching about c#' thread, I want to throw in my personal annoyances. Colour is spelt with a u. ;P
Simon
And Maths is spelt with an s.
-
So.....I want to write some C# code like this (using
constas an indicator of intent, as I would in C++):enumOf course, as I've already discovered[^],
constdoesn't work this way - it needs a compile-time constant expression. So I replace it withreadonly, as suggested by many and varied splendid CP members, only to get this error:The modifier 'readonly' is not valid for this item
Wuh? So I investigate
readonly. It can only be used on fields. What the flip? So, Microsoft, you 'design' this language with two (not one) type modifiers indicating a design intent; that an item will not be modified after initialisation. One of them (const) requires the programmer to know what the compiler will be able to calculate at compile time (something the compiler already knows, as it'll quite happily point out to you when you get it wrong), while the other (readonly) has what seems to be a purely arbitrary usage limitation. This is crazy - if I call somethingconstin C++, the compiler knows what I mean and *DOES THE RIGHT THING*. OK, it's only a very small part of the language, I know. I can just use a variable instead. It just ticks me off. Anyway rant over.Why have one .NET library (Math) which works with radians and another (Drawing2D) which works with degrees?
-
If we're turning this into a 'bitching about c#' thread, I want to throw in my personal annoyances. Colour is spelt with a u. ;P
Simon
Simon Stevens wrote:
Colour is spelt with a u.
Yeah, and don't forget
whilst. :rolleyes: :)My latest C# extension method: public static bool In<T>(this T value, params T[] values) { return values.Any(v => v.Equals(value)); } Example: bool valid = answer.In("Yes", "No", "Dunno");
-
Simon Stevens wrote:
Adding const wouldn't actually change anything. The only benefit it would give is a compiler warning if you tried to change the value. But you shouldn't be changing the value anyway if you want it to be readonly.
Scenario: Method returns reference to internal object. This object represents a fundamental type in the domain of this particular app; there are hundreds of thousands of unique instances and they're used all over the place. At one point in its lifetime, it was mutable - special loader classes pulled data into it from many disparate sources, checking and double-checking, correcting and re-correcting. Therefore, it has public mutator methods. But at this point, it is to be considered immutable. C++: method would return a const reference. Any naive caller attempting to modify it would trigger a compiler error. C#: method must return interface rather than direct object reference, or rely on callers to Do The Right Thing, or set some dodgy "done changing state" flag internal to the object itself and implement const checking at runtime.
Citizen 20.1.01
'The question is,' said Humpty Dumpty, 'which is to be master - that's all.'
Shog9 wrote:
C++: method would return a const reference. Any naive caller attempting to modify it would trigger a compiler error.
Yes, and that naive caller (who's also foolish and stubborn) soon discovers that he can cast away constness and get away with murder. :-)
Shog9 wrote:
C#: method must return interface rather than direct object reference
This is the way I would do it (which the above guy can also cast away if he wants).
My latest C# extension method: public static bool In<T>(this T value, params T[] values) { return values.Any(v => v.Equals(value)); } Example: bool valid = answer.In("Yes", "No", "Dunno");
-
Daniel Grunwald wrote:
They're two different languages. Get over it.
Very good point, and succinctly put. C# has totally different design goals.
Simon
Simon Stevens wrote:
C# has totally different design goals.
I would phrase it that C# has totally different design constraints.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
They still haven't produced a coordinate system where Y increases as you go up. This means that polar coordinates rotate the wrong way around the origin. How difficult can it be? They don't have X increasing to the left so why have Y increasing downwards? It's not difficult, other systems (e.g. RiscOS) have done it the right way up for years.
Because in user interfaces, the upper left corner is the origin. When you resize a screen, for example, you typically want the origin to remain where it is and have the bottom of the window reduce or expand.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
Shog9 wrote:
C++: method would return a const reference. Any naive caller attempting to modify it would trigger a compiler error.
Yes, and that naive caller (who's also foolish and stubborn) soon discovers that he can cast away constness and get away with murder. :-)
Shog9 wrote:
C#: method must return interface rather than direct object reference
This is the way I would do it (which the above guy can also cast away if he wants).
My latest C# extension method: public static bool In<T>(this T value, params T[] values) { return values.Any(v => v.Equals(value)); } Example: bool valid = answer.In("Yes", "No", "Dunno");
Al Beback wrote:
Yes, and that naive caller (who's also foolish and stubborn) soon discovers that he can cast away constness and get away with murder.
Yeah, and i can still access anything i want to with Reflection in C#, or with direct memory access in C++. I can still write a COM method that does evil things with (in,out) parameters. So what? This isn't about security, it's about the ability to specify what's appropriate and have the compiler help you out if you forget what's what. You know. The same reason some of us use languages with explicit datatypes. When i want my language to act like Javascript, i use Javascript.
Al Beback wrote:
This is the way I would do it (which the above guy can also cast away if he wants).
You must work with evil, evil people... :~
Citizen 20.1.01
'The question is,' said Humpty Dumpty, 'which is to be master - that's all.'