Comment Feed for Why can't you explicitly cast an int to a string in C#? (TechOff on Channel 9)

Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Why can't you explicitly cast an int to a string in C#?

Bas — Wed, 25 Jun 2008 17:27:16 GMT

1. The moment "internal details" are documented they stop being internal details. Simply stating in documentation that "Close calls Dispose" is not implementation detail. In fact the guideline for implementing Dispose actually states that, that if a Close method is implemented then it should just call Dispose().

So if I document the fact that my class has a private Dictionary member in which I store all my stuff, then that private member is no longer an internal detail? That's pretty strange.

2. All my comments/examples were about .NET Framework classes.

All my comments were about general good programming practice, not .NET specifically.

Why would it drop all details Bas?

Performance? Who knows? That's not the point. The point is that you shouldn't rely on stuff that you know to be true but isn't actually part of the contract.

by default- no classes in .net purposely transact their changes.. just for streams its important for control and performance that we have the ability to manage the flushing ourselves..

Sure, maybe it's all fine and dandy in .NET. What if you come across a third party library and they didn't implement it that way?

If I'm done with an object, I should expect that object ensures my changes are done..

No you shouldn't, unless it's stated in the contract.

But again it comes back to my point, and as sven pointed out - .net classes DON'T act in that way.. so why should I do it unless theres a problem?

Good practice resulting in robust code, even if you eventually start using a third party class library that didn't interpret "release all resources" as "finish up, then release"? That'd still comply with IDisposable's contract.

Adhere to the contract, not what you know about the implementation. And since you shouldn't know anything about the implementation, just adhere to the contract and be safe. The implementation might radically change in a next version: that the whole point of abstraction and encapsulation.

Anyway, evildictator is a lot better at conveying this than I am.

Edit: Paul Wilson does a pretty good job too.

Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Why can't you explicitly cast an int to a string in C#?

evildictaitor — Wed, 25 Jun 2008 14:30:22 GMT

If a class chooses to do something as part of a method that is not defined by the contract's method that's up to it. But you shouldn't rely (in general) on IDisposable doing anything more than disposing of unmanaged resources and memory which is what implementing IDisposable's contract means.

Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Why can't you explicitly cast an int to a string in C#?

Dexter — Wed, 25 Jun 2008 13:26:04 GMT

Depends on what you really mean by "contract" in this case. In any case:

- .NET/C# interfaces are a weak form of contracts. All they do is require a class to implement some methods, everything else is left to the documentation.
- There's nothing stopping an implementation to exceed contract requirements.
- Stream's IDisposable implementation exceeds contract requirements and documents that thus becoming a contract in itself because that's how contracts are defined in .NET/C#.
- Contract or not, the fact that Stream.Dispose writes changes to the store was documented and no matter how the internal implementation changs this must remain true.

And since _stevo mentioned transactions: the TransactionScope is a perfect example of exceeding IDisposable's "contract". It does the opposite of Stream, it rollbacks any changes that were made. Not only it does that but that's the only way to rollback a transaction because there's no Rollback method provided. Even more, TransactionScope.Dispose documentation does not mention anything about realising managed and unmanaged resources.

I guess TransactionScope's creation was the moment when IDisposable silently converted to a general purpose interface beyond its "release managed and unmanaged resources" original intent. Because this interface was used by the using C# keyword it is now used to model scope based lifetime similar to C++. Now this is not strictly related to "to Close or not to Close" but about what an "IDisposable contract" can really mean.

Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Why can't you explicitly cast an int to a string in C#?

evildictaitor — Wed, 25 Jun 2008 10:59:09 GMT

Because there's no guarrantee that they will continue to do so in future.

You should program to contracts not to implementations.

According to IDisposable:

/// <summary>Defines a method to release allocated unmanaged resources.</summary>
/// <filterpriority>2</filterpriority>
[ComVisible(true)]
public interface IDisposable
{
    /// <summary>Performs application-defined tasks associated with freeing, releasing, or resetting unmanaged resources.</summary>
    /// <filterpriority>2</filterpriority>
    void Dispose();
}

That is to say that my hypothetical example correctly implements IDisposable and so arguments that it is a silly example and so on aside, if you rely on implementation semantics from the .NET library, these may change without warning during a "bug fix" or a version change.

I cannot emphasise this enough. IDisposable does NOT guarrantee that it will flush buffers or correctly clean up the object - merely that it will free all unmanaged resources to avoid resource and memory leaks. That's what it's for.

