I have one method that receives a Stream to write on it using a BinaryWriter. But when I dispose this BinaryWriter it also closes the stream. Can I leave it undisposed so I can leave my stream open?
views:
595answers:
3
+10
A:
In the case of BinaryWriter, that isn't a direct option (although some stream wrappers do allow you to control this, for example GZipStream etc).
Jon has a NonClosingStreamWrapper in MiscUtil which should work: you wrap your stream in the non-closing wrapper, and give the wrapper to BinaryWriter. This essentially passes through everything except Close() and Dispose().
Marc Gravell
2009-07-05 20:57:23
Great library, nice work!
Jader Dias
2009-07-05 21:05:17
Link's broken: http://www.yoda.arachsys.com/csharp/miscutil/
colithium
2009-07-05 21:13:02
Dont you think that there is a bit of hack? You suggest to change behavior(and assumtions) of the BinnaryWriter by fooling it with wrapper?
Mike Chaliy
2009-07-05 22:24:52
No, that changes nothing **at all** related with `BinaryWriter`; it writes values to a stream and tells the stream when it is finished. Care to expand on what you have in mind? It is certainly *a lot* less hacky than not disposing something that is IDisposable on the grounds that you peeked at the implementation and decided to overrule it...
Marc Gravell
2009-07-05 22:35:48
this changes expected behaviour of the binnary writer. because of expected behaviour of close and dispose operations, binnarywriter does not bother to flash. By filtering close and dispose functions you simply introduce bug that in cirtan circumstances hard to find.
Mike Chaliy
2009-07-06 07:27:51
When a BinaryWriter closes, it flushes **itself** and tells the stream to close; with the wrapper, it would still flush itself. The difference it that the *stream* doesn't close.
Marc Gravell
2009-07-10 22:48:41
It's safe _today_. Are you going to use Reflector on ever release of .NET to make sure it continues to be safe? This is not a solution. -1.
John Saunders
2009-07-05 21:05:35
It will be always safe. Just because of writer semantics. Just think why it has dispose for now (hint look at examples on msdn). Also note that this is not the only place in .NET that incorrectly use IDisposable, for example well know Dispose problem with WCF channels.
Mike Chaliy
2009-07-05 21:12:03
I can say more, @Marc Gravell will fail the same way if Microsoft will change semantics of the Dispose in BinnaryWriter.
Mike Chaliy
2009-07-05 21:14:08
It has a dispose because it is assumed that it now owns the stream's lifetime. But if we don't want that, then I'd argue the correct thing to do is to separate the two - not hack how we use the writer. The writer is disposable; we should dispose it. In short, I disagree.
Marc Gravell
2009-07-05 21:48:19
It has dispose just because ONE of the usage scenarious assumes that it can own stream's lifetime.The fact that object is disposable is not something that requires to call dispose. Sometimes it just syntax helper. In the case of BinnaryWriter this is the case. (BTW BinnaryWriter is Serializable, lets make serialize it?, how so, how serialize writer?)Regarding hack, I am fail to see one.
Mike Chaliy
2009-07-05 22:22:32
"The fact that object is disposable is not something that requires to call dispose" - there we again disagree. IDisposable is a contract; unless you have a very good reason, you should dispose it when done. Anything else breaks encapsulation. You shouldn't know or care what it needs disposable for... it is disposable: dispose it. Replied to your other comment (on my post), too.
Marc Gravell
2009-07-10 22:50:32
+5
A:
The protected BinaryWriter.Dispose(bool) method is virtual, and all it does is closes the stream (you can check that it is true in Reflector). -This method is called by the Dispose() method.
You can simply inherit a class from the BinaryWriter and override the Dispose(bool) method to do nothing, or something else alltogether.
kek444
2009-07-05 21:04:48