IDisposable, using(), RAII and structs [Discussion]

[codymanix]

Last night I had several thought about RAII and want to discuss a bit.

Why doesn't CSharp support destructors in structs? Wouldn't that make RAII
possible like in C++? When the struct goes out of scope, the dtor could be
immediately be called (no GC needed).

For that, you don't have to declare the whole File class as a struct (which
would be not good for performance when File has a lot of data-members).
Instead creating a thin wrapper would be a good solution:

public struct MyFile
{
File f;
public MyFile(string p) { f=new File(p); }
~MyFile() { f.Close(); }
}

That would do it.

I have a second though which got through my mind. What about introducing an
interface which is recognized by the compiler and forces usage of the
using() statement.

public interface IDisposableForce : IDisposable{}

A second possibility could be declaring an attribute which marks
IDisposable-implementing-classes wheather using() should be mandatory or at
least suggested.

enum WarnLevel {NoWarn,WarnLvl1,WarnLvl2,WarnLvl3,WarnLvl4,GenerateError};

class UsingAttribute{UsingAttribute(WarnLevel w){}}

[Using(WarnLvl3)] // that means if warnlevel 3 or higher is set a warning
is issued when this class is used without using()-statement
public class MyFile : File
{
public class MyFile(string p) :base(p){}
}

What do you think?

 

[Michael Giagnocavo [MVP]]

For that, you don't have to declare the whole File class as a struct
(which

would be not good for performance when File has a lot of data-members).
Instead creating a thin wrapper would be a good solution:

public struct MyFile
{
File f;
public MyFile(string p) { f=new File(p); }
~MyFile() { f.Close(); }
}

Or you can just call f.Close(); yourself. Don't see the benefit here.

I have a second though which got through my mind. What about introducing an
interface which is recognized by the compiler and forces usage of the
using() statement.

public interface IDisposableForce : IDisposable{}

A second possibility could be declaring an attribute which marks
IDisposable-implementing-classes wheather using() should be mandatory or at
least suggested.

using() is a C#-specific thing. It's just a try/finally and a call to
dispose at the end. using() just saves a few lines of code, that's all.
Nothing magical.

enum WarnLevel {NoWarn,WarnLvl1,WarnLvl2,WarnLvl3,WarnLvl4,GenerateError};

class UsingAttribute{UsingAttribute(WarnLevel w){}}

[Using(WarnLvl3)] // that means if warnlevel 3 or higher is set a warning
is issued when this class is used without using()-statement
public class MyFile : File
{
public class MyFile(string p) :base(p){}
}

Any class that implements IDisposable should have it's Dispose method
(sometimes named Close) called. Simple as that. It's not too hard (check
to see if there's IDisposable, and if so, dispose it!).

-mike
MVP

 

[Ted Miller]

I was just talking about something similar last week. What came out of it is
the notion of a helper class that can help detect cases where a user forgot
to Dispose/Close an object whose class implements IDisposable. The idea is
cause exceptions, throw up message boxes, or at least log these things, to
force people into proper coding form. I am putting this into practice in my
stuff.

It's not quite the same as constructs that are an explicit part of the
CLR/CTS or a particular language such as what you are suggesting, but IMO
it's a reasonable substitute in the absence of thsoe things. (Though for the
record I agree with another poster about the dubious nature of an
IDisposableForce. I originally suggested that perhaps the system could
invoke an operator on a class whenever a reference is added or released,
which could allow classes to automatically perform their own disposal.)

 

[Gerhard Menzl]

Or you can just call f.Close(); yourself. Don't see the benefit here.

The benefit of and the idea behind RAII (resource acquisition is
initialization) is that it causes the cleanup code to be called
automatically upon exit, even when an exception is thrown earlier in the
function.

In my opinion, the absence of deterministic destruction, and hence the
impossibility of RAII, is something that Java and C# got totally wrong.

Gerhard Menzl

 

[Eric Newton]

