Только тем, что незачем преумножать сущности без необходимости. Зачем притягивать сюда за уши библиотечную функцию memset, когда ядро языка уже предоставляет вам встроенные возможности для выполнения инициализации?
Точно так же можно вызывать какую-нибудь библиотечную функцию для того, чтобы увеличить переменную на 1, вместо классического ++i. Чем это плохо? Да, вроде, ничем... Но зачем?!
И, еще раз, в глаза бросается именно то, что вы сами использовали термин "инициализация", но при этом почему-то не воспользовались предоставляемыми вам языком С возможностями инициализации.
И почему возврат int чем-то может не устраивать?
"Не устраивает" не сам возврат int, а тот факт, что функция очевидно ничего осмысленного не возвращает в этом int. Зачем тогда было делать ее int, если можно было сделать ее void? Зачем взваливать на плечи читателя кода вопрос о том, что же это за возвращаемое значение, только для того, чтобы он в результате выяснил, что это возвращаемое значение никакого смысла не несет?
Перед чтением файла программа узнает размер файла и создаёт массив который соответствует размеру файла и только потом файл считается в массив.
Так о том и речь. Вы создаете автоматический VLA, размер которого равен размеру файла. Размер файла запросто может оказаться слишком большим для автоматического объекта. Не создавайте потенциально большие объекты "на стеке". Это добром не кончится.
Чтобы интерпретатор работал надо подключить определённые библиотеки
С каких это пор стандартные заголовки стали назваться "библиотеками"?
char * plus = "+";
Язык С конечно же не требует const здесь, но это не причина не придерживаться элементарных правил константной корректности.
memset(stack, 0, 30000);
Обнуление агрегата при помощи memset в 2022 году? Да еще и с явным указанием размера через магическую константу??? И это при том, что верный термин "инициализация" вам таки знаком. Может быть стоило действительно воспользоваться инициализацией
char stack[30000] = { 0 };
gets(command);
O_o. Лолшто???
for (int x = 0; x < sizeof(command); x++) {
Интересно заметить, что в этом месте автор догадался использовать sizeof, пусть даже и с лишними скобками. Почему же тогда в memset выше была использована магическая константа?
int bf_shell()
Зачем эта функция возвращает int? И, пока не наступила эра C23, все таки пожалуйста
int bf_shell(void)
long size = ftell(file); fseek(file, 0L, SEEK_SET);
char buf[size];
Чтение целого файла в локальный VLA - весьма рискованная идея.
Когда речь зашла про углы, я сразу догадался, что "ЦОС" - это некая профессиональная аббревиатура, обозначающая полярную систему координат. Сразу стало понятно, что "С" - это "система". "Ц", как несложно догадаться - это "центр" или "центральная". Сейчас работаю над расшифровкой "О"... Пока что ничего не получается. "Округлая"? Подходит, но все вместе че-то как-то вычурно звучит. В общем, запустил программу брутфорсинга с нейросетью, к утру все должно получиться.
Статью я понял доскнально, но кое какие мелкие сомнения/вопросы к автору все таки еще теплятся. В частности: каким боком полярная система координат относится к DSP? Не хочется ударить в грязь лицом, когда спрашивать буду. В общем ждите, через несколько часов сообщу полную расшифровку.
if (NULL == method) report_and_exit("TLSv1_2_client_method...");
Йода-условия, чтобы код было "приятнее" читать... И if, записанный в одну строчку, чтобы код было "приятнее" отлаживать...
Египетские скобки трогать не буду, ибо холивар.
А вот объявления переменных, которые частично свалены в одну кучу в начале функции, а частично сделаны локально по месту - отдельная гнилая вишенка на торте удобочитаемости... и, как следствие, ужас memset(response, '\0', sizeof(response)).
В Турции ограничение на вывоз валюты составляет 5k на человека, а не 10k. И, что интересно, вывоз более 5k запрещен. Не "требует явной декларации", как во многих других странах, а именно запрещен напрочь.
Что за чушь? Кто сказал, что оно должно быть с оверхедом? Type erasure должно быть type erasure. А уж как вы его реализауете - это ваше дело. Сумеете без оверхеда - прекрасно.
Но в std::span нет никакого type erasure даже отдаленно. Об этом речь, а не об отсутствии оверхеда.
Про std::functionспору нет - это классический пример настоящего type erasure. std::function- это фактически специализированный вариант std::any, адаптированный специально под нужды функциональных объектов.
А std::span<T> - это ни что иное как тонкий адаптор над обычным массивом. Очень тонкий. То есть это просто указатель T * и размер. Все, с чем он может работать, должно тривиально превращаться в указатель и размер. Маловато для гордого звания type erasure.
Что-то много воды понаписано для объема. Нет никакого "type erasure" в любых формах compile-time типизации. T * - это не type erasure. std::span<T> - это не type erasure. А не то такими темпами мы вообще все шаблонное программирование запишем в type erasure. Или пойдем дальше и фактически поставим знак эквивалентности между type erasure и любыми формами полиморфизма, включая compile-time полиморфизм. Зачем тогда придумывать новый термин, если термин "полиморфизм" уже есть?
Ищите людей. Чисто по сумме IQ один возвращающийся в Россию равен примерно 70-80 тысячам мечтателей уехать в США. Надо же поддерживать разумный баланс.
Если кто-то еще зачем-то пользуется мозиллой, то поисковики туда легко добавляются вручную. Всякое дерьмо, вроде гугла, разумеется, сразу удаляется уже давно. УткаГоГо, насколько я знаю, тоже недавно ляпала что-то ртом в поддержку нациков, т.е. тоже идет туда, где солнышко не светит. Сразу добавляем Яндекс и, как я понимаю, по бингу финального вердикта еще нет, то есть его можно пока использовать в качестве альтернативы.
Как-то не раскрыта тема: человек давно живет в США, но хочет собрать манатки и все свои сбережения и вернуться в Россию/Беларусь. Как везти деньги? Вроде в начале статьи что-то такое анонсируется, но потом по тексту пошла чепуха для хипстеров про выезд в "свободный мир"...
Да это ж совсем не фокус. Фокус - это как во время недавнего американского скандала с блатными/взяточными поступлениями детишек богатеньких/прикормушечных родителей в университеты Ivy League выяснилось, что очное (!) тестирование за уточтенных девочек сдавал волосатый сорокалетний мужик. Даже не гримировался. И никто не замечал подмены. А тут одного "Джона" другим подменили - и уже сенсация...
Не имеет никакого значения, в каком порядке укладываются байты в регистре, если у нас нет возможности "увидеть" этот порядок тем или иным образом, т.е. наткнуться на некую зависимость от этого порядка. Понятия endianness не существует, пока у нас нет возможности адресовать части целого (не обязательно байты).
Кто-то может возразить, что в регистрах процессора у нас есть возможность адресовать части целого. А именно, регистр al является частью ax, ax является частью eax, а eax является частью rax. Однако эти подразделения по определению обладают не адресной семантикой, а семантикой позиционной значимости (как значимости разрядов в позиционной системе счисления). Определение eax сразу однозначно говорит нам, что это младшаяпо значимости часть rax. То есть это совсем не адресация, а арифметическое подразбиение, и нас тут совершенно не интересует, где и как "хранится" rax, ибо мы всегда знаем что eax обязательно даст нам младшую по арифметической значимости половину rax. То есть это не вопрос endianness вообще.
Деление на "little endian/big endian" относится к тому, как старшие/младшие по значимости байты представления значения проецируются на старшие/младшие адреса памяти. Понятие "little endian/big endian" применимо только к представлению данных в адресуемой (побайтно) памяти. К регистрам процессора это деление неприменимо.
Так вот же она выше - уже предъявлена прямо в статье. (Понятно, что последователность Фибоначчи будут генерировать оба варианта поведения, но расклад результата по регистрам будет разным.)
В качестве удобного правила постарайтесь запомнить, что команды ассемблера x86 формируют результат в первом операнде (для Intel-синтаксиса). Это простое правило срабатывает и здесь: сумма после выполнения xadd находится в первом операнде. Вот поэтому: сначала она меняет их местами, а потом складывает.
Если бы команда сначала складывала, а потом меняла местами, то сумма оказалась бы во втором операнде. Видите, какая бы ерунда получилась?
Тут используется побочная/альтернативная терминология, введенная в начале статьи. В теории обобщенной выпуклости и аналогичных областях термин "облочка" ("hull") - однозначно определен, как минималное содержащее множдество, обладающее интересующими нас свойствами (напр. выпуклостью). То есть оболочки всегда минимальны по определению, а "минимальная выпуклая оболочка" - это уже бросающися в глаза пример "масла масляного". Соответственно в литературе обычно всегда ведется речь о просто выпуклой оболочке. Никто не называет ее минимальной.
[&, x, &y] // захват всех переменных по ссылке, кроме x…
Если указан захват по умолчанию &, то все явные захваты должны быть по значению. То есть &y в данном списке не допускается.
И наоборот, если указан захват по умолчанию =, то все явные захваты должны быть по ссылке.
Изначально я предположил, что в 2009 году черновая версия спецификации не содержала такого ограничения, но несложно проверить, что это ограничение присутствовало с самого начала.
Только тем, что незачем преумножать сущности без необходимости. Зачем притягивать сюда за уши библиотечную функцию
memset, когда ядро языка уже предоставляет вам встроенные возможности для выполнения инициализации?Точно так же можно вызывать какую-нибудь библиотечную функцию для того, чтобы увеличить переменную на 1, вместо классического
++i. Чем это плохо? Да, вроде, ничем... Но зачем?!И, еще раз, в глаза бросается именно то, что вы сами использовали термин "инициализация", но при этом почему-то не воспользовались предоставляемыми вам языком С возможностями инициализации.
"Не устраивает" не сам возврат
int, а тот факт, что функция очевидно ничего осмысленного не возвращает в этомint. Зачем тогда было делать ееint, если можно было сделать ееvoid? Зачем взваливать на плечи читателя кода вопрос о том, что же это за возвращаемое значение, только для того, чтобы он в результате выяснил, что это возвращаемое значение никакого смысла не несет?Так о том и речь. Вы создаете автоматический VLA, размер которого равен размеру файла. Размер файла запросто может оказаться слишком большим для автоматического объекта. Не создавайте потенциально большие объекты "на стеке". Это добром не кончится.
С каких это пор стандартные заголовки стали назваться "библиотеками"?
Язык С конечно же не требует
constздесь, но это не причина не придерживаться элементарных правил константной корректности.Обнуление агрегата при помощи
memsetв 2022 году? Да еще и с явным указанием размера через магическую константу??? И это при том, что верный термин "инициализация" вам таки знаком. Может быть стоило действительно воспользоваться инициализациейchar stack[30000] = { 0 };O_o. Лолшто???
Интересно заметить, что в этом месте автор догадался использовать
sizeof, пусть даже и с лишними скобками. Почему же тогда вmemsetвыше была использована магическая константа?Зачем эта функция возвращает
int? И, пока не наступила эра C23, все таки пожалуйстаint bf_shell(void)Чтение целого файла в локальный VLA - весьма рискованная идея.
Демагогический прием, на основе которого построена эта статья, называется "ad absurdum". Но к чему это здесь?
Когда речь зашла про углы, я сразу догадался, что "ЦОС" - это некая профессиональная аббревиатура, обозначающая полярную систему координат. Сразу стало понятно, что "С" - это "система". "Ц", как несложно догадаться - это "центр" или "центральная". Сейчас работаю над расшифровкой "О"... Пока что ничего не получается. "Округлая"? Подходит, но все вместе че-то как-то вычурно звучит. В общем, запустил программу брутфорсинга с нейросетью, к утру все должно получиться.
Статью я понял доскнально, но кое какие мелкие сомнения/вопросы к автору все таки еще теплятся. В частности: каким боком полярная система координат относится к DSP? Не хочется ударить в грязь лицом, когда спрашивать буду. В общем ждите, через несколько часов сообщу полную расшифровку.
Йода-условия, чтобы код было "приятнее" читать... И
if, записанный в одну строчку, чтобы код было "приятнее" отлаживать...Египетские скобки трогать не буду, ибо холивар.
А вот объявления переменных, которые частично свалены в одну кучу в начале функции, а частично сделаны локально по месту - отдельная гнилая вишенка на торте удобочитаемости... и, как следствие, ужас
memset(response, '\0', sizeof(response)).В Турции ограничение на вывоз валюты составляет 5k на человека, а не 10k. И, что интересно, вывоз более 5k запрещен. Не "требует явной декларации", как во многих других странах, а именно запрещен напрочь.
Что за чушь? Кто сказал, что оно должно быть с оверхедом? Type erasure должно быть type erasure. А уж как вы его реализауете - это ваше дело. Сумеете без оверхеда - прекрасно.
Но в
std::spanнет никакого type erasure даже отдаленно. Об этом речь, а не об отсутствии оверхеда.Про
std::functionспору нет - это классический пример настоящего type erasure.std::function- это фактически специализированный вариантstd::any, адаптированный специально под нужды функциональных объектов.А
std::span<T>- это ни что иное как тонкий адаптор над обычным массивом. Очень тонкий. То есть это просто указательT *и размер. Все, с чем он может работать, должно тривиально превращаться в указатель и размер. Маловато для гордого звания type erasure.Что-то много воды понаписано для объема. Нет никакого "type erasure" в любых формах compile-time типизации.
T *- это не type erasure.std::span<T>- это не type erasure. А не то такими темпами мы вообще все шаблонное программирование запишем в type erasure. Или пойдем дальше и фактически поставим знак эквивалентности между type erasure и любыми формами полиморфизма, включая compile-time полиморфизм. Зачем тогда придумывать новый термин, если термин "полиморфизм" уже есть?... как закрадываеться лишний мягкий знак в глагол на -тся...
Ищите людей. Чисто по сумме IQ один возвращающийся в Россию равен примерно 70-80 тысячам мечтателей уехать в США. Надо же поддерживать разумный баланс.
Если кто-то еще зачем-то пользуется мозиллой, то поисковики туда легко добавляются вручную. Всякое дерьмо, вроде гугла, разумеется, сразу удаляется уже давно. УткаГоГо, насколько я знаю, тоже недавно ляпала что-то ртом в поддержку нациков, т.е. тоже идет туда, где солнышко не светит. Сразу добавляем Яндекс и, как я понимаю, по бингу финального вердикта еще нет, то есть его можно пока использовать в качестве альтернативы.
Как-то не раскрыта тема: человек давно живет в США, но хочет собрать манатки и все свои сбережения и вернуться в Россию/Беларусь. Как везти деньги? Вроде в начале статьи что-то такое анонсируется, но потом по тексту пошла чепуха для хипстеров про выезд в "свободный мир"...
Спрашиваю для друга.
Да это ж совсем не фокус. Фокус - это как во время недавнего американского скандала с блатными/взяточными поступлениями детишек богатеньких/прикормушечных родителей в университеты Ivy League выяснилось, что очное (!) тестирование за уточтенных девочек сдавал волосатый сорокалетний мужик. Даже не гримировался. И никто не замечал подмены. А тут одного "Джона" другим подменили - и уже сенсация...
Нет, не верно.
Не имеет никакого значения, в каком порядке укладываются байты в регистре, если у нас нет возможности "увидеть" этот порядок тем или иным образом, т.е. наткнуться на некую зависимость от этого порядка. Понятия endianness не существует, пока у нас нет возможности адресовать части целого (не обязательно байты).
Кто-то может возразить, что в регистрах процессора у нас есть возможность адресовать части целого. А именно, регистр al является частью ax, ax является частью eax, а eax является частью rax. Однако эти подразделения по определению обладают не адресной семантикой, а семантикой позиционной значимости (как значимости разрядов в позиционной системе счисления). Определение eax сразу однозначно говорит нам, что это младшая по значимости часть rax. То есть это совсем не адресация, а арифметическое подразбиение, и нас тут совершенно не интересует, где и как "хранится" rax, ибо мы всегда знаем что eax обязательно даст нам младшую по арифметической значимости половину rax. То есть это не вопрос endianness вообще.
Деление на "little endian/big endian" относится к тому, как старшие/младшие по значимости байты представления значения проецируются на старшие/младшие адреса памяти. Понятие "little endian/big endian" применимо только к представлению данных в адресуемой (побайтно) памяти. К регистрам процессора это деление неприменимо.
Так вот же она выше - уже предъявлена прямо в статье. (Понятно, что последователность Фибоначчи будут генерировать оба варианта поведения, но расклад результата по регистрам будет разным.)
В качестве удобного правила постарайтесь запомнить, что команды ассемблера x86 формируют результат в первом операнде (для Intel-синтаксиса). Это простое правило срабатывает и здесь: сумма после выполнения
xaddнаходится в первом операнде. Вот поэтому: сначала она меняет их местами, а потом складывает.Если бы команда сначала складывала, а потом меняла местами, то сумма оказалась бы во втором операнде. Видите, какая бы ерунда получилась?
Нет. Она сначала меняет их местами, а потом складывает.
Чего? С каких это пор к регистрам процессора стало применимо понятие "порядка хранения байтов"???
Тут используется побочная/альтернативная терминология, введенная в начале статьи. В теории обобщенной выпуклости и аналогичных областях термин "облочка" ("hull") - однозначно определен, как минималное содержащее множдество, обладающее интересующими нас свойствами (напр. выпуклостью). То есть оболочки всегда минимальны по определению, а "минимальная выпуклая оболочка" - это уже бросающися в глаза пример "масла масляного". Соответственно в литературе обычно всегда ведется речь о просто выпуклой оболочке. Никто не называет ее минимальной.
Статься содержит ошибку. Так не разрешается
[&, x, &y] // захват всех переменных по ссылке, кроме x…Если указан захват по умолчанию
&, то все явные захваты должны быть по значению. То есть&yв данном списке не допускается.И наоборот, если указан захват по умолчанию
=, то все явные захваты должны быть по ссылке.Изначально я предположил, что в 2009 году черновая версия спецификации не содержала такого ограничения, но несложно проверить, что это ограничение присутствовало с самого начала.