C# Irritation
-
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
In C++ the
constkeyword designates an item that may be initialized but not modified. If the programmer modifies the value, he'll get a compiler error. It's a way of ensuring that intentions for the value are met. It sounds like C# doesn't offer any consistent way to do that, and the two keywords that would seem to provide it are poorly implemented.Software Zen:
delete this; -
Venting on CP *is* anger management!
True, sharing the pain is is always good.
Wout
-
Why do you need it though? If you're not going to modify it anyway, then not making it const will not change anything and if you Are then it's just wrong IIRC readonly fields can only be assigned to in the constructors, right? And const fields are static constants - some kind of replacement for defines I think From a C++ perspective it may be a shade odd.. but afaik MSIL doesn't have const locals either, so even if you were allowed to write it, the information would just be redirected to the bit bucket (could be wrong though)
harold aptroot wrote:
Why do you need it though?
To indicate design intent as much as anything. A lot of my C++ follows a kind of functional approach (i.e. immutable state - I guess it's most like the 'do' notation that Haskell uses for monadic types). I find it makes my code more likely to be correct than modifying state willy-nilly.
-
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
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.
-
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
-
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.
-
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 ;}
-
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
And Maths is spelt with an s.
-
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");