This is probably a good idea, perhaps a base class in the framework
"BaseRAII" that is either recognized by the compiler as a special class
[like the Debug class in System.Diagnostics] or decorated with attributes to
warn of improper use.

In my mind the destructor of these BaseRAII classes should always be called
to release the resource immediately.

--
Eric Newton
C#/ASP Application Developer
http://ensoft-software.com/
(e-mail address removed)-software.com [remove the first "CC."]

I was just talking about something similar last week. What came out of it is
the notion of a helper class that can help detect cases where a user forgot
to Dispose/Close an object whose class implements IDisposable. The idea is
cause exceptions, throw up message boxes, or at least log these things, to
force people into proper coding form. I am putting this into practice in my
stuff.

It's not quite the same as constructs that are an explicit part of the
CLR/CTS or a particular language such as what you are suggesting, but IMO
it's a reasonable substitute in the absence of thsoe things. (Though for the
record I agree with another poster about the dubious nature of an
IDisposableForce. I originally suggested that perhaps the system could
invoke an operator on a class whenever a reference is added or released,
which could allow classes to automatically perform their own disposal.)

Last night I had several thought about RAII and want to discuss a bit.

Why doesn't CSharp support destructors in structs? Wouldn't that make RAII
possible like in C++? When the struct goes out of scope, the dtor could be
immediately be called (no GC needed).

For that, you don't have to declare the whole File class as a struct (which
would be not good for performance when File has a lot of data-members).
Instead creating a thin wrapper would be a good solution:

public struct MyFile
{
File f;
public MyFile(string p) { f=new File(p); }
~MyFile() { f.Close(); }
}

That would do it.

I have a second though which got through my mind. What about introducing an
interface which is recognized by the compiler and forces usage of the
using() statement.

public interface IDisposableForce : IDisposable{}

A second possibility could be declaring an attribute which marks
IDisposable-implementing-classes wheather using() should be mandatory or at
least suggested.

enum WarnLevel {NoWarn,WarnLvl1,WarnLvl2,WarnLvl3,WarnLvl4,GenerateError};

class UsingAttribute{UsingAttribute(WarnLevel w){}}

[Using(WarnLvl3)] // that means if warnlevel 3 or higher is set a warning
is issued when this class is used without using()-statement
public class MyFile : File
{
public class MyFile(string p) :base(p){}
}

What do you think?

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

 

[Joe \Nuke Me Xemu\ Foster]

Last night I had several thought about RAII and want to discuss a bit.

Why doesn't CSharp support destructors in structs? Wouldn't that make RAII
possible like in C++? When the struct goes out of scope, the dtor could be
immediately be called (no GC needed).

For that, you don't have to declare the whole File class as a struct (which
would be not good for performance when File has a lot of data-members).
Instead creating a thin wrapper would be a good solution:

public struct MyFile
{
File f;
public MyFile(string p) { f=new File(p); }
~MyFile() { f.Close(); }
}

That would do it.

This would be tantamount to admitting that castrating Visual Basic
was a mistake and, therefore, must be considered unnecessary and
"looking backwards" instead of Looking Towards The Future. You
might as well argue for the reintroduction of reference counting!

I have a second though which got through my mind. What about introducing an
interface which is recognized by the compiler and forces usage of the
using() statement.

public interface IDisposableForce : IDisposable{}

A second possibility could be declaring an attribute which marks
IDisposable-implementing-classes wheather using() should be mandatory or at
least suggested.

enum WarnLevel {NoWarn,WarnLvl1,WarnLvl2,WarnLvl3,WarnLvl4,GenerateError};

class UsingAttribute{UsingAttribute(WarnLevel w){}}

[Using(WarnLvl3)] // that means if warnlevel 3 or higher is set a warning
is issued when this class is used without using()-statement
public class MyFile : File
{
public class MyFile(string p) :base(p){}
}

What do you think?

