A re-announce on GC's defects

[Andre]

Andre, this is the whole point of the discussion. I said that you can make

errors even using stack based semantics.

I won't deny this. The problem is you can even make *more* errors if you
can't use stack
based semantics. Perhaps depends on the developer background - a Delphi
programmer
won't miss anything ;-)

should call Delete on it, when the disposable object is declared at
function scope, destruction is done automatically when leaving the
function scope.
And this is where the discussion started, a user of class B should not
need to know the internals of D (Resource class member can be declared
private in D), and as D doesn't

I agree, that's the point of the whole discussion. C# "using" can be
compared to stack
based semantics. And I think it to be a very good solution.
But if I embedd objects I can't use such a style or some kind of "using".
It's no big deal, though I have to write:

class MyObject
{
Embedded embedded:
void Dispose() { embedded.Dispose(); }
}

While in C++ / CLI it's sufficient to write:

ref class MyObject
{
Embedded embedded:
}

To ensure that embedded is Disposed, if MyObject is disposed too.

But as I already wrote, this style doesn't fit into C# syntax, so it's
perhaps better
to leave it as it is. Though for a C++ programmer it's not that convenient
as it is
for example for a Delphi programmer or a C programmer.

[...]
ref class Second
{
public: Embedded s; // stack allocated semantics
}

this because it holds a "stack allocated semantic" object reference. And
this is IMO the source of a lot of confusion and errors and in no way
better than C# and VB.NET "using" idiom.

Depends. Think of Embedded to be implemented in an external library. If in a
new version of the
library a resource will be added to Embedded (e.g. because it now holds a
file stream)- Dispose
must (should) be called. And all code using Embedded, should be changed.

In native languages it was natural that every object has to be deleted (due
to the allocated memory),
while in .NET I feel somewhat lost, meaning that I always tend to ignore if
I have to call Dispose or not.

Perhaps it's just another style I have to get used to (which will need some
time ;-) ).

Willy.

By the way. Since the sub-thread with the subject "C++/CLI is the way to go"
has been
made a "new thread", it seem that some newsreaders don't see posts of this
thread anymore.
Only if I completely delete the cache. For example Thunderbird is affected.
I don't see this thread in this newsreader anymore.

Andre

 

[Willy Denoyette [MVP]]

Andre, this is the whole point of the discussion. I said that you can make errors even
using stack based semantics.

I won't deny this. The problem is you can even make *more* errors if you can't use stack
based semantics. Perhaps depends on the developer background - a Delphi programmer
won't miss anything ;-)

should call Delete on it, when the disposable object is declared at function scope,
destruction is done automatically when leaving the function scope.
And this is where the discussion started, a user of class B should not need to know the
internals of D (Resource class member can be declared private in D), and as D doesn't

I agree, that's the point of the whole discussion. C# "using" can be compared to stack
based semantics. And I think it to be a very good solution.
But if I embedd objects I can't use such a style or some kind of "using".
It's no big deal, though I have to write:

class MyObject
{
Embedded embedded:
void Dispose() { embedded.Dispose(); }
}

While in C++ / CLI it's sufficient to write:

ref class MyObject
{
Embedded embedded:
}

To ensure that embedded is Disposed, if MyObject is disposed too.

But as I already wrote, this style doesn't fit into C# syntax, so it's perhaps better
to leave it as it is. Though for a C++ programmer it's not that convenient as it is
for example for a Delphi programmer or a C programmer.

[...]
ref class Second
{
public: Embedded s; // stack allocated semantics
}

this because it holds a "stack allocated semantic" object reference. And this is IMO the
source of a lot of confusion and errors and in no way better than C# and VB.NET "using"
idiom.

Depends. Think of Embedded to be implemented in an external library. If in a new version
of the
library a resource will be added to Embedded (e.g. because it now holds a file stream)-
Dispose
must (should) be called. And all code using Embedded, should be changed.

In native languages it was natural that every object has to be deleted (due to the
allocated memory),
while in .NET I feel somewhat lost, meaning that I always tend to ignore if I have to call
Dispose or not.

Perhaps it's just another style I have to get used to (which will need some time ;-) ).

Willy.

By the way. Since the sub-thread with the subject "C++/CLI is the way to go" has been
made a "new thread", it seem that some newsreaders don't see posts of this thread anymore.
Only if I completely delete the cache. For example Thunderbird is affected.
I don't see this thread in this newsreader anymore.

Andre

Well I think we can better close this thread. Only remark , in order to implement the
disposable pattern 'correctly' (whatever that means) is to provide a finalizer when the
embedded resource does not itself provide one.
So in your sample, your Second class should look like this:

ref class Second
{
private:
int i;
Embedded s;
!Second(){s.~Embedded();}
.....
.....
};
Here the Finalizer (!Second()) act as kind of a safety net - users will often forget to
write code which guarantees executing explicit dispose logic...

Willy.

 

[Andre]

Well I think we can better close this thread. Only remark ,

Yes, agreed.

in order to implement the disposable pattern 'correctly' (whatever that
means) is to provide a finalizer when the embedded resource does not
itself provide one.
So in your sample, your Second class should look like this:

ref class Second
{
private:
int i;
Embedded s;
!Second(){s.~Embedded();}
....
....
};
Here the Finalizer (!Second()) act as kind of a safety net - users will
often forget to write code which guarantees executing explicit dispose
logic...

Willy.

Thanks for the hint.

Andre