Я согласен с вами, что красивые примеры в статье таковы, что исправление квадрата в них не усложняет кода. Поэтому да, почему бы и не поправить их. И так же я согласен, что когда создаёшь библиотеку, все применения которой ты заранее не знаешь, то нужно постараться сделать адекватную асимптотику или по крайней мере задокументировать оценки производительности.
Но ведь в реальности обычно по-другому, и нет "белого" или "чёрного". Разработчик работает с километрами кодовой базы, в которой то тут, то там спрятаны квадраты. И какие-то поправить совсем легко, какие-то посложнее, а для каких-то потребуется уже отдельный мини-проект. Копья в code-review будут ломать как раз вокруг этого случая "посложнее", когда ускорение кода возможно путём некоторой потери читабельности или, скажем, расширяемости. Практический толк от каждой из таких оптимизаций будет, скорее всего, мизерным - до тех пор, пока в коде остаются другие квадраты.
Примеры красивые, но есть какие-нибудь данные о том, насколько часто "квадраты" в реальном коде возникают в таких "локальных" ситуациях - т. е. когда весь относящийся к "квадрату" код представляет собой несколько строк кода внутри одной функции?
По ощущениям, очень часто самые тяжёлые квадраты появляются из-за неудачных абстракций - и обнаружить их гораздо сложнее, потому что они "живут" на другом уровне, и для их обнаружения требуется держать в голове детали реализации разных компонентов (а исправление может потребовать редизайна абстракций или, скажем, намеренного их нарушения в конкретном месте).
И тогда может оказаться, что оптимизация работы отдельных .map()/.reduce()/и т. п. - это просто экономия на спичках, потому что настоящее бутылочное горлышко будет в других, менее очевидных местах. В таком случае чрезмерный акцент на этих локальных оптимизациях как не даст ощутимого прироста в производительности, так и, возможно, увеличит вероятность багов из-за менее читаемого кода.
Каким образом предлагается эффективно реализовать owns(), если потребовалось выделить несколько блоков? Насколько я понял предложенный дизайн, этим должен заниматься Cascading - и как раз про него сказана только пара слов ("Однако его реализация является не самой тривиальной из-за сложной логики поведения") - получается, обрывается на самом интересном...
Не будет ли из-за owns() просадки по производительности, если придётся насоздавать много блоков и, соответственно, аллокаторов?
И ещё как реализовать owns(), если мы хотим такой аллокатор, который, скажем, будет вызывать mmap для больших аллокаций. Ведь адреса, возвращаемые mmap, непредсказуемые, в том смысле, что range-проверки недостаточно.
Мда, теперь понятно, что salted sessions - это не просто наворот "для галочки" (как я по наивности предполагал - ну, вернее, защита от сферических коней в вакууме), а реальная защита от вполне реальных атак...
Ваше объяснение некорректно - как минимум, у вас куда-то константные ссылки потерялись... Во многом ведь из-за них весь сыр-бор с std::forward(), коллапсом ссылок в шаблонах и прочими ещё более странными наворотами.
Кроме того, из вашего объяснения можно получить неверное представление, что якобы из обычной ссылки нельзя сделать rvalue-ссылку (ведь вызывающий код не отказывался от владения, так? однако сделать std::move() в функции никто не запретит, так что получится, что как бы можно "заставить" вызывающий код отказаться от владения?). И вообще, даже с lvalue-ссылкой функция может сделать с объектом что угодно.
Ну, новичков можно понять, ведь достаточно малейшего изменения в этом паттерне, чтобы внезапно возникала ненужная копия, и снова требовался бы std::move(). Например, если возвращать не s, а поле x из структуры struct Foo {std::string x;}. И RVO, несмотря на кажущуюся похожесть этого случая, тут не сработает. Всё-таки семантика перемещения в C++ очень неинтуитивна.
А вы наверное не филолог. Вы из тех кому нравится "репортёрка" и "в Строгине" - по правилам новояза, но не по-русски.
«Вы знаете, я считаю неприличным делать замечания людям, если они неверно говорят. Неприличным и пошлым. Ничего не поправляю, всё переношу. Но вот «во сколько» вместо «в котором часу» или вместо «когда», — тут она задохнулась от гнева и дальше произнесла по складам, — я вы-нес-ти не мо-гу. И «мы живем в Кратово» вместо «в Кратове» — тоже не могу»
(цитата А. Ахматовой из «Записок об Анне Ахматовой» Л. К. Чуковской)
"Миф № 1. Географические названия на -ово, -ево, -ино, -ыно не склоняются и никогда не склонялись. Варианты в Болдине, из Останкина, в Пулкове – «новояз», безграмотность, порча языка. <...> На самом деле: Географические названия славянского происхождения, оканчивающиеся на -ово, -ево, -ино, -ыно, традиционно склонялись: в Останкине, в Переделкине, к Болдину, до Пулкова, из Косова. Тенденция к употреблению несклоняемого варианта сложилась лишь в последние десятилетия. Иными словами, новая норма – не в Люблине, а в Люблино."
Что-то странное - накручивали-накручивали деревья поверх списков, а в итоге получили асимптотику O(N +E) - и чем же она лучше тривиального алгоритма с линейным проходом слева направо?
Уверен, что если ре-парсинг не нужен, то задачу можно решить за log N + E - есть много структур данных, которые умеют прибавление на отрезке и вставку/удаление элементов в середине. Например, декартовы деревья. А если ре-парсинг нужен, то ведь и смысла нет оптимизировать поиск скобок быстрее стандартного линейного алгоритма?
P.S. Немного напоминает мне, как во время одного собеседования разработчик из Индии хвалился своим "знанием" алгоритмов и рассказывал, как он оптимизировал запросы к базе данных путём создания сбалансированных двоичных деревьев *во время обработки каждого запроса*. Т. е. база данных отвечает списком объектов, которые надо пофильтровать каким-то простым критерием вроде "мин. элемент >= X", и они для этого пихали весь ответ из базы в дерево, чтобы потом спуститься по дереву и найти нужный элемент. В общем, главное - прикрутили умный алгоритм, а что толка от него нет, поскольку перед этим всё равно линейный алгоритм работает - не важно.
Пример про "вибрацию луча" как-то совсем непонятен... Вообще, что такое вибрация луча? Кто вибрирует - сам луч или тело, на которое он падает?
"Вибрация луча вызывает уменьшение отражаемого им света" - здесь "им" относится к самому лучу или к чему-то другому?
"Через несколько десятков миллисекунд вибрация становится локализованной в массиве лучей, что приводит к появлению тёмной горизонтальной линии" - Какой массив лучей имеется здесь в виду?..
В Германии ни одна из "мэйнстримовых" партий не одобряет ядерную энергетику. Получается, как бы, замкнутый круг - но избиратели, выходит, его не замечают...
А когда? В аристократических кругах ещё за много веков до Бальзака продолжительность жизни (среди тех, кто преодолел детский возраст) была гораздо больше. Например, https://en.wikipedia.org/wiki/Life_expectancy говорит, что ещё в XV в. она составляла 69 лет для английской аристократии. А среди не-аристократии понятие "пенсионер" даже иносказательно трудно прикрутить...
Так непосредственно сразу после изобретения чего бы то ни было оно всегда дорого поначалу; другое дело - сколько оно будет стоить через пару лет и при условии достаточных инвестиций? В статье обещают, что их технология совместима с обычными производственными процессами ("compatibility with commercial paint fabrication process"), но это уже может значить что угодно...
На графике "WOC availability", визуально, самые плохие показатели - в Германии, Италии, Чехии (?), Австралии, Гренландии. Есть ли какое-нибудь объяснение, почему именно там? Например, почему в Германии, но не в её соседях Франции, Великобритании, Швеции?
Может быть, пример из статьи не совсем информативный? Ведь если проход на вечеринку осуществляется один раз, то достаточно, чтобы у каждого был приглашённого был рандомный приватный ключ, публичная часть которого подписана организатором. Т. е. протокол был бы таким:
Подготовка:
1. Организатор генерирует пару ключей, и сообщает привратнику публичную часть.
2. Каждый приглашённый генерирует свою пару ключей, и сообщает организатору публичную часть.
3. Организатор отправляет каждому приглашённому подпись публичного ключа этого приглашённого, сделанную с помощью приватного ключа организатора.
Пропуск на вечеринку:
0. Организатор сообщает привратнику список отозванных публичных ключей (соответствующих людям, которых организатор передумал приглашать).
1. При появлении гостя, привратник генерирует рандомный nonce и просит гостя подписать его.
2. Гость отвечает двумя блобами: подписью nonce, сделанную его собственным приватным ключом, и подписью публичного ключа, полученную от организатора.
3. Привратник проверяет эти две подписи и проверяет список отозванных ключей, после чего пускает или не пускает гостя.
По сути, это вариация на стандартную тему remote attestation protocol, который, например, используется в TPM-чипах (например, насколько я знаю, DRM-системы уже используют такое в продакшене, чтобы отличать "своих"/"чужих" клиентов, не зная при этом настоящего идентификатора каждого пользователя).
Какое требование из описанной в статье задаче делает этот протокол неподходящим?
Я согласен с вами, что красивые примеры в статье таковы, что исправление квадрата в них не усложняет кода. Поэтому да, почему бы и не поправить их. И так же я согласен, что когда создаёшь библиотеку, все применения которой ты заранее не знаешь, то нужно постараться сделать адекватную асимптотику или по крайней мере задокументировать оценки производительности.
Но ведь в реальности обычно по-другому, и нет "белого" или "чёрного". Разработчик работает с километрами кодовой базы, в которой то тут, то там спрятаны квадраты. И какие-то поправить совсем легко, какие-то посложнее, а для каких-то потребуется уже отдельный мини-проект. Копья в code-review будут ломать как раз вокруг этого случая "посложнее", когда ускорение кода возможно путём некоторой потери читабельности или, скажем, расширяемости. Практический толк от каждой из таких оптимизаций будет, скорее всего, мизерным - до тех пор, пока в коде остаются другие квадраты.
Примеры красивые, но есть какие-нибудь данные о том, насколько часто "квадраты" в реальном коде возникают в таких "локальных" ситуациях - т. е. когда весь относящийся к "квадрату" код представляет собой несколько строк кода внутри одной функции?
По ощущениям, очень часто самые тяжёлые квадраты появляются из-за неудачных абстракций - и обнаружить их гораздо сложнее, потому что они "живут" на другом уровне, и для их обнаружения требуется держать в голове детали реализации разных компонентов (а исправление может потребовать редизайна абстракций или, скажем, намеренного их нарушения в конкретном месте).
И тогда может оказаться, что оптимизация работы отдельных .map()/.reduce()/и т. п. - это просто экономия на спичках, потому что настоящее бутылочное горлышко будет в других, менее очевидных местах. В таком случае чрезмерный акцент на этих локальных оптимизациях как не даст ощутимого прироста в производительности, так и, возможно, увеличит вероятность багов из-за менее читаемого кода.
Каким образом предлагается эффективно реализовать owns(), если потребовалось выделить несколько блоков? Насколько я понял предложенный дизайн, этим должен заниматься Cascading - и как раз про него сказана только пара слов ("Однако его реализация является не самой тривиальной из-за сложной логики поведения") - получается, обрывается на самом интересном...
Не будет ли из-за owns() просадки по производительности, если придётся насоздавать много блоков и, соответственно, аллокаторов?
И ещё как реализовать owns(), если мы хотим такой аллокатор, который, скажем, будет вызывать mmap для больших аллокаций. Ведь адреса, возвращаемые mmap, непредсказуемые, в том смысле, что range-проверки недостаточно.
"С пятью десятками домашних кошек" могло быть.
Не обязательно - достаточно использовать шифрование при передаче данных. Все протоколы и средства для этого есть, Microsoft лишь не применила их...
Мда, теперь понятно, что salted sessions - это не просто наворот "для галочки" (как я по наивности предполагал - ну, вернее, защита от сферических коней в вакууме), а реальная защита от вполне реальных атак...
Есть несколько статей, которые предлагают "destructive move" в качестве альтернативной модели. Это как раз то, что используется в Rust.
https://www.thecodedmessage.com/posts/cpp-move/
https://www.foonathan.net/2017/09/destructive-move/
Ваше объяснение некорректно - как минимум, у вас куда-то константные ссылки потерялись... Во многом ведь из-за них весь сыр-бор с std::forward(), коллапсом ссылок в шаблонах и прочими ещё более странными наворотами.
Кроме того, из вашего объяснения можно получить неверное представление, что якобы из обычной ссылки нельзя сделать rvalue-ссылку (ведь вызывающий код не отказывался от владения, так? однако сделать std::move() в функции никто не запретит, так что получится, что как бы можно "заставить" вызывающий код отказаться от владения?). И вообще, даже с lvalue-ссылкой функция может сделать с объектом что угодно.
Ну, новичков можно понять, ведь достаточно малейшего изменения в этом паттерне, чтобы внезапно возникала ненужная копия, и снова требовался бы std::move(). Например, если возвращать не s, а поле x из структуры struct Foo {std::string x;}. И RVO, несмотря на кажущуюся похожесть этого случая, тут не сработает. Всё-таки семантика перемещения в C++ очень неинтуитивна.
«Вы знаете, я считаю неприличным делать замечания людям, если они неверно говорят. Неприличным и пошлым. Ничего не поправляю, всё переношу. Но вот «во сколько» вместо «в котором часу» или вместо «когда», — тут она задохнулась от гнева и дальше произнесла по складам, — я вы-нес-ти не мо-гу. И «мы живем в Кратово» вместо «в Кратове» — тоже не могу»
(цитата А. Ахматовой из «Записок об Анне Ахматовой» Л. К. Чуковской)
Также см. http://gramota.ru/class/istiny/istiny_1_toponimy/:
"Миф № 1. Географические названия на -ово, -ево, -ино, -ыно не склоняются и никогда не склонялись. Варианты в Болдине, из Останкина, в Пулкове – «новояз», безграмотность, порча языка. <...> На самом деле: Географические названия славянского происхождения, оканчивающиеся на -ово, -ево, -ино, -ыно, традиционно склонялись: в Останкине, в Переделкине, к Болдину, до Пулкова, из Косова. Тенденция к употреблению несклоняемого варианта сложилась лишь в последние десятилетия. Иными словами, новая норма – не в Люблине, а в Люблино."
Есть доказательства того, что она именно не использовалась? Есть гипотезы, что викинги и полинезийцы могли использовать её для навигации.
Что-то странное - накручивали-накручивали деревья поверх списков, а в итоге получили асимптотику O(N +E) - и чем же она лучше тривиального алгоритма с линейным проходом слева направо?
Уверен, что если ре-парсинг не нужен, то задачу можно решить за log N + E - есть много структур данных, которые умеют прибавление на отрезке и вставку/удаление элементов в середине. Например, декартовы деревья. А если ре-парсинг нужен, то ведь и смысла нет оптимизировать поиск скобок быстрее стандартного линейного алгоритма?
P.S. Немного напоминает мне, как во время одного собеседования разработчик из Индии хвалился своим "знанием" алгоритмов и рассказывал, как он оптимизировал запросы к базе данных путём создания сбалансированных двоичных деревьев *во время обработки каждого запроса*. Т. е. база данных отвечает списком объектов, которые надо пофильтровать каким-то простым критерием вроде "мин. элемент >= X", и они для этого пихали весь ответ из базы в дерево, чтобы потом спуститься по дереву и найти нужный элемент. В общем, главное - прикрутили умный алгоритм, а что толка от него нет, поскольку перед этим всё равно линейный алгоритм работает - не важно.
Пример про "вибрацию луча" как-то совсем непонятен... Вообще, что такое вибрация луча? Кто вибрирует - сам луч или тело, на которое он падает?
"Вибрация луча вызывает уменьшение отражаемого им света" - здесь "им" относится к самому лучу или к чему-то другому?
"Через несколько десятков миллисекунд вибрация становится локализованной в массиве лучей, что приводит к появлению тёмной горизонтальной линии" - Какой массив лучей имеется здесь в виду?..
В Германии ни одна из "мэйнстримовых" партий не одобряет ядерную энергетику. Получается, как бы, замкнутый круг - но избиратели, выходит, его не замечают...
А когда? В аристократических кругах ещё за много веков до Бальзака продолжительность жизни (среди тех, кто преодолел детский возраст) была гораздо больше. Например, https://en.wikipedia.org/wiki/Life_expectancy говорит, что ещё в XV в. она составляла 69 лет для английской аристократии. А среди не-аристократии понятие "пенсионер" даже иносказательно трудно прикрутить...
Так непосредственно сразу после изобретения чего бы то ни было оно всегда дорого поначалу; другое дело - сколько оно будет стоить через пару лет и при условии достаточных инвестиций? В статье обещают, что их технология совместима с обычными производственными процессами ("compatibility with commercial paint fabrication process"), но это уже может значить что угодно...
На графике "WOC availability", визуально, самые плохие показатели - в Германии, Италии, Чехии (?), Австралии, Гренландии. Есть ли какое-нибудь объяснение, почему именно там? Например, почему в Германии, но не в её соседях Франции, Великобритании, Швеции?
Я бы сказал, получилась скорее нумерология, а не математика.
В рамках этого проекта разработан двукрылый дрон с размахом крыльев в 78 м.Как-то по фото непохоже на двукрылого... В Википедии пишут, что это "flying wing", что переводится как "летающее крыло".
Может быть, пример из статьи не совсем информативный? Ведь если проход на вечеринку осуществляется один раз, то достаточно, чтобы у каждого был приглашённого был рандомный приватный ключ, публичная часть которого подписана организатором. Т. е. протокол был бы таким:
Подготовка:
1. Организатор генерирует пару ключей, и сообщает привратнику публичную часть.
2. Каждый приглашённый генерирует свою пару ключей, и сообщает организатору публичную часть.
3. Организатор отправляет каждому приглашённому подпись публичного ключа этого приглашённого, сделанную с помощью приватного ключа организатора.
Пропуск на вечеринку:
0. Организатор сообщает привратнику список отозванных публичных ключей (соответствующих людям, которых организатор передумал приглашать).
1. При появлении гостя, привратник генерирует рандомный nonce и просит гостя подписать его.
2. Гость отвечает двумя блобами: подписью nonce, сделанную его собственным приватным ключом, и подписью публичного ключа, полученную от организатора.
3. Привратник проверяет эти две подписи и проверяет список отозванных ключей, после чего пускает или не пускает гостя.
По сути, это вариация на стандартную тему remote attestation protocol, который, например, используется в TPM-чипах (например, насколько я знаю, DRM-системы уже используют такое в продакшене, чтобы отличать "своих"/"чужих" клиентов, не зная при этом настоящего идентификатора каждого пользователя).
Какое требование из описанной в статье задаче делает этот протокол неподходящим?