468,771 Members | 1,892 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,771 developers. It's quick & easy.

Performance comparison - C#, C++, java

I read this fantastic article this morning, which raises some interesting
points... like, for example, the TREMENDOUS performance advantage of writing
code with using() as opposed to just letting the garbage collection do it's
thing. The author appears to be quite neutral, so this is not a "C# is
better than java" type of post. In fact, he is pretty brutal to C# (that it
apparently deserves) on several points.

Skeet, you ought to love this one. :)

http://click.wd-mag.email-publisher....aa2d30b5V7MTb/
Nov 15 '05 #1
20 6478
"This article looks at the 'threat' C#/Java has become to C++..."

The "threat" (benefit in using C# over other language) was never in
performance to begin with (although his benchmarks seem pretty good for C#).

As far as the using statement, he didn't understand how to Dispose an object
correctly. If an object has a Dispose method (and most likely has a
Finalizer) then it's VERY important to call the Dispose method, period. The
using statement does that for us. If you don't use it, you need to call
Dispose. This applies to object with a Finalizer, even if it has no
unmanaged resources. He shouldn't be benchmarking these features if he
doesn't understand them. Later he talks about the GC time (apparently
showing that using helps). Well, if you call Dispose and that does the
SuppressFinalize, then you get objects collected much faster (since they get
collected in one collection instead of needing 2). This of course has
performance issues, but only if you code incorrectly. His statements of
saying that it requires the users to understand things very well is not
true. Just calling Dispose (or Close) on a class is enough. Don't see what
the big deal is.

Overall, I get the feeling that C# is kicking butt (considering he's
comparing the first release of C#).

-mike
MVP

"Daniel Billingsley" <db**********@NO.durcon.SPAAMM.com> wrote in message
news:Oz**************@TK2MSFTNGP09.phx.gbl...
I read this fantastic article this morning, which raises some interesting
points... like, for example, the TREMENDOUS performance advantage of writing code with using() as opposed to just letting the garbage collection do it's thing. The author appears to be quite neutral, so this is not a "C# is
better than java" type of post. In fact, he is pretty brutal to C# (that it apparently deserves) on several points.

Skeet, you ought to love this one. :)

http://click.wd-mag.email-publisher....aa2d30b5V7MTb/

Nov 15 '05 #2
"Michael Giagnocavo [MVP]" <mg*******@Atrevido.net> wrote in message
news:eT**************@TK2MSFTNGP09.phx.gbl...
"This article looks at the 'threat' C#/Java has become to C++..."

The "threat" (benefit in using C# over other language) was never in
performance to begin with (although his benchmarks seem pretty good for C#).

No, but the "threat" would be mitigated by a percieved performance weakness
in C#. That certainly was one of the plagues of VB6 - no "serious"
programmer would consider it for a "real" application, right?

As far as the using statement, he didn't understand how to Dispose an object correctly. If an object has a Dispose method (and most likely has a
Finalizer) then it's VERY important to call the Dispose method, period. The using statement does that for us. If you don't use it, you need to call
Dispose. This applies to object with a Finalizer, even if it has no
unmanaged resources. He shouldn't be benchmarking these features if he
doesn't understand them. Later he talks about the GC time (apparently
showing that using helps). Well, if you call Dispose and that does the
SuppressFinalize, then you get objects collected much faster (since they get collected in one collection instead of needing 2). This of course has
performance issues, but only if you code incorrectly. His statements of
saying that it requires the users to understand things very well is not
true. Just calling Dispose (or Close) on a class is enough. Don't see what the big deal is.
I think he makes it quite clear that having to know if you CAN call Dispose
is the big deal in his opinion.

You sure took this point differently than I did. I'll say that I've been to
many many seminars, MSDN cafes, VSLive!, etc. and have never heard a single
speaker, Microsoft employee or otherwise, say calling Dispose on every class
you can is "VERY important". In fact, what I've heard preached over and
over is "forget about it" because the GC will watch your back. Yes,
everyone preaches close close close (in try/finally blocks) on resources
like file or database connections but that's a different thing, isn't it?

