c# Const vs. Readonly, Scope, Usings

[Chris Maunder]

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

[pherschel]

True enough. I'd love to banish usings somehow. I want to use a create & use an class, not manage it's lifetime.

- Pete

[Slacker007]

You don't have to use the "using statement". You can create an instance of the object and dispose of it manually when you are done.

[F ES Sitecore]

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); // what will the compiler replace "p" with?

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 i

[dandy72]

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.

[TheGreatAndPowerfulOz]

usings are only necessary when you need to know deterministically that a resource has been freed.

#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

[Lost User]

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

[TheGreatAndPowerfulOz]

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_ :rolleyes:) as a compiler hack because _const_ant (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 _const_ant 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]

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

[pherschel]

I can't do this either :(( const DateTime tick = new DateTime(2001, 1, 1);

- Pete

[TheGreatAndPowerfulOz]

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

[Foothill]

That's not entirely true. Look at streams. One would think this is correct.

using (var outerStream = new MemoryStream(someData))
{
using (var innerStream = new TextReader(outerStream))
{
// do something
}
}

However, the proper way is this

var outerStream = new MemoryStream(someData);
using (var innerStream = new TextReader(outerStream)
{
// do something
}

This is because the a stream will dispose of the underlying streams when you call Stream.Dispose(). I had code analysis bark at me all the time until I figured this one out.

if (Object.DividedByZero == true) { Universe.Implode(); } Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016

[Slacker007]

I was always under the impression that any IO stuff should be done in the "using" statement. Once the memory stream instance is not needed then it will be disposed, no need to kill it manually. Can you please show be some supporting evidence to support your later example, because I don't know that to be entirely true.

[Foothill]

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

[Foothill]

That little path of discovery started when I started learning the Cryptography namespace. This little code snippet (copied directly from MSDN) was getting flagged with CA2202 during code analysis.

// Create the streams used for decryption.
using (MemoryStream msDecrypt = new MemoryStream(cipherText))
{
using (CryptoStream csDecrypt = new CryptoStream(msDecrypt, decryptor, CryptoStreamMode.Read))
{
using (StreamReader srDecrypt = new StreamReader(csDecrypt))
{
// Read the decrypted bytes from the decrypting stream
// and place them in a string.
plaintext = srDecrypt.ReadToEnd();
}
}
}

This really boggled me as this is Microsoft example code being flagged as incorrect so I began to dig. Turns out there is still a lively debate about this since the documentation is a little unclear in this area. Refactoring it to the following stopped the code analysis from flagging the code.

MemoryStream memStream = new MemoryStream(data);
CryptoStream decStream = new CryptoStream(memStream, decryptor, CryptoStreamMode.Read);

using (StreamReader reader = new StreamReader(decStream))
{
decryptedValue = Encoding.UTF8.GetBytes(reader.ReadToEnd());
}

Research into this led me to this one little line in this MSDN article: StreamReader Constructor. The StreamReader object calls Dispose() on the provided Stream object when StreamReader.Dispose is called. This reads that when you close certain classes of streams, they also close the streams that underlie them as well. TL;DR Not all IDisposable classes behave the same way, event in Microsoft code, and the using statement isn't always the correct way.

if (Object.DividedByZero == true) { Universe.Implode(); } Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016

[Slacker007]

Good to know. Thanks.

[Fabio Franco]

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; //Compile-time error.

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_ :rolleyes: )

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

[kalberts]

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.)

[Fabio Franco]

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

[kalberts]

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.)