The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Реализация FastCGI на современном C++, opennews (??), 17-Май-19, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


46. "Реализация FastCGI на современном C++"  –1 +/–
Сообщение от Аноним (51), 17-Май-19, 16:13 
Может быть какая-то либа-зависимость не установлена?
Ответить | Правка | Наверх | Cообщить модератору

72. "Реализация FastCGI на современном C++"  +1 +/–
Сообщение от Аноним (39), 17-Май-19, 17:43 
> Может быть какая-то либа-зависимость не установлена?

Если я нашёл определение, значит нашёл и либу (того же автора).

Вопрос по сементике самого макроса.

Ответить | Правка | Наверх | Cообщить модератору

82. "Реализация FastCGI на современном C++"  –1 +/–
Сообщение от dmitigr (ok), 17-Май-19, 18:09 
> Вопрос по сементике самого макроса.

Что конкретно Вам не ясно?

Ответить | Правка | Наверх | Cообщить модератору

104. "Реализация FastCGI на современном C++"  +2 +/–
Сообщение от Аноним (39), 17-Май-19, 19:57 
>> Вопрос по сементике самого макроса.
> Что конкретно Вам не ясно?

Не ясно, зачем ассерт бросает исключение, которое:
а) из названия не очевидно;
б) может быть по недоразумению проигнорировано.

Плюс к тому, существует вариант NOTHROW, не приводящий к прерыванию выполнения:


#define DMITIGR_DOUT_ALWAYS(...)         DMITIGR_DOUT__(__VA_ARGS__)
#define DMITIGR_ASSERT_ALWAYS(a)         DMITIGR_ASSERT__(a, true)
#define DMITIGR_ASSERT_NOTHROW_ALWAYS(a) DMITIGR_ASSERT__(a, false)
#define DMITIGR_IF_DEBUG__(code) if constexpr (dmitigr::is_debug_enabled) { code }
#define DMITIGR_DOUT(...)         { DMITIGR_IF_DEBUG__(DMITIGR_DOUT_ALWAYS(__VA_ARGS__)) }
#define DMITIGR_ASSERT(a)         { DMITIGR_IF_DEBUG__(DMITIGR_ASSERT_ALWAYS(a)) }
#define DMITIGR_ASSERT_NOTHROW(a) { DMITIGR_IF_DEBUG__(DMITIGR_ASSERT_NOTHROW_ALWAYS(a)) }

То есть: либо автор не стал менять название, постепенно модернизируя давно написанное, либо есть скрытый от малознакомых с новыми веяниями С++ (т.е. от меня) смысл.

Ну и было интересно, кто что скажет из знатоков, коих тут в избытке.

Ответить | Правка | Наверх | Cообщить модератору

108. "Реализация FastCGI на современном C++"  –2 +/–
Сообщение от dmitigr (ok), 17-Май-19, 20:51 
Здесь автор.

> Не ясно, зачем ассерт бросает исключение

Я используют DMITIGR_ASSERT() вместо стандартного assert() почти везде из-за того, что обычный assert() слишком груб и по умолчанию приводит к завершению программы. DMITIGR_ASSERT() же просто генерирует исключение std::logic_error если утверждение ложно. (Мне очевидно, что надо это задокументировать.)

> а) из названия не очевидно;

Спасибо за замечание. Я задокументирую этот момент!

> б) может быть по недоразумению проигнорировано.

По недоразумению может быть всё, что угодно. std::logic_error игнорировать не стоит. Это признак бага в программе или в библиотеках, от которых она зависит.

Ответить | Правка | Наверх | Cообщить модератору

119. "Реализация FastCGI на современном C++"  +1 +/–
Сообщение от RibiKukan (ok), 17-Май-19, 23:13 
>Я используют DMITIGR_ASSERT() вместо стандартного assert()

Кто тебе мешает использовать нормальные имена?

>слишком груб и по умолчанию приводит к завершению программы.

