Здравствуйте, Ночной Смотрящий, Вы писали:
НС>А с чего ты решил, что это кто то конкретный?
С переписки...
НС>Я так проглядел выборочно последние твои баны — вроде везде по делу.
Например, мне трудно считать, что это по делу, а не от того, что нечего ответить
НС> Может проблемы в себе поискать?
Причины того, что поддостал? Ну да, у меня обострённое чувство справедливости. Думаешь это плохо?
Я бы много мог чего написать, но я не хочу обсуждать политику модерирования RSDN. Это не только запрещено, но и неконструктивно. Кроме того, я считаю, что команда сайта тут в своём праве. они могут банить кого и как хотят, нарушать свои правила или не нарушать их проявлять подлость или благородство. Это же их территория. Я же могу рещить хочу я сюда ходить или нет, или, напирмер, хочу ли я положить сайт и т. д.
В целом я просто проверил местную публику на вшивость и сделал для себя выводы, стоит так уж хотеть тут присутствовать, или пустое это всё. Все могут посмотреть на результаты моих скормных тестов и тоже сделать свои выводы...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
НС>>Я так проглядел выборочно последние твои баны — вроде везде по делу. E>Например, мне трудно считать, что это по делу, а не от того, что нечего ответить
Т.е. ты намеренно занялся провокацией, о чем ниже признался, а когда тебя за провокацию забанили пытаешься выдать себя за невинную овечку? Какая то запредельная степень нарциссизма.
E>Все могут посмотреть на результаты моих скормных тестов и тоже сделать свои выводы...
Только не факт, что выводы будут такими, какие тебе хочется.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Т.е. ты намеренно занялся провокацией, о чем ниже признался, а когда тебя за провокацию забанили пытаешься выдать себя за невинную овечку? Какая то запредельная степень нарциссизма.
В смысле провокацией? Мне правда не ясно в чём суть претензий Влада к другим, когда он сам занят немерлением...
НС>Только не факт, что выводы будут такими, какие тебе хочется.
Мне всё равно какие будут у кого выводы.
Мне задали вопрос, я объяснил своё поведение. Тот, кому я объяснял, походу меня понял. Остальные могут решать что им нравится. Мне это не важно.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[28]: 1) Родовая травма: исключеиния в деструкторах
Здравствуйте, Ku-ku, Вы писали:
EP>>трик известный, вот только вопрос был про глобальный объект. KK>Так мне вроде никто не запрещал вместо глобального объекта использовать что-нибудь другое
EP>>Например, какие есть штатные приёмы для глобальных объектов? auto_ptr, optional, и т.п.?
я к тому, что конструкторы объектов могут кидать, в том числе и глобальных, но это не делает кидающие конструкторы неюзабельными.
KK>>>Оба подхода можно сравнить на предмет читаемости, предрасположенности к провоцированию совершения ошибок и простоты поддержки. Для меня, с учётом моих субъективных качеств, первый подход вчистую проигрывает второму по пунктам 1 и 3 и как минимум не лучше по пункту 2. EP>>ИМХО, когда исключения только появились, они тоже сливали по пунктам 1 и 3 коду без них, как минимум потому, что далеко не все сразу научились ими пользоваться (к сожалению, многие не умеют это делать и по сей день). KK>Ты веришь, что твою любимую методику ждёт неминуемый успех? Что ж, мечтать не вредно
Нет, я всего лишь показал, что "читаемость" и "простота поддержки", в этом случае являются вопросом "existance practice", и не являются каким-либо фундаментальным фейлом самого механизма.
EP>>>>>>1. ИМХО, лучше иметь два разных класса — один с исключениями, другой без. KK>>>>>А что делать с общими бессбойными операциями? Дублировать? Не так уж и привлекательно. EP>>>>Зачем дублировать? Пусть тот который с исключениями, наследует того который без исключений. KK>>>Не пойму в чём прелесть такого финта ушами. EP>>это ответ на вопрос про дублирование. KK>Я так и не понял зачем надо два класса вместо одного.
имхо, ситуации, в которых требуются методы выполняющие одинаковые действия, но отличающиеся throw/return_error_code, нужны одновременно для одного объекта — редки. То есть обычно нужны либо exceptions, либо error-code.
EP>>>>>>>>Если flush кидает, то скорей всего и конструктор кидает, да и write тоже кидает — ловить придётся в любом случае. KK>>>>>>>Это зависит от интерфейса File. Иногда одни и те же операции реализуют в двух вариантах: с использованием исключений для сообщения об ошибках и с использованием кодов ошибок. EP>>>>>>1. ИМХО, лучше иметь два разных класса — один с исключениями, другой без. EP>>>>>>2. Может точно также реализовать класс который позволяет контролировать кидаются исключения из deferred или нет. KK>>>>>И какую же версию будет звать деструктор: бросающую или небросающую? EP>>>>Также как и в ostream — достаточно ведь exceptions установить, а методы остаются теме же. KK>>>ostream — это настоящая помойка и пример того, как делать не нужно. EP>>Ну так я согласен. Это же не я предложил класс поддерживающий два варианта обработки ошибок KK>Использование флагов — это не единственный способ. Можно предоставить две функции, как например делается в случае basic_stream_socket::connect из Boost. KK>>>Это зависит от интерфейса File. Иногда одни и те же операции реализуют в двух вариантах: с использованием исключений для сообщения об ошибках и с использованием кодов ошибок. EP>>ostream делает именно это. KK>Но через заднее место.
((ostream -> помойка) && (ostream использует флаги для exceptions)) -> всё что использует флаги теперь ацтой, и так делать не нужно?
KK>>>>>Нет. SRP не подразумевает, что задача не может состоять из подзадач. EP>>>>Ну так и тут есть задача финализации объекта, которая состоит из подзадач — deferred и release. KK>>>Финализация объекта — это не задача. Если бы произвольную сумму действий можно было назвать задачей, то SRP не имел бы смысла. EP>>При поддержки со стороны компилятора, когда deferred вызывается не из деструктора — SRP нарушается? KK>Вроде, не нарушается. AFAIK, SRP распространяется на функции, классы, модули. А тут к чему его применять?
Ну а к чему ты применяешь SRP в случае текущей реализации? К авто-генерированному деструктору?
В чём существенная разница, между текущей реализацией и решением основанным на поддержке компилятора, которая делает делает одно не SRP-шным, а второе SRP-шным?
Только exception specification??
EP>>>>А мне свекла не нравится А если серьёзно, то я не увидел сильных аргументов против. KK>>>Ну значит пора сворачить дискуссию. Пусть каждый останется при своём мнении. EP>>Ну так ты же тоже согласен, что каких-то фатальных недостатоков нет. KK>У ручного управления ресурсами, например, их тоже нет. Но это как-то не очень мотивирует к применению такого подхода при возможности использовать более удобную альтернативу вроде RAII.
1. надо ставить flush руками
2. не надо ставить flush руками
что более удобное
Re[29]: 1) Родовая травма: исключеиния в деструкторах
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>я к тому, что конструкторы объектов могут кидать, в том числе и глобальных, но это не делает кидающие конструкторы неюзабельными.
А я к тому, что бросающие деструкторы — error prone, причём в большей степени, чем конструкторы.
EP>Нет, я всего лишь показал, что "читаемость" и "простота поддержки", в этом случае являются вопросом "existance practice", и не являются каким-либо фундаментальным фейлом самого механизма.
Это твоё мнение, и я с ним не согласен.
EP>((ostream -> помойка) && (ostream использует флаги для exceptions)) -> всё что использует флаги теперь ацтой, и так делать не нужно?
ostream — потому и помойка, что берёт на себя кучу совершенно разных обязанностей, которые можно и следовало бы разделить по отдельным классам и функциям. Наличие у объекта состояний, которые не обусловлены изначально возлагаемой на него задачей, — это именно отстой. Любая функция, инкапсулирующая какое-то действие над объектом, должна или документировать в каком состоянии она оставляет флаг, или заниматься сохранением флага перед началом работы и восстановлением его значения по завершении. Первый подход создаёт геморрой для вызывающей стороны, а второй не удобен для того, кто реализует функцию. Да и вообще непонятно считать ли изменение флага логической модификацией объекта. Если какая-то операция изменяет флаг, но в остальном никак не меняет состояние объекта, то она мутирующая или нет?
Забота об исключениях — это отдельная задача. Если она не является единственной задачей объекта, то согласно SRP объект не должен браться за её решение.
EP>Ну а к чему ты применяешь SRP в случае текущей реализации? К авто-генерированному деструктору?
Да. Деструктор — часть интерфейса.
EP>В чём существенная разница, между текущей реализацией и решением основанным на поддержке компилятора, которая делает делает одно не SRP-шным, а второе SRP-шным?
Разница в возможности выполнять две операции по отдельности без применения трюков. Которая кстати не отменяет наличие общей проблемы у обоих решений.
EP>>>Ну так ты же тоже согласен, что каких-то фатальных недостатоков нет. KK>>У ручного управления ресурсами, например, их тоже нет. Но это как-то не очень мотивирует к применению такого подхода при возможности использовать более удобную альтернативу вроде RAII.
EP>1. надо ставить flush руками EP>2. не надо ставить flush руками
EP>что более удобное
Для меня — ставить flush руками. Потому что альтернатива — неочевидный error prone код. Неявные действия хороши далеко не всегда, преобразования типов тому показательный пример.
Re[13]: 1) Родовая травма: исключеиния в деструкторах
Здравствуйте, landerhigh, Вы писали:
E>>Кстати, а как при таком подходе гарантировать освобождение критических ресурсов? terminate их же не освободит?
L>Каких ресурсов? Их уже твой забытый поток покромсал в салат.
А как же смартпоинтеры? Или написать на С++ программу, гарантированно не расстреливающую память, невозможно?
Re[14]: 1) Родовая травма: исключеиния в деструкторах
Здравствуйте, Ночной Смотрящий, Вы писали:
L>>Каких ресурсов? Их уже твой забытый поток покромсал в салат.
НС>А как же смартпоинтеры? Или написать на С++ программу, гарантированно не расстреливающую память, невозможно?
Да, да, невозможно. Мы все умрем и только в переплавку.
Здравствуйте, Ku-ku, Вы писали:
EP>>я к тому, что конструкторы объектов могут кидать, в том числе и глобальных, но это не делает кидающие конструкторы неюзабельными. KK>А я к тому, что бросающие деструкторы — error prone, причём в большей степени, чем конструкторы.
оба error-prone, деструкторы в большей степени. у меня даже caution есть.
EP>>Нет, я всего лишь показал, что "читаемость" и "простота поддержки", в этом случае являются вопросом "existance practice", и не являются каким-либо фундаментальным фейлом самого механизма. KK>Это твоё мнение, и я с ним не согласен.
, раз требует, значит для них это наверное будет читаемым
KK>ostream — потому и помойка, что берёт на себя кучу совершенно разных обязанностей, которые можно и следовало бы разделить по отдельным классам и функциям. Наличие у объекта состояний, которые не обусловлены изначально возлагаемой на него задачей, — это именно отстой. Любая функция, инкапсулирующая какое-то действие над объектом, должна или документировать в каком состоянии она оставляет флаг, или заниматься сохранением флага перед началом работы и восстановлением его значения по завершении. Первый подход создаёт геморрой для вызывающей стороны, а второй не удобен для того, кто реализует функцию. Да и вообще непонятно считать ли изменение флага логической модификацией объекта. Если какая-то операция изменяет флаг, но в остальном никак не меняет состояние объекта, то она мутирующая или нет?
Ну это же тебе нужны объекты, позволяющие отменить deferred? Я наоборот считаю, что лучше без этого геморроя. Например, я не видел жалоб на flush в fclose.
KK>Забота об исключениях — это отдельная задача. Если она не является единственной задачей объекта, то согласно SRP объект не должен браться за её решение. EP>>Ну а к чему ты применяешь SRP в случае текущей реализации? К авто-генерированному деструктору? KK>Да. Деструктор — часть интерфейса. EP>>В чём существенная разница, между текущей реализацией и решением основанным на поддержке компилятора, которая делает делает одно не SRP-шным, а второе SRP-шным? KK>Разница в возможности выполнять две операции по отдельности без применения трюков.
Основной смысл deferred в том, чтобы как раз убрать необходимость в вызове отдельного flush.
Ок, это получилось. Теперь ты задаёшь вопрос — как же их выполнить по-отдельности.. — зачем??
KK>Которая кстати не отменяет наличие общей проблемы у обоих решений.
Какой?
EP>>>>Ну так ты же тоже согласен, что каких-то фатальных недостатоков нет. KK>>>У ручного управления ресурсами, например, их тоже нет. Но это как-то не очень мотивирует к применению такого подхода при возможности использовать более удобную альтернативу вроде RAII. EP>>1. надо ставить flush руками EP>>2. не надо ставить flush руками EP>>что более удобное KK>Для меня — ставить flush руками. Потому что альтернатива — неочевидный error prone код. Неявные действия хороши далеко не всегда, преобразования типов тому показательный пример.
Про преобразования типов не спорю — я бы предпочёл ключевое слово implicit, где explicit — это default.
Потеря контроля в любом виде, очевидно имеет как плюсы так и минусы.
Любая новая фича, позволяющая потерять частичку контроля, всегда встречается OMG дискуссиями:
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Т.е. ты намеренно занялся провокацией, о чем ниже признался, а когда тебя за провокацию забанили пытаешься выдать себя за невинную овечку? Какая то запредельная степень нарциссизма.
Ну вот ты неподалёку совершил прямое оскорбление, назвав меня вором на ровном месте а забанили меня. Это адекватно?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>С RAII писать код готовый к исключениям получится проще, чем без него. Например, в C#, Java, Python — RAII нет
RAII это паттерн, а вовсе не автоматический вызов деструктора при выходе из блока, и он вполне реализуем в перечисленных тобой языках. А конкретно в C# есть еще и конструкция using, которая в основном для RAII и предназначена.
Здравствуйте, Ночной Смотрящий, Вы писали:
EP>>С RAII писать код готовый к исключениям получится проще, чем без него. Например, в C#, Java, Python — RAII нет НС>RAII это паттерн, а вовсе не автоматический вызов деструктора при выходе из блока, и он вполне реализуем в перечисленных тобой языках. А конкретно в C# есть еще и конструкция using, которая в основном для RAII и предназначена.
EP>С RAII писать код готовый к исключениям получится проще, чем без него. Например, в C#, Java, Python — RAII нет, но зато есть различные workarounds на эту тему.
Открой ссылку, там и using, и try-with-resouces, и with.
Вопрос, как эти костыли помогают справляться с транзитивностью глубоко-вложенных в объекты ресурсов?
Вот где-то в глубине композиции добавляется новый ресурс, и теперь все классы хоть напрямую, хоть как-то косвенно включающие этот ресурс сами становятся ресурсами. То есть теперь все их использования нужно оборачивать в эти самые юсинги.
The compositional properties of RAII, however, differ significantly from scope bound resources in that it allows for full encapsulation of the resources behind an abstraction. With the dispose pattern for resource management, "being a resource" becomes a property that is transitive to composition.That is, any object that is composed using a resource that requires resource management effectively itself becomes a resource that requires resource management.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Открой ссылку, там и using, и try-with-resouces, и with.
Я открывал ссылку. И эта ссылка никак не доказывает то, что RAII использовать в перечисленных языках невозможно.
EP>Вот где-то в глубине композиции добавляется новый ресурс, и теперь все классы хоть напрямую, хоть как-то косвенно включающие этот ресурс сами становятся ресурсами. То есть теперь все их использования нужно оборачивать в эти самые юсинги.
А не надо ценные ресурсы заворачивать в глубину иерархии. А если ресурс не настолько ценный, что ему непременно нужно мгновенное освобождение, то GC совместо с вещами типа CriticalFinalizer вполне справляются с любыми иерархиями.
Ну и, в любом случае, подобные моменты никак не доказывают, что RAII использовать в перечисленных языках невозможно.
Re[2]: 1) Родовая травма: исключеиния в деструкторах
Это известная фича. В темном энтерпрайзе лечится двумя способами:
1. Если есть много легаси кода без исключений — мы просто отказываемся от исключений. Кода ненамного больше, в деструкторе ничего в принципе выкинуться не может. Хрестоматийный пример — Qt.
2. Если у нас мало легаси кода и много джедаев — делим исключения на две группы ожидаемых / неожиданных, оборачиваем все и не кидаем ожидаемые исключения в деструкторах. Если в деструкторе выкинулось неожиданное исключение (не которое неожиданное для программиста, а которое unchecked в терминологии джавы) — то падаем, как и полагается по спецификации. Примеров не знаю, но доходили слухи что так можно делать без серьезных последствий .
Использование настолько низкоуровневых примитивов не рекомендуется. Рекомендуется использовать высокоуровневые объекты, которые сами себе смарт поинтеры и создаются не через new, а на стеке. См. как это реализовано в Qt.
Здравствуйте, Ночной Смотрящий, Вы писали:
EP>>Открой ссылку, там и using, и try-with-resouces, и with. НС>Я открывал ссылку. И эта ссылка никак не доказывает то, что RAII использовать в перечисленных языках невозможно.
Если открывал ссылку которую я дал, то зачем мне рассказываешь про эти юсинги, которые по этой ссылке и находятся?
А конкретно в C# есть еще и конструкция using, которая в основном для RAII и предназначена.
EP>>Вот где-то в глубине композиции добавляется новый ресурс, и теперь все классы хоть напрямую, хоть как-то косвенно включающие этот ресурс сами становятся ресурсами. То есть теперь все их использования нужно оборачивать в эти самые юсинги. НС>А не надо ценные ресурсы заворачивать в глубину иерархии.
В C# это нельзя нормально сделать, поэтому не надо это делать
НС>Ну и, в любом случае, подобные моменты никак не доказывают, что RAII использовать в перечисленных языках невозможно.
The "resource acquisition is initialization" technique (TC++PL3 section 14.4). The basic idea is to represent a resource by a local object, so that the local object's destructor will release the resource. That way, the programmer cannot forget to release the resource.
TC++PL 14.4:
The technique for managing resources using local objects is usually referred to as ‘‘resource acquisition is initialization.’’ This is a general technique that relies on the properties of constructors and destructors and their interaction with exception handling.
И как реализовать его в перечисленных языках, опираясь на определение от автора?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Если открывал ссылку которую я дал, то зачем мне рассказываешь про эти юсинги, которые по этой ссылке и находятся?
Затем что ты сам то ли ссылку не читал, то ли не понял что там написано.
EP>В C# это нельзя нормально сделать, поэтому не надо это делать
Почему нельзя? Можно.
EP>И как реализовать его в перечисленных языках, опираясь на определение от автора?
Заменяем деструктор на dispose и получаем примерно тоже самое.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Заменяем деструктор на dispose и получаем примерно тоже самое.
а толку то? В чем ценность раии в плюсах? в том, что деструктор автоматом вызывается для объектов на стеке. в чем _относительная_ ценность IDisposable в шарпе? в том, что есть синтаксический сахар для вызова IDiposable.Dispose(). В чем полная бесполезность RAII для какого нить языка где нет пользовательского метода, который компилятор бы детерминировано вызывал? В том, что "деструктор" мне все равно ручкамивызвать нужно!
Здравствуйте, Ночной Смотрящий, Вы писали:
EP>>Если открывал ссылку которую я дал, то зачем мне рассказываешь про эти юсинги, которые по этой ссылке и находятся? НС>Затем что ты сам то ли ссылку не читал, то ли не понял что там написано.
Я же написал "workarounds". они и в подмётки не годятся RAII.
EP>>В C# это нельзя нормально сделать, поэтому не надо это делать НС>Почему нельзя? Можно.
Что можно? Справится с транзитивностью глубоко-вложенных в объекты ресурсов?
EP>>И как реализовать его в перечисленных языках, опираясь на определение от автора? НС>Заменяем деструктор на dispose и получаем примерно тоже самое.
When implementing this method, ensure that all held resources are freed by propagating the call through the containment hierarchy. For example, if an object A allocates an object B, and object B allocates an object C, then A's Dispose implementation must call Dispose on B, which must in turn call Dispose on C. An object must also call the Dispose method of its base class if the base class implements IDisposable.
То есть рукопашка по вызову dispose по всей иерархии наследования, по всей иерархии композиции, рукопашное проставление using, это примерно тоже самое?
С тем же успехом можно сказать что ручной вызов fopen/fclose это примерно тоже самое
В то время как деструкторы вызываются автоматически, и для вложенных объектов, и для родителей, для глобальных, и для стековых переменных.
Re[2]: 1) Родовая травма: исключеиния в деструкторах
Здравствуйте, Erop, Вы писали:
E>Ну это ещё пол-беды. Главная родовая травма деструкторов С++, это то, что их нельзя тормознуть. E>То есть, если пользователь в алерт-боксе, нажмёт не "Сохранить" или "не сохранять", а "отменить", то мы вообще не сможем никак этого поддержать в нашей прекрасной RAII-архитектуре
Опаньки ! Сиплюсник оказывается сам не знает что такое RAII
Вобщем тред специльно как по заказу — демонстрирует сколько разных мнений бывает у сиплюсников по поводу простецкой феньки.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>В то время как деструкторы вызываются автоматически, и для вложенных объектов, и для родителей, для глобальных, и для стековых переменных.
Надо определиться, какой код ты собираешься вложить в деструктор. Если освобождение памяти, то в дотнете это не нужно.
А если в деструкторе ты хочешь чего то разрушать или отпускать, то это уже гнусь, т.к. деструктор внезапно может кинуть исключение.
Само по себе это не создаёт проблемы, а вотреализация исключений в С++ скажем не благоприятствует такой тактике.
Что интересно, если ты отказываешься от кода который может кинуть исключение в деструкторе, то приходится вводить метод навроде Dispose. Опаньки !
то есть деструкторы годятся для
1. мелких фенек привязаных к скопу переменной, типа сброс флажка
2. управления ресурсами когда этот код никогда не может кинуть исключение
3. управления памятью
Итого, преимуществ перед менеджед IDisposable около нуля.
А если серьёзно, то я не увидел сильных аргументов против.