While file-streams are perhaps not a very good example, take some better example of some TcpConnection that it used for some persistent connection (e.g. for a MMO)

class NetworkConnection : IDisposable {
TcpClient client;

public void Logout();
public void Close();
public void Dispose();
}

Now when I call Close(), by the contract of what Close() does on objects, it should close the object as best it can, so in this case it should call Logout(). Let us say for example that Logout() uses the underlying connection to actively logout. The question I now pose to you is should Dispose() logout?

My answer to this would be a resounding no. Dispose should guarrantee that it closes the client and that it releases the resources associated with the network layer and any buffers it may still have, but Dispose() does not have to guarrantee that it cleans up nicely, nor would it be appropriate in this case, since Dispose() could legitimately be called if the underlying client breaks for some reason. The Dispose() method of the NetworkConnection should merely be responsible for the cleaning up of resources associated with an object to avoid leaks, as the contractual obligation to IDisposable itself says.

Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Why can't you explicitly cast an int to a string in C#?

stevo_ — Wed, 25 Jun 2008 10:37:57 GMT

Why would it drop all details Bas? by default- no classes in .net purposely transact their changes.. just for streams its important for control and performance that we have the ability to manage the flushing ourselves..

If I'm done with an object, I should expect that object ensures my changes are done.. because I've worked with that object as if the changes have been done.. I'm not aware as a developer that the object works in a transacted mannor.

But again it comes back to my point, and as sven pointed out - .net classes DON'T act in that way.. so why should I do it unless theres a problem?

Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Why can't you explicitly cast an int to a string in C#?

Dexter — Wed, 25 Jun 2008 10:17:06 GMT

1. The moment "internal details" are documented they stop being internal details. Simply stating in documentation that "Close calls Dispose" is not implementation detail. In fact the guideline for implementing Dispose actually states that, that if a Close method is implemented then it should just call Dispose().

2. All my comments/examples were about .NET Framework classes. If you have some crappy third party library where Dispose does not imply Close then of course it is ok/required to call Close. Hopefully such a lame library does not exist.

Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Why can't you explicitly cast an int to a string in C#?

Bas — Wed, 25 Jun 2008 08:39:15 GMT

So does "releasing all managed and unmanaged resources in a clean and predictable way" mean "I'm gonna finish all this stuff you were doing and then release all resources" or does it mean "I'm gonna drop everything that was going on and release all resources"?
The contract doesn't state that. It only states that resources should be released when Dispose() returns.

Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Why can't you explicitly cast an int to a string in C#?

Tommy Carlier — Wed, 25 Jun 2008 08:15:56 GMT

IDisposable was designed for this: to release all managed and unmanaged resources in a clean and predictable way. If a class that implements IDisposable does not work like this, then that's a bug with that class. A contract only works if the implementor does what you expect it to do.

Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Why can't you explicitly cast an int to a string in C#?

Bas — Wed, 25 Jun 2008 07:44:29 GMT

"Why in the world it is better practice to do something that the documentation states that's not needed is beyond me."

Let's say I'm using some third party class library and the documentation carelessly states all sorts of details about the class's private implementation. Should I write my code based on my knowledge of how those classes are implemented?

Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Why can't you explicitly cast an int to a string in C#?

Dexter — Wed, 25 Jun 2008 07:08:39 GMT

Why in the world it is better practice to do something that the documentation states that's not needed is beyond me. That's really at the borderline of Cargo cult programming, calling methods for the sake of it.

And I don't see how can it be less of a hassle to write x.Close() a thousand times instead of just checking the documentation once. It's not like there are a thousand classes that have both Close and Dispose and anyway you're supposed to read the documentation, that's why it exists.

I give up!

PS: Luckily no one here pretends that one must also call Flush before Close. I've seen cases like that and I tend to go kboom :)

Re: Re: Re: Re: Re: Why can't you explicitly cast an int to a string in C#?

Sven Groot — Wed, 25 Jun 2008 01:17:40 GMT

Hypothetical examples aside, fact is that no framework class actually does that, and in most cases this is stated in the documentation (so relying on it is not relying on implementation details).

Quite frankly I think you'd have to be pretty stupid as a library programmer to make a class behave like that, as it goes against what programmers expect (even the C++ stream classes will properly flush in their destructors if you don't explicitly call close). You'd better have a damn good reason to do something like that.

Re: Re: Re: Re: Why can't you explicitly cast an int to a string in C#?

evildictaitor — Tue, 24 Jun 2008 22:56:43 GMT