Это семантика асерта.

>DMITIGR_ASSERT() же просто генерирует исключение std::logic_error если утверждение ложно.

https://github.com/dmitigr/common/blob/b582b4daf674eed5df1d1...

Что это за нелепое говно? Ты вообще понимаешь почему assert макрос? Только для LINE и т.п. Если ты что-то там вещаешь про "модный С++" и пытаешься(нелепо) использовать увиденные где-то трюки(constexpr/constexpr if), то на них логика и должна быть построена. Эта же клоунада - просто клоунада нелепая. Зачем ты превратил макрос в переменную, что-бы потом использовать нахрен ненужный так constexpr if?

Ответить | Правка | Наверх | Cообщить модератору

135. "Реализация FastCGI на современном C++"  +/–
Сообщение от Аноним (39), 18-Май-19, 07:22 
>>Я используют DMITIGR_ASSERT() вместо стандартного assert()
> Кто тебе мешает использовать нормальные имена?

По-простому это называется "глаз замылился". Автору и без имён понятно, что делает макрос. Код выложил, что бы посмотреть на него со стороны.

>>слишком груб и по умолчанию приводит к завершению программы.
> Это семантика асерта.

Да. К счастью, макрос порвал мне шаблон при беглом просмотре исходников, а не при открытии некоего сайта.

>>DMITIGR_ASSERT() же просто генерирует исключение std::logic_error если утверждение ложно.
> https://github.com/dmitigr/common/blob/b582b4daf674eed5df1d1...
> Что это за нелепое говно? Ты вообще понимаешь почему assert макрос? Только
> для LINE и т.п. Если ты что-то там вещаешь про "модный
> С++" и пытаешься(нелепо) использовать увиденные где-то трюки(constexpr/constexpr if),
> то на них логика и должна быть построена. Эта же клоунада
> - просто клоунада нелепая. Зачем ты превратил макрос в переменную, что-бы
> потом использовать нахрен ненужный так constexpr if?

constexpr if нужен, что бы свести к минимуму использование препроцессора, отказавшись от #ifdef. IDE синтаксическом разборе исходного текста выкидывают одну из веток препроцессора в зависимости от NDEBUG, что не всегда удобно при разборе кода.

Ответить | Правка | Наверх | Cообщить модератору

136. "Реализация FastCGI на современном C++"  +/–
Сообщение от RibiKukan (ok), 18-Май-19, 07:40 
>constexpr if нужен, что бы свести к минимуму использование препроцессора, отказавшись от #ifdef.

Полный бред. Я там объяснял почему.

>IDE синтаксическом разборе исходного текста выкидывают одну из веток препроцессора в зависимости от NDEBUG, что не всегда удобно при разборе кода.

Причин гениальней это я не слышал. Т.е. constexpr if только для того, чтобы захакать ide? Да, сильно. К тому же, чем это неудобно я так и не понял.

Ответить | Правка | Наверх | Cообщить модератору

139. "Реализация FastCGI на современном C++"  +/–
Сообщение от Аноним (39), 18-Май-19, 08:26 
>>constexpr if нужен, что бы свести к минимуму использование препроцессора, отказавшись от #ifdef.
> Полный бред. Я там объяснял почему.

Да, там похоже на это самое. Мы ведь понимаем, что "бред" не технический аргумент.

>>IDE синтаксическом разборе исходного текста выкидывают одну из веток препроцессора в зависимости от NDEBUG, что не всегда удобно при разборе кода.
> Причин гениальней это я не слышал. Т.е. constexpr if только для того,
> чтобы захакать ide? Да, сильно. К тому же, чем это неудобно
> я так и не понял.

Есть многое в природе, друг Горацио, что и не снилось нашим мудрецам (с) https://www.sourceinsight.com/wp-content/uploads/2016/03/app...

Ответить | Правка | Наверх | Cообщить модератору

