Всем привет. Прошу вашего совета. Какие патерны проектирования желательно знать junior'u, либо какие самые востребованные в работе

от джуна это обычно не требуется

от джуна это обычно не требуется

От жуна нет. От программиста требуется

От жуна нет. От программиста требуется

какая-то софистика

ЖЕлательно все GoF

Спасибо за ответ)

Спасибо за ответ)

Это не то что бы ответ, найти бы сеньора, который их все знает и применял

Всем привет. Прошу вашего совета. Какие патерны проектирования желательно знать junior'u, либо какие самые востребованные в работе

На самом деле по моему знание конкретных паттернов не так ценно, как само чтение книги, которое даёт тебе понимание того, что классы можно не только наследовать друг от друга. Далее при чтении книги ты может что-то запомнишь или что-то нет, это не важно, потому что всегда ты сможешь книгу открыть , вспомнить и применить нужный паттерн

Это не то что бы ответ, найти бы сеньора, который их все знает и применял

Ну все они в разной степени часты в применении

Привет. Напомните, я могу в деструкторе понять, из разворачивания ли исключения он вызван, или «штатно»? Если у меня паттерн как во всяких автолоках, но я хочу делать разные вещи в зависимости от.

плохо кончится родной

Привет. Напомните, я могу в деструкторе понять, из разворачивания ли исключения он вызван, или «штатно»? Если у меня паттерн как во всяких автолоках, но я хочу делать разные вещи в зависимости от.

Нет, не можешь

Привет. Напомните, я могу в деструкторе понять, из разворачивания ли исключения он вызван, или «штатно»? Если у меня паттерн как во всяких автолоках, но я хочу делать разные вещи в зависимости от.

Лучше это не делать. Можно использовать std::uncaugth_exceptions, но потом через пару лет кто-то захочит использовать С++ корутины (они же появятся) и всё это сломается.

Привет. Напомните, я могу в деструкторе понять, из разворачивания ли исключения он вызван, или «штатно»? Если у меня паттерн как во всяких автолоках, но я хочу делать разные вещи в зависимости от.

Согласен, что плохо кончиться

Оно же в любом случае будет штатно, объект помер - деструктор

Лучше это не делать. Можно использовать std::uncaugth_exceptions, но потом через пару лет кто-то захочит использовать С++ корутины (они же появятся) и всё это сломается.

Да, вот я тоже подумал, что в корутинах бросок какого-нибудь условного std::co_return будет штатным её завершением, и всё у меня сломается. Придётся, видимо, по-старинке, если хочу «делать действие только если всё хорошо», то тупо писать строчку в конце метода.

Оно же в любом случае будет штатно, объект помер - деструктор

С точки зрения объекта — да, но я то хочу понять, что вокруг происходит. Ну, то есть, не хочу, конечно, не должен хотеть.

Да, вот я тоже подумал, что в корутинах бросок какого-нибудь условного std::co_return будет штатным её завершением, и всё у меня сломается. Придётся, видимо, по-старинке, если хочу «делать действие только если всё хорошо», то тупо писать строчку в конце метода.

Ну ты можешь создать локальный struct объект и в его деструктор записать логику, при делании, там можно проверять флаг, который будет меняться в catch. Понятней ли от этого станет в частном случае, тебе должно быть видней.

Ну ты можешь создать локальный struct объект и в его деструктор записать логику, при делании, там можно проверять флаг, который будет меняться в catch. Понятней ли от этого станет в частном случае, тебе должно быть видней.

Скорее деструктор по умолчанию ничего не делает, но если в процессе вызвали какой-нибудь .everything_is_ok(), то проставляется флажок и случается то, что надо. catch то может быть сильно выше где-то, а вставлять ещё один и прокидывать исключение из него наверх желания как-то нет.

Скорее деструктор по умолчанию ничего не делает, но если в процессе вызвали какой-нибудь .everything_is_ok(), то проставляется флажок и случается то, что надо. catch то может быть сильно выше где-то, а вставлять ещё один и прокидывать исключение из него наверх желания как-то нет.

Мне вот кажется не надо так сильно упарываться по RAII...

Поясни. Смущает, что так запросто кучу логики запихивается в спецэффекты, она становится неявной?