A class implements IDisposable correctly if a class does not leak memory or system resources if it's Dispose method is called, and it does so deterministically. Consider some hypotethical class:

BufferedStream : Stream, IDisposable {
string someBuffer;
Stream underlyingStream;
public BufferedStream(Stream underlyingStream){
    this.underlyingStream = underlyingStream;
}
//<summary>
// Flushes the buffer to the stream
//</summary>
public void Flush(){
    if(someBuffer != null) {
      byte[] bytes =Encoding.UnicodeEncoding.GetBytes();
      underlyingStream.Write(bytes,0,bytes.Length);
      someBuffer = null;
    }
}
// <summary>
// Writes a string to the stream
// </summary>
public void Write(string str){
    Flush(); someBuffer = str;
}

// <summary>
// Closes the stream
// </summary>
public void Close(){
    Flush();
    underlyingStream.Close();
}

// <summary>
// Disposes of system resources and native memory
// </summary>
public void Dispose(){
    stream.Dispose();
}
}

Now consider the following examples:

public void Example1(){
BufferedStream s = new BufferedStream(System.IO.File.OpenWrite("myfile.txt")));
s.Write("Hello World!");
}

This is bad because the unmanaged resources are potentially lost and the connection may never be closed, and will be in an inconsistent state when it does

public void Example2(){
BufferedStream s = new BufferedStream(System.IO.File.OpenWrite("myfile.txt")));
s.Write("Hello World!");
s.Dispose();
}

This is bad because although no resource leaks occur (as guarranteed by IDisposable) there is no guarrantee that the underlying buffers will be flushed to the device, as this is not guarranteed by IDisposable

public void Example3(){
BufferedStream s = new BufferedStream(System.IO.File.OpenWrite("myfile.txt")));
s.Write("Hello World!");
s.Close();
}

This is bad because although Close guarrantees that the open object is closed, it makes no guarrantee about disposing of OS resources or memory

public void Example4(){
BufferedStream s = new BufferedStream(System.IO.File.OpenWrite("myfile.txt")));
s.Write("Hello World!");
s.Dispose();
s.Close();
}

This is bad because Dispose() clears up the OS resources and thus any subsequent operations will likely break. Dispose() should always be the last thing you call on a method:

public void Example5(){
BufferedStream s = new BufferedStream(System.IO.File.OpenWrite("myfile.txt")));
s.Write("Hello World!");
s.Close();
s.Dispose();
}

This is the only correct example that would lead to correct determinsitic behaviour for the BufferedStream.

Re: Re: Re: Why can't you explicitly cast an int to a string in C#?

stevo_ — Tue, 24 Jun 2008 21:53:56 GMT

I agree, I shouldn't of referred to close as destruction.. but to be honest, I don't think I could articulate my thoughts on this over this medium. I still keep to the same overall thoughts on this though.. unless theres a problem, why do it?

Re: Re: Re: Why can't you explicitly cast an int to a string in C#?

stevo_ — Tue, 24 Jun 2008 21:44:33 GMT

Its not rude littleguru, its humour.. bloody is traditionally thought of as a brit word, along with having bad teeth and various other points. If anything, I'm digging at myself.

Still, my point lies- programmers love to argue about things that generally make little difference.. I didn't say it was a bad thing, actually I find it amusing and I imagine can even be helpful at times.

Perhaps I should append my posts with a 'tongue out' smiley, but we don't seem to have those yet.

Re: Re: Why can't you explicitly cast an int to a string in C#?

Christian Liensberger — Tue, 24 Jun 2008 21:31:12 GMT

Bloody programmers and your arguing about details..

Offtopic: Why are you so rude?

Re: Re: Re: Why can't you explicitly cast an int to a string in C#?

stevo_ — Tue, 24 Jun 2008 20:59:35 GMT

No, not at all.. I'm very aware of the reasons disposable was intended.. I just don't see why you could ALSO call "close" without reason.. sure - if theres a class that doesn't implement idisposable correctly- then yea.. but why otherwise?

Re: Re: Why can't you explicitly cast an int to a string in C#?

Bas — Tue, 24 Jun 2008 20:56:50 GMT

Close() isn't the destructor. And it's not about calling Close() because dispose "might not be implemented properly", it's about calling Close() because you shouldn't rely on the knowledge that Dispose() calls Close() itself.

Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Why can't you explicitly cast an int to a string in C#?

lensman — Tue, 24 Jun 2008 20:27:47 GMT