157. "Реализация FastCGI на современном C++"  +/–
Сообщение от RibiKukan (ok), 18-Май-19, 18:01 
>Да, там похоже на это самое. Мы ведь понимаем, что "бред" не технический аргумент.

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

>Есть многое в природе, друг Горацио, что и не снилось нашим мудрецам (с) https://www.sourceinsight.com/wp-content/uploads/2016/03/app...

И, что ты этим показал? Ну кроме того, что ты привык жрать птушное говно.

Ответить | Правка | Наверх | Cообщить модератору

161. "Реализация FastCGI на современном C++"  +/–
Сообщение от Аноним (39), 18-Май-19, 18:32 
>>Да, там похоже на это самое. Мы ведь понимаем, что "бред" не технический аргумент.
> Технический. Твоя обязанность обосновать. Ты не обосновал, а поиграл в клоуна. Именно
> это является бредом.

Бред, по определению, девиация мышления на фоне деменции. И есть, Петька, один нюанс. Оппонент твой  сменился. Ты пишешь про обязанности не автору. Могу ещё сыграть в того самого клоуна. Ты только как следует попроси.

>>Есть многое в природе, друг Горацио, что и не снилось нашим мудрецам (с) https://www.sourceinsight.com/wp-content/uploads/2016/03/app...
> И, что ты этим показал? Ну кроме того, что ты привык жрать
> птушное говно.

Это была Чорная Магия. Заклинание 1го уровня "зеркало". Всего лишь.

Ответить | Правка | Наверх | Cообщить модератору

169. "Реализация FastCGI на современном C++"  –1 +/–
Сообщение от RibiKukan (ok), 18-Май-19, 20:36 
>Бред, по определению, девиация мышления на фоне деменции. И есть, Петька, один нюанс. Оппонент твой  сменился. Ты пишешь про обязанности не автору. Могу ещё сыграть в того самого клоуна. Ты только как следует попроси.

Клоун, мне без разницы на то кто ты. Ты для меня не отличаешься от любого другого клоуна в интернете. Ты пыль. Твоя задача - либо смешить меня жалкими потугами что-то мне ответить, либо обделаться. Ты выбрал второе, и я даже жалких потуг не увидел.

>Это была Чорная Магия. Заклинание 1го уровня "зеркало". Всего лишь.

Опять нырнул в дерьмо.

Ответить | Правка | Наверх | Cообщить модератору

180. "Реализация FastCGI на современном C++"  +/–
Сообщение от Аноним (39), 19-Май-19, 08:57 
>>Бред, по определению, девиация мышления на фоне деменции. И есть, Петька, один нюанс. Оппонент твой  сменился. Ты пишешь про обязанности не автору. Могу ещё сыграть в того самого клоуна. Ты только как следует попроси.
> Клоун, мне без разницы на то кто ты.

Знаю. Ты ошибся адресатом, что лишает персонализированные обращения смысла, но для тебя это ничего не меняет. Плоды фантазии безусловно верны для бредящего.

> Опять нырнул в дерьмо.

Смотри, не задохнись. Зачем ты вообще это делаешь?

Ответить | Правка | К родителю #169 | Наверх | Cообщить модератору

138. "Реализация FastCGI на современном C++"  +/–
Сообщение от Аноним (39), 18-Май-19, 08:07 
> Здесь автор.
>> Не ясно, зачем ассерт бросает исключение
> Я используют DMITIGR_ASSERT() вместо стандартного assert() почти везде из-за того, что
> обычный assert() слишком груб и по умолчанию приводит к завершению программы.

А зачем продолжать её исполнение?

> DMITIGR_ASSERT() же просто генерирует исключение std::logic_error если утверждение ложно.
> (Мне очевидно, что надо это задокументировать.)