If you want real destructors, use C++ or Visual FoxPro. Get over it!
Anyway, what happens when (not if) existing classes are changed to
implement IDisposableForce in addition to or instead of IDisposable?
Do you force everyone to go back and rewrite their code? Oh wait, this
has already been done to Visual Basic, so it must be OK. Never mind...

 

[Ted Miller]

This would be tantamount to admitting that castrating Visual Basic
was a mistake and, therefore, must be considered unnecessary and
"looking backwards" instead of Looking Towards The Future. You
might as well argue for the reintroduction of reference counting!

Actually, I sorta do argue for the reintroduction of refcounting -- but not
for lifetime control. I think there should be a 'reference' operator,
because (I believe) the system (compiler and runtime) know when references
are added and removed from an object; this would allow an object to use a
sort of refcounting scheme to implement auto destruction.

If you want real destructors, use C++ or Visual FoxPro. Get over it!

If you want to target the CLR (i.e., if you want to program for .Net), this
is not possible. (Managed C++ destructors have similar semantics to C#
destructors.)

Anyway, what happens when (not if) existing classes are changed to
implement IDisposableForce in addition to or instead of IDisposable?
Do you force everyone to go back and rewrite their code? Oh wait, this
has already been done to Visual Basic, so it must be OK. Never mind...

This isn't so sifferent from the notion of breaking binary compatibility
that existed in earlier versions of VB. There's an interface contract, and
changing it requires changes to consumers of the class, just as it always
has.

 

[cody]

Actually, I sorta do argue for the reintroduction of refcounting -- but
not

for lifetime control. I think there should be a 'reference' operator,
because (I believe) the system (compiler and runtime) know when references
are added and removed from an object; this would allow an object to use a
sort of refcounting scheme to implement auto destruction.

The compiler knows it when references are added or released. Reference
counting would be fine for some classes that:
- Does not contain References of reference-counted types (to avoid situation
where objects references each other but nowbody can reach them)
- That aren't copied and passed much (Sorting an array of reference counted
objects would be very slow since each swap involves lots of decrementing
and incrementing the reference count)

If structs would be allowed to have dtors, reference counting could simply
be implemented by developers.

 

[Michael Giagnocavo [MVP]]

I was just talking about something similar last week. What came out of it
is

the notion of a helper class that can help detect cases where a user forgot
to Dispose/Close an object whose class implements IDisposable. The idea is
cause exceptions, throw up message boxes, or at least log these things, to
force people into proper coding form. I am putting this into practice in my
stuff.

The compilers should generate a warning when they see an IDisposable that is
not disposed (a local or a non-public field). As far as forcing people into
proper coding form, I'd take whatever approach is normally taken when people
write poor code.

-mike
MVP

Last night I had several thought about RAII and want to discuss a bit.

Why doesn't CSharp support destructors in structs? Wouldn't that make RAII
possible like in C++? When the struct goes out of scope, the dtor could be
immediately be called (no GC needed).

For that, you don't have to declare the whole File class as a struct (which
would be not good for performance when File has a lot of data-members).
Instead creating a thin wrapper would be a good solution:

public struct MyFile
{
File f;
public MyFile(string p) { f=new File(p); }
~MyFile() { f.Close(); }
}

That would do it.

I have a second though which got through my mind. What about introducing an
interface which is recognized by the compiler and forces usage of the
using() statement.

public interface IDisposableForce : IDisposable{}

A second possibility could be declaring an attribute which marks
IDisposable-implementing-classes wheather using() should be mandatory or at
least suggested.

enum WarnLevel {NoWarn,WarnLvl1,WarnLvl2,WarnLvl3,WarnLvl4,GenerateError};

class UsingAttribute{UsingAttribute(WarnLevel w){}}

[Using(WarnLvl3)] // that means if warnlevel 3 or higher is set a warning
is issued when this class is used without using()-statement
public class MyFile : File
{
public class MyFile(string p) :base(p){}
}

