Можно ли помешать StreamReader располагать базовый поток?
Мне нравится правильность константы... в теории. К каждому разу, когда я попытался применить его строго на практике, это сломалось в конечном счете, и const_cast начинает вползать в создание ужасного кода.
, Возможно, это - просто шаблоны разработки, которые я использую, но константа всегда заканчивает тем, что была слишком широкой кистью.
, Например, вообразите простой механизм базы данных..., он имеет объекты схемы, таблицы, поля и т.д. У пользователя может быть 'указатель' Таблицы константы, означающий, что им не позволяют изменить саму схему таблицы..., но что относительно того, чтобы управлять данными, связанными с таблицей? Если Вставка () метод является отмеченной константой тогда внутренне, это должно выбросить мыс константы для фактического управления базой данных. Если это не отмеченная константа тогда, это не защищает от вызова метода AddField.
, Возможно, ответ должен разделить класс на основе требований мыса константы, но это имеет тенденцию усложнять дизайн больше, чем я хотел бы за преимущество, которое это приносит.
5 ответов
Я не хочу просто позволять это тоже выходит за рамки. Затем сборщик мусора в конечном итоге вызовет Dispose, уничтожив поток.
Сборщик мусора вызовет метод Finalize (деструктор), а не метод Dispose . Финализатор вызовет Dispose (false) , который не удалит основной поток. Вы должны быть в порядке, оставив StreamReader вне области видимости, если вам нужно напрямую использовать базовый поток. Просто убедитесь, что вы удалили основной поток вручную, когда это необходимо.
Да. Как и во всех ответах, если вы на 100% уверены, что данные класса не будут использоваться после вызова delete, это .
Например, в одном проекте:
void Test()
MyClass * Someclass = new MyClass;
SomeClass->DoYourThing();
SomeClass->KillYourself();
return;
void MyClass::DoYourThing() { return; }
void MyClass::KillYourself() {delete this;}
Очень упрощенное объяснение , проект использовал удалить это; как часть управления памятью для объектов этого типа; их конструктор добавил их в частный список используемых классов этого типа и удалил себя из этого списка, когда они были уничтожены, а затем удалил себя (этого не было в деструкторе). Любые объекты этого класса, которые не
Просто удалите using-Block. Думаю, вам не нужно Dispose () StreamReader, если вы не хотите использовать Dispose () для потока.
Закройте его самостоятельно в предложении try / finally , когда закончите с ним.
var sr = new StreamReader();
try {
//...code that uses sr
//....etc
}
finally
{
sr.Close();
}
Вы можете создать новый класс, унаследованный от StreamReader, и переопределить метод Close; внутри вашего метода Close вызовите Dispose (false), который, как указал Мердад, не закрывает поток. Конечно, то же самое относится и к StreamWriter.
Однако похоже, что лучшим решением было бы просто удерживать экземпляры StreamReader и StreamWriter до тех пор, пока они вам могут понадобиться. Если вы уже планируете оставить поток открытым, вы можете также оставить открытыми StreamReader и StreamWriter. Если вы правильно используете StreamWriter.Flush и Stream.Seek, вы сможете заставить эту работу работать даже при чтении и записи.