Виноват, но я принципиально не смотрел документацию, где сказано про зависимости. При этом (в отличии он некоторых читавших) нашёл макрос, поднявшись на уровень выше в репозитории, где увидел common и debug. Если бы имя макроса содержало в себе что-то вроде COMMON или LIB, было бы сразу очевидно, что искать его следует в другой библиотеке.

>> а) из названия не очевидно;
> Спасибо за замечание. Я задокументирую этот момент!

Имеете ввиду, где-то отдельно уточнить? Если есть вариант с NOTHROW, почему нет с THROW?

>> б) может быть по недоразумению проигнорировано.
> По недоразумению может быть всё, что угодно. std::logic_error игнорировать не стоит. Это
> признак бага в программе или в библиотеках, от которых она зависит.

The class logic_error defines the type of objects thrown as exceptions to report errors presumably detectable before the program executes, such as violations of logical preconditions or class invariants.

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

Ответить | Правка | К родителю #108 | Наверх | Cообщить модератору

140. "Реализация FastCGI на современном C++"  +/–
Сообщение от dmitigr (ok), 18-Май-19, 10:31 
> А зачем продолжать её исполнение?

Здесь больше интересен вопрос: как по-мягче завершить её выполнение? Меня не устраивает заверешние через std::abort(), поэтому DMITIGR_ASSERT() генерирует std::logic_error, что предоставляет возможность самому приложению решать как именно закругляться (или не закругляться).

> Если бы имя макроса содержало в себе что-то вроде COMMON или LIB, было бы сразу очевидно, что искать его следует в другой библиотеке.

Так и было. Раньше он назывался DMITIGR_INTERNAL_ASSERT(). Но я не вижу в этом больше смысла.

> Имеете ввиду, где-то отдельно уточнить? Если есть вариант с NOTHROW, почему нет с THROW?

Вариант с "THROW" - это и есть DMITIGR_ASSERT().

> Тут пишут, что не просто бага, а тех, что могут быть исключены до выполнения программы.

Это и есть баг. И всякий баг - это логическая ошибка. Можно ввести класс Bug, унаследованный от std::logic_error, но в этом смысл околонулевой - о классе std::logic_error знают все, кто пишет на C++.

Ответить | Правка | Наверх | Cообщить модератору

144. "Реализация FastCGI на современном C++"  +/–
Сообщение от Аноним (39), 18-Май-19, 11:32 
>> А зачем продолжать её исполнение?
> Здесь больше интересен вопрос: как по-мягче завершить её выполнение? Меня не устраивает
> заверешние через std::abort(), поэтому DMITIGR_ASSERT() генерирует std::logic_error,
> что предоставляет возможность самому приложению решать как именно закругляться (или не
> закругляться).

Наверное, прежде всего для этого необходимо обеспечить 100% гарантии вызова обработчика исключений, ведь в ситуации ассерта он (в общем случае) может оказаться неконсистентном состоянии.

>> Если бы имя макроса содержало в себе что-то вроде COMMON или LIB, было бы сразу очевидно, что искать его следует в другой библиотеке.
> Так и было. Раньше он назывался DMITIGR_INTERNAL_ASSERT(). Но я не вижу в
> этом больше смысла.
>> Имеете ввиду, где-то отдельно уточнить? Если есть вариант с NOTHROW, почему нет с THROW?
> Вариант с "THROW" - это и есть DMITIGR_ASSERT().

При этом называется он не DMITIGR_ASSERT_THROW. В последнем варианте наименования все аргументы вида "семантика ассерта отличается" теряют смысл. :)

>> Тут пишут, что не просто бага, а тех, что могут быть исключены до выполнения программы.
> Это и есть баг. И всякий баг - это логическая ошибка. Можно
> ввести класс Bug, унаследованный от std::logic_error, но в этом смысл околонулевой
> - о классе std::logic_error знают все, кто пишет на C++.

__builtin_trap() - ошибка физическая (на x86 транслируется в UD2). SIGILL логическая. Тоже генерируют исключение, которое можно попробовать поймать, но перепутать его с подмножеством ошибок std::logic_error -- надо постараться.