What do you think?

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

 

[Eric Newton]

Thats a more difficult subject, you may be returning the IDisposable class
to another method that is disposing it properly... in that case the compiler
would have to get very sophisticated to detect that situation I think...

and what if the calling method isnt even in the same project?

I'm not sure if there's a good answer here except for a new Base Object
class built into the framework that DOES have reference counting built in...
unfortunately once you build two of them and point them at each other you've
got a classic COM style memory leak.

--
Eric Newton
C#/ASP Application Developer
http://ensoft-software.com/
(e-mail address removed)-software.com [remove the first "CC."]

I was just talking about something similar last week. What came out of

it

is
the notion of a helper class that can help detect cases where a user forgot
to Dispose/Close an object whose class implements IDisposable. The idea is
cause exceptions, throw up message boxes, or at least log these things, to
force people into proper coding form. I am putting this into practice in my
stuff.

The compilers should generate a warning when they see an IDisposable that is
not disposed (a local or a non-public field). As far as forcing people into
proper coding form, I'd take whatever approach is normally taken when people
write poor code.

-mike
MVP
could

be

immediately be called (no GC needed).

For that, you don't have to declare the whole File class as a struct (which
would be not good for performance when File has a lot of data-members).
Instead creating a thin wrapper would be a good solution:

public struct MyFile
{
File f;
public MyFile(string p) { f=new File(p); }
~MyFile() { f.Close(); }
}

That would do it.

I have a second though which got through my mind. What about

introducing
an

interface which is recognized by the compiler and forces usage of the
using() statement.

public interface IDisposableForce : IDisposable{}

A second possibility could be declaring an attribute which marks
IDisposable-implementing-classes wheather using() should be mandatory

or
at

least suggested.

enum WarnLevel {NoWarn,WarnLvl1,WarnLvl2,WarnLvl3,WarnLvl4,GenerateError};

class UsingAttribute{UsingAttribute(WarnLevel w){}}

[Using(WarnLvl3)] // that means if warnlevel 3 or higher is set a warning
is issued when this class is used without using()-statement
public class MyFile : File
{
public class MyFile(string p) :base(p){}
}

What do you think?

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

 

[cody]

Thats a more difficult subject, you may be returning the IDisposable class

to another method that is disposing it properly... in that case the compiler
would have to get very sophisticated to detect that situation I think...

and what if the calling method isnt even in the same project?

I'm not sure if there's a good answer here except for a new Base Object
class built into the framework that DOES have reference counting built in...
unfortunately once you build two of them and point them at each other you've
got a classic COM style memory leak.

Yes I see, IDisposable is a crappy and unsafe pattern for disposing things.
So the question still is:
Why doesn't c# structs dtors? That would allow reference counting techniques
for special things like files or connections. The classical problem with
objects referencing each other will not occur because not file, bitmap,
handle, connection contains each other since that are special classes.

--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu
[noncommercial and no ****ing ads]

 

[Ted Miller]

Also, nothing says that the refcounting can or should be used for lifetime
control. It would, however, potentially allow me to perform my own automatic
disposal. Whether or not the objects were actually garbage collected is of
much less importance than whether the (unmanaged) resources they control
have been disposed in a timely fashion.

Thats a more difficult subject, you may be returning the IDisposable class
to another method that is disposing it properly... in that case the compiler
would have to get very sophisticated to detect that situation I think...

and what if the calling method isnt even in the same project?

I'm not sure if there's a good answer here except for a new Base Object
class built into the framework that DOES have reference counting built in...
unfortunately once you build two of them and point them at each other you've
got a classic COM style memory leak.

Yes I see, IDisposable is a crappy and unsafe pattern for disposing things.
So the question still is:
Why doesn't c# structs dtors? That would allow reference counting techniques
for special things like files or connections. The classical problem with
objects referencing each other will not occur because not file, bitmap,
handle, connection contains each other since that are special classes.