Now granted, I'm fairly ignorant in regards to the technical details of
Dispose() and Finalize() and GC - but I think that's the point. Someone
like me has been led to believe I don't have to worry about much because GC
is such a beautiful thing, and that's not necessarily the case. I say not
necessarily, because of course we're talking about a certain type of
application where it would even matter to a significant. That is, many
business simply don't have to consider a scenario of creating millions of
objects as fast as they can.

Overall, I get the feeling that C# is kicking butt (considering he's
comparing the first release of C#).


Indeed.

BTW, what kind of guy writes a language like D in his spare time? :)

I also thought things like the string concatenation results were very
interesting. I think the general attitude of C# developers tends to be anal
about using stringbuilder instead of successive concatenations, for example,
but the test results show the performance hit isn't really that bad.
Nov 15 '05 #3
Here's an example of what I was talking about straight from the
documentation:

"Automatic memory management is one of the services that the common language
runtime provides during Managed Execution. The common language runtime's
garbage collector manages the allocation and release of memory for an
application. For developers, this means that you do not have to write code
to perform memory management tasks when you develop managed applications.
Automatic memory management can eliminate common problems, such as
forgetting to free an object and causing a memory leak, or attempting to
access memory for an object that has already been freed."
Nov 15 '05 #4
> > The "threat" (benefit in using C# over other language) was never in
performance to begin with (although his benchmarks seem pretty good for C#).

No, but the "threat" would be mitigated by a percieved performance

weakness in C#. That certainly was one of the plagues of VB6 - no "serious"
programmer would consider it for a "real" application, right?
Was that sarcastic? VB6 has HUGE usage for very serious and real purposes.
Maybe not D3D games or rendering engines or office, but many many business
apps run on VB6.

I think he makes it quite clear that having to know if you CAN call Dispose is the big deal in his opinion.
Well, I guess it just depends on how hard he thinks finding out if a Close
or Dispose method is. In VS.NET, this is trivial. I suppose it might be
harder in emacs (you gotta go read... the docs!).
You sure took this point differently than I did. I'll say that I've been to many many seminars, MSDN cafes, VSLive!, etc. and have never heard a single speaker, Microsoft employee or otherwise, say calling Dispose on every class you can is "VERY important". In fact, what I've heard preached over and
over is "forget about it" because the GC will watch your back. Yes,
everyone preaches close close close (in try/finally blocks) on resources
like file or database connections but that's a different thing, isn't it?


The GC will handle things. It cleans up *managed memory*. It will also
call the finalizers for you so technically, you don't need to call Dispose,
because *eventually* it'll do that when the managed memory requirements for
a GC are hit. The doc quote you posted is referring to this.

The reason I say it's VERY important is because if an object is finalizable,
that means it takes two GCs to collect it. After it's no longer accessible,
then it's collected, but kept around for it's finalizer to be run. After
the finalizer is run, then it's not longer on the finalizequeue. Then there
are *no* roots to it, and it can be freed. Thus, you'll incur many more
GCs, due to the fact that these objects are staying around for much longer
than needed. This is regardless if there are unmanaged resources, since any
finalizable object will get put on the finalize queue.

In his test, he created a situation that was crafted to break. Then he
seems to say that "using" is the only way around this. No, if he is using
an IDisposable, he should dispose it. He was smart enough to figure out
which objects could go in the using statement, so how hard is it to just
call Dispose when you're done?

-mike
MVP
Nov 15 '05 #5

"Michael Giagnocavo [MVP]" <mg*******@Atrevido.net> wrote in message
news:%2******************@TK2MSFTNGP09.phx.gbl...
Was that sarcastic? VB6 has HUGE usage for very serious and real purposes. Maybe not D3D games or rendering engines or office, but many many business
apps run on VB6.
Yes, of course. But as you point out in certain circles VB6 was easily (and
validly) dismissed because of performance issues alone, so performance does
affect the threat level, even though it may not be the basis of the threat
in the first place. That's all, not trying to argue.
The reason I say it's VERY important is because if an object is finalizable, that means it takes two GCs to collect it. After it's no longer accessible, then it's collected, but kept around for it's finalizer to be run. After
the finalizer is run, then it's not longer on the finalizequeue. Then there are *no* roots to it, and it can be freed. Thus, you'll incur many more
GCs, due to the fact that these objects are staying around for much longer
than needed. This is regardless if there are unmanaged resources, since any finalizable object will get put on the finalize queue.
Yes, I understand all that reasonably well I think. My point is that I have
only very recently started to hear about the importance of using(), etc. and
it's not from Microsoft types. The marketing-speech, and even the
documentation, is talking about .NET was how great GC was because you just
simply didn't have to worry about those pesty details.

And I think that's still true enough for many business applications, just as
VB6 was good enough for them, as you point out. Probably only in an
application where performance is extremely critical or the expected scaleout
is quite large (same thing?) does it significantly matter.
In his test, he created a situation that was crafted to break. Then he
seems to say that "using" is the only way around this. No, if he is using
an IDisposable, he should dispose it. He was smart enough to figure out
which objects could go in the using statement, so how hard is it to just
call Dispose when you're done?


I just now realized that when writing "using(ObjectA)" that ObjectA must
implement IDisposable, so your points are spot on. His statement/argument
doesn't make a whole lot of sense. I had assumed that using() would just
figure out what it should do (or not).
Nov 15 '05 #6
> Yes, I understand all that reasonably well I think. My point is that I
have
only very recently started to hear about the importance of using(), etc. and it's not from Microsoft types. The marketing-speech, and even the
documentation, is talking about .NET was how great GC was because you just
simply didn't have to worry about those pesty details.


Can you point me to some docs that say Dispose/Close is completely
unnecesary (details so I can find it in the MSDN library)? I'd like to file
some bugs.

Thanks,
-mike
Nov 15 '05 #7
Daniel,
"Automatic memory management is one of the services that the common language
runtime provides during Managed Execution. The common language runtime's
garbage collector manages the allocation and release of memory for an
application. For developers, this means that you do not have to write code
to perform memory management tasks when you develop managed applications.
Automatic memory management can eliminate common problems, such as
forgetting to free an object and causing a memory leak, or attempting to
access memory for an object that has already been freed."


How true. Note however, that this statement is only about *memory*
management. Finalize() (written as destructor in C#) and Dispose() are
about *resource* management.

When you scan through the .NET framework you'll find 4 different types
of classes implementing IDisposable:

1. Classes where cleanup affects more than one object with a
finalizer, e.g. StreamWriter (A StreamWriter object internally holds a
reference to a Stream object and both have a finalizer).
2. Classes representing non-shareable resources, e.g. FileStream
3. Classes representing resources that are limited by other factors
than memory, e.g. Icon (the number of Icons an AppDomain can create
seems to be limited to ~5000).
4. Others implement it to put the object in a state where it is no
longer used, e.g. MemoryStream.Dispose() marks the stream as closed
but does nothing else.

a. When you fail to call Dispose() (or any other method that cleans up
like e.g. Close()) on objects of classes similar to 1, you are
guaranteed to lose data. This is because the finalization order of no
longer accessible objects is not defined in .NET. Consequently
StreamWriter.~StreamWriter cannot access the Stream object because its
finalizer might have run already.

b. When you fail to call Dispose() on an object similar to 2, you will
*often* run into a problem. I.e. when you try to use the resource
again later. E.g. create a FileStream object, write to the file and
let the object go out of scope. A few seconds later try to do the same
again. Unless you've been very lucky (i.e. the GC has run in the mean
time), the second attempt will fail, as the first object is still
sticking around having a write lock on the file.

c. When you fail to call Dispose() on objects similar to 3, you will
*sometimes* run into problems. I.e. when you use a large enough number
simultaneously and have a high create/throw-away rate.

d. When you fail to call Dispose() on objects similar to 4, you'll
almost never run into problems.

If you want your code do the right thing you have two strategies:

A. Always call Dispose() on objects implementing IDisposable
B. Check documentation what kind of class you have (1 .. 4) and call
Dispose only if necessary

You decide what's best ;-) ...

Regards,

Andreas

P.S. I personally went from A to B and back to A (and I think I stick
with A for the rest of my carreer). The last move is due to a
discussion with John Skeet followed by a deep of research into the
subject.
Nov 15 '05 #8
"Daniel Billingsley" <db**********@NO.durcon.SPAAMM.com> wrote in message news:<ey**************@TK2MSFTNGP10.phx.gbl>...
Here's an example of what I was talking about straight from the
documentation:

"Automatic memory management is one of the services that the common language
runtime provides during Managed Execution. The common language runtime's
garbage collector manages the allocation and release of memory for an
application. For developers, this means that you do not have to write code
to perform memory management tasks when you develop managed applications.
Automatic memory management can eliminate common problems, such as
forgetting to free an object and causing a memory leak, or attempting to
access memory for an object that has already been freed."


Ha ha ha. My experience is that memory management in C# is extremely
tricky, much trickier than memory management of C++ applications. I
have found several obscure ways for things to go wrong. For example,
closing a form disposes it, and you will get an exception if some
timer callback attempts to manipulate the controls of a closed form.
Also, some Windows.Forms controls are registered in some internal data
structure, and will never be garbage collected unless explicitly
disposed, which means that any form that contains them will never be
garbage collected, nor will any data used by the form, and so on...

You could argue that these are library issues and not language issues,
but it's all the same to me. The result is that effective C#
programming requires a lot of arcane knowledge.
Nov 15 '05 #9

"Andreas Huber" <ah****@gmx.net> wrote in message
news:3e**************************@posting.google.c om...

How true. Note however, that this statement is only about *memory*
management. Finalize() (written as destructor in C#) and Dispose() are
about *resource* management.
Hmm... good distinction that I didn't detect through my newbie colored
glasses.

Why then is Dispose() so necessary if I am very anal about closing
resources. I mean if I write all my file, database, etc. in try/finally
blocks and .Close() everything has that done a lot to mitigate the Dispose()
need or is it something different? Talking about your type 2 (and maybe 1)
below, of course.

When you scan through the .NET framework you'll find 4 different types
of classes implementing IDisposable:

1. Classes where cleanup affects more than one object with a
finalizer, e.g. StreamWriter (A StreamWriter object internally holds a
reference to a Stream object and both have a finalizer).
2. Classes representing non-shareable resources, e.g. FileStream
3. Classes representing resources that are limited by other factors
than memory, e.g. Icon (the number of Icons an AppDomain can create
seems to be limited to ~5000).
4. Others implement it to put the object in a state where it is no
longer used, e.g. MemoryStream.Dispose() marks the stream as closed
but does nothing else.

Nov 15 '05 #10
I think the idea was for *clients* of your code to have an easy formalism to
remember that would accomplish the clean-up after the object was no longer
needed. Ideally, the documentation would specify that Dispose needs to be
called (although just the presence of the method should be enough to suggest
that). Once folk get used to seeing the same discipline across classes
authored by various sources it should become natural for users to invoke
Dispose.
"Daniel Billingsley" <db**********@NO.durcon.SPAAMM.com> wrote in message
news:OD***************@TK2MSFTNGP11.phx.gbl...

"Andreas Huber" <ah****@gmx.net> wrote in message
news:3e**************************@posting.google.c om...

How true. Note however, that this statement is only about *memory*
management. Finalize() (written as destructor in C#) and Dispose() are
about *resource* management.
Hmm... good distinction that I didn't detect through my newbie colored
glasses.

Why then is Dispose() so necessary if I am very anal about closing
resources. I mean if I write all my file, database, etc. in try/finally
blocks and .Close() everything has that done a lot to mitigate the

Dispose() need or is it something different? Talking about your type 2 (and maybe 1) below, of course.

When you scan through the .NET framework you'll find 4 different types
of classes implementing IDisposable:

1. Classes where cleanup affects more than one object with a
finalizer, e.g. StreamWriter (A StreamWriter object internally holds a
reference to a Stream object and both have a finalizer).
2. Classes representing non-shareable resources, e.g. FileStream
3. Classes representing resources that are limited by other factors
than memory, e.g. Icon (the number of Icons an AppDomain can create
seems to be limited to ~5000).
4. Others implement it to put the object in a state where it is no
longer used, e.g. MemoryStream.Dispose() marks the stream as closed
but does nothing else.


Nov 15 '05 #11

"Fred Mellender" <no****************@frontiernet.net> wrote in message
news:N_****************@news01.roc.ny...
I think the idea was for *clients* of your code to have an easy formalism to remember that would accomplish the clean-up after the object was no longer
needed. Ideally, the documentation would specify that Dispose needs to be called (although just the presence of the method should be enough to suggest that). Once folk get used to seeing the same discipline across classes
authored by various sources it should become natural for users to invoke
Dispose.

Not to mention that it allows language features like foreach(if your
IEnumerator is disposable, it will dispose it) and using to properly clean
up. A standard interface was needed, as to why they choise IDisposable and
Dispose is a question to ask others, but a standard way of doing it is
important.

"Daniel Billingsley" <db**********@NO.durcon.SPAAMM.com> wrote in message
news:OD***************@TK2MSFTNGP11.phx.gbl...

"Andreas Huber" <ah****@gmx.net> wrote in message
news:3e**************************@posting.google.c om...

How true. Note however, that this statement is only about *memory*
management. Finalize() (written as destructor in C#) and Dispose() are
about *resource* management.


Hmm... good distinction that I didn't detect through my newbie colored
glasses.

Why then is Dispose() so necessary if I am very anal about closing
resources. I mean if I write all my file, database, etc. in try/finally
blocks and .Close() everything has that done a lot to mitigate the

Dispose()
need or is it something different? Talking about your type 2 (and maybe

1)
below, of course.

When you scan through the .NET framework you'll find 4 different types
of classes implementing IDisposable:

1. Classes where cleanup affects more than one object with a
finalizer, e.g. StreamWriter (A StreamWriter object internally holds a
reference to a Stream object and both have a finalizer).
2. Classes representing non-shareable resources, e.g. FileStream
3. Classes representing resources that are limited by other factors
than memory, e.g. Icon (the number of Icons an AppDomain can create
seems to be limited to ~5000).
4. Others implement it to put the object in a state where it is no
longer used, e.g. MemoryStream.Dispose() marks the stream as closed
but does nothing else.



Nov 15 '05 #12
Kevin Cline <kc******@hotmail.com> wrote:

<snip>
You could argue that these are library issues and not language issues,
but it's all the same to me. The result is that effective C#
programming requires a lot of arcane knowledge.


Not really - you dispose everything that implements IDisposable (such
as Form) when you're certain it's not needed any more. Anything that
doesn't implement IDisposable, you assume you don't need to worry
about. I haven't seen many cases that doesn't cover.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #13
> Why then is Dispose() so necessary if I am very anal about closing
resources. I mean if I write all my file, database, etc. in try/finally
blocks and .Close() everything has that done a lot to mitigate the Dispose()
need or is it something different? Talking about your type 2 (and maybe 1)
below, of course.


Close() and Dispose() do exactly the same in all classes I am aware of
so just having Dispose() would be enough. However, for historical
reasons it would confuse people in some cases. E.g. many consider it
unnatural not to have a .Close() function on a FileStream.
I personally only use using-blocks, even inside Dispose(). I.e. a
typical Dispose function of mine looks as follows:

class SomeClass : IDisposable
{
FileStream stream = new FileStream( /* ... */ );

// ...

public void Dispose()
{
using ( stream ) {}
}
}

The using block is equivalent to the following:

if ( stream != null )
{
stream.Dispose();
}

So this saves me some typing. The only place where you can't use using
is when you call the base implementation of Dispose(), as follows:

class A : IDisposable
{
public void Dispose() { /* ... */ }

// ...
}

class B : A
{
public override void Dispose()
{
try
{
// ...
}
finally
{
base.Dispose();
}
}
}
Nov 15 '05 #14


--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.
"Andreas Huber" <ah****@gmx.net> wrote in message
news:3e**************************@posting.google.c om...
Why then is Dispose() so necessary if I am very anal about closing
resources. I mean if I write all my file, database, etc. in try/finally
blocks and .Close() everything has that done a lot to mitigate the Dispose() need or is it something different? Talking about your type 2 (and maybe 1) below, of course.


Close() and Dispose() do exactly the same in all classes I am aware of
so just having Dispose() would be enough. However, for historical
reasons it would confuse people in some cases. E.g. many consider it
unnatural not to have a .Close() function on a FileStream.


Typically, such classes define Close(), but then implement IDisposable
explicitly to do the same thing as Close().
Nov 15 '05 #15
On 21 Nov 2003 05:28:27 -0800, ah****@gmx.net (Andreas Huber) wrote:
Close() and Dispose() do exactly the same in all classes I am aware of
so just having Dispose() would be enough. However, for historical
reasons it would confuse people in some cases. E.g. many consider it
unnatural not to have a .Close() function on a FileStream.

So, are you saying that when using FileStream objects, you should call
stream.Dispose() instead of stream.Close() after you are finished using it?
From that, I take it that the close of the file actually comes when you close
your binaryReader/Writer object. Is that right or am I missing something?

I come from the Delphi world where you always dispose of objects and free memory
structures that you have allocated on the heap. :)

Nov 15 '05 #16
> >Close() and Dispose() do exactly the same in all classes I am aware of
so just having Dispose() would be enough. However, for historical
reasons it would confuse people in some cases. E.g. many consider it
unnatural not to have a .Close() function on a FileStream.

So, are you saying that when using FileStream objects, you should call
stream.Dispose() instead of stream.Close() after you are finished using

it? From that, I take it that the close of the file actually comes when you close your binaryReader/Writer object. Is that right or am I missing something?

I come from the Delphi world where you always dispose of objects and free memory structures that you have allocated on the heap. :)


As I understand it, Close() does the same as Dispose() but is provided
because people will first look for a Close() as it is common to close a file
instead of "Disposing" it.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
Nov 15 '05 #17
Kerry,
Close() and Dispose() do exactly the same in all classes I am aware of
so just having Dispose() would be enough. However, for historical
reasons it would confuse people in some cases. E.g. many consider it
unnatural not to have a .Close() function on a FileStream.

So, are you saying that when using FileStream objects, you should call
stream.Dispose() instead of stream.Close() after you are finished using it?


Using either Close() or Dispose() is fine as long as you put these
calls in a finally block. Some people prefer to see Close() for
classes that define this method, others prefer to use Dispose() (or
using blocks) throughout.
As I said, I think using using-blocks throughout your code is the most
elegant solution.
However, because Dispose(), Close() and using lead to equally correct
code I don't think this is something worth having extensive arguments
over.
From that, I take it that the close of the file actually comes when you close
your binaryReader/Writer object. Is that right or am I missing something?


Correct. You only need to call Dispose() on the BinaryWriter object,
the underlying Stream is closed automatically.

Regards,

Andreas
Nov 15 '05 #18
Ok, should I find that I rarely need to implement IDisposable myself?
That's part of what I meant by my original question regarding using
..Close().

To rephrase, if I am very careful to use one of these three methods within
my class in the highest finally block on all objects that support
IDisposable, is it necessary to extend the IDisposable to MY class, which in
the context we're discussing would lead the developer using it to think he
must call my Close()?

I would think not. Am I understanding that part clearly?
"Eric Gunnerson [MS]" <er****@online.microsoft.com> wrote in message
news:eW**************@TK2MSFTNGP12.phx.gbl...
Close() and Dispose() do exactly the same in all classes I am aware of
so just having Dispose() would be enough. However, for historical
reasons it would confuse people in some cases. E.g. many consider it
unnatural not to have a .Close() function on a FileStream.


Typically, such classes define Close(), but then implement IDisposable
explicitly to do the same thing as Close().

Nov 15 '05 #19
Daniel Billingsley <db**********@NO.durcon.SPAAMM.com> wrote:
Ok, should I find that I rarely need to implement IDisposable myself?
Yes.
That's part of what I meant by my original question regarding using
.Close().

To rephrase, if I am very careful to use one of these three methods within
my class in the highest finally block on all objects that support
IDisposable, is it necessary to extend the IDisposable to MY class, which in
the context we're discussing would lead the developer using it to think he
must call my Close()?

I would think not. Am I understanding that part clearly?


It's only *usually* necessary to implement IDisposable if:

o One of your instance variables is something that implements
IDisposable
o One of your instance variables represents an unmanaged resource

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #20
Ok, whew, that makes perfect sense. And those are very concise guidelines
to remember. Thanks.

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

It's only *usually* necessary to implement IDisposable if:

o One of your instance variables is something that implements
IDisposable
o One of your instance variables represents an unmanaged resource

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 15 '05 #21

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

44 posts views Thread by jmoy | last post: by
10 posts views Thread by Alex Gerdemann | last post: by
14 posts views Thread by Greg | last post: by
11 posts views Thread by Steven D'Aprano | last post: by
7 posts views Thread by Otto Carl Marte | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
1 post views Thread by Marin | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.