Был у меня случай, надо было массив длл-к проверить на адекватность. И был сделан класс типа DllTestRecord, который перед процедурой писал на диск, а в методе .everything_is_ok() удалял запись. Ну и соответственно, плохая длл потом вычеркивалась из массива.

Ну это удобно, в go же добавили defer

Поясни. Смущает, что так запросто кучу логики запихивается в спецэффекты, она становится неявной?

Нет, смущает что ты долбишься головой в стену, зациклившись на одном варианте решения

Поясни. Смущает, что так запросто кучу логики запихивается в спецэффекты, она становится неявной?

Представь, что RAII нет вообще. Сделай два варианта деиници ализации. Потом Общее из двух положи в деструктор

Хорошо было писать на чистом C, там сделал два варианта и всё, больше ничего никуда не надо класть.

Возникла задача. Есть потомки базовый класс и потомки базового класса. В одну из функций передаю указатель на базовый класс. Можно как-то без явно приведения к потомку, обратиться через указатель базового класса к потомку?

Что-то в головек мешанина. НЕ могу придумать, как без приведения сделать.

Представь, что RAII нет вообще. Сделай два варианта деиници ализации. Потом Общее из двух положи в деструктор

А зачем? scope_guard существует уже лет 10. Вроде бы уже всем должен быть достаточно понятен. Вариации scope_guard с dismiss() тоже не редкость.

Да, вот я тоже подумал, что в корутинах бросок какого-нибудь условного std::co_return будет штатным её завершением, и всё у меня сломается. Придётся, видимо, по-старинке, если хочу «делать действие только если всё хорошо», то тупо писать строчку в конце метода.

Как связаны co_return и исключения?

Что-то в головек мешанина. НЕ могу придумать, как без приведения сделать.

Вообще не понятно, что хочется? Чем virtual неподходит?

Как связаны co_return и исключения?

Это скорее мне надо про корутины в плюсах почитать, а то я только с питоновскими генераторами имел дело, и там в качестве возврата метод __next__ бросает StopIteration.

Вообще не понятно, что хочется? Чем virtual неподходит?

Просто вызвано нежелание подключать заколовок произвольного класса, чтобы преобразовать указатель базового класса на произвольный и получить доступ к полям и методам

Да и не надо подключать классы наследников. void foo(A* a) { a->bar(); } Если B — наследник А, и bar() объявлен как virtual, то вызовется реализация для B.

Как связаны co_return и исключения?

SCOPE_SUCCESS и SCOPE_FAIL обычно делаются через std::uncaught_exceptions. В конструкторе запоминается количество активных исключений текущего потока, в деструкторе проверяется, не увеличилось ли оно. std::uncaught_exceptions - это thread local счётчик. Корутины позволяют начать вычисление в одном потоке, а продолжать исполнение в другом потоке. Получаем замечательный код, который запоминает количество исключений одного потока, а проверят - по количеству исключений другого. И это может некоторое время даже производить впечатление работающего кода.

Как связаны co_return и исключения?

Да никак, просто предположили, что в будущих корутинах что-то не сработает с этим подходом.

SCOPE_SUCCESS и SCOPE_FAIL обычно делаются через std::uncaught_exceptions. В конструкторе запоминается количество активных исключений текущего потока, в деструкторе проверяется, не увеличилось ли оно. std::uncaught_exceptions - это thread local счётчик. Корутины позволяют начать вычисление в одном потоке, а продолжать исполнение в другом потоке. Получаем замечательный код, который запоминает количество исключений одного потока, а проверят - по количеству исключений другого. И это может некоторое время даже производить впечатление работающего кода.

Надо ассертить что thread id совпадает. Но наверное да, без корутин такая проблема не возникнет.

Надо ассертить что thread id совпадает. Но наверное да, без корутин такая проблема не возникнет.

Тогда оно будет время от времени падать без объективной причины. Лучше, чем UB, но толку-то.

Тогда оно будет время от времени падать без объективной причины. Лучше, чем UB, но толку-то.

Толк примерно такой же как и от других ассертов - показать программисту что нельзя такие классы использовать в корутинах. Падать будет постоянно если корутина действительно выполняется на нескольких потоках.

Надо ассертить что thread id совпадает. Но наверное да, без корутин такая проблема не возникнет.