--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu
[noncommercial and no ****ing ads]

 

[Andreas Huber]

Cody,

Yes I see, IDisposable is a crappy and unsafe pattern for disposing things.
So the question still is:
Why doesn't c# structs dtors?

Because this only works properly as long as you don't put a struct
object on the heap (via boxing). In contrast to stack objects heap
objects have non-deterministic finalization what inevitably also makes
RAII non-deterministic, which is a contradiction. In a GCed language
deterministic RAII can only work when there is a guarantee that
certain objects can only be allocated on the stack. Thinking about
that, you pretty soon find out that you'd end up with a .NET framework
having many more classes than it has today, as anything requiring
clean-up would exist in a struct and a class version. When you need
deterministic clean-up you go for the struct version, otherwise you go
for the class.
IMO, the using keyword is the best solution possible, as it does more
or less the same as a stack-only struct but without the need provide
two versions.

You'll find a much longer version of the above here:
http://discuss.develop.com/archives/wa.exe?A2=ind0010A&L=DOTNET&P=R28572

That would allow reference counting techniques
for special things like files or connections. The classical problem with
objects referencing each other will not occur because not file, bitmap,
handle, connection contains each other since that are special classes.

GC was introduced to solve the circular reference problem. If .NET
supported a special type of class that is reference-counted then there
would be no way to keep people from introducing cycles.

BTW, reference counting is still useful for pooling & sharing things
(see e.g. Regex).

Regards,

Andreas

 

[cody]

Yes I see, IDisposable is a crappy and unsafe pattern for disposing
things.

Because this only works properly as long as you don't put a struct
object on the heap (via boxing). In contrast to stack objects heap
objects have non-deterministic finalization what inevitably also makes
RAII non-deterministic, which is a contradiction. In a GCed language
deterministic RAII can only work when there is a guarantee that
certain objects can only be allocated on the stack.

Yes, when you box the struct you will lose this ability. Do it will be a
good idea that these "special refcounted structs" do not support implicit
boxing, you must explicitly cast them to (object) when you need to box them.

Thinking about
that, you pretty soon find out that you'd end up with a .NET framework
having many more classes than it has today, as anything requiring
clean-up would exist in a struct and a class version. When you need
deterministic clean-up you go for the struct version, otherwise you go
for the class.

Yes there will, but maybe the struct versions could be genereated implicitly
by the compiler. Maybe you don't need 2 types. One could introduce a new
"type" besides class and struct, maybe "nativeresourcewrapper", which is
just like a normal class but with reference counting. there must be one
restriction: these types cannot contain another object of type
"nativeresourcewrapper".

IMO, the using keyword is the best solution possible, as it does more
or less the same as a stack-only struct but without the need provide
two versions.

You'll find a much longer version of the above here:
http://discuss.develop.com/archives/wa.exe?A2=ind0010A&L=DOTNET&P=R28572


GC was introduced to solve the circular reference problem. If .NET
supported a special type of class that is reference-counted then there
would be no way to keep people from introducing cycles.

There would be no problem: the mark&sweep GC can easily detect such lost
objects. using refcounting & mark/sweep together can be a poweful feature
IMO.

What about a class-attribute that enables reference counting for a certain
class which implements dispsable? When the refcount==0 Dispose() is
automatically called.

[ReferenceCounted(true)]
class File : IDisposable
{
// stuff
}

BTW, reference counting is still useful for pooling & sharing things
(see e.g. Regex).

agreed!

 

[Eric Newton]

You're exactly right on several points, cody.

Sometimes reference counting IS a good thing, and I believe that instead of
the IDisposable pattern being the catch all (and henceforth ungauranteed
because of .Net newbies not realizing that say, a SqlConnection really needs
to be "Close"d or "Dispose"d before it goes out of scope) that a special
type that the compiler can look at and disallow the type to reference OTHER
reference counted types (and prevent the memory leak of two ref-counted
objects pointing at each other)

