Вы можете увидеть, что код с memset и без компилируется одинаково, если компилятор может доказать, что ваш массив с секретом не используется после memset.
По 0х13, ENSURE(secretKeyPwa[0] == 0); всё ещё неправильно. Ваш memset всё так же может быть выброшен по as-if-rule. Используйте memset_s, для него не нужны никакие костыли, тем более не гарантированные стандартом.
Нет, зависимость не от культуры. Встроенный калькулятор Windows, например, в ранних версиях вычислял выражения сразу при вводе. В результате 2 + 2 × 2 вычислялось так: 2 + 2 даёт сразу 4, пользователь дописывал × 2 и получал 8. Так работали многие старые, «железные» калькуляторы. Более свежие версии учитывают приоритет операций, и откладывают вычисление и показ промежуточного результата до момента, когда этот промежуточный результат более не сможет измениться дальнейшим вводом пользователя.
По поводу скобок, если вы вводите длинное выражение (например, 1 + 2 / 3 + 4), скобки были бы полезны для случая, если вам на самом деле надо (1 + 2) / (3 + 4).
Под рабочим диапазоном я понимаю диапазон [−10⁹⁹, 10⁹⁹], как указано в статье.
Из требований, которые неплохо было бы уточнить: раз нам позволяется вводить выражения большой длины, то нужно установить приоритет операций (2 + 2 × 2 — это 6 или 8?), а также, очевидно, разрешить скобочные выражения.
Также следует определить реакцию на синтаксические ошибки (как интерпретировать ввод "1 + ="?). Со скобками количество различных синтаксических ошибок увеличивается.
Далее, у нас есть возможность переполнения рабочего диапазона даже при вводе, ну и при сложении тоже, как её обрабатывать? А что если при промежуточных вычислениях случается переполнение рабчего диапазона, но ответ может быть вычислен всё равно? (MAX + 1 − 1)
Далее, десятичные разделители и разделители тысяч, нужны? Должны ли зависеть от локали? И что такое локаль — системный язык или задаётся юзером в настройках?
Ну например размерность можно считать так. Отрезок имеет размерность 1: если вы возьмёте вдвое меньшие отрезки, то чтобы составить исходный отрезок, их нужно 2¹ штук. Квадрат имеет размерность 2: если вы возьмёте вдвое меньшие (линейно) квадраты, то чтобы составить исходный квадрат, их нужно 2² штук. По той же причине куб имеет размерность 3. А вот салфетка Серпинского интереснее: вам понадобится 3 штуки вдвое меньших салфеток, чтобы составить одну исходного размера. Поэтому размерность d салфетки Серпинского считается как решение 2ᵈ = 3, то есть d = ln 3 / ln 2 = log₂ 3.
Например, если взять отравленное значение и проделать с ним and 0, можно предположить, что результат всегда будет 0
Нет, нельзя. UB — это UB всегда. «Значение», полученное в результате UB, имеет право быть сильно отравленным, например, как описано тут, и убить ваш процесс.
Извините, вы безапеляционно заявляете, будто бы ТеХ бесполезен, а можете ли вы обосновать? В защиту ТеХа: автор может поставить ТеХовский исходник, который можно скомпилировать под любой выходной формат на конечном устройстве. В форматы с изменяемой в рантайме шириной, наподобие html, не компилируется, ну так не проблема скомпилировать под конкретно нужную ширину экрана. Скорость компиляции невысокая, в частности, потому, что целью ТеХа является высокое качество производимого вывода (например, там используется нежадный алгоритм разбиения на строки).
Это вовсе не бесполезная фича. Из-за того, что в дотнете каждый объект может служить мьютексом, приходится выделять дополнительные байты в заголовке каждого объекта для обслуживающей информации: номер потока, держащего блокировку, и текущее количество рекурсивных блокировок (подробнее тут). Чтобы изгнать эту в обычном случае ненужную информацию из объекта, нужно для начала запилить специальный тип объекта, который таки будет служить мьютексом. Вот этим и занимается данный proposal.
Возможно, ТС недопонял задание. Или, возможно, нужно было поддерживать эти списки всегда в отсортированном состоянии, чтобы иметь возможность фильтровать однопроходным алгоритмом. Кто его знает, какое решение авторы задачи имели в виду, когда давали её?
По поводу handwaving, тут скорее всего имелся в виду этот смысл, что наверное лучше перевести как «бездоказательно». Так что «поверьте на слово» — адекватный перевод.
Насчёт тотиента, в Википедии в этом месте упоминается именно функция Эйлера, называемая на английском totient function. (Я, кажется, вовсе не встречал слова «тотиент» в русскоязычном употреблении.)
По поводу факторизации, правильно не «факторизации больших простых чисел», а «факторизации произведений больших простых чисел». Смысл в том, что перемножить два больших простых числа легко, а вот извлечь из произведения эти простые числа обратно (то есть, разложить произведение на множители) сложно.
По поводу wrapping operations, имеется в виду поведение при переполнении. Если при сложении 32-битных чисел результат выходит за 32 бита, то можно либо завершить операцию аварийно (checked operations), либо игнорировать биты старше 32, при этом значение как бы «заворачивается» (wraps around maximum), и получается результат, верный лишь по модулю 2³² (описано, например, здесь). [Примечание для зануд: да, я знаю о представлениях отрицательных чисел не в дополнительном коде.] То же происходит и при умножении.
The most common result of an overflow is that the least significant representable digits of the result are stored; the result is said to wrap around the maximum (i.e. modulo a power of the radix, usually two in modern computers, but sometimes ten or another radix).
А также handwaving — это вовсе не «махание руками», а скорее «пустой трёп».
А также Euler's totient — это просто функция Эйлера.
А также factoring the product of large prime numbers — это не факторизация больших простых чисел (простые числа потому и простые, что они факторизуются тривиальным образом).
А также wrapping operations — это не «обёртывающие операции», а скорее «вычисления по модулю».
Даже если бы это было проблемой, memory safety — это когда невозможно вместо объекта получить неинициализированную память (или попасть в середину чужого объекта), а не утечки памяти.
Если Вы хотите определить движение чисто математически (кинематически)
Подождите, а что, есть какое-то ещё нормальное определение движения? Я не имею в виду метафизику, я имею в виду нечто проверяемое на практике.
А если мы определяем движение как параметр тела, который всегда присутствует, но проявляет себя через изменение положения на разных кадрах
Это какая-то игра словами, простите. Определения, очевидно, эквивалентны, т. к. в движении более ничего, кроме смены положений, нет.
Но даже если определять движение через скорость, как вы предлагаете, то всё равно непонятно, почему этот хитрый параметр должен быть «виден» на кадре, что бы это не значило. Откуда взялся парадокс, не вижу. Кто-то постулировал, что на картинке обязательно должны быть видны все параметры? Ну так тепературу тоже не видно, так что, её нет?
Давайте ещё раз: с моей точки зрения, совершенно очевидно и непосредственно следует из определения, что никакого движения «на одном кадре» нет, движение про различие между кадрами. Поэтому весь парадокс выглядит так: выдумали нелогичное и неверное предположение, получили из него нонсенс в качестве следствия, удивились.
Вы можете увидеть, что код с memset и без компилируется одинаково, если компилятор может доказать, что ваш массив с секретом не используется после memset.
По 0х13,
ENSURE(secretKeyPwa[0] == 0);всё ещё неправильно. Вашmemsetвсё так же может быть выброшен по as-if-rule. Используйтеmemset_s, для него не нужны никакие костыли, тем более не гарантированные стандартом.Нет, зависимость не от культуры. Встроенный калькулятор Windows, например, в ранних версиях вычислял выражения сразу при вводе. В результате 2 + 2 × 2 вычислялось так: 2 + 2 даёт сразу 4, пользователь дописывал × 2 и получал 8. Так работали многие старые, «железные» калькуляторы. Более свежие версии учитывают приоритет операций, и откладывают вычисление и показ промежуточного результата до момента, когда этот промежуточный результат более не сможет измениться дальнейшим вводом пользователя.
По поводу скобок, если вы вводите длинное выражение (например, 1 + 2 / 3 + 4), скобки были бы полезны для случая, если вам на самом деле надо (1 + 2) / (3 + 4).
Под рабочим диапазоном я понимаю диапазон [−10⁹⁹, 10⁹⁹], как указано в статье.
Из требований, которые неплохо было бы уточнить: раз нам позволяется вводить выражения большой длины, то нужно установить приоритет операций (2 + 2 × 2 — это 6 или 8?), а также, очевидно, разрешить скобочные выражения.
Также следует определить реакцию на синтаксические ошибки (как интерпретировать ввод "1 + ="?). Со скобками количество различных синтаксических ошибок увеличивается.
Далее, у нас есть возможность переполнения рабочего диапазона даже при вводе, ну и при сложении тоже, как её обрабатывать? А что если при промежуточных вычислениях случается переполнение рабчего диапазона, но ответ может быть вычислен всё равно? (MAX + 1 − 1)
Далее, десятичные разделители и разделители тысяч, нужны? Должны ли зависеть от локали? И что такое локаль — системный язык или задаётся юзером в настройках?
Требования можно улучшать до бесконечности.
умеет форматировать xml и json?
Ну например размерность можно считать так.
Отрезок имеет размерность 1: если вы возьмёте вдвое меньшие отрезки, то чтобы составить исходный отрезок, их нужно 2¹ штук.
Квадрат имеет размерность 2: если вы возьмёте вдвое меньшие (линейно) квадраты, то чтобы составить исходный квадрат, их нужно 2² штук.
По той же причине куб имеет размерность 3.
А вот салфетка Серпинского интереснее: вам понадобится 3 штуки вдвое меньших салфеток, чтобы составить одну исходного размера. Поэтому размерность d салфетки Серпинского считается как решение 2ᵈ = 3, то есть d = ln 3 / ln 2 = log₂ 3.
Но нельзя исходить из того, что это сойдёт с рук.
Вы придираетесь к словам. «Можно предположить...» в данном контексте означает «Мы имеем право считать что...». А Стандарт такого права не даёт.
Нет, нельзя. UB — это UB всегда. «Значение», полученное в результате UB, имеет право быть сильно отравленным, например, как описано тут, и убить ваш процесс.
Извините, вы безапеляционно заявляете, будто бы ТеХ бесполезен, а можете ли вы обосновать?
В защиту ТеХа: автор может поставить ТеХовский исходник, который можно скомпилировать под любой выходной формат на конечном устройстве.
В форматы с изменяемой в рантайме шириной, наподобие html, не компилируется, ну так не проблема скомпилировать под конкретно нужную ширину экрана.
Скорость компиляции невысокая, в частности, потому, что целью ТеХа является высокое качество производимого вывода (например, там используется нежадный алгоритм разбиения на строки).
— У Эпла найдена жирная дыра в безопасности!
— А
в Америке негрову китайфонов что нет проблем?Это вовсе не бесполезная фича.
Из-за того, что в дотнете каждый объект может служить мьютексом, приходится выделять дополнительные байты в заголовке каждого объекта для обслуживающей информации: номер потока, держащего блокировку, и текущее количество рекурсивных блокировок (подробнее тут). Чтобы изгнать эту в обычном случае ненужную информацию из объекта, нужно для начала запилить специальный тип объекта, который таки будет служить мьютексом.
Вот этим и занимается данный proposal.
Ну вот и надо нафонтанировать идей, чтобы интервьюер не успел вставить и слова.
Возможно, ТС недопонял задание. Или, возможно, нужно было поддерживать эти списки всегда в отсортированном состоянии, чтобы иметь возможность фильтровать однопроходным алгоритмом. Кто его знает, какое решение авторы задачи имели в виду, когда давали её?
Возможно, они считали списки предварительно отсортированными, и хотели чтобы вы прошли двумя указателями по обоим спискам (типа как merge наоборот).
По поводу handwaving, тут скорее всего имелся в виду этот смысл, что наверное лучше перевести как «бездоказательно». Так что «поверьте на слово» — адекватный перевод.
Насчёт тотиента, в Википедии в этом месте упоминается именно функция Эйлера, называемая на английском totient function. (Я, кажется, вовсе не встречал слова «тотиент» в русскоязычном употреблении.)
По поводу факторизации, правильно не «факторизации больших простых чисел», а «факторизации произведений больших простых чисел». Смысл в том, что перемножить два больших простых числа легко, а вот извлечь из произведения эти простые числа обратно (то есть, разложить произведение на множители) сложно.
По поводу wrapping operations, имеется в виду поведение при переполнении. Если при сложении 32-битных чисел результат выходит за 32 бита, то можно либо завершить операцию аварийно (checked operations), либо игнорировать биты старше 32, при этом значение как бы «заворачивается» (wraps around maximum), и получается результат, верный лишь по модулю 2³² (описано, например, здесь). [Примечание для зануд: да, я знаю о представлениях отрицательных чисел не в дополнительном коде.] То же происходит и при умножении.
В английской версии той же статьи Википедии:
А также handwaving — это вовсе не «махание руками», а скорее «пустой трёп».
А также Euler's totient — это просто функция Эйлера.
А также factoring the product of large prime numbers — это не факторизация больших простых чисел (простые числа потому и простые, что они факторизуются тривиальным образом).
А также wrapping operations — это не «обёртывающие операции», а скорее «вычисления по модулю».
Даже если бы это было проблемой, memory safety — это когда невозможно вместо объекта получить неинициализированную память (или попасть в середину чужого объекта), а не утечки памяти.
И в чём тут проблема?
Подождите, а что, есть какое-то ещё нормальное определение движения? Я не имею в виду метафизику, я имею в виду нечто проверяемое на практике.
Это какая-то игра словами, простите. Определения, очевидно, эквивалентны, т. к. в движении более ничего, кроме смены положений, нет.
Но даже если определять движение через скорость, как вы предлагаете, то всё равно непонятно, почему этот хитрый параметр должен быть «виден» на кадре, что бы это не значило. Откуда взялся парадокс, не вижу. Кто-то постулировал, что на картинке обязательно должны быть видны все параметры? Ну так тепературу тоже не видно, так что, её нет?
Давайте ещё раз: с моей точки зрения, совершенно очевидно и непосредственно следует из определения, что никакого движения «на одном кадре» нет, движение про различие между кадрами.
Поэтому весь парадокс выглядит так: выдумали нелогичное и неверное предположение, получили из него нонсенс в качестве следствия, удивились.