developer.* Blogs - To Dispose or Not to Dispose ? - Comments

This article was really

Guest — Tue, 24 Apr 2007 05:36:03 -0700

This article was really helpful. Thanks Bijesh Kuruvar for the good info.

dispose

Edward G Nilges — Fri, 06 Apr 2007 16:19:46 -0700

I'm going nuts myself because I do indeed put in the equivalent of an isDisposed flag in each class. I've generalized it and its name is always booUsable (yeah, I am a Magyar and I like Hungarian).

It has a more general use than MERELY indicating that the class instance is disposed. It also can show that the class has performed an internal self - inspection and found serious assert failures, the sign of a software bug (yes, code can and should know it has a bug).

However, I end up, in Build Your Own .Net Language and Compiler and more recent .Net code, with a repetitious infrastructure, and this while not NECESSARILY bad is a sign of trouble.

I grow weary of implementing my usability infrastructure, and this is the weariness of the artist who wants to create something new. This echo of an outdated bourgeois sensitivity has to be taken seriously because technology necessarily embeds the bourgeois sensibility.

The answer is in my language spinoza, which I am working on. Basically, .Net did not fully factor, as did Eiffel, the distinction between a class and an object, but even Eiffel does not "understand" the common needs of all classes on earth...their "human rights".

Basically, if a class has state, it needs to know when it is "disposed" or "not Usable" and it needs in this state to go on strike.

Lemme look further at your stuff and get back at you.

Interface implementation is the wrong answer to a need that is only met by MULTIPLE INHERITANCE. This is because there is no apriori reason why the thin interface may not grow over software evolution to something fat with state.

I realize that it is the fashion to be lean, mean and stateless. However, this becomes managerial anti-intellectualism in which the use of memory becomes thoughtcrime, and this is bullshit.

IDisposable design pattern for .NET 2.0??

Sheir — Wed, 04 Apr 2007 08:41:56 -0700

Hello,
I was wondering about an implementation of the IDisposable design pattern that would work in .NET 2.0 (or 3.0) where by the interface is implemented in a base class and the derived classes do not have to implement the interface.

I found an article on the web and it works great for .NET 1.1 but in VS2005 with Code Anal-ysis turned on, it does not work.
http://www.vbinfozine.com/a_disposable.shtml

Anyone have any ideas?

No answers? Really? So sorry...but...

Edward G Nilges — Wed, 07 Mar 2007 09:17:07 -0800

The "answer" was that you can clutter the heap without meaning to if you set a reference to null, and the referenced object contains references, EITHER in its current incarnation, or in a new version: the answer was informed by a vision of software as it exists in reality, in which a software artifact BY DEFAULT is a set of artifacts under continuous modification IN REALITY.

Now this is just about as simple as I can responsibly make it.

Sorry I was verbose, but I am in the process of thinking through a process, that of programming, in which the programmer is made too often into an object not permitted to think outside the box. My goal is to use language to show that the best programming occurs in full awareness, not in a narrow technical FAQ awareness, in which we're all rushing to get a job done and making a lot of mistakes.

Dispose || !Dispose

Paul — Tue, 06 Mar 2007 04:48:22 -0800

I just read the comments posted by Edward G Nilges. I must say, while I found it to be very interesting reading, it was entirely devoid of useful information. OK, so I'm not a grizzled guru of coding. That's how I got here in the 1st place, looking for useful information.

