Ни в коем случае. Режим 't' - канонический С, растущий из начала времен. Указание режима 't' при работе с текстовыми потоками - обязательная практика, тщательно выдерживаемая везде и всегда.
Потому что программа, как ясно сказано изначально, написана на стандартом С, в котром нет никакого getopt. Не надо замусоривать программирование пингвинизмами.
Эта реальность называется языком С. В языке никакого getopt нет и никогда не было. Это чистый пингвинизм, в этой задаче, разумеется, ни в коем случае не допустимый.
Каким боком здесь может понадобиться функция feof? feof - очень нишевая и специальная функция, которая практически не используется в программах на С. Поэтому не совсем ясно, к чему вы тут упомянули feof.
Ответ: булевой переменной в принципе не существует без подключения стандартных библиотек. А при подключении библиотеки stdbool.h, размер bool = 1 байт
Что это за чушь?
В С89/90 действительно не существует булевского типа и никакое "подключение стандартных библиотек" здесь не поможет.
Начиная с C99 в языке С есть булевский тип _Bool. Он является частью ядра языка. Никакое "подключение стандартных библиотек" здесь не нужно. Заголовок <stdbool.h> лишь определяет некоторые макро-псевдонимы.
И что вообще такое "стандартные библиотеки" - именно во множественном числе? В языке С есть только одна стандартная библиотека.
Использовать предельно аккуратно, так как при преобразовании указателя, данные внутри не преобразовываются: символ со знаком -0x7F равен символу без знака 0xFF из-за того, что самый большой бит ответственен за знак. А если мы преобразовываем указатель с размером типа 2 байта, в указатель с размером типа 1 байт, мы гарантированно получим только первую половину данных, если считать от адреса указателя.
Что это? О чем это??? O_o
int* a = (int*) malloc(sizeof(int));
Явное приведение типа применено к результату стандартной функции выделения памяти... Что это за пионэрство?
Массивы в Си - это указатели на области памяти, которые имеют N размеров типа данных (N * sizeof(type))
Что? Постарайтесь запомнить раз и навсегда: массивы в С - это НЕ указатели. Сколько уже сил потрачено на то, чтобы развеять этот пионэрский морок. Но он все вылазит и вылазит откуда-то...
Я не знаю, на что именно опиралась эта нейросеть в своих выводах, но она совершенно права в оценке вашей реализации std::array. Предложенный вами вариант не является допустимой реализацией std::array по причине того, что ваш класс не является агрегатным типом. А агрегатность результирующего типа требуется: она является частью спецификации std::array.
Причем сеть достаточно правильно указала, что ваши пользовательские конструкторы (унаследованные из art::array_impl в art::array) - это и есть причина, по которой ваш вариант потерял агрегатность. Дальнейшие ее разглагольствования про добавление конструкторов неверны. Пользовательские конструкторы недопустимы в самом std::array ни в явном, ни в унаследованном виде.
Классический пример статьи "ни о чем". Нет такого понятия как "переход на С99" (или на любой другой стандарт) у вас не было необходимости мучительно "эмулировать" те возможности, которые новая спецификация предоставляет из коробки.
P.S. Также, по странностям перевода возникает подозрение, что автор перевода не совсем хорошо разбирается в фичах языка. Перевести "designated initializers" как "специальные инициализаторы"... Навскидку совсем непонятно, о чем идет речь.
В то же время, я думаю, такая необходимость у авторов curl скорее всего в какой-то мере была (чисто теоретически предположу, например, использование struct hack вместо предоставляемого C99 flexible array member, использование именованных временных переменных вместо составных литералов, функциональные макросы вместо inline-функций, snprintf), но им просто лень всем этим заниматься. Работает - ну и пусть.
В данном случае, конечно, не критично, учитывая специфику задачи, но тем не менее: использование pow для возведения в целые степени всегда режет глаз. А уж в квадрат...
Ым... Может быть надо бы расширить немного вводную часть, чтобы было понятно, о чем идет речь?
"Многие знакомы с алгоритмами дерева отрезков"? Да, многие действительно знакомы с весьма распространенной и полезной хрестоматийной структурой данных - деревом отрезков (aka interval tree) - и сопутствующими алгоритмами, использующимися для решения таких задач как эффективное обнаружение перекрывающихся интервалов, попадания точки в набор интервалов и т.п.
Какое отношение ко всему этому имеют ваши рассуждения - тайна за семью печатями. "Дерево отрезков похоже на корневую декомпозицию"... Оок....
"Собственно код на С (подключенным для удобства STL)"? Чего? STL в С?
"Споры об IDE" закончились лет пятнадцать назад. Общепризнанной вершиной Олимпа IDE является Microsoft Visual Studio. Все остальное в этой области - это лишь попытки в условиях ограниченных ресурсов reinvent каждую фичу в VS чуть ли не попиксельно. Poorly, разумеется...
Что касается использования условных точек останова - это верно, торможение от их использования в общем случае будет существенным. И в условиях разработки "на своей базе" действительно в большинстве случаев лучше просто явно добавить в код соответствующий if и перекомпилировать.
Но иногда приходится отлаживаться и "на вражеской территории", то есть на клиентском оборудовании и в клиентском окружении, голым gdb без возможности редактирования и/или перекомпиляции кода. В таких случаях помогает стратегическое создание в критических точках кода специальных параметризуемыхif-закладок, призванных отлавливать наиболее часто встречающиеся потребности в условной остановке. То есть что-то вроде
Разумеется, все возможные необходимости для постановки условных точек останова заранее не предугадаешь, но тем не менее очень существенная их доля прекрасно покрывается вот таким планированием на будущее еще на этапе разработки кода.
Для того, чтобы функция CustomFilter работала для обоих разрядностей (x86 и x64) можно воспользоваться директивами условной компиляции
Совершенно не понятно, почему вы ассоциируете разницу в коде с разрядностью платформы. Разрядность платформы тут совершенно ни при чем, а все зависит от настроек кодогенератора и в первую очередь от настроек оптимизации. Зависимость от разрядности платформы - это не более чем паразитная/случайная зависимость. И судя по вашим экспериментам, вы выполняли их в отладочной конфигурации, что является весьма странной затеей.
Это проблему такими директивами условной компиляции не решить. Или, точнее, это будет "решение", которое очень запросто "превратится в тыкву" в самый неожиданный момент.
Я так и не смог понять, что имеется в виду под "ansi style". Автор местами использует фичи C99, но при этом валит объявления переменных в одну кучу в начале функции и избегает инициализации... С const тоже винегрет: где-то есть, где-то нет.
#define s_exit(e) do { endwin(); exit(e); } while(0);
Что это за белиберда?
Вся идея идиомы do { ... } while(0) в макросах критически основана на том, что в самом макросе ни в коем случае не должно быть ; после while (0). Кто и зачем влепил туда эту ;?
Если у автора это "работает" в коде, значит ему вообще не нужна была эта идиома. Можно было пользоваться просто парой { ... }. Зачем он слепо вставлял в свои макросы все это do { ... } while(0)?
Это просто классический пример карго-культа: где-то в чьих-то макросах увидел это do { } while(0) и слепо повторяет, совершенно не понимая, зачем все это делается и как это должно работать.
Ни в коем случае. Режим 't' - канонический С, растущий из начала времен. Указание режима 't' при работе с текстовыми потоками - обязательная практика, тщательно выдерживаемая везде и всегда.
for (int i = index_end_flags + 1; i < argc, i++) {Уж проверить свои примеры кода на банальные опечатки перед публикацией, наверное, можно было?
Потому что программа, как ясно сказано изначально, написана на стандартом С, в котром нет никакого getopt. Не надо замусоривать программирование пингвинизмами.
Использование const обязательно и никаким образом не зависит от компилятора, и уж тем более от execution environment.
Эта реальность называется языком С. В языке никакого getopt нет и никогда не было. Это чистый пингвинизм, в этой задаче, разумеется, ни в коем случае не допустимый.
Каким боком здесь может понадобиться функция feof? feof - очень нишевая и специальная функция, которая практически не используется в программах на С. Поэтому не совсем ясно, к чему вы тут упомянули feof.
Что это за чушь?
В С89/90 действительно не существует булевского типа и никакое "подключение стандартных библиотек" здесь не поможет.
Начиная с C99 в языке С есть булевский тип
_Bool. Он является частью ядра языка. Никакое "подключение стандартных библиотек" здесь не нужно. Заголовок<stdbool.h>лишь определяет некоторые макро-псевдонимы.И что вообще такое "стандартные библиотеки" - именно во множественном числе? В языке С есть только одна стандартная библиотека.
Что это? О чем это??? O_o
Явное приведение типа применено к результату стандартной функции выделения памяти... Что это за пионэрство?
Что? Постарайтесь запомнить раз и навсегда: массивы в С - это НЕ указатели. Сколько уже сил потрачено на то, чтобы развеять этот пионэрский морок. Но он все вылазит и вылазит откуда-то...
Я не знаю, на что именно опиралась эта нейросеть в своих выводах, но она совершенно права в оценке вашей реализации
std::array. Предложенный вами вариант не является допустимой реализациейstd::arrayпо причине того, что ваш класс не является агрегатным типом. А агрегатность результирующего типа требуется: она является частью спецификацииstd::array.Причем сеть достаточно правильно указала, что ваши пользовательские конструкторы (унаследованные из
art::array_implвart::array) - это и есть причина, по которой ваш вариант потерял агрегатность. Дальнейшие ее разглагольствования про добавление конструкторов неверны. Пользовательские конструкторы недопустимы в самомstd::arrayни в явном, ни в унаследованном виде.Классический пример статьи "ни о чем". Нет такого понятия как "переход на С99" (или на любой другой стандарт) у вас не было необходимости мучительно "эмулировать" те возможности, которые новая спецификация предоставляет из коробки.
P.S. Также, по странностям перевода возникает подозрение, что автор перевода не совсем хорошо разбирается в фичах языка. Перевести "designated initializers" как "специальные инициализаторы"... Навскидку совсем непонятно, о чем идет речь.
В то же время, я думаю, такая необходимость у авторов curl скорее всего в какой-то мере была (чисто теоретически предположу, например, использование struct hack вместо предоставляемого C99 flexible array member, использование именованных временных переменных вместо составных литералов, функциональные макросы вместо inline-функций,
snprintf), но им просто лень всем этим заниматься. Работает - ну и пусть.В данном случае, конечно, не критично, учитывая специфику задачи, но тем не менее: использование
powдля возведения в целые степени всегда режет глаз. А уж в квадрат...Также: почему
float, а неdouble?Что такое "переменная int24_t "?
Ым... Может быть надо бы расширить немного вводную часть, чтобы было понятно, о чем идет речь?
"Многие знакомы с алгоритмами дерева отрезков"? Да, многие действительно знакомы с весьма распространенной и полезной хрестоматийной структурой данных - деревом отрезков (aka interval tree) - и сопутствующими алгоритмами, использующимися для решения таких задач как эффективное обнаружение перекрывающихся интервалов, попадания точки в набор интервалов и т.п.
Какое отношение ко всему этому имеют ваши рассуждения - тайна за семью печатями. "Дерево отрезков похоже на корневую декомпозицию"... Оок....
"Собственно код на С (подключенным для удобства STL)"? Чего? STL в С?
"Брейкпоинтеры" [x]
"Споры об IDE" закончились лет пятнадцать назад. Общепризнанной вершиной Олимпа IDE является Microsoft Visual Studio. Все остальное в этой области - это лишь попытки в условиях ограниченных ресурсов reinvent каждую фичу в VS чуть ли не попиксельно. Poorly, разумеется...
Что касается использования условных точек останова - это верно, торможение от их использования в общем случае будет существенным. И в условиях разработки "на своей базе" действительно в большинстве случаев лучше просто явно добавить в код соответствующий
ifи перекомпилировать.Но иногда приходится отлаживаться и "на вражеской территории", то есть на клиентском оборудовании и в клиентском окружении, голым
gdbбез возможности редактирования и/или перекомпиляции кода. В таких случаях помогает стратегическое создание в критических точках кода специальных параметризуемыхif-закладок, призванных отлавливать наиболее часто встречающиеся потребности в условной остановке. То есть что-то вродеРазумеется, все возможные необходимости для постановки условных точек останова заранее не предугадаешь, но тем не менее очень существенная их доля прекрасно покрывается вот таким планированием на будущее еще на этапе разработки кода.
Несколько раз перечитал раздел, но не нашел никакого объяснения...
Совершенно не понятно, почему вы ассоциируете разницу в коде с разрядностью платформы. Разрядность платформы тут совершенно ни при чем, а все зависит от настроек кодогенератора и в первую очередь от настроек оптимизации. Зависимость от разрядности платформы - это не более чем паразитная/случайная зависимость. И судя по вашим экспериментам, вы выполняли их в отладочной конфигурации, что является весьма странной затеей.
Это проблему такими директивами условной компиляции не решить. Или, точнее, это будет "решение", которое очень запросто "превратится в тыкву" в самый неожиданный момент.
Я так и не смог понять, что имеется в виду под "ansi style". Автор местами использует фичи C99, но при этом валит объявления переменных в одну кучу в начале функции и избегает инициализации... С const тоже винегрет: где-то есть, где-то нет.
Но целью автора кода было именно подчеркнутое использование только и исключительно С, а не С++. Почему вдруг зашла речь о С++?
Что это за белиберда?
Вся идея идиомы
do { ... } while(0)в макросах критически основана на том, что в самом макросе ни в коем случае не должно быть;послеwhile (0). Кто и зачем влепил туда эту;?Если у автора это "работает" в коде, значит ему вообще не нужна была эта идиома. Можно было пользоваться просто парой
{ ... }. Зачем он слепо вставлял в свои макросы все этоdo { ... } while(0)?Это просто классический пример карго-культа: где-то в чьих-то макросах увидел это
do { } while(0)и слепо повторяет, совершенно не понимая, зачем все это делается и как это должно работать."Asset"? Может аssert?