C# Irritation
-
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 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)
-
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:
IIRC readonly fields can only be assigned to in the constructors, right?
If they are members, yeah. Yes, his overall problem is that C# assumes that this just doesn't matter, and doesn't support it well.
Christian Graus No longer a Microsoft MVP, but still happy to answer your questions.
-
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.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
-
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.
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
-
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'm with you there! When will they produce a proper UK English version of Windows? :mad:
-
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.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.
-
You need some anger management. :laugh:
Wout
Venting on CP *is* anger management!
-
I'm with you there! When will they produce a proper UK English version of Windows? :mad:
No UK-EN version of OSX either I believe, also, I seem to remember them slapping us in the face by having the specific option of "US-English" but no other version of English at all.
He who makes a beast out of himself gets rid of the pain of being a man
-
You need some anger management. :laugh:
Wout
It's about C#. It is managed.
Software Zen:
delete this; -
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.
Daniel Grunwald wrote:
They're two different languages. Get over it.
Very good point, and succinctly put. C# has totally different design goals.
Simon
-
It's about C#. It is managed.
Software Zen:
delete this; -
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.
-
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 :-)