[quoted text, click to view]

I can't help but laugh at the irony of this (not at you). Unmanaged
languages like C/C++ have been scoffed at for years because of memory
issues. Now people can't even handle a system that takes care of memory for
them. It goes a long way to demonstrate the complexities of our field
(there's no free lunch).

Hellow

I'am not sure what to think about the Garbage Collector.

I have a Class OutlookObject, It have two private variables.
Private Microsoft.Office.Interop.Outlook.Application _Application = null;
Private Microsoft.Office.Interop.Outlook.NameSpace _Namespace = null;

The Constructor:
public OutlookObject()
{
_Application = new Microsoft.Office.Interop.Outlook.Application();
_Namespace = _Application.GetNameSpace("MAPI");
}
..... after this alot of members and properties

When i need to do something in outlook, I'll instanciate the OutlookObject
objOL = new OutlookObject();
And when i don't need Outlook anymore I'll use objOL = null;

In my head this should destroy the objOL and thereafter also the
_Application and _Namespace in the Garbage Collector, but it don't happens
all time.
So I'll found a way that should force the destruction, the use of finalizer,
so i put this into the OutlookObject() class:

~OutlookObject()
{
if ( _Application == null)
return;
else
{
_Application =null;
}
}

And I'll also tryed with the OutlookClass to dever from IDisposable class
and put in:
Public Dispose()
{
if ( _Application == null)
return;
else
{
_Application =null;
}
}

With both the same result - Outlook don't get destroyed before i'll close
the application.

The problem is that I'll use Outlook a lot of times within my application,
and with the Task Manager I'll some time see five or more Outlook instances
WHY?????
And if there is so many Outlook instances, they stay open event after I'll
close my application. WHY???


Kind regards

Johnny E. Jensen

"Peter Duniho" <NpOeStPeAdM@NnOwSlPiAnMk.com> schrieb im Newsbeitrag
news:13go42isos2ngfc@corp.supernews.com...
<snip>
[quoted text, click to view]

You should not call Dispose in the finalizer. When the finalizer runs, the
referenced object will also be eligible for collection resp. finalization,
and it's finalizer will run, maybe has allready run. But you should call
Dispose on the held objects in the Dispose method of the container.

Christof

This is also true for unmanaged clients using "automation" interfaces to
interact with Office Applications. A native COM client that fails to call
"Quit" (all office application support this method) will result in the
server (here Outlook.exe) to stay loaded in memory. As you correctly said,
learn the object model before you even start "automating" Office (or any
other DCOM server like) applications.

Willy.



[quoted text, click to view]

Hello

Thanks to all the replies.

Outlook don't have a Close() or Dispose(),but it has a Quit() method. But if
Outlook is running (the normal GUI Outlook) and if I use the Quit() method
this (GUI outlook) is closing - a bit anoing for the user.

As Nicholas mentioned to use the ReleaseComObject - this does the trick. So
my OutlookObject class has a Dispose() method and here I use the
ReleaseComObject(_Application) and ReleaseComObject(_Namespace) and it
works.

Kind regards

Johnny E. Jensen


"Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard.caspershouse.com> wrote in
message news:CE4C280C-A8D4-4687-AA62-BE63B9035DD0@microsoft.com...
[quoted text, click to view]

Do you mean you are connecting to a running instance?
Note that even without this ReleaseComObject calls, there should be NO new
instance of Outlook getting created.
What kind of application is this (Windows, Console, other)?

Willy.



[quoted text, click to view]

[quoted text, click to view]

That's just because you expect it to do something that it's not supposed
to do. ;)

[quoted text, click to view]

It doesn't. It only makes the object available for garbage collection.

Garbage collections happen at times that the garbage collector decides,
and not every time an object is available for garbage collection. Also,
when a garbage collection happens, that doesn't guarante that all
available objects are collected. The garbage collector can decide that
it's not efficient to collect some of the objects at that time.

[quoted text, click to view]

