Потому что про i++ компилятор имеет и прав, и возможность убрать лишние операции, превратив в ++i, а v.size() выносить за пределы цикла нет. Если я, конечно, правильно понял вашу претензию к i++
Так вектор и не теряет. Немного маскирует. На чистом uint8_t* вы получите ту же самую беду с алиасингом, если не как автор в примере с указателем передадите по значению, а создадите свой struct с указателем и длинной и передадите указтель на этот самый struct. Это очень часто используется в C для всевозможных массивов и буферов и точно так же стреляет.
При чём тут C++? Заметьте, код корректно работает во всех версиях, дело только в производительности. Ну а то, что для написания производительного кода приходится закапываться в асм и архитектуру процессора, никогда никого не удивляло.
Спасибо за перевод. У меня появился ещё один аргумент в войне за возвращение strict aliasing в проект. К сожалению сейчас по причинам зависимостей и глубокой истории включен -fno-strict-aliasing. Он вообще абсурдно популярен. С одной стороны люди не хотят разбираться с правилами и багами оптимизированного билда, но с другой иногда существенно теряют в производительности, что и показано в статье.
Ошибся на 3 порядка. Всё-таки получается выдержка в микросекундах. Разница относительно реальных около 100 раз, но это уже выглядит решаемым при помощи ведения за объектом и TDI, про который написали выше.
С дифракционным пределом всё просто, но на какой выдержке сделан кадр, чтобы не было смаза? Если не компенсировать орбитальную скорость, то получится, что нужна выдержка 10см / 7км/с, что даёт наносекунды. Никакой светосилы не хватит.
Если компенсировать, вращая телескоп в обратную движению сторону, то будет лучше, но на реально возможных выдержках порядка 1мс (1/1000), паралакс должен смазать все высокие здания. Да и на уровне земли из-за поворота кадра будет смаз сильно выше дифракционного.
Как они это делают?
Выглядит как панацея и серебряная пуля вместе взятые. Я правильно понимаю, что вы при каждой потере ссылки проходите до рута чтобы понять, не была ли она последней? Если да, то это медленно. Если нет, то не понятно, как это защищает от циклических ссылок.
Есть ли замеры скорости работы? Потребления памяти?
Хотя бы раз попробую оправдать свой ник и поучаствую в челендже ++++++++++[>++++++++++<-]>[->+>[-]>[-]++++++++++<<[->+>-[>+>>]>[+[-<+>]>+>>]<<<<<<]>[<+>-]>[-]>[<+<+>>-]+<[>-<[-]]>[>-<<<++++++++++>>-]<<[>+>+<<-]>>>+<[>[>+>+<<-]>[<+>-]<<-]>[-]>>[>>+>+<<<-]>>>[<<<+>>>-]<<+>[<->[>++++++++++<[->-[>+>>]>[+[-<+>]>+>>]<<<<<]>[-]++++++++[<++++++>-]>[<<+>>-]>[<<+>>-]<<]>]<[->>++++++++[<++++++>-]]<[.[-]<]<[-]<<<<---------->+<[>-<[-]+++++++++.[-]]>[[-]++++++++++.[-]]<<<<]
P.S. Ужимать код не пытался, главное, что вообще работает.
Как только речь заходит об эмодзи и их сочетаниях, в памяти должны всплывать такие слова, как code point, сурогатная пара, графема. Тысячи статей про отличия букв, байт, нормализацию юникода и прочее. Кстати, при простом гуглении разделения по графемам в js находится, например: github.com/orling/grapheme-splitter
Это всё к тому, что надо знать разные тонкости, а так же иметь банальный IT кругозор чтобы знать, что спросить у гугла. В этом смысле задачка отличная.
Более того, с учётом реализации any_of, предложенной выше, она ещё и медленнее. Она перебирает все элементы, а не останавливается на первом удовлетворяющем, как цикл. Так что зависит от реальных данных, а на общий случай нужны как минимум бенчмарки.
Спасибо за статью, тема ranges не частый гость на хабре.
Не могли бы вы уточнить, что вам не нравится в коде, который упомянут в заключении? Да, ваш вариант короче, но при чём здесь эффективность? Алгоритмическая сложность одинаковая, особого оверхеда я тоже не вижу. В чём проблема?
Почему-то представил себе антиутопию, в которой люди борются за право оставаться людьми, введя специальные курсы в школах для прохождения капчи. Что-то основанное на задачах, которые мозг решает лучше процессора, но уже настолько сложное, что нетренированный человек не в состоянии это сделать. И постоянная гонка со слабым ИИ за эффективность. Учись или сольёшься с безликой массой людей и роботов.
Есть неплохое выступление Мейерса, в котором он разбирает странности C++ www.youtube.com/watch?v=KAWA1DuvCnQ
Так вот он акцентирует внимание на том, что всё это не плохо, это не идиоты в комитете, у всего есть нормальное объяснение, почему именно так, а не иначе. Да, C++ сложен, но и задача, которую он перед собой ставит не тривиальна. Сложная задача не решается просто. Совсем отдельный вопрос, актуальна ли задача и нельзя ли было взять нишу поуже.
Раз уж тут собрались знатоки clang-format, то посмею задать вопрос не совсем в тему статьи. Есть ли какой-нибудь способ объяснить ему несколько допустимых вариантов форматирования? Самый простой пример — разрешить делать однострочные функции, но если в коде уже есть перенос, то не трогать его? Это вкусовщина, но уже привык делать однострочными только конструкции вида return smth; и никогда не заталкивать никакую логику. Кстати, встречал и полностью обратное — однострочные if разрешены, но return всегда должен быть перенесён, чтобы проще было искать точки выхода. Ну или есть ли другие форматилки, которые оставляют свободу выбора?
Простите, что встреваю со своими тараканами, Julia действительно хорошо подходит для задач обработки данных и статистики, но не могу не порекомендовать язык D.
Вы получите: производительность C, можно не возиться с аллокациями (а можно и возиться, если это оправдано), хорошая библиотека алгоритмов (std.algorithm), mir — одна из самых быстрых либ для матриц, алгоритмов и линейной алгебры, во многом вдохновлена numpy, и много-много всего.
Круто! Я бы не стал делать макрос, а оставил бы вариант *in*:
if (auto res = "true" *in* some_map)
Для этого придётся сделать глобальную переменную in, зато она уже нормально включается в namespace. Понятно, что сама она состояние хранить не сможет, нужно на первом умножении создавать временное значение и хранить ключ там.
Если компенсировать, вращая телескоп в обратную движению сторону, то будет лучше, но на реально возможных выдержках порядка 1мс (1/1000), паралакс должен смазать все высокие здания. Да и на уровне земли из-за поворота кадра будет смаз сильно выше дифракционного.
Как они это делают?
Есть ли замеры скорости работы? Потребления памяти?
++++++++++[>++++++++++<-]>[->+>[-]>[-]++++++++++<<[->+>-[>+>>]>[+[-<+>]>+>>]<<<<<<]>[<+>-]>[-]>[<+<+>>-]+<[>-<[-]]>[>-<<<++++++++++>>-]<<[>+>+<<-]>>>+<[>[>+>+<<-]>[<+>-]<<-]>[-]>>[>>+>+<<<-]>>>[<<<+>>>-]<<+>[<->[>++++++++++<[->-[>+>>]>[+[-<+>]>+>>]<<<<<]>[-]++++++++[<++++++>-]>[<<+>>-]>[<<+>>-]<<]>]<[->>++++++++[<++++++>-]]<[.[-]<]<[-]<<<<---------->+<[>-<[-]+++++++++.[-]]>[[-]++++++++++.[-]]<<<<]P.S. Ужимать код не пытался, главное, что вообще работает.
Это всё к тому, что надо знать разные тонкости, а так же иметь банальный IT кругозор чтобы знать, что спросить у гугла. В этом смысле задачка отличная.
Не могли бы вы уточнить, что вам не нравится в коде, который упомянут в заключении? Да, ваш вариант короче, но при чём здесь эффективность? Алгоритмическая сложность одинаковая, особого оверхеда я тоже не вижу. В чём проблема?
Так вот он акцентирует внимание на том, что всё это не плохо, это не идиоты в комитете, у всего есть нормальное объяснение, почему именно так, а не иначе. Да, C++ сложен, но и задача, которую он перед собой ставит не тривиальна. Сложная задача не решается просто. Совсем отдельный вопрос, актуальна ли задача и нельзя ли было взять нишу поуже.
Вы получите: производительность C, можно не возиться с аллокациями (а можно и возиться, если это оправдано), хорошая библиотека алгоритмов (std.algorithm), mir — одна из самых быстрых либ для матриц, алгоритмов и линейной алгебры, во многом вдохновлена numpy, и много-много всего.
Для этого придётся сделать глобальную переменную in, зато она уже нормально включается в namespace. Понятно, что сама она состояние хранить не сможет, нужно на первом умножении создавать временное значение и хранить ключ там.