|
Yeah, I quanta say something, but I don't know how he'd react.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
Aye, matey! Methinks we should make him walk the Planck.
/ravi
|
|
|
|
|
He'd probably would walk to the end and start fission for his supper.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
That as uncertain as it can get.
Is it also true that as you dress more and more like Schroedinger your less and less certain if you're wearing anything at all; and as you're more certain that you're wearing something, the less certain you are that it looks like Schroedinger?
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Now that's thinking inside the box!
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
Just make sure no one sees you.
|
|
|
|
|
I may or may not have a super witty answer to that.
... such stuff as dreams are made on
|
|
|
|
|
I'm going as Heisenberg - however, as I know exactly where the party is I can't be sure when I'll get there.
|
|
|
|
|
And if Pauli turns up, I'll just have to leave.
|
|
|
|
|
Everett just called and said he's already seen me at the party. He's in a world of his own, that guy.
|
|
|
|
|
don't forget to feed the cat, otherwise it may or may not be there when you return (- can't do experiments if it's gone.)
Sin tack
the any key okay
|
|
|
|
|
OriginalGriff wrote: .. fancy dress party – I may or may not dress as Schroedinger ..but, did Schrodinger wear fancy dresses? I guess I'll know when I observe it.
|
|
|
|
|
In either case you will be half naked; but, no need to feel shy, because: everyone else will be, too.
«Beauty is in the eye of the beholder, and it may be necessary from time to time to give a stupid or misinformed beholder a black eye.» Miss Piggy
|
|
|
|
|
I am afraid you are going to collapse at first observation.
|
|
|
|
|
With C# getting to version 7+ I wish I could have some basic improvments.
Is it me or do you get confused by this? Why can't I say
const DateTime today = DateTime.Now;
I can see readonly for parameters and such, but I would be happy using const there too
void Doit(const MyObj arg) ...
For properties, why can't I hide the worker variable for the rest of the class?
public int PageNbr
{
int _worker = 9;
get { return _worker;}
set { _worker = value; }
}
For destructors, why can't you give me option to destroy right away? I hate disposing with all its using code bloat. How about a free keyword on a variable or something to get me out of the business of resource management. If you open a file and a DB you have to nest usings before you even get started doing some work!
Or maybe I'm missing something?
- Pete
|
|
|
|
|
Using statements tell .Net to dispose resources/object instances (auto-magically). You nest your using statements so that once that statement block is done executing is is then released (auto-magically). Each nested statement block frees itself upon completion.
Edit: Lot's of stuff on the internet about this. Objects have to implement IDisposable to be used in "using statements".
I forgot to mention that these questions should be posted in the Q&A so that people can tell you search Google for the answers. Silly me.
|
|
|
|
|
True enough. I'd love to banish usings somehow. I want to use a create & use an class, not manage it's lifetime.
- Pete
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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))
{
}
} However, the proper way is this
var outerStream = new MemoryStream(someData);
using (var innerStream = new TextReader(outerStream)
{
} 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
|
|
|
|
|
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.
|
|
|
|
|
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.
using (MemoryStream msDecrypt = new MemoryStream(cipherText))
{
using (CryptoStream csDecrypt = new CryptoStream(msDecrypt, decryptor, CryptoStreamMode.Read))
{
using (StreamReader srDecrypt = new StreamReader(csDecrypt))
{
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
|
|
|
|
|
|
Foothill wrote: However, the proper way is this
var outerStream = new MemoryStream(someData);
using (var innerStream = new TextReader(outerStream)
{
} 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.
No, it's not: if "new TextReader(outerStream)" throws you get an unclosed outerStream.
The code analysis tool you're using is broken unless it can prove that the TextReader constructor never throws, and I really doubt that 1) it's doing that analisys and 2) that it's good practice to encourage not doing the outer using because in one specific case it's guaranteed the inner stream constructor doesn't throw.
|
|
|
|
|
Sorry, TextReader was a bad example. I typed it for speed. I went into more detail here in this response[^]. There are, however, certain stream classes that implement IDisposable in which the disposal pattern goes further and disposes of underlying streams.
The code analysis is built into VS 2015 and I run it with all the rules turned on so I don't think it's broken. It was detecting MS .Net code that was going to behave contrary to preconceptions of IDisposable objects.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|