Я бы тут отметил, что упоминать в каждом классе «test_case» как-то выглядит излишним. Они же и так в тестах и не будут использоваться нигде вне них, зачем это повторять?
Помнится, изначально казалось, что в тесте потребуется больше классов, поэтому-то и появились суффиксы _mbox_case_t и _test_case_t. Но потом выяснилось, что больше ничего и не нужно, но избавиться от префиксов в голову уже не пришло.
Хороший пример применения шаблонов в небиблиотечном коде, спасибо!
Вам спасибо!
можно добавить просто ещё один аргумент шаблона
Можно было бы. Но это явно бы сделало реализацию теста более сложной. Тем более, что нам нужно ограничиваться тем подмножеством C++11, которое реализовано в MSVC++12.0. Там фокус с static auto functor() не так-то просто провернуть.
А в описанной реализации небольшая копипаста дает простоту и независимость от ограничений старых C++ компиляторов.
Генератор может быть полезен когда количество возможных сочетаний тестируемых параметров измеряется сотнями, а то и тысячами. Для десяти же вариантов (как в статье) применение генератора — это уже из пушки по воробьям.
Касательно имен и читаемости я бы отметил три аспекта.
1. Удачность и понятность конкретных имен классов/методов. Например, pfn_test_case_t для меня, как для прошедшего через венгерскую нотацию, вполне нормальное и читабельное имя. Но вот для тех, кто помоложе и про венгурку не слышал, буквосочетание pfn может быть совершенно нечитаемым. Поэтому и возник вопрос, но он повис в воздухе без ответа. Что наводит на мысли о том, что конструктива автор комментария явно не предполагал изначально.
2. Следование общепринятым стандартам кодирования. Например, если бы кто-то в Java или в C# коде начал использовать только snake_case, то это должно было бы вызвать нарекания у других Java/C# разработчиков, т.к. для этих языков уже есть давно устоявшиеся соглашения об именовании. Но в C++ же такого нет, в C++ вполне благополучно живут и развиваются проекты, которые используют snake_case, а так же проекты, которые используют CamelCase. И даже проекты, которые используют Camel_With_Underscores_Case. Поэтому в C++ коде претензии к стилю оформления — это чистой воды вкусовщина. На которую вообще не следовало бы обращать внимания. Но поди ж ты :(
3. У меня лично возврат к snake_case был вполне себе обоснованным и, где-то, выстраданным решением после многих лет использования CamelCase. Так что использование snake_case — это вполне себе обдуманное и взвешенное решение. Я могу понять, что кому-то такой стиль именования не нравится. Но если snake_case мне объективно помогает, то чисто вкусовые претензии по поводу отсутствия CamelCase просто не принимаются во внимание.
Может давайте поговорим не об абстрактных «ложноотрицательных падения», а о более приземленных вещах. Вот, например, берем тест для so_unsubscribe_deadletter_handler из статьи. Пишем его нормальный вариант, запускаем. Получаем успешный результат теста.
Запускаем еще раз. И мы можем оказаться в двух ситуациях.
1. Тест «упал». Значит есть вероятность, что тест был написан правильно.
2. Тест «не упал». Значит в тесте 100% есть ошибка.
Соответственно, если в результате провоцирования неправильной работы теста (путем комментирования отдельных фрагментов, добавления дополнительных операций, изменения параметров операций и т.д.) возникают ситуации №2, то, как по мне, это гораздо лучше, чем полный отказ от попыток проверки корректности работы тестов.
А вы как предлагаете проверять корректность тестов?
Справедливости ради нужно сказать, что using не поможет с именами методов, к примеру.
Да и тестов, которые не работают, пользу нет. Так что если тесты есть, то они должны быть рабочими.
Другое дело, что споры о code convention начинаются тогда, когда о сути и смысле статьи сказать нечего. И уж тем более странно видеть споры о code convention для C++, в котором нет официального и общепринятого соглашения об именовании. И в котором давно и успешно сосуществуют snake_case, CamelCase и Camel_With_Underscore_Case.
В вашем комментарии прекрасно все, от начала и до конца.
Хочется, однако, прояснить один момент: вы когда нибудь в глаза видели названия классов, методов и функций из стандартной библиотеки С++? Ну или из Boost-а?
Я, обычно, каждый новый тест провоцирую на «падение». Если создаешь в тесте условие, при котором тест должен упасть, а он не падает, значит сам тест нужно тестировать. Где-то один раз из 10-15 это приходится делать.
Прямое сравнение с Erlang-ом неправомочно по двум причинам.
Во-первых, Erlang реализует для своих процессов вытесняющую многозадачность. Поэтому в Erlang-е процесс может «заснуть» на receive и это не повлияет на другие процессы. В SObjectizer-е для агентов, в общем случае, реализуется не вытесняющая, а кооперативная многозадачность. Поэтому агент должен отдать управление назад SObjectizer-у после того, как завершит обработку очередного сообщения. Т.е. должен вернуться из своего текущего обработчика. Из-за этого уже получается, что если в SO-5 агент хочет отослать сообщение другому агенту и подождать ответ, то агенту нужно два метода-обработчика (в одном он отсылает свой запрос, в другом получает ответ) + кухня по подписке-отписке. Ну и при наличии тайм-аутов это еще более усложняется.
С Erlang-ом в этом плане можно сравнивать такие реализации Модели Акторов, в которых акторы представлены отдельными потоками выполнения. Например, каждому актору выдается своя нить ОС или своя зеленая нить/файбер. Скажем, в SO-5 вы можете привязать агентов к диспетчерам так, что у каждого агента будет своя рабочая нить. Тогда вместо манипуляций с подпиской/отпиской можно будет использовать CSP-каналы (mchains). И ожидание ответов может быть записано как:
Во-вторых, SObjectizer использует для взаимодействия агентов механизм publish-subscribe. Он в принципе отличается от того, что принято в Модели Акторов вообще (там жестко один почтовый ящик у актора) и в Erlang-е в частности (там одна единственная очередь сообщений для процесса да плюс еще и selective receive). Поэтому показанный пример имело бы смысл сравнивать с реализацией взаимодействия через какой-то MQ-шный брокер и несколько топиков в этом брокере.
Ну и заодно хочу спросить. А вот, допустим, в Erlang-е вы отослали сообщения трем процессам и вам нужно дождаться ответов от них. Только один ответ нужно ждать не более N секунд, второй — не более M, третий не более L. Как между собой соотносятся N, M и L неизвестно. Так же вы должны обрабатывать ответные сообщения в том порядке, в котором они приходят (а не сперва от первого, затем от второго, затем от третьего). Как это будет выглядеть в Erlang-е? Полагаю, в виде цикла, на каждой итерации которого вы будете вынуждены вычислять наименьший из оставшихся тайм-аутов и это значение будете подставлять в after timeout.
Если это тот персонаж, о котором я думаю, то на linux.org.ru он давно известен. И те, кто его знают, воздерживаются от попыток конструктивного общения с ним. Если же попытаться с ним поговорить как с адекватным человеком, то получается, например, вот так. Можно обратить особое внимание на пассажи вида:
Неверно, никто этого не сделал, да и даже если сделал — из этого ничего не следует. Нигде обратное не утверждалось, да и вообще разговор был не об этом.
И это еще не самый худший образчик его мыслеизложения.
Соображаете что такое доказательство или опровержение?
Что-то вы совсем того, давайте я вам еще раз объясню, как обстоит дело. Может хоть в этот раз вы поймете что к чему.
Представьте, что вы доктор и к вам на прием приходит больной. Он говорит, что у него болит нога. А вы просто советуете делать примочки.
Все. Вы не выяснили, что именно болит, ни симптомов, ни анализов, ни общего состояния пациента, ни истории его болезней. Ничего. Вы даже не рассказали, что за примочки и как их применять (количество, длительность, состав и пр.).
Вы просто сказали «Я рекомендую делать примочки» и все.
Далее у вас начали выяснять, а что же это за примочки-то такие. Для чего, что делают, в каких условиях могут применяться. Но вместо того, чтобы дать конкретный ответ, вы разошлись на тему обиженной невинности и своем нежелании говорить о деталях, т.к. по-вашему, детали — это не суть. Главное же — это идея. Любой разумный человек поймет, что в идее делать примочки, когда болит нога, есть здравое зерно.
Вот точно так же и с вашими обертками. Без знания того, что за обертка, для чего, как работает, какие последствия имеет и пр. деталей невозможно определить, где обертка может применяться, а где нет. Поэтому из вас и тянули конкретику. А когда вытянули, все стало понятно. И с вами, и с вашими обертками.
И тут нечего опровергать. Есть просто конкретный рецепт и список конкретных противопоказаний к нему.
Так что умойтесь.
Вы это, когда разговариваете с оппонентом в подобном тоне, перестаньте жаловаться на оскорбления в свой адрес. Тут уже «либо крестик сними, либо трусы надень».
А по поводу MALLOC_TRY/MALLOC_EXCEPT — вы серьезно хотите обсудить качество этого говноподелия?
Человек серьезно воспринимающий это поток сознания — вероятно полный дурак
Вы понимаете, почему термин «архитектор-астронавт» пошел в массы? Потому что это узнаваемый образ. Спольски только сумел мастерски его описать, но он его не выдумывал, а подсмотрел в жизни. Так что вы можете не верить в существование архитекторов-астронавтов, но ваше неверие ни на что, к счастью, не влияет. Вы, как раз, подтверждаете их существование.
Можно было бы. Но это явно бы сделало реализацию теста более сложной. Тем более, что нам нужно ограничиваться тем подмножеством C++11, которое реализовано в MSVC++12.0. Там фокус с static auto functor() не так-то просто провернуть.
А в описанной реализации небольшая копипаста дает простоту и независимость от ограничений старых C++ компиляторов.
1. Удачность и понятность конкретных имен классов/методов. Например, pfn_test_case_t для меня, как для прошедшего через венгерскую нотацию, вполне нормальное и читабельное имя. Но вот для тех, кто помоложе и про венгурку не слышал, буквосочетание pfn может быть совершенно нечитаемым. Поэтому и возник вопрос, но он повис в воздухе без ответа. Что наводит на мысли о том, что конструктива автор комментария явно не предполагал изначально.
2. Следование общепринятым стандартам кодирования. Например, если бы кто-то в Java или в C# коде начал использовать только snake_case, то это должно было бы вызвать нарекания у других Java/C# разработчиков, т.к. для этих языков уже есть давно устоявшиеся соглашения об именовании. Но в C++ же такого нет, в C++ вполне благополучно живут и развиваются проекты, которые используют snake_case, а так же проекты, которые используют CamelCase. И даже проекты, которые используют Camel_With_Underscores_Case. Поэтому в C++ коде претензии к стилю оформления — это чистой воды вкусовщина. На которую вообще не следовало бы обращать внимания. Но поди ж ты :(
3. У меня лично возврат к snake_case был вполне себе обоснованным и, где-то, выстраданным решением после многих лет использования CamelCase. Так что использование snake_case — это вполне себе обдуманное и взвешенное решение. Я могу понять, что кому-то такой стиль именования не нравится. Но если snake_case мне объективно помогает, то чисто вкусовые претензии по поводу отсутствия CamelCase просто не принимаются во внимание.
Потом берем, и меняем
на
Запускаем еще раз. И мы можем оказаться в двух ситуациях.
1. Тест «упал». Значит есть вероятность, что тест был написан правильно.
2. Тест «не упал». Значит в тесте 100% есть ошибка.
Соответственно, если в результате провоцирования неправильной работы теста (путем комментирования отдельных фрагментов, добавления дополнительных операций, изменения параметров операций и т.д.) возникают ситуации №2, то, как по мне, это гораздо лучше, чем полный отказ от попыток проверки корректности работы тестов.
А вы как предлагаете проверять корректность тестов?
Да и тестов, которые не работают, пользу нет. Так что если тесты есть, то они должны быть рабочими.
Другое дело, что споры о code convention начинаются тогда, когда о сути и смысле статьи сказать нечего. И уж тем более странно видеть споры о code convention для C++, в котором нет официального и общепринятого соглашения об именовании. И в котором давно и успешно сосуществуют snake_case, CamelCase и Camel_With_Underscore_Case.
А можно еще вопрос: а вы на C++ давно программируете? И вообще: программируете ли вы на C++?
Хочется, однако, прояснить один момент: вы когда нибудь в глаза видели названия классов, методов и функций из стандартной библиотеки С++? Ну или из Boost-а?
Во-первых, Erlang реализует для своих процессов вытесняющую многозадачность. Поэтому в Erlang-е процесс может «заснуть» на receive и это не повлияет на другие процессы. В SObjectizer-е для агентов, в общем случае, реализуется не вытесняющая, а кооперативная многозадачность. Поэтому агент должен отдать управление назад SObjectizer-у после того, как завершит обработку очередного сообщения. Т.е. должен вернуться из своего текущего обработчика. Из-за этого уже получается, что если в SO-5 агент хочет отослать сообщение другому агенту и подождать ответ, то агенту нужно два метода-обработчика (в одном он отсылает свой запрос, в другом получает ответ) + кухня по подписке-отписке. Ну и при наличии тайм-аутов это еще более усложняется.
С Erlang-ом в этом плане можно сравнивать такие реализации Модели Акторов, в которых акторы представлены отдельными потоками выполнения. Например, каждому актору выдается своя нить ОС или своя зеленая нить/файбер. Скажем, в SO-5 вы можете привязать агентов к диспетчерам так, что у каждого агента будет своя рабочая нить. Тогда вместо манипуляций с подпиской/отпиской можно будет использовать CSP-каналы (mchains). И ожидание ответов может быть записано как:
Во-вторых, SObjectizer использует для взаимодействия агентов механизм publish-subscribe. Он в принципе отличается от того, что принято в Модели Акторов вообще (там жестко один почтовый ящик у актора) и в Erlang-е в частности (там одна единственная очередь сообщений для процесса да плюс еще и selective receive). Поэтому показанный пример имело бы смысл сравнивать с реализацией взаимодействия через какой-то MQ-шный брокер и несколько топиков в этом брокере.
Ну и заодно хочу спросить. А вот, допустим, в Erlang-е вы отослали сообщения трем процессам и вам нужно дождаться ответов от них. Только один ответ нужно ждать не более N секунд, второй — не более M, третий не более L. Как между собой соотносятся N, M и L неизвестно. Так же вы должны обрабатывать ответные сообщения в том порядке, в котором они приходят (а не сперва от первого, затем от второго, затем от третьего). Как это будет выглядеть в Erlang-е? Полагаю, в виде цикла, на каждой итерации которого вы будете вынуждены вычислять наименьший из оставшихся тайм-аутов и это значение будете подставлять в after timeout.
И это еще не самый худший образчик его мыслеизложения.
Сишки-Балабол сюда приплыл.Не там вы собрались прекрасное искать.
Представьте, что вы доктор и к вам на прием приходит больной. Он говорит, что у него болит нога. А вы просто советуете делать примочки.
Все. Вы не выяснили, что именно болит, ни симптомов, ни анализов, ни общего состояния пациента, ни истории его болезней. Ничего. Вы даже не рассказали, что за примочки и как их применять (количество, длительность, состав и пр.).
Вы просто сказали «Я рекомендую делать примочки» и все.
Далее у вас начали выяснять, а что же это за примочки-то такие. Для чего, что делают, в каких условиях могут применяться. Но вместо того, чтобы дать конкретный ответ, вы разошлись на тему обиженной невинности и своем нежелании говорить о деталях, т.к. по-вашему, детали — это не суть. Главное же — это идея. Любой разумный человек поймет, что в идее делать примочки, когда болит нога, есть здравое зерно.
Вот точно так же и с вашими обертками. Без знания того, что за обертка, для чего, как работает, какие последствия имеет и пр. деталей невозможно определить, где обертка может применяться, а где нет. Поэтому из вас и тянули конкретику. А когда вытянули, все стало понятно. И с вами, и с вашими обертками.
И тут нечего опровергать. Есть просто конкретный рецепт и список конкретных противопоказаний к нему.
Вы это, когда разговариваете с оппонентом в подобном тоне, перестаньте жаловаться на оскорбления в свой адрес. Тут уже «либо крестик сними, либо трусы надень».
А по поводу MALLOC_TRY/MALLOC_EXCEPT — вы серьезно хотите обсудить качество этого говноподелия?
Вы понимаете, почему термин «архитектор-астронавт» пошел в массы? Потому что это узнаваемый образ. Спольски только сумел мастерски его описать, но он его не выдумывал, а подсмотрел в жизни. Так что вы можете не верить в существование архитекторов-астронавтов, но ваше неверие ни на что, к счастью, не влияет. Вы, как раз, подтверждаете их существование.