Ответить | Правка | Наверх | Cообщить модератору

145. "Реализация FastCGI на современном C++"  +/–
Сообщение от dmitigr (ok), 18-Май-19, 11:46 
> Наверное, прежде всего для этого необходимо обеспечить 100% гарантии вызова обработчика исключений, ведь в ситуации ассерта он (в общем случае) может оказаться неконсистентном состоянии.

Обработчики исключений, которые пересекают границы библиотек, определяются в приложениях.

> ведь в ситуации ассерта он (в общем случае) может оказаться неконсистентном состоянии.

О каком неконсистентном состоятии речь?

> При этом называется он не DMITIGR_ASSERT_THROW. В последнем варианте наименования все аргументы вида "семантика ассерта отличается" теряют смысл. :)

Он называется DMITIGR_ASSERT(), а не ASSERT() или Assert(). Поэтому судить о семантике следует либо из документации, либо из определения.

>  __builtin_trap() - ошибка физическая (на x86 транслируется в UD2). SIGILL логическая. Тоже генерируют исключение, которое можно попробовать поймать, но перепутать его с подмножеством ошибок std::logic_error -- надо постараться.

Не совсем понял к чему это, но исключения std::logic_error ловятся стандартным образом.

Ответить | Правка | Наверх | Cообщить модератору

149. "Реализация FastCGI на современном C++"  +/–
Сообщение от Аноним (39), 18-Май-19, 15:24 
>> При этом называется он не DMITIGR_ASSERT_THROW. В последнем варианте наименования все аргументы вида "семантика ассерта отличается" теряют смысл. :)
> Он называется DMITIGR_ASSERT(), а не ASSERT() или Assert(). Поэтому судить о семантике
> следует либо из документации, либо из определения.

Следует? Автору виднее. Автор может поступать, как считает нужным. Сам.

Ответить | Правка | Наверх | Cообщить модератору

155. "Реализация FastCGI на современном C++"  +/–
Сообщение от dmitigr (ok), 18-Май-19, 17:01 
Следует. С чего вдруг некий DMITIGR_ASSERT() должен повторять семантику стандартного assert()? Наличие слова "ASSERT" в названии к этому не обязывает.

Мне не понятно, зачем вообще Вам этот макрос? Это деталь реализации. Пользователям библиотеки она совершенно не нужна. Если Вы собираетесь поучаствовать в разработке, то Вы уже знаете что это за макрос, благо его определение занимает 5 строчек. Спасибо за дискуссию!

Ответить | Правка | Наверх | Cообщить модератору

159. "Реализация FastCGI на современном C++"  +/–
Сообщение от Аноним (39), 18-Май-19, 18:18 
> Следует. С чего вдруг некий DMITIGR_ASSERT() должен повторять семантику стандартного assert()?

"Должен" не то слово. Есть ожидания пользователя, читателя кода. Если они расходится положением дел, возможны варианты (принять/не принять).

> Мне не понятно, зачем вообще Вам этот макрос?

Интерес представляет в первую очередь ход мыслей автора. Если глаз цепляется, значит такое наверняка повстречается где-то ещё. Чем больше задаю таких глупых вопросов, тем проще потом сориентироваться в новом коде. Документация не всегда в наличии, как и исходники. Благодарю за разъяснения.

Ответить | Правка | Наверх | Cообщить модератору

151. "Реализация FastCGI на современном C++"  +/–
Сообщение от Anonymoustus (ok), 18-Май-19, 16:29 
> DMITIGR_
> DMITIGR_
> DMITIGR_
> DMITIGR_
> DMITIGR_
> DMITIGR_
> DMITIGR_
> DMITIGR_
> DMITIGR_
> DMITIGR_

Аффтару нимб не жмёт?

Ответить | Правка | К родителю #140 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру