Global Variables

Quote:

---

TheCPUWizard - how would you create forms which contain other controls?

---

Here we are talking about member variables, this changes things (at least from a perspective point).

The controls are created as part of the Forms Construction Process (technically during one of the startup events), and need to live for the life of the form.

Since the form implements IDisposable it can reliably call Dispose on all os the consituent controls. (And the base class in-fact does this)

Therefore, the reality is that the scope of the controls never leaves the scope of the creator (the form).

Note: If you try to take a reference to a forms control, and then close (dispose) the form, you will find that you are holding onto a "disposed" reference. :)

Quote:

---

Originally Posted by MadHatter

yes, always use a using statement to make cpuwizard happy. by all means, if you have a disposable object, dispose of it right after you create it, never dispose of an idisposable object yourself (leave that to the compiler to do) never dispose of your idisposable objects inside your dispose method, and always use the lazy using brackets (and go ahead and try to use automatic disposal on idisposable objects that dont support automatic disposal), never implement idisposable in your class that contains disposible objects, never use finializers, or any other conventions, just use disposable objects in the context of a using statement, and use objects in a using statement...

pretty solid logic.

---

1) The CPUWizard is happy, regardless of if one writes great, good, medicore, poor or no code at all (unless you are employed by me or are one of my vendors). The point is that great code will make you happy, as well as your boss, company, and customers (if you are a professional developer).

2) IDisposable means that the class contains some resource which may significantly impact system performance and should be used for the minimal amount of time. There is no such thing as "automatic disposal". In many applications it may be minutes, hours or even days before the garbage collector runs, and then it only invokes finalizers, and never (directly) calls Dispose().

3) "never implement idisposable in your class that contains disposible object" actually (assuming you are talking about contains member variables which implement IDisposable" then you should (almost) always implement IDisposable. A much bigger question is doues the design actual require that your class contain member variables which implement IDisposable (the answr is many times, yes; but also often, no....)

4) "never use finializers" They really should be avoided where ever possible. The overhead of cleaning up resources via finalizers is significantly higher than explicit cleanup.

5) j"ust use disposable objects in the context of a using statement". This is an ideal situation. I have repeatedly posted the challenge of someone developing code that does not use the internal structure of a using block, that is not succiptable to at least one leak. Remember the following are equivilant:

Code:

---

using (Class instance = new Class())
{
  /// Code
}

---

and

Code:

---

{
Class instance = null;
try
{
  instance = new Class();
  /// Code
}
finally
{
  if (instance != null)
    instance.Dispose();
}
}

---

But which is more readable????

Quote:

---

Originally Posted by TheCPUWizard

Here we are talking about member variables, this changes things (at least from a perspective point).

---

Right, so what you are saying is merely: Always make certain that Dispose will be called when an object which you created is no longer needed.

In principle I agree, but even that is not always possible. Conside for example System.IO.File.Open method which creates and returns a disposable object.

Hard rules which say "never ever" usually don't work, not even 99.999xxx% of the time.
:)

Look at the example on the link that you posted. :) :) :)

Code:

---

      using (FileStream fs = File.Open(path, FileMode.Open, FileAccess.Write, FileShare.None))
        {
            Byte[] info = new UTF8Encoding(true).GetBytes("This is some text in the file.");
            // Add some information to the file.
            fs.Write(info, 0, info.Length);
        }

---

Quote:

---

Originally Posted by TheCPUWizard

1) The CPUWizard is happy, regardless of if one writes great, good, medicore, poor or no code at all.

---

glad to hear it. I really could care less.

Quote:

---

Originally Posted by TheCPUWizard

2) IDisposable means that the class contains some resource which may significantly impact system performance and should be used for the minimal amount of time. There is no such thing as "automatic disposal".

---

placing an IDisposable object in a using statement is an automatic mechanism for disposal is it not? the IL code that is generated from it places the call to dispose on the instance, so yes.

Quote:

---

Originally Posted by TheCPUWizard

3) "never implement idisposable in your class that contains disposible object"

---

guess sarcasm is a stranger to you.

Quote:

---

Originally Posted by TheCPUWizard

4) "never use finializers" They really should be avoided where ever possible. The overhead of cleaning up resources via finalizers is significantly higher than explicit cleanup.

---

there goes that absolute reasoning again. they have their place. they do slow down destruction, but are good for unmanaged resources.

Quote:

---

Originally Posted by TheCPUWizard

5) j"ust use disposable objects in the context of a using statement". This is an ideal situation. I have repeatedly posted the challenge of someone developing code that does not use the internal structure of a using block, that is not succiptable to at least one leak. Remember the following are equivilant:

Code:

---

using (Class instance = new Class())
{
  /// Code
}

---

and

Code:

---

{
Class instance = null;
try
{
  instance = new Class();
  /// Code
}
finally
{
  if (instance != null)
    instance.Dispose();
}
}

---

But which is more readable????

---

as Zaccheus pointed out, and you obviously missed, going back to what you originally said, File.Open leaves scope with an IDisposable object, which you swore never to do.


unless you were the only guy at microsoft who was tasked with writing all the rules of fxcop and the code analysis tool, then you have just as much room for error in saying what is right and what is wrong as any of us do.

Coming in somewhere and saying:

Quote:

---

Originally Posted by TheCPUWizard

ANDY A BigSlap to you. :(

Assuming this is some type of ADO or Communication conntection they should *always* be inside of a using statement.

---

to me just shows ignorance and intolerance for other peoples ways of coding. In fact, regarding that statement, if you opened and closed a connection each time you needed a data structure for an enterprise level application, you generate a DOS on the database. So I think that you'd better watch how you say what you say, and if you're going to present an absolute on .NET, you'd better get Anders Hejlsberg or Bill Gates to come back you up.