On 12/15/2011 12:16 AM, jyuyjiyuijyu wrote:
> специально засаженные в код главное когда ты сам пишеш не делать таких ляпов > имхо очень тупая проверка и тест в целом что можно после этого сказать о > соискателе ? ничего
Тест достаточно хороший. Если это тест. И ляп такой сделать очень просто.
Достаточно не вдумываться в функциональность предка и иметь привычку
инициализировать в инициализаторах.
На самом деле тут этот AsyncActionBase уже закладывает своим дизайном
такую ошибку. У него нет дефолтного конструктора, так что указать Callable
ему нужно, и именно в инициализаторе.
On 12/15/2011 01:00 PM, Masterkent wrote:
> ежели они всё-таки выполняются, то это будет свидетельством того, что программа > ведёт себя непредсказуемым образом; по правилам C++11 такой деструктор имеет > спецификацию исключений noexcept(true) и поэтому попытка выброса исключения из > него должна будет привести к незамедлительному вызову функции std::terminate).
Всё это правильно, но логика кода написанного вроде бы диктует, что пользователь
ожидает от программы другое поведение.
Оно конечно, нужно бы иметь формальную спецификацию ...
1) Конструктор AsyncActionBase: если там возникнет исключение (которое генерится TST_LE_CHECK), деструктор этого обьекта вызван не будет.
2) Деструктор AsyncActionBase: он бросается исключениями, ай-яй-яй как нехорошо
3) Вызов виртуального метода Call() по сути дела из конструктора (хоть и в другой нитке), ай-яй-яй как нехорошо.
ЗЫ. Специально не смотрел ответы выше по нитке. Если дубликаты — звиняйте.
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, Lorenzo_LAMAS, Вы писали:
RNS>>Имена неговорящие, комментариев нет, какие-то константы кругом.
L_L>Ну и что, ты бы на собеседовании так и сказал, код у вас какой-то голимый и некрасивый, хер разберешь, мне в лом?
Как минимум, можно спросить, всегда они так пишут, или это они специально в тестовых целях написали ужос-ужос?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, antonio_banderas, Вы писали:
_>Здравствуйте, Alex Dav, Вы писали:
_>О, никто про это не написал: Exception(const wchar_t* szwText) : m_wstrText(szwText), если const wchar_t* szwText будет 0, то упадет, std::wstring не любит ноль принимать в качестве const wchar_t*. Т.к. в этой программе сюда ноль точно не передается, то ошибка потенциальная.
А std::basic_string приводящий к падению если в конструктор передали 0-й указатель не смущает? Если это и считать ошибкой, то не класса Exception, а, как раз, std::basic_string'а.
Здравствуйте, rg45, Вы писали:
R>Здравствуйте, k.o., Вы писали:
R>>>Это так, но при этом деструктор лучше делать защищенным, все-таки, иначе чревато. Саттер и Александреску в своей книге дают рекомендацию, которая выглядит буквально так: "Делайте деструкторы базовых классов открытыми и виртуальными либо защищенными и невиртуальными".
KO>>Теоретически, всё верно, но на практике оказалось что это не так уж и чревато: большая система, куча legacy кода с более чем 10 летней историей, куча абстрактных классов без виртуальных или защищенных деструкторов и ни одной вызванной этим ошибки. В общем, правильная архитектура оказалась полезней следованию советов из книжки, которой ещё не было когда этот код начинали писать.
R>Я бы согласился, если бы речь шла о классах, в принципе не проектировавшихся для полиморфного использования. Примеров таких классов великое множество: std::string, std::vector, boost::shared_ptr и пр. и др. Но когда речь идет об абстрактных классах, то лучше не провоцировать ошибки там, где от них не трудно защититься. Я понимаю, legacy код, ошибки молодости и все такое... Но нельзя же это утверждать как норму.
Я не утверждал что это норма, моё утверждение, дословно, было таким:
Значение виртуальных деструкторов сильно преувеличено, при использовании умных указателей, знающих как удалять объект (например, boost::shared_ptr/std::shared_ptr) можно прекрасно обходиться без виртуальных деструкторов.
Ну и основано оно было на личном опыте, когда несмотря на "legacy код, ошибки молодости и все такое" ошибок связанных с отсутствием виртуальных деструкторов не было. Собственно, смысл в том, что несмотря на то, что совет из вышеупомянутой книги, в принципе, верный, вероятность ошибки при его невыполнении, всё-равно, ничтожна.
Здравствуйте, k.o., Вы писали:
KO>Здравствуйте, antonio_banderas, Вы писали:
_>>Здравствуйте, Alex Dav, Вы писали:
_>>О, никто про это не написал: Exception(const wchar_t* szwText) : m_wstrText(szwText), если const wchar_t* szwText будет 0, то упадет, std::wstring не любит ноль принимать в качестве const wchar_t*. Т.к. в этой программе сюда ноль точно не передается, то ошибка потенциальная.
KO>А std::basic_string приводящий к падению если в конструктор передали 0-й указатель не смущает? Если это и считать ошибкой, то не класса Exception, а, как раз, std::basic_string'а.
Вообще, смущает, нехорошо так себя вести (про std::basic_string). Возможно, их можно оправдать в плане оптимизации быстродействия, типа зачем лишнюю проверку ставить (хотя польза от такой оптимизации сомнительная), больше оправданий я тут не вижу.
Но в любом случае, std::basic_string имеется такой, какой есть, и давать ему в конструктор не проверяя полученный извне const wchar_t* — это потенциальная возможность нарваться на падение.
Здравствуйте, antonio_banderas, Вы писали:
_>Здравствуйте, k.o., Вы писали:
KO>>Здравствуйте, antonio_banderas, Вы писали:
_>>>Здравствуйте, Alex Dav, Вы писали:
_>>>О, никто про это не написал: Exception(const wchar_t* szwText) : m_wstrText(szwText), если const wchar_t* szwText будет 0, то упадет, std::wstring не любит ноль принимать в качестве const wchar_t*. Т.к. в этой программе сюда ноль точно не передается, то ошибка потенциальная.
KO>>А std::basic_string приводящий к падению если в конструктор передали 0-й указатель не смущает? Если это и считать ошибкой, то не класса Exception, а, как раз, std::basic_string'а.
_>Вообще, смущает, нехорошо так себя вести (про std::basic_string). Возможно, их можно оправдать в плане оптимизации быстродействия, типа зачем лишнюю проверку ставить (хотя польза от такой оптимизации сомнительная), больше оправданий я тут не вижу.
_>Но в любом случае, std::basic_string имеется такой, какой есть, и давать ему в конструктор не проверяя полученный извне const wchar_t* — это потенциальная возможность нарваться на падение.
Ну, т.е., в данном отношении, код не хуже чем в стандартной библиотеке. Вообще это обычное дело для библиотек в C и C++ — при невыполнении предусловий получаем UB.
Здравствуйте, k.o., Вы писали:
KO>>>Теоретически, всё верно, но на практике оказалось что это не так уж и чревато...
Не ради флейма... Просто тема интересная, для меня по крайней мере. Цитаты немного перекроЮ для связности мысли...
KO>...моё утверждение, дословно, было таким: KO>
KO>Значение виртуальных деструкторов сильно преувеличено, при использовании умных указателей, знающих как удалять объект (например, boost::shared_ptr/std::shared_ptr) можно прекрасно обходиться без виртуальных деструкторов.
Тут +1 и никаких возражений с моей стороны
R>>...Но когда речь идет об абстрактных классах, то лучше не провоцировать ошибки там, где от них не трудно защититься. Я понимаю, legacy код, ошибки молодости и все такое... Но нельзя же это утверждать как норму. KO>Я не утверждал что это норма... KO>...Собственно, смысл в том, что несмотря на то, что совет из вышеупомянутой книги, в принципе, верный, вероятность ошибки при его невыполнении, всё-равно, ничтожна.
А вот тут как-то... С одной стороны, совет вроде и принимается, с другой — необходимость его соблюдения поставлена под сомнение — еще чуть-чуть и его несоблюдение становится нормой.
"вероятность ошибки при его невыполнении ничтожна" только при соблюдении некоторых условий: 1) нормальная архитектура и 2) пользователем классов является сам разработчик (и никто другой). А что если по прошествии нескольких месяцев (или лет) одно из этих условий окажется нарушенным? Ошибки, которые могут при этом возникнуть могут быть достаточно коварными.
Я вот, например, при проектировании нового класса давно выработал привычку представлять, что его пользователем может быть кто угодно: и Криворукий и Безголовый, даже в тех случаях когда мне кажется, что кроме меня этими классами никто пользоваться не будет. И вы знаете, при таком подходе обычно и появляются сущности, которые хочется использовать повторно в разных проектах.
Конечно, стопроцентную защиту от дурака сделать трудно, если вообще возможно, дурак все равно найдет способ выстрелить себе в ногу, и все равно при этом будет искать виноватых вокруг себя. И при любом проектировании, имхо, следует стремиться, чтобы, во-первых, оставить дураку минимум возможностей выстрелить себе в ногу, а, во-вторых, когда он таки выстрелит, быстро показать ему что дурак — он сам.
--
Не можешь достичь желаемого — пожелай достигнутого.
On 12/15/2011 02:50 PM, B0FEE664 wrote:
> К сожалению я должен признать, что скорее всего я ошибся или мои знания > устарели. Я помню, что этот вопрос я изучал для студии Visual Studio 6.0 (1998) > и *мне кажется*, что была специальная опция, которая позволяла отключить > создание vtable до вызова конструктора. Вероятно я ошибаюсь.
VTable -то создаётся ещё при старте программы. А вот указатели на них
инициализируются в конструкторе. И никогда не было чего-то другого.
Здравствуйте, rg45, Вы писали:
R>>>...Но когда речь идет об абстрактных классах, то лучше не провоцировать ошибки там, где от них не трудно защититься. Я понимаю, legacy код, ошибки молодости и все такое... Но нельзя же это утверждать как норму. KO>>Я не утверждал что это норма... KO>>...Собственно, смысл в том, что несмотря на то, что совет из вышеупомянутой книги, в принципе, верный, вероятность ошибки при его невыполнении, всё-равно, ничтожна.
R>А вот тут как-то... С одной стороны, совет вроде и принимается, с другой — необходимость его соблюдения поставлена под сомнение — еще чуть-чуть и его несоблюдение становится нормой.
Ну а с третьей стороны
There is no substitute for intelligence, experience, common sense, and good taste.
Если пункт 1 не выполняется, то проблем и так будет много, а вот 2-е условие как раз необязательно. В том-то и дело, что у меня перед глазами проект с многолетней историей, прошедший через руки множества разработчиков самой разной квалификации, и, несмотря на это, никаких проблем по части деструкторов. Честно говоря, сам был крайне удивлен когда столкнулся с таким вопиющим нарушением "рекомендаций лучших собаководов". Единственный, пожалуй, нюанс это то, что этот код не относится к API, и совсем уж дебилов к нему можно не подпускать. Если же с кодом будут работать сторонние разработчики, этот совет будет более актуальным, этакий "Framework Design Guideline" для C++.
Здравствуйте, antonio_banderas, Вы писали:
KO>>А std::basic_string приводящий к падению если в конструктор передали 0-й указатель не смущает? ;) Если это и считать ошибкой, то не класса Exception, а, как раз, std::basic_string'а.
_>Вообще, смущает, нехорошо так себя вести (про std::basic_string). Возможно, их можно оправдать в плане оптимизации быстродействия, типа зачем лишнюю проверку ставить (хотя польза от такой оптимизации сомнительная), больше оправданий я тут не вижу.
_>Но в любом случае, std::basic_string имеется такой, какой есть, и давать ему в конструктор не проверяя полученный извне const wchar_t* — это потенциальная возможность нарваться на падение.
Это всё нормально. Есть правила — нельзя делить на нуль, нельзя брать вещественнозначный корень от отрицательного числа, нельзя разыменовывать нулевой указатель. Нельзя вызывать библиотечные или свои функции с такими параметрами, которые приведут к делению на нуль, взятию корня из отрицательного числа, разыменованию нулевого указателя или вызову библиотечных функций с такими параметрами, которые приведут.
Всем известно, что конструктор std::string с параметром char const * попытается скопировать себе оттуда содержимое, пока не наткнётся на завершающий ноль. И никому не приходит в голову передавать нулевой указатель, невалидный указатель или указатель на строку, не завершённую нулём. А если кому-то куда-то приходит, то, во-первых, это не голова; и во-вторых, сами виноваты.
Здравствуйте, Masterkent, Вы писали:
M>Если контора предлагает хорошие условия, то почему бы и нет? Ну а тест, разумеется, полезен для отсева явных чайников и неадекватов (если кандидат с оттопыренными пальцами начинает устраивать истерики по поводу целесообразности первичного теста и рассказывать о том, как бы он поступил на месте работодателя, такого надо сразу пинками под зад гнать).
У меня летом приходило по 3 предложения о работе в день, если бы я на каждого тратил по неделе...
С другой стороны, если вы не ищете работу сейчас и тут появилась вакансия в компании-мечте, то можно и сделать — в качестве развлечения.
Здравствуйте, MasterZiv, Вы писали:
>> К сожалению я должен признать, что скорее всего я ошибся или мои знания >> устарели. Я помню, что этот вопрос я изучал для студии Visual Studio 6.0 (1998) >> и *мне кажется*, что была специальная опция, которая позволяла отключить >> создание vtable до вызова конструктора. Вероятно я ошибаюсь.
MZ>VTable -то создаётся ещё при старте программы. А вот указатели на них MZ>инициализируются в конструкторе. И никогда не было чего-то другого.
The Microsoft-specific __declspec(novtable) option instructs the compiler not to initialize the virtual function pointer in the constructor of the given object. Normally, this would be a "bad thing." However, for abstract classes, there's no reason to initialize the pointer, because it will always be properly initialized when a concrete class derived from the object is constructed.
By the way, this option is misnamed. It sounds like it removes the vtable itself, which isn't at all true. The option should be called noinitvtable.
Здравствуйте, rg45, Вы писали: R>Я вот, например, при проектировании нового класса давно выработал привычку представлять, что его пользователем может быть кто угодно: и Криворукий и Безголовый, даже в тех случаях когда мне кажется, что кроме меня этими классами никто пользоваться не будет. И вы знаете, при таком подходе обычно и появляются сущности, которые хочется использовать повторно в разных проектах.
зачем когда делаеш для себя писать такой огромный оверхед ? если бы я думал что любой безголовый сможет моим классом пользоваться то я бы все время тратил на укрепление брони а не на решение задачи вот например когда пишеш код для себя можно вообще очень тонкий код писать решающий только твою задачу который упадет при неправильном использовании но это как говорится сам дурак с нулевым оверхедом имхо это нормально если ты не пишеш библиотеку для всеобщего пользования я вообще не представляю как решать задачу и все время тратить на укреплении брони от фантомного вредителя так рождаются уроды там где они не нужны
