这不是明白错误，BinaryFormatter [英] Is this not plain wrong, BinaryFormatter
问题描述
嗨
由于某种原因BinaryWriter在处理时关闭了流。我不想要它关闭流。
。根据我的逻辑，BinaryWriter
应该写入流，仅此而已。如果我想要关闭流，我将自己关闭它，而不是一些帮助类。
据我所知BinaryWriter应该*不*触摸流。除了
增加流的位置和
写入数据的预期行为。
想象一下这个.. 。
private void WriteWhateverBinaryThingsToStream（Stream aStream）{
using（BinaryWriter Writer = New BinaryWriter（aStream））{
Writer .WriteInt64（MyInt64）;
Writer.WriteString（MyString）;
}
}
public void SaveToFile（string FileName）{
using（FileStream fs = new FileStream（" c：\\test.dat"，FileMode.Create））
{
WriteWhateverBinaryThingsToStream（fs）;
WriteWhateverBinaryThingsToStream（fs）; //流已经关闭了
这里。
WriteWhateverBinaryThingsToStream（fs）;
}
}
即使我不使用使用关键字我不能创建多个实例
的BinaryWriters在同一个流上工作。因为GC可以随时关闭
流。请告诉我，我正在做非常非常错的事情
。如果我的假设是正确的，那么有人可以向我解释这些优势吗？我没有看到:(。
亲切的问候和许多感谢
亚历山大
Alexander Muylaert< Re ******** @ pandora.be>写道：由于某种原因，BinaryWriter在处理时关闭了流.I br不希望它关闭流。根据我的逻辑，BinaryWriter
应该写入流，仅此而已。如果我想要关闭流，我将自己关闭它，不是一些助手类。
我相信这个想法是它完全包裹了流。在我看来，
应该是一个可选参数构造函数说是否或者
而不是BinaryWriter有效地拥有流 - 在某些情况下，你想要能够将流引用传递给构造函数
并知道它会被处理;在其他情况下你想要你描述的
行为如下：
-
Jon Skeet - < sk *** @ pobox.com>
http://www.pobox.com/~skeet
如果回复小组，请不要给我发邮件
所以...
我有两种可能的修复方法。
*我写自己的BinaryWriter。 （具有正常行为）
*我将作者作为参数传递
两个解决方案都很糟糕。第一个给了我很多额外的工作。第二个
更糟糕的是，通过将作者作为参数传递，我需要使用
编写器来传输内容。也许我不想要，或者我应该访问
BaseStream属性。但是......
嗯
谁的想法是这个以及他在想什么......
规则n°1：免费创建任何内容（即使GC适用，我也很喜欢
使用声明）
规则n°2：不要释放你没有创造的东西。
规则n°3：首先创建物体，然后实施处置，第三个
实现中间的东西。
即使你没有GC，上面的规则也会阻止所有的泄漏和null
指针异常。人们应该非常严格地应用这三个非常简单的规则，
。没有但是... :-)
Imho这与GC无关，关闭流只是一个坏主意
并使二进制文件更少对我有意思。特别是在我提到的
情况中。相信我，这种情况发生了很多。
亲切的问候
Alexander
" Alexander Muylaert" <回复******** @ pandora.be>在留言中写道
新闻：eq ************** @ TK2MSFTNGP10.phx.gbl ...嗨
由于某种原因，BinaryWriter在处理时关闭了流。我不希望它关闭流。根据我的逻辑，BinaryWriter应该写入流，仅此而已。如果我想要关闭流，
我将自己关闭它，而不是一些帮助类。
根据我的说法，BinaryWriter应该*不*触摸流。除了
增加流的位置和向其写入数据的预期行为。
想象一下......
private void WriteWhateverBinaryThingsToStream（Stream aStream）{
使用（BinaryWriter Writer = New BinaryWriter（aStream））{
Writer.WriteInt64（MyInt64）;
Writer.WriteString（MyString）;
}
}
public void SaveToFile（string FileName）{
using（FileStream fs = new FileStream（" c：\\test.dat"，FileMode。创建））
{WriteWhateverBinaryThingsToStream（fs）;
WriteWhateverBinaryThingsToStream（fs）; //流已经
关闭
这里。
WriteWhateverBinaryThingsToStream（fs）;
}
}
即使我不是使用使用关键字我不能创建在同一个流上工作的BinaryWriters的多个
实例。因为GC可以随时关闭
流。请告诉我，我正在做一些非常非常错误的事情。如果我的假设是正确的，那么有人可以解释一下
对我的好处。我没有看到:(。
这是试图取悦所有人的挫折之一。有时
你希望读者只是一个访客，一些东西做某事并且
消失了，其他读者创建了流，然后othertimes仍然
你让读者完全控制流并让它完成工作/>
而不是你。非常难以确定哪条路径是真正的库。
正确的库。设计师选择按照
烦人虽然更常见的是设计读者和作家的路径来控制流。然而，我认为我同样会对其他
选项感到恼火。分别关闭流和读者。
坦率地说，我希望看到一些读者的版本不能控制
流，但我''我没有屏住呼吸（也许静态地实施，类似于目录的
方式和DirectoryInfo等）。最简单的路径你会发现获得aroudn这是创建一个忽略关闭和包裹的流
其他流（如果你环顾四周，必然会在gotdotnet，codeproject等上有很多
的例子。
亲切的问候和非常感谢
Alexander
Hi
for some reason the BinaryWriter is Closing the stream when disposed. I
don''t want it to close the stream. According to my logic the BinaryWriter
should Write to the stream, nothing more. If I want the stream to close, I
will close it myself, not some helper class.
According to me the BinaryWriter should *not* touch the stream. Except for
the expected behaviour of incrementing the Position of the stream and
writing data to it.
Imagine this ...
private void WriteWhateverBinaryThingsToStream(Stream aStream){
using (BinaryWriter Writer = New BinaryWriter(aStream)){
Writer.WriteInt64(MyInt64);
Writer.WriteString(MyString);
}
}
public void SaveToFile(string FileName){
using (FileStream fs = new FileStream("c:\\test.dat", FileMode.Create))
{
WriteWhateverBinaryThingsToStream(fs);
WriteWhateverBinaryThingsToStream(fs); // stream is already close
here.
WriteWhateverBinaryThingsToStream(fs);
}
}
Even when I don''t use the "using" keyword I cannot create multiple instances
of BinaryWriters that work on the same stream. Because GC can close the
stream at any time. Please tell me I''m doing something very, very wrong
here. If my assumption is correct, could somebody explain the advantages to
me. I see none :(.
Kind regards and many thanks
Alexander
Alexander Muylaert <Re********@pandora.be> wrote:for some reason the BinaryWriter is Closing the stream when disposed. I
don''t want it to close the stream. According to my logic the BinaryWriter
should Write to the stream, nothing more. If I want the stream to close, I
will close it myself, not some helper class.
I believe the idea is it wraps the stream entirely. In my view there
should be an optional parameter to the constructor saying whether or
not the BinaryWriter effectively "owns" the stream - in some cases you
want to be able to just pass a stream reference off to the constructor
and know that it will be taken care of; in other cases you want the
behaviour you''ve described below.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
So...
Two possible fixes for me.
* I write my own BinaryWriter. (with normal behaviour)
* I pass the writer as a Parameter
Both sollutions suck. The first gives me a ton of extra work. The second
is even worse, by passing the writer as a parameter, I need to use the
writer to stream something. Wich perhaps I don''t want, or I should access
the BaseStream property. But ...
Hmmm
Who''s idea was this and what was (s)he thinking...
Rule n°1: Free whatever you create (even with GC this one applies, I adore
the "using" statement)
Rule n°2: Don''t free something that you didn''t create.
Rule n°3: First create the object, next Implement the dispose, third
implement the thing inbetween.
Even when you have no GC the above to rules will prevent all leaks and null
pointer exceptions. One should only apply these three very simple rules,
extremely strictly. No buts... :-)
Imho this has nothing to do with GC, closing the stream is just a bad idea
and makes the binarywriter less interesting for me. Especially in the
situation I mentioned. And trust me, this happens a lot.
Kind regards
Alexander
"Alexander Muylaert" <Re********@pandora.be> wrote in message
news:eq**************@TK2MSFTNGP10.phx.gbl...Hi
for some reason the BinaryWriter is Closing the stream when disposed. I
don''t want it to close the stream. According to my logic the BinaryWriter
should Write to the stream, nothing more. If I want the stream to close,
I
will close it myself, not some helper class.
According to me the BinaryWriter should *not* touch the stream. Except
for
the expected behaviour of incrementing the Position of the stream and
writing data to it.
Imagine this ...
private void WriteWhateverBinaryThingsToStream(Stream aStream){
using (BinaryWriter Writer = New BinaryWriter(aStream)){
Writer.WriteInt64(MyInt64);
Writer.WriteString(MyString);
}
}
public void SaveToFile(string FileName){
using (FileStream fs = new FileStream("c:\\test.dat", FileMode.Create))
{
WriteWhateverBinaryThingsToStream(fs);
WriteWhateverBinaryThingsToStream(fs); // stream is already
close
here.
WriteWhateverBinaryThingsToStream(fs);
}
}
Even when I don''t use the "using" keyword I cannot create multiple
instances
of BinaryWriters that work on the same stream. Because GC can close the
stream at any time. Please tell me I''m doing something very, very wrong
here. If my assumption is correct, could somebody explain the advantages
to
me. I see none :(.
Its one of the frustrations inherent to trying to please everyone. Sometimes
you want a reader to be just a visitor, something that does something and
goes away, othertimes the reader creates the stream, and othertimes still
you give the reader complete control over the stream and let it do the work
instead of you. Its terribly difficult to determine which path is the
correct one for a library, really. The designers chose to follow the
annoying, albeit more common, path of designing readers and writers to
control the stream. However, I think I''d be equally annoyed with the other
option of having to close both the stream and the reader seperatly.
Frankly I''d like to see versions of some readers that don''t control the
stream, but I''m not holding my breath(perhaps implemented statically, in a
way similar to Directory and DirectoryInfo, etc). The easiest path you''ll
find to get aroudn this is to create a stream that ignores close and wraps
other streams(if you look around, there is bound to be plenty of examples of
this on gotdotnet, codeproject, etc)
Kind regards and many thanks
Alexander
这篇关于这不是明白错误，BinaryFormatter的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
