Я писал ответы на SO. И вопросы тоже. Джуновские вопросы и вопросы «на понимание темы» там заходили, а вот что-то более-менее сложное или узкоспециализированное требовало везения (чтобы пришёл тот единственный спец, который шарит). Мне чаще не везло с более специфическими темами, а по базе C# мне, например, ответил сам Эрик Липперт.
Тривиальные вещи, которые джун может не знать, на Stackoverflow быстро подсказывали. А сложные, включая «как скомпоновать простые в один проект», всегда встречались в штыки, т. к. это очевидная «работа за автора».
Всякая вещь или событие во Вселенной происходит по какой-то причине, причём эта причина находится вне рамок этой вещи или события. Любой предмет у вас под рукой кто-то сделал, причём сам этот предмет в своём рождении участия не принимал, будь то стол, компьютерная мышь, кот или занавески.
Одному мне кажется, что если сформулировать то же утверждение более многословно, и подкрепить парой примеров, то оно от этого не окажется «доказанным»?
Это автор не пробовала сделать подсветку для TeX'а. Там синтаксические категории символов (\catcode) можно менять на лету, так что без интерпретатора не обойтись. А как подсвечивать текст внутри конструкций наподобие \expandafter\csname...\endcsname, которые раскрывают макросы, а результат интерпретируют как имя команды, вообще непонятно.
Вы можете увидеть, что код с 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.
Возможно, ТС недопонял задание. Или, возможно, нужно было поддерживать эти списки всегда в отсортированном состоянии, чтобы иметь возможность фильтровать однопроходным алгоритмом. Кто его знает, какое решение авторы задачи имели в виду, когда давали её?
Я писал ответы на SO. И вопросы тоже. Джуновские вопросы и вопросы «на понимание темы» там заходили, а вот что-то более-менее сложное или узкоспециализированное требовало везения (чтобы пришёл тот единственный спец, который шарит). Мне чаще не везло с более специфическими темами, а по базе C# мне, например, ответил сам Эрик Липперт.
Тривиальные вещи, которые джун может не знать, на Stackoverflow быстро подсказывали. А сложные, включая «как скомпоновать простые в один проект», всегда встречались в штыки, т. к. это очевидная «работа за автора».
Читаем утверждение:
Потом его «доказательство»:
Одному мне кажется, что если сформулировать то же утверждение более многословно, и подкрепить парой примеров, то оно от этого не окажется «доказанным»?
Например, как подсвечивать текст после
\catcode`\\=\the\month\relax?Это автор не пробовала сделать подсветку для TeX'а. Там синтаксические категории символов (
\catcode) можно менять на лету, так что без интерпретатора не обойтись. А как подсвечивать текст внутри конструкций наподобие\expandafter\csname...\endcsname, которые раскрывают макросы, а результат интерпретируют как имя команды, вообще непонятно.Кстати, может иметь смысл, если у вас в проекте встречается перегруженный оператор
==.Вы можете увидеть, что код с 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 наоборот).