Have you ever looked at the connections log on the database?

Failure to use close leaves connections open until the database "snipes" the connection. It is better, from a resource perspective, to close and dispose of your connection.

Re: Re: Why can't you explicitly cast an int to a string in C#?

evildictaitor — Tue, 24 Jun 2008 19:46:50 GMT

You mean why call Dispose() or Close() at all?

class SomeClass {

byte[] payload = Encoding.UnicodeEncoding.GetBytes("Hello World"));

SomeClass(){
    Foo1();
    Foo2();
}

void Foo1(){
System.IO.FileStream fs = System.IO.File.Open("myFile.txt");
fs.Write(payload, 0, payload.Length);
    // and don't release fs here - the GC will clean it up right?
}

void Foo2(){
    // let's hope the GC has cleaned up the old fs, if it hasn't this will break:
System.IO.FileStream fs = System.IO.File.Open("myFile.txt");
fs.Write(payload, 0, payload.Length);
}

}

Re: Why can't you explicitly cast an int to a string in C#?

stevo_ — Tue, 24 Jun 2008 18:57:42 GMT

Bloody programmers and your arguing about details.. that said.. I'm in the camp of not explicitely calling a 'destruction' method on the object if possible..

I won't post an essay repeating mostly what others have said, but I'll add that- why call the objects destruction method explicitely on the whim that you don't trust it to have implemented disposable properly..

Unless theres a problem, why do it?

Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Why can't you explicitly cast an int to a string in C#?

Bas — Tue, 24 Jun 2008 18:07:55 GMT

Does it imply, or does it guarantee close, and the exact behaviour of close?

Even if the documentation states "I'm just calling Close for you", I think it's better practice to explicitly call it yourself. Both because I find it less of a hassle to just call Close and be certain than check what, exactly, the Dispose method for every class I use does.

And, like I said, I don't care how a Class's method is implemented, that's what abstraction is for. All I know is that Dispose releases resources. Wether it just drops everything it is doing and releases or if it helps me out and finishes stuff up for me in case I didn't is irrelevant to me.

Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Why can't you explicitly cast an int to a string in C#?

Dexter — Tue, 24 Jun 2008 10:05:23 GMT

And what does Stream.Dispose documentation say to us?

"This method disposes the stream, by writing any changes to the backing store and closing the stream to release resources."

I'd say it's pretty clear about flushing buffers...

And I did not claim that they are semantically equivalent. Dispose implies Close, Close does not always imply Dispose, this is not equivalence.

And this topic should be in a separate thread :)

Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Why can't you explicitly cast an int to a string in C#?

Tommy Carlier — Tue, 24 Jun 2008 09:19:48 GMT

The (often non-) difference between Close and Dispose.

Around Whidbey, it was realized that the rules around Dispose needed to be tightened up. C++ destructors -- which are deterministic -- needed to map to Dispose (the general Framework solution for deterministic cleanup).

Based on this experience, I'd encourage you to think very carefully before attempting to use a domain-specific name instead of Dispose -- we're now at a place where users are familiar with Dispose and it is the most discoverable method name.

Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Why can't you explicitly cast an int to a string in C#?

evildictaitor — Tue, 24 Jun 2008 09:05:48 GMT

While that may be true, there is a semantic difference between Close() and Dispose():

Dispose() tells the object to dispose of its unmanaged resources properly and that it should prepare itself for cleanup.

Close() tells the object that the actions being applied to it have now finished and that any existing buffers to the object should be flushed to the device.

This means that you should (in general) call both, although as Tommy said it's typically better practise to abstract the Dispose() method via the using directive:

using(MyDisposableObject obj = GetDisposableObject()){
var result = DoSomething(obj);
obj.Close();
}

Note that using the using statement guarrantees Dispose() via the try..finally directive, so the code above Closes (which properly flushes the internal buffers to the device) conditional on DoSomething() not throwing an exception, whereas Dispose() is unconditionally called (which is why the using directive is preferrable).

Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Why can't you explicitly cast an int to a string in C#?

Dexter — Tue, 24 Jun 2008 07:56:46 GMT

In addition: indeed, I'm not aware of any case were calling Dispose won't have the same effect as calling Close. It is the opposite that doesn't always hold true, for example calling Close on a modal form does not dispose it.

In general I don't like calling both Close and Dispose. I know nothing bad happens if you do that but I'm used to C++ where a double delete is an error and I consider it to be a bug when people only call Close and they don't put it in a finally block.