that would be cool to have the compilers enforce this...


--
Eric Newton
(e-mail address removed) (Remove the CC)
www.ensoft-software.com
C#/ASP.net Solutions developer

Because this only works properly as long as you don't put a struct
object on the heap (via boxing). In contrast to stack objects heap
objects have non-deterministic finalization what inevitably also makes
RAII non-deterministic, which is a contradiction. In a GCed language
deterministic RAII can only work when there is a guarantee that
certain objects can only be allocated on the stack.

Yes, when you box the struct you will lose this ability. Do it will be a
good idea that these "special refcounted structs" do not support implicit
boxing, you must explicitly cast them to (object) when you need to box them.

Thinking about
that, you pretty soon find out that you'd end up with a .NET framework
having many more classes than it has today, as anything requiring
clean-up would exist in a struct and a class version. When you need
deterministic clean-up you go for the struct version, otherwise you go
for the class.

Yes there will, but maybe the struct versions could be genereated implicitly
by the compiler. Maybe you don't need 2 types. One could introduce a new
"type" besides class and struct, maybe "nativeresourcewrapper", which is
just like a normal class but with reference counting. there must be one
restriction: these types cannot contain another object of type
"nativeresourcewrapper".

IMO, the using keyword is the best solution possible, as it does more
or less the same as a stack-only struct but without the need provide
two versions.

You'll find a much longer version of the above here:
http://discuss.develop.com/archives/wa.exe?A2=ind0010A&L=DOTNET&P=R28572


GC was introduced to solve the circular reference problem. If .NET
supported a special type of class that is reference-counted then there
would be no way to keep people from introducing cycles.

There would be no problem: the mark&sweep GC can easily detect such lost
objects. using refcounting & mark/sweep together can be a poweful feature
IMO.

What about a class-attribute that enables reference counting for a certain
class which implements dispsable? When the refcount==0 Dispose() is
automatically called.

[ReferenceCounted(true)]
class File : IDisposable
{
// stuff
}

BTW, reference counting is still useful for pooling & sharing things
(see e.g. Regex).

agreed!

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

 

[Andreas Huber]

cody,

[snip]

Yes, when you box the struct you will lose this ability. Do it will be a
good idea that these "special refcounted structs" do not support implicit
boxing, you must explicitly cast them to (object) when you need to box them.

Even an explicit cast does not remove the contradiction. It still
means that a type requiring deterministic cleanup is subjected to
non-deterministic cleanup. That is not normally a good idea and would
more often than not lead to subtle errors, IMO.

[snip]

There would be no problem: the mark&sweep GC can easily detect such lost
objects. using refcounting & mark/sweep together can be a poweful feature
IMO.

I don't think so. The initial rationale for introducing
RAII/refcounting in .NET was that it would help to implement classes
that need deterministic clean-up, right? If you let GC clean up the
cycles then those objects are finalized non-determinisitically what
defeats the original purpose.
I think deterministic clean-up via RAII/refcouting and
non-deterministic clean-up via GC are two very different beasts. IMO,
there is no way to mix the two without running into contradictions.

Therefore, for some situations manual cleanup through
IDisposable/using() is pretty much inevitable.

Regards,

Andreas

 

[cody]

Because this only works properly as long as you don't put a struct

them.

Even an explicit cast does not remove the contradiction. It still
means that a type requiring deterministic cleanup is subjected to
non-deterministic cleanup. That is not normally a good idea and would
more often than not lead to subtle errors, IMO.

This is no error but just a performanceproblem. Forcing the programmer to
use explicit cast is good to prevent unintentionally boxings. Maybe one
could go so far to forbid boxing with refcounted objects.

I don't think so. The initial rationale for introducing
RAII/refcounting in .NET was that it would help to implement classes
that need deterministic clean-up, right? If you let GC clean up the
cycles then those objects are finalized non-determinisitically what
defeats the original purpose.
I think deterministic clean-up via RAII/refcouting and
non-deterministic clean-up via GC are two very different beasts. IMO,
there is no way to mix the two without running into contradictions.