Each time I go hunting for an answer to some particularly vexxing problem, I find more of this sort of self indulgent ranting than I do answers, (yeah, yeah, I know, I'm doing the same right now) most of it not nearly as entertaining. Perhaps, if I use "-IMO" and "-IMHO" in my search string, I'll find less of this.

my $.02
back to my quest.

Paul Simon

Edward G Nilges — Thu, 05 Jan 2006 23:06:26 -0800

I should add that in the view of my Yi Number One Son, Paul Simon is a total baby Boom sell-out who writes anthems that justify desertion and abandonment. And it is true that Simon's songs can at times exhibit precisely that sort of maudlin and emotionally self-indulgent quality one hears at times in the haverings of a Steve Jobs or any member of the Live Aid rock royalty.

Nobunny is perfect. Especially not me.

(Oh no, not Leonard Cohen! Not Bird on a Wire!)

OK, enough. I gotta start listening to music again. I think I will go out and buy my third copy of Gracelands.

[No, I can't afford an iPod].

"The dead Father was killing the musicians" - Donald Barthelme

Weinberg

Edward G Nilges — Thu, 05 Jan 2006 22:49:20 -0800

I loved The Psychology of Computer Programming, Dan, but it was like Elvis' 1959 Heartbreak Hotel: you wanted the song to tell you more about what life is like "down at the end of Lonely street" but economic forces (the limit to the song imposed by the then-popular 45 RPM recording format) and a mental ban on "negative thinking" combined as a constellation (two remote things which act together in social phenomena) to force Elvis to sing more upbeat songs: the theme in HH was taken up by Coltrane.

Likewise Jerry had bills to pay (the American phrase MEANS economic, and partly deterministic, economic forces which in Europe would have different names) and having been fired by IBM (a difficult stunt before Lou Gerstner, who made it easy) Jerry was forced to make structured programming, structured design, and the psychological mindset of humility, openness and transparency (a mindset IMO at war with the competitive anger that constitutes a successful mindset in laissez-faire) into saleable, marketable commodities.

He had to "sell" his classes first in the structured design techniques and then in a more general team-building as classes that would increase productivity. He could not say that programmers would be happier and that would be a good thing.

In a different society, he might become part of an NGO organization funded at strictly apportioned proportions by government and corporations with the mission of creating and maintaining a highly professional programming work-force.

To the extent, mathematically defined, he received tax dollars he COULD talk about human flourishing and human happiness as goods in themselves logically independent of productivity. Hell, if he's spending my tax money, he'd better talk in some measure about MY personal pursuit of happiness.

But as it is, in seminars where the bottom line rules, we have to be at all times ready to reword such fine phrases as "human happiness" in such a way that they do not occur in texts which instead state that the corporation's profits will increase, and hell, won't THAT be great.

This is as reductionist in its own way as vulgar Marxism and it results in a constant low-lying tension in MIS. Basically, I have been told more than once that I am not supposed to have fun at work even though I have strange ideas of what is fun inclusive of good code and my little dispose().

Work "for hire", I agree, is in America a demand that you always be ready to obey the boss or leave if you can't abide by the rules. Indeed, this is the case in Hong Kong...MORE so than in America. I have to punch a timeclock (something I like doing because it starts and ends the work day clearly) even though I am a "professional" as a teacher.

But note that in America there are additional shackles created by a more generalized laissez - faire. For example, American programmers live I think in fear of unexpected medical costs.

By labeling Gerry's classes re-education I didn't mean that they are all bad. SOME Chinese "re-education" is good, for example, the treatment of first time drug offenders in China emphasises recovery from addiction while in America imprisoned addicts often are also denied the ability to get treatment or attend meetings.

But basically, in any corporate humanism, the corporation's needs will be first and foremost in a society in which the public sector has resigned from its role as helping people out in the main.

Corporate humanism just like Leninism always allows the system to victimize people invisibly and at the crisis. The only REAL humanism is, well, humanism, and as I read Bernard Henri Levy's book Sartre, I am hoping to confirm that even Sartre learned this.

dispose(), not IDisposeable

Edward G Nilges — Thu, 05 Jan 2006 22:05:33 -0800

I don't implement IDisposeable but I do always code a dispose() with the intent that it be used at the instant the class is no longer needed. My versions of dispose() always set a Boolean flag in the state to False, and each method and property (including dispose()) tests this flag before doing anything.

If the Boolean flag, always called blnUsable or booUsable, is False, the property or method will return a suitable default value if it has a nonvoid return and throw an error.

The constructor sets this flag to True on object startup after it is certain that it has required all needed resources. The flag may be set to False by any non-static procedure when that procedure detects corrupt data or a programming error (such as a case statement without the expected list of values).

This practice, Dan, is like that of the White Knight in Alice in Wonderland: "it's my own invention".

I totally agree that in a work for hire situation, Job One is most of the time to get along technically with the team. This rule applies even if the "team" is the 1919 Black Sox, that Chicago baseball club that deliberately lost the world series so that Meyer Lansky could make money.

The problem for me is that in my experience, the Black Sox teams have increased in number.

I am not claiming that most or even many corporations are engaged in fraud on the scale of the Black Sox (although we did learn that Enron, formerly well-regarded with a large and progressive MIS department, was). But I do claim that the players in many organizations are under subtle Black Sox pressure to not play baseball but to serve a self-defined unique "customer" who is merely the most powerful player in a corporation...that remains, despite the spin, a collection of individuals who are competing with each other.

Given that this is my view, it's my responsibility not to work in MIS, because my code would look so dissimilar to that of most .Net developers. There is a genuine need for code to look alike just as I learned when I studied engineering drawing that the boss wanted my drawings to look like those of every other competent draftsman.

This has been an old problem of mine. A computer operator in 1972 who was looking at one of my printouts and who was studying assembler for the mainframe refused to believe that my code was BAL. Every line had a comment and the identifiers were mostly at the maximum size.

But the initial wrong remains in an American MIS culture that so unquestioningly supports private needs and refuses programmers the ability to generate a true professional codex. Draftsmen could aspire to be registered professional engineers, but today, no such career path exists for programmers, only a vast wasteland of management or being a Microsoft MVP, where despite the fact that great people are MVPs, you simply have to be loyal to Microsoft's directions.

Offshoring has further put paid to the very idea of programming professionalism, although I support offshoring for other reasons including global fairness.

As to Jerry Weinberg, he is a good person I am sure. But he is ALSO responsible for the way "structured programming" was used to humiliate good programmers by the time "structured" came to mean in 1980 "I, who are stupid, can understand it".

Agree to Disagree

Daniel Read — Thu, 05 Jan 2006 09:02:58 -0800

Edward wrote:

No, I think my rule applies even in MIS .Net development, Dan. In fact it applies even more because other people will depend on your code continuing to work for all of its client objects after change.

I think we'll just have to agree to disagree on this one, Edward. I probably did not explain myself well enough previously. When I wrote this:

My point of view as a craftsperson and tradesperson for hire is that I am bound to do my best to work within the capabilities of the tools and platform in which I am being paid to work. I have to balance technical goals against the interests of my client and employer, both of whom are driven of course by business-oriented concerns. Discussions of an ideal system are interesting to me, but ultimately hypothetical.

What I meant was that, in my opinion, the best way for me to serve the people paying for my services, and at the same time the best way for me to create systems that will be recognizable and understandable by future maintainers, is for me to follow the conventions of the platform. The conventions of the platform, as established by the platform vendor and as generally agreed upon by the community, is that IDisposable and Dispose() are intended for use as I described in a previous comment. If I truly thought that there was something incorrect about the suggested uses for IDisposable and Dispose(), then I would take a different position, but I am satisfied with this suggested solution to the downsides of non-deterministic finalization.

You also wrote:

would use dispose() in a business .Net application precisely because doing it correctly in MIS is far more important than doing it correctly in hobbyist programming and arguably more important than in scientific programming...

Here again, we'll have to agree to disagree, because I disagree that what you describe is "doing it correctly." If you want to code your libraries to always implement IDisposable, then that is your perogative, and were I coding against your library I would do my best to match your intent and call Dispose() when finished with one of your objects. That is keeping to the spirit of the intent of IDisposable: respecting the class designer's desire to have deterministic finalization. But I will still contend that implementing IDisposable on every class is overkill and dilutes the usefullness and original intent of IDisposable.

Changing subjects a bit, please don't mistake me as someone who is frustrated working in the corporate environment. I am not. It's not a perfect world, but I am satisfied. The bottom line for me is that I perform work for hire. For me to take the money from my employers and clients and then to fight against their interests in the process would make me feel hypocritical (some amount of hypocrisy and contradiction in life is inevitable anyway). There are certain kinds of companies I won't work for, and certain kinds of projects I would prefer to avoid, but I work for money. I do my best to work within the bounds of professional ethics and my own high standards for quality, correctness, and sound workmanship, but beyond that the interests I am serving are my employer's and my clients'. If I don't want to serve their interests, then I should stop taking their money. I may reach that point someday, who knows.

Finally, I must come to the defense of Jerry Weinberg. It is supremely unfair, not to mention incorrect, to describe Jerry's workshops as "corporate re-education camps."

Best,
Dan

Fifty ways to leave your lover

Edward G Nilges — Wed, 04 Jan 2006 22:47:35 -0800

Note: I post *pro bono* and am not paid. I regret if my final sentence implied any other relationship of business or employment. I am a volunteer at this site.

But I am no longer even qualified in the technical sense to post on .Net because I can't afford to stay current. At the same time, I reject any imputation that my bad attitude is the problem. It's a straight technical problem.

Therefore I shall post on Open Source and on C for the most part while developing my own language. Long term I plan to acquire a Linux-only development system. I hope this meets the needs of users at this site.

Man is born free but everywhere in chains, Dan

Edward G Nilges — Wed, 04 Jan 2006 22:43:26 -0800

No, I think my rule applies even in MIS .Net development, Dan. In fact it applies even more because other people will depend on your code continuing to work for all of its client objects after change.

The argument here has the structure of one advanced by Kant after he put forward his ideas for universal peace and harmony, as was met with the "practical" objection that "this is all very well in theory but won't work in the real world".

Kant replied that he was concerned with the real world and meant his recommendations for universal peace, based on trade and democracy not as ideals but as a practical solution to the real problems of a Europe, that had undergone a global war in the form of the Seven Year's war.

I would use dispose() in a business .Net application precisely because doing it correctly in MIS is far more important than doing it correctly in hobbyist programming and arguably more important than in scientific programming where users are on average better positioned to take computer results with a grain of salt. Furthermore, microefficiency is often not important in common business applications, and microefficiency gains are not nearly as important as choosing algorithms with low polynomial time.

As it happens, because this rule isn't followed, people get screwed, as far as I can see, many times in their relationship as consumers and employees with businesses. Credit "black marks" made by erroneous software (perhaps because an object was never disposed) turn out to be not erasable because the software to erase them isn't ready yet and not considered critical because the real user is the bum who probably has bad credit anyway.

Veterans beg for health care that they were promised when they returned from Vietnam and are told to fill out THE SAME FORM repeatedly because despite all the "efficiency" of MUMPS, it can't properly network as can Oracle.

In fact, it is a well-known scandal in American health care that owing at base to the unavailability of software that keeps working after its text has been changed (the goal of my dispose() rule!), no one patient record exists, and instead information has to be entered and re-entered repeatedly to qualify for what should be a human right. During my Father's illness, I had to repeatedly meet with clerks who although they had computers continually prompted me for the same set of information and his care was screwed up because not all computers had the same set of medical facts.

This stems in part from the fact that all the way down, software isn't trust-worthy. We cannot know that it hasn't been changed, for example, so that it allocates a resource today which it did not allocate yesterday in such a matter that its unwitting clients use the software object, today UNWITTINGLY allocating those resources such that starting today, the use of the clients (which haven't been changed!) causes the system to slow down.

Therefore and as a result, it appears that reinvention is the norm in health care and patient records are incomplete and incorrect. The real user, the patient, pays the cost.

New systems are carefully designed as "object oriented" and then PROGRAMMED as static functions in the "OO" language which (whew) allows the programmer to avoid having to program objects. Or he then learns enough to be dangerous...and starts creating objects. But he is told it is "overkill" to worry about destroying them. He is laughed at not for his bugs but for "unnecessary" code which violates a nano form of efficiency by programmers who can't discern common errors in their own code and who triumphantly discovered the incorrect way to perform a binary search last week.

Computing personnel are continually in this culture urged to forget their integrity and not insist too loudly in code reviews on a practice they think or know will ensure the long-term reliability, not of a specific piece of code, but of the family of related programs that is changed over time to meet changing needs.

Indeed, in my experience, their loud insistence becomes in the data processing pop culture an unpleasant personality quirk and they find themselves sent to various corporate re-education camps...some of them operated by Jerry Weinberg...in which the TECHNICAL problem (that code really does exist not as specific bit patterns but as families of related solutions, including solutions that at first do not allocate reference objects) is recoded for corporate convenience as some sort of a personality problem.

Now, because I have educational experience including service as an instructor or adjunct prof at three universities, and because I have escaped America, I am able to escape this problem set which in my experience is unsolvable, because in my experience in the USA programmers are regarded as a lower form of life who are not entitled to have "professional" views in any enforceable sense.

But I have to say, Dan, that I am very, very offended by any phrasing which in any way implies that I am not "qualified" to do .Net programming because I won't change the view to one in which I don't dispose(). I am offended because you are asking me once again, as has been asked before, that I essentially live a real contradiction.

On the one hand, I am supposed to show up as a professional for a .Net job and do the best job possible helping to create large and critical systems which have to be correct first and then efficient.

On the other, I can't make a discovery or form an opinion at variance with the local practice of the team. Unfortunately, because of the depth of my experience, you can bet your sweet patootie this is what I'll do. I may be wrong and my practice may suck, but the past experience will be unavoidable, and I'll find it impossible to take a stupid pill (or drink from the waters of Nepenthe) in order to be a sunny corporate drone. I'll also find it a bad deal, financially, as every day, things like health insurance and affordable living space disappears.

I was listening the other day to some recent ragas composed and played by Ravi Shankar with his daughter Anoushka. What I like about Indian music is that it deconstructs the bound between song and speech, and its rythym is not externally imposed but imposed by the original direction of the Vedic hymn on which the raga was based.

The only thing worth doing is one in which you are this type of *pandit* who subordinates himself only to the demands of the work of art. If you cannot be a *pandit* then be a *guru* and teach. I may suck as a *guru*, of course, but I am at peace with myself.

I continue to believe that in a just and open society (such as the labor-friendly university in which I started programming) the first computing concern would be with truth (requirements are matched by the code over time and change) and only then with an "efficiency" which on the ground means "we don't have time for certain types of people...certain scheduled castes...certain transactions...and certain considerations".

This isn't computing. It's police work which uses the discourse of "efficiency" to make the ATM user, who has only 100.00 in his bank account, feel small and indeed unscheduled when the ATM informs him that 100 is not divisible by 20.

My recommendation for programmers who find themselves working in a frustrating corporate environment is very simple:

The problem is all inside your head
She said to me
The answer is easy if you
Take it logically
Iâ€™d like to help you in your struggle
To be free
There must be fifty ways
To leave your lover [employer]

She said itâ€™s really not my habit
To intrude
Furthermore, I hope my meaning
Wonâ€™t be lost or misconstrued
But Iâ€™ll repeat myself
At the risk of being crude
There must be fifty ways
To leave your lover [employer]
Fifty ways to leave your lover

CHORUS:
You just slip out the back, Jack
Make a new plan, Stan
You donâ€™t need to be coy, Roy
Just get yourself free
Hop on the bus, Gus
You donâ€™t need to discuss much
Just drop off the key, Lee
And get yourself free

She said it grieves me so
To see you in such pain
I wish there was something I could do
To make you smile again
I said I appreciate that
And would you please explain
About the fifty ways

She said why donâ€™t we both
Just sleep on it tonight
And I believe in the morning
Youâ€™ll begin to see the light
And then she kissed me
And I realized she probably was right
There must be fifty ways
To leave your lover (or the boss)
Fifty ways to leave your lover (or the boss)

CHORUS

I hope that this blog entry doesn't damage our long-distance friendship or get my ass fired from developer dot star. It's not as if I need the money but I like youse guys.

I Don't Have the Luxury of Full Independence from Technology

Daniel Read — Wed, 04 Jan 2006 09:12:57 -0800

However, I want my code to be fully independent of the technology (reference tracing, reference tracking, or Ouiji boards) used in the operating system, and I am willing to sacrifice micro "effiency" to do so.

As it appears you have yourself concluded, I think Windows .NET development is simply not for you. I'm not arguing that .NET and Windows as it is today represent the best possible situation, but this is the platform in use by the people who pay my salary, and the clients that purchase the services of our company to develop software for them that will add value to their business.

My point of view as a craftsperson and tradesperson for hire is that I am bound to do my best to work within the capabilities of the tools and platform in which I am being paid to work. I have to balance technical goals against the interests of my client and employer, both of whom are driven of course by business-oriented concerns. Discussions of an ideal system are interesting to me, but ultimately hypothetical. In your position, Edward, I say idealize away, but I suspect the road you are seeking is outside the Microsoft world, as you have yourself alluded to in your recent post about switching from .NET to C development. If I were myself working towards different ends in my daily technical work, I might join you.

Dan

Here I am havering about the "persistence of myth":

Edward G Nilges — Tue, 03 Jan 2006 23:13:04 -0800

but my own recommendation is a mythos too.

Oops. My only defense is that some myths are better than other myths and that myths that overdo "effiency" myth the point which is reliability before wrong answers at high speed.

Thanks for the interesting tech info

Edward G Nilges — Tue, 03 Jan 2006 23:08:09 -0800

but my concern is to program independent of the specific methods used in Framework. As it happens, I implement a dispose() in my book without using IDisposeable in some cases which from a standpoint of communication-of-intent is probably bad practice.

One of my primary purposes in dispose() is in fact to have the object inspect its final state for correctness. Other ceremonies can be conducted at dispose() time. For example, the object could log its termination in an appropriate place.

In my C praxis I can "see" that malloc and free must always balance and I am writing the utility to match malloc and free messages. I would think that having dispose in addition to constructors would allow one to add audit code to a system for a similar reckoning whose negative result would be an apriori indication that the system needs further work.

There's no need as far as I can see to set reference objects to null in dispose because when they go out of scope, the reference tracer (not the reference counter) knows they no longer exist. As David points out the algorithm used means that setting them to null is useless although IMO "inefficient" only in the *de minimis* sense of micro-efficiency which wastes a lot of programmer time.

However, even if a reference counter were used the "ideal" framework would not need application code to set anything to null, because it would know when the object goes out of scope.

[I suggest a style of coding that given the fact that Microsoft can change the Framework, reasons about a minimal, ideal Framework so as to stay within a margin of safety, in the way in which Chinese people living under Chinese law implement a margin of extra caution in their daily lives so as to stay out of trouble. This may offend computing libertarians, but I like working code.]

I'll be the first to admit it. I am being deliberately obtuse and refusing to "stay current" with the details of the implementation of the underlying system because it's been my experience that code written by a programmer who is TOO *au fait* and groovy-with-respect-to the operating system contains mental hooks to implementation details.

Furthermore, hard scope is important to reliability. An object should exist when it exists and should "leave not a rack behind" (through an explicit dispose()) when it dies.

This is even more important in multithread applications which in my experience require the object to clearly define when it is being-born and busy-dyin':

For he who is not busy bein' born is busy dyin'

- Bob Dylan, It's All Right Ma, I'm Only Bleeding

There needs to be bright lines in the form of object semaphores (available in crude form in .Net via Interlocked) at the moment of conception and the moment when the object startup is complete, and at the moment (signalled by dispose()) when death begins and when the object completes its last rattle and thrash.

But if the object does not implement my pro forma dispose() in version 1.0 then it becomes, when the time is ripe (die Zeit ist hier) to multithread, just harder to find the time at which to add the code. Whereas a dispose() can be wrapped in a synclock which prevents incoming requests from starting up.

Having seen the consequences over thirty years of smart people meditating on and committing to memory the MISTAKES made by OS developers, and as treating those mistakes as Holy Writ, I would rather ponder code that is truly efficient where you aren't efficient until it works.

Ponder the difference between a monstrous system with no clear dispose(), littered with objects on life support, and a decent and condign burial for each object at the end of its useful life. Aesthetic considerations, as Dijkstra knew, are often ethics and mathematics in a tutu and as such must be taken seriously.

However, I want my code to be fully independent of the technology (reference tracing, reference tracking, or Ouiji boards) used in the operating system, and I am willing to sacrifice micro "effiency" to do so.

I think it was a mistake to implement asynch garbage collection in this way which makes it possible for individual application programs to barf the system. But I don't know if I could have done better.

This is one of the reasons that I am leaving .Net development because it seems that in each commercial closed system I have encountered there are these "features" which offload the need for thought onto the users, who then are tasked with remedying the defects of the operating system.

Sour grapes? Perhaps. But we make fine wine from sour grapes, as well as swill.

And I appreciate Donna's kind remarks. They are probably undeserved since I have smoked a lot of computing equipment in my day (metaphorically) in addition to smoking other substances literally. But it seems to me that reliable and safe computing is more ecofriendly and results in fewer trips to the Gizmo Shop.

Sounds like your old man, Donna, is a man of parts (many parts, all in the garage). You shall be rewarded when those computing classics become valuable museum pieces. My many moves, sadly, have caused me to abandon old computers to their fate, but in recent years I have done so carefully.

For example, I was looking at manually humping all my worldly goods out of Red China last summer therefore I put a Presario in the trash, but I knew that it would be immediately useful, and five minutes after I put this orphan out, it had been spirited away. It was fully loaded with VB Enterprise and other goodies so it's probably serving the world struggle of the intelligentsia forces of the aroused proletariat against the running dogs of the Fascist capitalist imperialists.

Or, burning illegal DVDs.

Had I been in the USA, I would have given the damn thing to a church, a synagogue, a mosque, a Hindu *ashram*, a troop of Girl Scouts, or the Socialist Workers Party.

.NET Reference Tracing

Daniel Read — Tue, 03 Jan 2006 15:24:13 -0800

Garbage collection in .NET does not use reference counting per se; it uses what is called reference tracing, where the garbage collector determines in a real-time fashion whether there are any references to an object that can still be accessed from running code.

That is interesting information. Thanks.

Dan

To Dispose or Not to Dispose ?

Bijesh Karuvar — Fri, 19 Aug 2005 04:05:28 -0700

Dispose() is merely a convenient place for a class developer to place any resource clean-up code, in the hope that clients will call it. Dispose does not free the managed memory allocated for an object.