|
pherschel wrote: I can see readonly for parameters and such,
That's actually one of the things I love about Swift[^]: params are by default readonly
cheers
Chris Maunder
|
|
|
|
|
That's actually a VERY good idea. I.e. if you wanted some by-value parameter and be able to change its value inside the function, decorate it with something like volatile (or perhaps duplicated would be a more apt naming). Or to just make it sound similar to out and ref ... call it something like in, or dup, or copy, ...
This would allow for so much better optimisations across the board, while disallowing stupid things like assigning new values to by-value parameters unless you specifically state that's what you want.
|
|
|
|
|
Quote: Why can't I say
const DateTime today = DateTime.Now;
Because DateTime.Now is not a compile-time constant, it's a run time property which returns an non-constant value.
Suppose it did allow it: what value should be in today?
The DatetIme when the app was started? When the assembly containing the code was loaded? When the class containing the constant value was statically initialized?
What would happen if two different classes (or worse assemblies) both declared the same value? Would they be the same? Should they be? How would the system decide for you?
That's the point of const vs readonly - the former is a compile time constant value, the later is a runtime constant value. That way, you have the choice for what exactly you want to do, rather than letting the system try to make up it's mind for you.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: What would happen if two different classes (or worse assemblies) both declared the same value? Would they be the same? Should they be? How would the system decide for you?
Well no they because they would be separate instances (each class it's own), even if from the same or separate assemblies.
Sin tack
the any key okay
|
|
|
|
|
OriginalGriff wrote: That's the point of const vs readonly - the former is a compile time constant value, the later is a runtime constant value.
While this is true, readonly is used for objects (except for string  ) as a compiler hack because constant (i.e. readonly) objects are really pointers whose value varies at load time. The fact the compiler writers did it for string means they could have done it for any object. But, I'm not interested in the object's pointer, I'm interested in the object's constant value.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
TheGreatAndPowerfulOz wrote: The fact the compiler writers did it for string means they could have done it for any object.
That's not true, although string is an object, it's a special type of object. It's immutable and can be allocated both on the heap and the stack. Other object types are allocated on the heap exclusively but are not nativelly immutable.
Strings also have a mechanism called interning. By default const strings are interned for optimization purposes.
Having that said, string gets all kinds of special treatment. Remember that you can only declare a const string literal. For example:
const string _myString = String.Empty;
This also defeats the statement that other reference types could have the same treatment. As every reference type you want to use const with, would have to have a literal representation, so its value could be determined at compile-time. Like the string literal.
TheGreatAndPowerfulOz wrote: readonly is used for objects (except for string )
Value types can also be readonly.
Reinforcing what Original Griff said, the difference between readonly and const are as simple as one is a run-time constant and the other a compile-time constant. If a variable's value cannot be determined at compile-time, it cannot be a const.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
Our heads are round so our thoughts can change direction - Francis Picabia
modified 8-Jun-17 8:00am.
|
|
|
|
|
What you say may be true, but const could have and should have been used for both situations.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
TheGreatAndPowerfulOz wrote: could
Yes, could, but should it?
They behave differently and actually generate different IL code. The compiler could also determine that automatically, when generating IL code. But I don't think that's a good idea, but we will end up in another filosophical discussion. In my opinion this compiler behavior could generate those situations developers don't understand what's happening and why their code does not work as expected.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
Fabio Franco wrote: should it?
Yes.
Fabio Franco wrote: my opinion
Doubt it.
Fabio Franco wrote: another filosophical discussion
That's what life is about.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
I'd like to see the let keyword added to C# for this purpose, to replace var in cases where the binding will not be mutated. Swift makes this distinction, and F# uses let with this meaning (and let mutable for what C# calls var).
It also just feels really good, like a benevolent ruler. The variable wants to have this value, and you just have to let it.
const is what JavaScript uses for non-mutable bindings, but in C# it already specifically refers to compile-time constants in C#. Also, const just doesn't feel as good as letting a variable follow its heart.
|
|
|
|
|
Member 10277807 wrote: I'd like to see the let keyword added to C#
That would actually be pretty cool. It already exists with Linq, but it would a nice addition to the language itself, at least for value types.
let has a functional nature and C# has been slowly adopting some of the functional programming features. I can see it come to C# soon enough.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
I can't do this either 
const DateTime tick = new DateTime(2001, 1, 1);
- Pete
|
|
|
|
|
Of course, you would use readonly for that. I happen to agree with you that const should be allowed in these cases. The readonly verb is an admitted hack by the compiler writers. After all, string is an object (i.e. non-primitive) and you can use const with it.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
That's because const value must be known at compile-time. Instantiating DateTime requires code execution, which will only be done at run-time.
For that scenario you have the readonly, a run-time constant (intialized once and never changes).
You can only use const on variables that can be represented by literals.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
pherschel wrote: Is it me or do you get confused by this? Why can't I say
const DateTime today = DateTime.Now;
Constants aren't variables, they just look like them, they are aids for the compiler, they don't exist at run-time. When you write
const int x = 5;
int y = 2;
int z = y + x;
bool b = z <= x;
what gets compiled is this
int y = 2;
int z = y + 5;
bool b = z <= 5;
The compiler replaces all instances of "x" with the constant value. If you could define x as DateTime.Now then what would be compiled? If it literally replaced "x" with "DateTime.Now" everywhere it appears then you almost certainly would not get the result you desire. If it replaced DateTime.Now with the date of compilation then that wouldn't work either. What you really want is a read-only variable, and that's why we have read only variables and constants. You have to understand what they are and use them appropriately, that's not a failing of .net.
This is also why you can't make objects const.
const Person p = new Person();
p.FirstName = "John";
p.Age = 33;
Console.WriteLine (p);
pherschel wrote: For properties, why can't I hide the worker variable for the rest of the class?
Use the short-hand version
int PageNbr { get; set; }
Again it's simply a case of understanding the difference and knowing when and where to use the appropriate solution.
pherschel wrote: For destructors, why can't you give me option to destroy right away?
Because .net is better at memory management than you are and if you leave .net to do your memory management you'll get code that performs well, if you try and do your own memory management you get code that performs badly. For one it means the code is harder for the compiler to optimise as the compiler likes to move your code around for the best overall result but when you have in-line memory management you lesser the optimiser's abilities. Also memory deallocation is expensive. If you could free your objects immediately you probably would (otherwise why would you want this feature?) and that will result in a not-insignificant performance hit. By leaving this aspect to .net it can clear the memory down at a time better suited, like when your app is idling, or some other conditions are met. That way the performance hit is not noticeable, it discretely happens in the background.
pherschel wrote: If you open a file and a DB you have to nest usings before you even get started doing some work
You don't have to nest usings at all
using (This x = new This())
using (That y = new That())
{
}
|
|
|
|
|
F-ES Sitecore wrote: Because .net is better at memory management than you are and if you leave .net to do your memory management you'll get code that performs well, if you try and do your own memory management you get code that performs badly.
Well, you could jump outside of the CLR and allocate memory directly such as
unsafe
{
[DllImport(@"C:\Windows\System32\kernal32.dll")
public static extern void * HeapAlloc(void * procHeap, UInt32 dword, UInt32 size);
}Not saying that this is a good thing but it's possible and pretty much defeats the purpose of the CLR and GC. Not to mention memory management is one of the most challenging aspects of computer programing. If it weren't for .Net, my programs would most likely leak memory all over the place (my C and C++ KungFu is not strong).
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
If you need to explain const to someone with a C background: Think of it as a #define. It is integrated in the the language, processed by the compiler rather than a preprocessor, e.g. it is typed, so it isn't a perfect parallell. Yet, lots of the things people think that should be allowed with const can be answered by "Can you do what you want with C #define statements?"
"Constants ain't. Variables won't." - this is what the requests usually boil down to - constants that ain't. (But I can understand that you might be confused by "read-only variables": Considering the semantics, that sounds like an oxymoron, a variable that won't. A more desciptive term would be "set_once", but readonly is firmly established, and can't be changed today.
(In C, you could do it by a #define. I used to do that, e.g. #define ever (;;), so that I could write "for ever { ... }", but some of my colleauges insisted that "while (1) {...}" was far more readable. I suggeste that we declared "#define WW3 0" so that we could write "while (!WW3)", but that was met with even stronger protests.)
|
|
|
|
|
pherschel wrote: How about a free keyword on a variable or something to get me out of the business of resource management
Isn't that a contradiction in terms? Having done over a decade of C++ (and not missing it one bit), it seems to me that if you want a 'free' keyword, then you're not getting out of the business of resource management, you're asking to get into it...
I must be completely misunderstanding something.
|
|
|
|
|
dandy72 wrote: I must be completely misunderstanding something.
Or he is...
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
I always give the other guy the benefit of the doubt. Then if it turns out I'm right, I point and laugh.
|
|
|
|
|
In my historical archives I have preserved a long NetNews-discussion from the late 1990s: Even that late, there were some people insisting that high level languages are just a short-lived fad; programmers will soonrealize that for high-performing programs, you must code in assembler. Fortunately, they were not right.
For another fifteen years, I was similarly convinced that to control memory use, you simply had to do mallocs and frees yourself in longhand. No way can an automatic garbage collector know what is the best strategy. Then I read the memory management chapter of "CLR via C#". Again and again, I said to myself: Gee, that's smart! I would never have thought of that! ... So my sceptisism towards garbage collectors dwindled away in a few days.
I have several colleagues who have not yet read the same book, so they are still as sceptical as I used to be. Besides, some of them are coding in C rather than C#. If/when you switch from C to C#, you might want to bring some old habits over to the new environment, such as trying to "help" the GC. You should not. Its usefulness is at the same level as telling the C compiler how to use its registers. (I recently read that 'register' will disappear from C++17 - I'd say that is extremely overdue.)
|
|
|
|
|
Member 7989122 wrote: If/when you switch from C to C#, you might want to bring some old habits over to the new environment, such as trying to "help" the GC. You should not.
Well said. When I transitioned from C++ to C#, I read a small amount of material on garbage collection (admittedly, a very small amount), but everything I read convinced me from the get-go that it was pointless to try to do just that, and instead just let it do its job. I've never looked back.
|
|
|
|
|
What's so wrong with it?
If you don't like the idea, you could always just:
var someObject = new MyDisposableObject();
someObject.Dispose();
The trouble with that is, if the code never reaches that Dispose line, it won't get called. In which case you then incorporate it into a try-finally block like so:
var someObject = new MyDisposableObject();
try {
}
finally {
someObject.Dispose();
}
But ... that's exactly what a using clause does for you ... just a whole lot less coding on your side:
using (var someObject = new MyDisposableObject()) {
}
I might have liked an idea where you could add numerous unrelated disposables into the using clause - this may alleviate nesting usings. Though take note that with nesting you've got some control over the order in which they're disposed. Also some disposables are contained in other disposables, and in most such cases disposing the container does so to its contents as well, meaning you only need dispose the final container --> only one using clause.
More of an issue for me is the fact that a destructor isn't called deterministically, if at all. If such were possible, then the dispose pattern could be moved into the destructor instead of a dispose method. And even if you forget to dispose it, it would finally happen once the GC frees it from resources. Though this means the entire GC idea needs a revamp, in fact some of C#'s creators also think this is one of the biggest mistakes in the entire DotNet, just that they do know the reasons such choice was made.
|
|
|
|
|
From your example (i.e. placing DateTime.Now into a const) ... are you intending to save the compile timestamp into the executable code? What would be the intent? It would be pretty close (if not exactly the same) as the file date of the EXE/DLL.
Only idea I could think for this to be used is to check if the executing file has been altered since it was compiled. Though for that I'd rather use some hash value instead, even just CRC would be more comprehensive than a timestamp.
To me, the readonly idea makes more sense - i.e. it would save the time the program was started.
This is the true difference between const and readonly: Const is as if the compiler changes your code to as if you typed in a literal value. Readonly is a way to make sure a variable only gets assigned its value once - from any calculation at runtime. The two ideas are not interchangeable, at least not in most cases.
|
|
|
|
|
These are probably a good idea. Though semantic-wise I'd actually want it to be a readonly instead. In C++ const is used to give the compiler a hint so it knows this parameter wont get changed inside the function, so a copy of it need not go onto its stack (just a direct memory link instead). But even there I'd actually want to rename it to something like readonly instead, const just confuses the hell out of me (is it only a param calculated at compile time, why then not just a normal const in the first place and do away with the param entirely?)
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