Where is the problem? These Disposable classes use referencecounting for
deterministic GC. The mark&sweep GC is just as a failsafe just for the case
when refcounting fails for some reason, to prevent memory leaks.

Therefore, for some situations manual cleanup through
IDisposable/using() is pretty much inevitable.

It is still unsafe and crappy. It is not very funny to note that you can
write programs in C++ more safe than in C#.
Wasn't that C# was invented for? Safety? No more memory leaks? Mission
failed.

--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu
[noncommercial and no ****ing ads]

 

[Valery Pryamikov]

GC is a truly good demonstration that there is no silver bullet technology
;-).

GC supposed to make our life easier, but did it?

Timely manual disposition of unmanaged resources isn't ultimate resource
management task that multithreaded application (like ASP.NET) should really
care about.

There is another rarely discussed, but also important task- multithreaded
application must care about setting to null all unused managed resources
ASAP especially before any operation that may block the thread.

Otherwise these managed resources may end up in generation 2 objects and
after some time require really expensive complete GC making the process
using 30%-50% time in garbage collector instead of real processing. Check:
http://weblogs.asp.net/ricom/posts/41281.aspx for excellent discussion of
why managed ASP.NET code should looks like:



MyManagedClass mc = new MyManagedClass();

//use mc here

//.

mc= null; //set mc to null immediately after last usage of mc

....



-Valery.

 

[Andreas Huber]

Eric,

Sometimes reference counting IS a good thing, and I believe that instead of
the IDisposable pattern being the catch all (and henceforth ungauranteed
because of .Net newbies not realizing that say, a SqlConnection really needs
to be "Close"d or "Dispose"d before it goes out of scope) that a special
type that the compiler can look at and disallow the type to reference OTHER
reference counted types (and prevent the memory leak of two ref-counted
objects pointing at each other)

The following questions come to mind:
- Could a refcounted (RCed) object hold references to GCed objects?
- Could a GCed object hold references to RCed objects?

Regards,

Andreas

 

[Andreas Huber]

Cody,

This is no error but just a performanceproblem. Forcing the programmer to
use explicit cast is good to prevent unintentionally boxings. Maybe one
could go so far to forbid boxing with refcounted objects.


Where is the problem? These Disposable classes use referencecounting for
deterministic GC. The mark&sweep GC is just as a failsafe just for the case
when refcounting fails for some reason, to prevent memory leaks.

What is your rationale for introducing reference counting then? More
specifically: Why is reference-counted *memory* management better than
garbage collection?

In the title of this thread IDisposable & using are mentioned. You
don't need those for *memory* management!

It is still unsafe and crappy.

You're not alone with that thinking (I once had similar concerns).
Many people have tried to come up with a better solution but to my
knowledge none has ever come up with something substantial. Have you
followed the link I posted? The guy that worte that article is an MS
person involved in the design of .NET. He explains how he also once
was a strong proponent of refcounting but became more and more
convinced that a GC-only strategy is better the more he explored the
exact semantics of a twin (GC and refcounting) solution.

Moreover, isn't it interesting that all other GCed languages (Java,
Python, etc.) work just like .NET does? There is always something
similar to the .NET dispose pattern. Scores of very smart people have
designed those languages and it speaks volumes that they haven't come
up with a better solution either.

BTW, to my knowledge, none of the other GCed languages supports
something similar to using.

It is not very funny to note that you can
write programs in C++ more safe than in C#.
Wasn't that C# was invented for? Safety? No more memory leaks? Mission
failed.

You cannot produce what is classically known as a *memory* leak in a
garbage collected language. This because of the very definition of how
a garbage collector works.
If you believe you can, please post a program that does produce
*memory* leaks.

Regards,

Andreas