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 IDisposableForc e : 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,WarnLvl 1,WarnLvl2,Warn Lvl3,WarnLvl4,G enerateError};

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

[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 IDisposableForc e : 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,WarnLvl 1,WarnLvl2,Warn Lvl3,WarnLvl4,G enerateError};

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
IDisposableForc e. 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.)

"codymanix" <do************ *********@gmx.d e> wrote in message
news:eu******** ******@TK2MSFTN GP09.phx.gbl...

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 IDisposableForc e : 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,WarnLvl 1,WarnLvl2,Warn Lvl3,WarnLvl4,G enerateError};

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

[Gerhard Menzl]

Michael Giagnocavo [MVP] wrote:

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.

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
--
Replace "spambucket " with "kapsch" to reply

[Sami Vaaraniemi]

"Michael Giagnocavo [MVP]" <mg*******@Atre vido.net> wrote in message
news:%2******** **********@TK2M SFTNGP11.phx.gb l...

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.

Err... well, that's the whole point of RAII: you don't have to call
f.Close() yourself. The benefit is that when you don't have to call
f.Close() explicitely there is less room for you to make an error.

RAII is the single biggest thing I miss from C++ since I started working
with C#. It is scary to see all the sample code that uses unmanaged
resources sloppily. All these samples will end up creating armies of
programmers who deal sloppily with unmanaged resources, and these
programmers will create waves of applications that work unreliably.

A very typical code sample, from an ASP.NET application, is this:

private void BindData()
{
// Connect to the Database
SqlConnection myConnection = new SqlConnection(c onnection string);

// Retrieve the SQL query results and bind it to the Repeater
string SQL_QUERY = "SELECT ProductName, UnitPrice, UnitsInStock " +
"FROM Products";
SqlCommand myCommand = new SqlCommand(SQL_ QUERY, myConnection);

myConnection.Op en();
dgProducts.Data Source = myCommand.Execu teReader();
dgProducts.Data Bind();
myConnection.Cl ose();
}

What's wrong with this code? The problem is that if myCommand.Execu teReader
fails because e.g., a temporary network problem or any other reason and
throws an exception, then the connection will not be closed and it won't be
returned to the connection pool in a timely manner. Code like this will
result in a web app that will work unreliably under load and might start
failing when conditions are not ideal.

To make the code above robust, you'll want to wrap the usage of the
SqlConnection into a using-statement, which is the best we can do without
real RAII. I feel sorry for VB.NET programmers who don't have the using
keyword.

Sorry for the rant,
Sami

[Eric Newton]

My thoughts exactly, Sami

Poorly written samples spawn poor code writers, since most of the "code
writers" simply cut and paste from other work instead of fully understanding
what is going on.

And yes, I see tons of ExecuteReader code not properly written to account
for a simple timeout or database exception. Hence they get connection
pooling at maximum exceptions and instead of trying to figure out why, they
just say "I need to increase the pool size"

....Amateurs...

--
Eric Newton
C#/ASP Application Developer
http://ensoft-software.com/
er**@cc.ensoft-software.com [remove the first "CC."]

PS: I run into many of these "cut and paste" coders in my career and I'm
wondering if its a sin to call them out?

"Sami Vaaraniemi" <sa************ ***@jippii.fi> wrote in message
news:bp******** **@phys-news1.kolumbus. fi...

"Michael Giagnocavo [MVP]" <mg*******@Atre vido.net> wrote in message
news:%2******** **********@TK2M SFTNGP11.phx.gb l...

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.

Err... well, that's the whole point of RAII: you don't have to call
f.Close() yourself. The benefit is that when you don't have to call
f.Close() explicitely there is less room for you to make an error.

RAII is the single biggest thing I miss from C++ since I started working
with C#. It is scary to see all the sample code that uses unmanaged
resources sloppily. All these samples will end up creating armies of
programmers who deal sloppily with unmanaged resources, and these
programmers will create waves of applications that work unreliably.

A very typical code sample, from an ASP.NET application, is this:

private void BindData()
{
// Connect to the Database
SqlConnection myConnection = new SqlConnection(c onnection string);

// Retrieve the SQL query results and bind it to the Repeater
string SQL_QUERY = "SELECT ProductName, UnitPrice, UnitsInStock " +
"FROM Products";
SqlCommand myCommand = new SqlCommand(SQL_ QUERY, myConnection);

myConnection.Op en();
dgProducts.Data Source = myCommand.Execu teReader();
dgProducts.Data Bind();
myConnection.Cl ose();
}

What's wrong with this code? The problem is that if

myCommand.Execu teReader fails because e.g., a temporary network problem or any other reason and
throws an exception, then the connection will not be closed and it won't be returned to the connection pool in a timely manner. Code like this will
result in a web app that will work unreliably under load and might start
failing when conditions are not ideal.

To make the code above robust, you'll want to wrap the usage of the
SqlConnection into a using-statement, which is the best we can do without
real RAII. I feel sorry for VB.NET programmers who don't have the using
keyword.

Sorry for the rant,
Sami

[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.Diagnost ics] 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/
er**@cc.ensoft-software.com [remove the first "CC."]

"Ted Miller" <te*@nwlink.com > wrote in message
news:vs******** ****@corp.super news.com...

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
IDisposableForc e. 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.)

"codymanix" <do************ *********@gmx.d e> wrote in message
news:eu******** ******@TK2MSFTN GP09.phx.gbl...

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 IDisposableForc e : 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,WarnLvl 1,WarnLvl2,Warn Lvl3,WarnLvl4,G enerateError};
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]

"codymanix" <do************ *********@gmx.d e> wrote in message <news:eu******* *******@TK2MSFT NGP09.phx.gbl>. ..

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 IDisposableForc e : 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,WarnLvl 1,WarnLvl2,Warn Lvl3,WarnLvl4,G enerateError};

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 IDisposableForc e 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...

--
Joe Foster <mailto:jlfoste r%40znet.com> DC8s in Spaace: <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Ted Miller]

"Joe "Nuke Me Xemu" Foster" <jo*@bftsi0.UUC P> wrote in message
news:uk******** ******@TK2MSFTN GP11.phx.gbl...

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 IDisposableForc e 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.

--
cody

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