?Ага, знал бы, где упаду - соломку бы подстелил. Например, авторы предложения добавить в стандарт scope_success и scope_fail (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0052r3.pdf) вроде бы про assert такой тоже не думали. Там ссылка на пример реализации есть (https://github.com/PeterSommerlad/SC22WG21_Papers/blob/master/workspace/P0052_scope_exit/src/scope_exit.h)

Хм.... надо автору написать, спросить, знает ли он про такой юзкейс

какие есть побочные эффекты при использовании attribute packed, кроме скорости работы?

Привет. Напомните, я могу в деструкторе понять, из разворачивания ли исключения он вызван, или «штатно»? Если у меня паттерн как во всяких автолоках, но я хочу делать разные вещи в зависимости от.

https://en.cppreference.com/w/cpp/error/current_exception

https://en.cppreference.com/w/cpp/error/current_exception

обалдеть, чего только не найдёшь в необъятных закромах родины

обалдеть, чего только не найдёшь в необъятных закромах родины

а как бы std::future файрили о проблемах? только сохраняя std::exception_ptr

const poisoning вам о чём-нибудь говорит? можно это как-то вменяемо объяснить? подобное объяснeние скорее путает чем разъясняет

const poisoning вам о чём-нибудь говорит? можно это как-то вменяемо объяснить? подобное объяснeние скорее путает чем разъясняет

речь о C и снятии константности на примере strchr char * strchr ( const char *, int ); в C++ этой проблемы нет

ты передаешь указатель на константную строку, а функция снимает эту константность и возращает неконстантный указатель

речь о C и снятии константности на примере strchr char * strchr ( const char *, int ); в C++ этой проблемы нет

если const poisoning это про снятие константности т.е. immut -> mut cast, тогда вопрос вообще снимается

ты передаешь указатель на константную строку, а функция снимает эту константность и возращает неконстантный указатель

понял, т.е. именно это и подразумевает понятие "const poisoning"?

если const poisoning это про снятие константности т.е. immut -> mut cast, тогда вопрос вообще снимается

это const poisoing - порча константности

это const poisoing - порча константности

отлично, спасибо за простое объяснение!

Ребята, а шесть точек после аргументов шаблона, что значЯт:?

Да, Костику спасибо. Я просто не могу лить файлы :)

это эквивалент _ArgTypes..., ...

pack expansion + ellipsis

это эквивалент _ArgTypes..., ...

аааа это типа a, b, c...?

okay

pack expansion + ellipsis

а это 11ые кресты?

а это 11ые кресты?

ну да. вариадики - 11, эллипсис вообще из си

аааа это типа a, b, c...?

запятую перед эллипсисом можно опускать, а так - это просто вариадик функция с последним эллипсис аргументом

Ну, я простл конкретно такую объединенную запись впервой вижу.

Why is this valild? We can see that , ... is synonymous with ... from the draft C++11 standard section 8.3.5 [dcl.fct] which has the following grammar: parameter-declaration-clause: parameter-declaration-listopt...opt parameter-declaration-list , ... and says: [...] Where syntactically correct and where “...” is not part of an abstract-declarator, “, ...” is synonymous with “...”. [...]

ERROR: S client not available

https://en.cppreference.com/w/cpp/error/current_exception

std::current_exception возвращает текущее исключение, которое обрабатывается. С его помощью нельзя узнать, в результате исключения вызвался деструктор или штатно. Можно узнать только находимся ли мы сейчас в обработке исключения (внутри какого-либо catch). Пример: https://wandbox.org/permlink/7ZJ9MxDqV2t1Rnco

1...42 в свичах gcc, значит, распарсить не может, а вот 6 точек подряд — запросто

Ну, я простл конкретно такую объединенную запись впервой вижу.

да, в первый раз это удивляет, а вообще это типичный пример функций, которые почти никогда не встречаются в реальном коде (как const volatile &&), но должны корректно работать с std::is_function и прочими трейтами

https://www.youtube.com/watch?v=ovxNM865WaU MUST HAVE для просмотра.

спасибо гайцы, пока вы есть - ноги мира могут спать спокойно!

там про альтернативную реализацию std::is_function без перечисления всех https://i.imgur.com/Lhh0FGl.png

там про альтернативную реализацию std::is_function без перечисления всех https://i.imgur.com/Lhh0FGl.png

я видел в вижаке реализацию, просто макрос и поехали