Actually, at the exact moment that the objOL can be garbage collected,
every object that it references (and isn't referenced somewhere else)
can also be garbage collected.

[quoted text, click to view]

A finalizer is not useful if you want to control when the objects are
released. An object that has a finalizer will be put in the freachable
queue instead of being collected. A background thread then runs the
finalizer methods in the objects one after one, but you have no control
over when this happens.

If it takes too long to go throught the freachable queue when the
application ends, the rest of the objects will just be discarded without
finalization, so it's not even guaranteed that the finalizer will ever run.

[quoted text, click to view]

Why checking? Setting the reference to null again doesn't do any harm.

[quoted text, click to view]

Why a return statement here? It's totally superflous as there is no more
code from this point to the end of the method.

[quoted text, click to view]

Did you actually call the Dispose method? It's not called automatically.

[quoted text, click to view]

--
Göran Andersson
_____

[quoted text, click to view]

Just a point of clarification for other people who might misread your
post -- calling Dispose from the finalizer is a common pattern and
it's perfectly ok to do. You just need to make sure that when you do
it, your Dispose method doesn't try to touch other managed objects
when called from the finalizer. As you point out, these other managed
objects might have already been cleaned up, so calling them will lead
to errors. The pattern I've seen most often is to have Dispose( ) and
the finalizer both call Dispose(bool disposing). When calling from
Dispose( ), pass disposing=true and call GC.SuppressFinalize(this).
When calling from the finalizer, disposing=false. Inside Dispose(bool
disposing), you should dispose other managed resources only if
disposing=true.

John

[quoted text, click to view]

This is simply human nature at work. People who master any complex skill
will generally feel superior to those who master a "lesser" skill (one
that's less complicated). They then convince themselves that the lesser
skill itself must also be inferior in some way. It's a fallacious argument
but most are guilty of it to some extent.

[quoted text, click to view]

As far as handling resources is concerned however, I think C++ has always
been unfairly maligned. Not only is it much less error-prone than people
believe (IMHO), the RAII paradigm itself is a cleaner design compared to a
GC system (again, IMHO). While it would be very difficult for anyone to
technically [dis]prove it (I certainly can't), I base it solely on my own
experience.

[quoted text, click to view]

I have the impression that you feel it's also a fallacious argument that
C/C++ is deserving of scorn and scoffing. Which is fine...I think
there's a lot of pointless scorning and scoffing going on in both
directions.

My point was simply that the scorn and scoffing isn't limited to the
C/C++ direction. It's also directed at garbage collection, and is just
as fallacious in that case as the case you mention.

[quoted text, click to view]

Well, my experience is the opposite. It is simply not possible to have
a memory leak in a garbage collection system. But memory leaks abound
in conventionally written C/C++ applications. I see it all the time.

There are ways to write code in a way that helps ensure against memory
leaks, but these aren't things that the language provide. They are
things that the developer must implement oneself (for example, code in
the debug build that actually tracks memory allocations and requires
idle-time consistency checks).

Now, does that mean that C++ is as error-prone as people believe? I
don't know. What do people believe? How do you measure that? But in
terms of C++ being more error-prone than a garbage collecting system
goes, I'd say that's easily observed and demonstrated.

IMHO the only real error likely to come up with respect to memory
management is, by definition, failing to manage memory correctly. That
is, either failing to allocate memory when you need it, or failing to
release it when you're done. The former is a trivial problem, easily
solved in any paradigm, while the latter simply doesn't exist in a
garbage collecting system.

So it's easily proven that, as long as one is looking only at those
kinds of errors, C/C++ is trivially more error-prone than a
garbage-collecting system.

Is the explicit allocation-and-release of C/C++ itself unwieldy and
excessively error-prone? No, I don't think so. I agree with you that
it's actually not hard to use, even while ensuring correct code. But it
is very unforgiving of carelessness, and unfortunately there are a lot
of programmers out there whose primary identifying characteristic is
carelessness.

I don't know how to evaluate "cleaner design" in this context. If
you're talking about the design of the memory manager, I'd have to agree
that a GC memory manager is more complicated, less "clean". On the
other hand, that only needs to be written once. I would definitely
disagree if you are trying to claim that the design of code written that
_uses_ the memory manager is "cleaner" in C/C++ than if using a GC
memory manager. What could be cleaner than not having to write the code
in the first place?

But really, the only thing I was pointing out is that just as you've
observed people scoffing at the C/C++ paradigm, I have observed people
scoffing at the garbage collection paradigm. It's not as one-sided as
your post seems to imply, and in fact (maybe as a result of the
environment in which I work) my experience has been that I see more
people criticizing the GC paradigm than the other way around.

[quoted text, click to view]

As John says, that's not true. I may not have been clear enough in my
own post, but you should call your own Dispose() in the finalizer to
ensure that unmanaged resources in your own object are released.

But really, the situation here isn't about the finalizer at all. As I
said, that's a backup plan for when things aren't coded right.

The non-finalizing scenario (indicated by the boolean passed in) in the
Dispose() method of the class should release managed and unmanaged
resources, and should call the appropriate method on the
Outlook.Application object (that is apparently the Quit() method, as
Peter Bromberg has pointed out) to release that object.

And the OP's code should call his own class's Dispose() method directly,
rather than relying on the finalizer.

I don't know whether the Outlook.Application finalizer also calls
Quit(), but if it doesn't, that would mean it's essentially an unmanaged
resource and your own (that is, the OP's) Dispose() method should call
Quit() even in the finalizing case.

[quoted text, click to view]

Well, for what it's worth, in a 3 hour presentation on application Tuning,
about 1/2 that time is spent on Memory Leaks, and how to track them down.

Just like in C/C++ land, they're due to a user misunderstanding how GC works
and making a silly mistake. For some reason, the people who most often seem
to get bitten are novice devs who discover they really like static
variables...

.... so I spend quite a bit of time using a Memory Profiler, and showing them
how to read it's output.

My favorite leaks invoke making my laptop (with 2GB of memory) generate an
OOM while only actually allocating a few hundred KB of memory. (I have a
very nasty pinning / fragementation demo that really drives home the
issue...)

--
Chris Mullins

[quoted text, click to view]

public class MyWebService
{
private static List<Byte[]> _myReceivedData;

private void DataFromAWebService(Byte[] rawData)
{
_myReceivedData.Add(rawData);
// Do operations
}
}

I see "innocent" code that looks like this all the time. The List, because
it's static, is never cleaned up.

People add data into it, and forget the list is static. They exepect that
when the class instance of MyWebService goes away, that the list of received
data will as well.

It's a really simple error, but I see it again and again and again...

--
Chris Mullins

[quoted text, click to view]

I guess that depends on your definition of "memory leak". Mine is such
that a garbage collection system specifically precludes them.

I understand how you might call your example of a static variable that
isn't released a "memory leak", but the memory hasn't become orphaned or
anything. The application simply failed to release it, and the same
kind of "leak" exists regardless of the type of memory management (ie it
would be just the same error for a CRT-based program to fail to release
that memory).

To me, a true "memory leak" is a situation in which the memory is gone
forever for that process. There's simply no way for any code anywhere
to ever recover it. Whether or not such code exists isn't relevant to
my use of the term. It's whether it _could_ exist.

At the very least, it seems to me that in your presentation you should
make clear the differing definitions of "memory leak".

[quoted text, click to view]

I certainly agree there. But one system is definitely more resilient to
programmer error.

[quoted text, click to view]

I think we've found ourselves in vehement agreement on that point
previously. I'm still in vehement agreement with you on it. :)

[quoted text, click to view]

Well, the thing is...once you no longer have a reference to a memory
resource, it _is_ released. Just because the GC hasn't run, that
doesn't mean the memory isn't available. It just means that the GC
hasn't gotten around to moving it into the collection of memory that is
_immediately_ available for use.

Logically speaking, the memory is still in fact available, the moment
you release your last reference to it.

[quoted text, click to view]

IMHO, it's a mistake to think of the "using" statement, the finalizer,
or IDisposable as related to a C++ destructor. It's only "ugly"
compared to it if you are treating them the same.

The "using" statement and IDisposable exist for one purpose: to
explicitly release resources held by an object without releasing the
object itself. Within that one purpose, there are two sub-categories of
types of resources that may be released: managed, and unmanaged.

Obviously the only reason the unmanaged category even exists is that
..NET runs on top of a system that is not entirely managed code. If all
of Windows was based on a garbage collection system, that category
wouldn't exist.

So, let's consider only the managed category. In this case, it's
beneficial to be able to tell an object "let go of the resources you're
holding" without releasing that object itself. But this is again not
comparable to a destructor, because the object itself still exists. It
hasn't been released or destroyed and it is theoretically possible that
it could be reused. This is much more comparable to a C++ class that
hasn't been deleted, and thus hasn't been destroyed, but which has some
sort of "release your resources" function that has been called.

[quoted text, click to view]

And in C# not having a reference to an object is nicely symmetrical to
creating a reference to an object. The latter initializes the object
and the former cleans it up. In a purely managed environment, releasing
a single reference to an object is exactly equivalent to the C++
paradigm of having to call a destructor where individual resources
within the object have to be explicitly cleaned up.

In fact, the garbage collection model is, at least for that particular
operation, much more efficient, because there's no need to go through
the entire object cleaning things up. Everything that object refers to
is automatically released, with a single nulling, or leaving scope, of
the last variable holding a reference to that object.

Overall, I suspect the efficiency is about the same. The extra work
that the C++ model has to do initially is balanced by the extra work the
garbage collector will have to do later.

[quoted text, click to view]

Likewise, using GC as soon as an object is no longer referenced, any
managed resources no longer exist. They are automatically released when
that object referencing them is.

[quoted text, click to view]

But why do you care when the GC is going to occur? It only happens when
it needs to, or when it gets the opportunity to, and there should be
nothing in your code that depends on or otherwise relies on when, if at
all, garbage collection happens.

In a multi-tasking operating system like Windows, there are a wide
variety of things that occur and which you have no control over. A
garbage collection system simply introduces a new instance to this
already very broad category of components.

[quoted text, click to view]

I don't understand that at all. A person who isn't used to releasing a
reference to an object when they are done with it isn't going to be used
to deleting a C++ object when they are done with. Conversely, a person
who can remember to delete a C++ object when they are done with it can
remember to release a reference to a .NET object when they're done with it.

[quoted text, click to view]

What kind of resource? If you're talking about a managed resource, then
simply releasing the reference to the referencing object is sufficient
to release the resource.

If you're talking about an unmanaged resource, well...that's not a
problem inherent with garbage collection. It's a natural consequence of
mixing a garbage collection system with a traditional alloc/free system.
That problem _only_ exists because of the traditional alloc/free
system; it hardly seems fair to blame it on the garbage collection paradigm.

[quoted text, click to view]

This one I understand even less. If a deep copy is required but a
shallow copy is done, this is if anything more dangerous in the C++
model, because the referenced data can be freed by any one copy of the
instance. This just won't happen in a garbage collection system.

With a GC system, you still have the potential issue of having multiple
instances refer to the same data, but this issue exists regardless of
the memory management model. It's an implementation problem, not a
memory management problem.

[quoted text, click to view]