Здравствуйте, B0FEE664, Вы писали:
BFE>Что лучше variant 1 или 2? BFE>И вообще, что бы вы сказали увидев это в проекте?
Зачем так сложно-то?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Caracrist, Вы писали:
C>если у тебя pop_front упадёт, то catch тебе скорее всего уже не поможет, C>а, иначе, зачем все эти сложности?
Это пример. В реальном коде всё много сложнее. Меня, собственно, интересует не то, как цикл изменить, а то , что вместо этой слишком сложной конструкции подставить:
Здравствуйте, B0FEE664, Вы писали:
BFE>А как надо? (В рамках старого стандарта).
Да хоть бы и в рамках старого.
Зачем-то в одном месте собраны и RAII и обработчик прерывания, и всё это ещё в цикл зачем-то засунуто...
Никак нельзя как-то концептуально проще быть?
Попробуй объяснить, что конкретно тебе надо-то?
Пройтись по списку, и выкинуть из него элементы, на которых падает какой-то метод?
Вызвать у всех элементов списка метод, даже если какой-то элемент кинет исключение?
Что-то ещё?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, B0FEE664, Вы писали:
BFE>Макросы не предлагать.
BFE>Что лучше variant 1 или 2?
Оба хуже
BFE>И вообще, что бы вы сказали увидев это в проекте?
"Я вам в отцы гожусь", сказал бы настоящий петербуржец.
Проще надо быть, и люди потянутся.
Логика работы ведь какая:
— дёрнуть f() у объекта, находящегося в голове списка
— диагностировать исключение
— удалить объект из головы
Если объекту неважно, лежит он в списке на момент вызова, — то сперва извлечь, потом дёрнуть.
Если важно, то так прямо и написать
while(!theList.empty())
{
A& obj = theList.front();
try { obj.f(); }
catch(std::exception const& e) { report_error(e); }
catch(...) { assertion_fault("неизвестное исключение! мы все умрём!"); throw; } // нет смысла дальше молотить наш цикл
theList.pop_front(); // если исключение вылетит отсюда (?!), то тоже нет смысла дальше молотить цикл
}
Здравствуйте, B0FEE664, Вы писали:
BFE>>>Неужели в boost нет ничего более подходящего? EP>>Boost.ScopeExit BFE>Нет, макросы мне не нужны.
Неужели если бы выбор стоял между тем что было в первом сообщении, и BOOST_SCOPE_EXIT, ты бы выбрал boost::shared_ptr, в котором лишние атомарные инструкции, лишний type erasure и менее читабельный код?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
BFE>>>>Неужели в boost нет ничего более подходящего? EP>>>Boost.ScopeExit BFE>>Нет, макросы мне не нужны.
EP>Неужели если бы выбор стоял между тем что было в первом сообщении, и BOOST_SCOPE_EXIT, ты бы выбрал boost::shared_ptr, в котором лишние атомарные инструкции, лишний type erasure и менее читабельный код?
Вы ещё про заказ памяти посредством new внутри shared_count забыли
А как вы думаете, зачем я написал первую строчку в первом сообщении?
К счастью, выбор так не стоит, а если бы и стоял, то — да, предпочитаю стандартную практику без макросов см. документацию.
PS: Но кончилось всё как обычно: написал ещё один класс который только и делает, что pop_front в деструкторе вызывает.
Здравствуйте, B0FEE664, Вы писали:
EP>>Неужели если бы выбор стоял между тем что было в первом сообщении, и BOOST_SCOPE_EXIT, ты бы выбрал boost::shared_ptr, в котором лишние атомарные инструкции, лишний type erasure и менее читабельный код? BFE>Вы ещё про заказ памяти посредством new внутри shared_count забыли
new и так уже нужен при type erasure.
BFE>А как вы думаете, зачем я написал первую строчку в первом сообщении?
Сообщение с вопросом про boost, я прочитал намного позже первого, поэтому был не в контексте.
BFE>PS: Но кончилось всё как обычно: написал ещё один класс который только и делает, что pop_front в деструкторе вызывает.
Это кстати намного лучше shared_ptr, а при вероятности реиспользования (если получится дать хорошее имя) даже лучше чем scope exit.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>Неужели если бы выбор стоял между тем что было в первом сообщении, и BOOST_SCOPE_EXIT, ты бы выбрал boost::shared_ptr, в котором лишние атомарные инструкции, лишний type erasure и менее читабельный код? BFE>>Вы ещё про заказ памяти посредством new внутри shared_count забыли EP>new и так уже нужен при type erasure.
type erasure можно и на ссылках смастерить. Впрочем зачем type erasure у shared_ptr мне не понятно.
BFE>>PS: Но кончилось всё как обычно: написал ещё один класс который только и делает, что pop_front в деструкторе вызывает. EP>Это кстати намного лучше shared_ptr, а при вероятности реиспользования (если получится дать хорошее имя) даже лучше чем scope exit.
Как показывает практика, вероятность реиспользования таких классов стремится к нулю.
Здравствуйте, B0FEE664, Вы писали:
EP>>>>Неужели если бы выбор стоял между тем что было в первом сообщении, и BOOST_SCOPE_EXIT, ты бы выбрал boost::shared_ptr, в котором лишние атомарные инструкции, лишний type erasure и менее читабельный код? BFE>>>Вы ещё про заказ памяти посредством new внутри shared_count забыли EP>>new и так уже нужен при type erasure. BFE>type erasure можно и на ссылках смастерить. Впрочем зачем type erasure у shared_ptr мне не понятно.
Ну а как без type erasure сохранить произвольный deleter, не меняя тип shared_ptr<void>?
Здравствуйте, B0FEE664, Вы писали:
BFE>PS: Но кончилось всё как обычно: написал ещё один класс который только и делает, что pop_front в деструкторе вызывает.
А зачем?
Можешь понятно пояснить, что тебе надо-то было?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Evgeny.Panasyuk, Вы писали:
BFE>>type erasure можно и на ссылках смастерить. Впрочем зачем type erasure у shared_ptr мне не понятно. EP>Ну а как без type erasure сохранить произвольный deleter, не меняя тип shared_ptr<void>?