я видел в вижаке реализацию, просто макрос и поехали

я тоже, хотелось развидеть..

там про альтернативную реализацию std::is_function без перечисления всех https://i.imgur.com/Lhh0FGl.png

оно : https://stackoverflow.com/questions/43470741/how-does-eric-nieblers-implementation-of-stdis-function-work

?

вот еще забавный момент из презентации выше (кому лень смотреть): https://i.imgur.com/7hXxnZf.png

В msvc

Там переклбчается

оно : https://stackoverflow.com/questions/43470741/how-does-eric-nieblers-implementation-of-stdis-function-work

про это там тоже упоминается, но в целом там намного больше ценной инфы.

std::current_exception возвращает текущее исключение, которое обрабатывается. С его помощью нельзя узнать, в результате исключения вызвался деструктор или штатно. Можно узнать только находимся ли мы сейчас в обработке исключения (внутри какого-либо catch). Пример: https://wandbox.org/permlink/7ZJ9MxDqV2t1Rnco

А, точно. В деструкторе нужен https://en.cppreference.com/w/cpp/error/uncaught_exception

https://www.youtube.com/watch?v=ovxNM865WaU MUST HAVE для просмотра.

вообще у меня иногда ощущение, что нужно организовать всечеловеческую корпорацию и каким-то образом объединять результаты действия фор тех лулз со стороны всего человечества

Ребят поскажите есть ли какая-либо идиома когда объединяют pure virtual функции и шаблонные методы вроде ISession из примера по ссылке ниже? https://github.com/Belgorodsky/BoostAsioCppNetworkProgrammingCookbookDmitroRadchuk/blob/master/03_impl_client_apps/tcp_asynchronous.cpp

Ребят поскажите есть ли какая-либо идиома когда объединяют pure virtual функции и шаблонные методы вроде ISession из примера по ссылке ниже? https://github.com/Belgorodsky/BoostAsioCppNetworkProgrammingCookbookDmitroRadchuk/blob/master/03_impl_client_apps/tcp_asynchronous.cpp

Не знаю про идиомы, но в упор не понимаю, зачем вы так усиленно принимаете TCallback&& callback

Ребят поскажите есть ли какая-либо идиома когда объединяют pure virtual функции и шаблонные методы вроде ISession из примера по ссылке ниже? https://github.com/Belgorodsky/BoostAsioCppNetworkProgrammingCookbookDmitroRadchuk/blob/master/03_impl_client_apps/tcp_asynchronous.cpp

Я не очень понял вопрос, но назвал бы эту идиому "Необходимость template-методов в полиморфном классе".

Не знаю про идиомы, но в упор не понимаю, зачем вы так усиленно принимаете TCallback&& callback

просто на автопилоте написал

просто на автопилоте написал

ну тогда и forward на автопилоте пишите

Я не очень понял вопрос, но назвал бы эту идиому "Необходимость template-методов в полиморфном классе".

?

ну тогда и forward на автопилоте пишите

разумно. поправлю

разумно. поправлю

в действительности еще ваши static_assert на вызовах просто ужасны, они не к месту написаны

в действительности еще ваши static_assert на вызовах просто ужасны, они не к месту написаны

похоже на то, но всё же ошибки компиляции с ними мб чуток понятнее

Я не очень понял вопрос, но назвал бы эту идиому "Необходимость template-методов в полиморфном классе".

Я бы назвал "притянутая за уши необходимость в джаваполиморфизме"

И кажется боязнь/ненавистьк александреску

похоже на то, но всё же ошибки компиляции с ними мб чуток понятнее

ну это к разработчикам буста. еще m_cancel_guard мало того что имя misleading, да еще и одну переменную усиленно закрывает, уж не atomic_bool ли это?

Я бы назвал "притянутая за уши необходимость в джаваполиморфизме"

окей, прост захотелось поэксперементировать ?

ну это к разработчикам буста. еще m_cancel_guard мало того что имя misleading, да еще и одну переменную усиленно закрывает, уж не atomic_bool ли это?

это уже название переменной из книги, из которой тривиальный говнокод я переписал в нетривиальный, попахивающий, забавы ради ?

это уже название переменной из книги, из которой тривиальный говнокод я переписал в нетривиальный, попахивающий, забавы ради ?

ну х3, я предпочитаю guard обзывать RAII объекты