эквивалентный, посмотри на expression templates еще раз

c expression templates там в итоге будет сразу складывание без промежуточных векторов

Точно!

нет, не эквивалентный! а если строка 9 вызывает crash (stack overflow)?

с точки зрения С++ это не эквивалентный код

При strictfp - эквивалентный.

хотя это шутка, но на самом-то деле суть примерно в этом

нет, не эквивалентный! а если строка 9 вызывает crash (stack overflow)?

Это уже не с точки зрения плюсов, а с точки зрения рантайма =) Так-то clang вообще free(malloc(...)) оптимизирует нафиг :)

и потом, ничего не мешает сделать auto v3 = v0 + v1; v3 += v2;

хотя последнее очень неприятно

оно примерно так и делает на уровне SIMD - складывает всё кусками

емнип совпадение source и destination операции вызывает небольшой ручник процессора

для xmm пофигу кажется

потом, как я понимаю, на std::vector накладные расходы все на перемещении

Циклы в строчке 34 должны свернуться в один.

Я думал о том, что можно вычислять только несколько элементов в v3. Так не умеете?

т.е. их просто нет

Я думал о том, что можно вычислять только несколько элементов в v3. Так не умеете?

нет, я обязан заполнить вектор

мне неизвестно, что dynamicFloat() не обладает side-effect-ами

Я думал о том, что можно вычислять только несколько элементов в v3. Так не умеете?

Это простая оптимизация, и это может легко сделать и плюсовый компилятор. Разговор же шёл за оптимизацию, которую он сделать не может.

мне неизвестно, что dynamicFloat() не обладает side-effect-ами

Да, но тебе известно, что далее результат не используется.

мне неизвестно, что dynamicFloat() не обладает side-effect-ами

dynamicFloat() нужно вызвать. А вот сумму можно считать только для нескольких элементов вектора. Заполнять полностью v3 не нужно

опять же, я не очень понимаю, почему это работа компилятора

практика показывает, что плохой оптимизатор лучше, чем оптимизатор, сгенерировавший неправильный код)

опять же, я не очень понимаю, почему это работа компилятора

Потому что не надо заставлять пользователя мудрить что-то со строчкой 34, если он на выходе использует только пару значений из вектора. Пользователь должен работать продуктивно. Вбросил код и быстро получил результат.

эта оптимизация поломается от любого чиха

чего ж она работает во всяких Eigen тогда?

дураки писали наверное

Это простая оптимизация, и это может легко сделать и плюсовый компилятор. Разговор же шёл за оптимизацию, которую он сделать не может.

Может и может, но не делает.

Потому что не надо заставлять пользователя мудрить что-то со строчкой 34, если он на выходе использует только пару значений из вектора. Пользователь должен работать продуктивно. Вбросил код и быстро получил результат.

Я запутался. Все-таки в 34ой строчке будут складываться все элементы v0, v1 и v2 или нет?

Может и может, но не делает.

Ну, это уж так написали компилятор. Речь о том, что если сейчас какому-нибудь Intel приспичит оптимизировать подсчёт только нужных значений - они это сделают за пару недель. Сделать же автоматическую дедукцию ET будет намного сложнее.

Циклы в строчке 34 должны свернуться в один.

Эту оптимизацию ещё просто не сделали в GCC https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80317 (в clang её ещё тоже не сделали, тикет искать лень, он такой же как в GCC)

"This would require loop fusion, sth we don't do at the moment. For this particular case dependence analysis should even make it possible."

короче если подумать, то у компилятора плюсов вся информация есть

вопрос в том, что такой код компилятор оптимизирует хуже

чем человек

Ну, формально есть. По факту - такую оптимизацию делать на данном уровне просто очень дорого.

совершенно нет

компилятору нужны формальные доказательства, что нет side effect

человек может выяснить, что там с dynamicFloat, компилятор в любом случае вынужден сделать вызовы

в остальном компилятор может построить такое доказательство достаточно легко

ему нужно будет перепроверить, что const на самом деле работает как const

что копирования памяти просто так делаются

в реальности там вместо С-style массива будет стоять С++, еще и вектор в худшем, так что компилятору придется еще проверять что вектора доказанно на один элемент не указывают

и все это учитывая тот факт, что человек может просто в хотпафе такое увидеть и переделать за 5 минут

короче, меня пока не убедили

ему нужно будет перепроверить, что const на самом деле работает как const

Ну вот это не есть гуд, ящитаю.

Когда есть возможность обойти const.

И компилю ПРИХОДИТСЯ проверять и верить, что его никто не сломает.

void f(int & x, int const& y) { x += y; x += y; } void g() { int x = 1; f(x, x); }

не говоря о случаях, когда просто нельзя не написать const_cast

не говоря о случаях, когда надо писать mutable

Когда есть возможность обойти const.

Собственно, я слышал, что оптимизатор просто вообще не может учитывать const

как вообще обойти вот этот пример: struct CachedComputingEngine: ComputingEngine { int get() const override { /*суперсложный расчет, который надо кэшировать */ } mutable bool cached = false; mutable int cache; };

привет, народ. есть русский текст и английский. надо искать там регулярки. регулярка на вход поступает как string val. текст тоже в string. пробовала icu - не работает с русским текстом - возможно, что-то идёт не так, когда я из string делаю UnicodeString. в общем, кто-нибудь может посоветовать, какими регулярками пользоваться?

ну, не считая читов под названием "const не очевиден при нарушении семантики типа" как вообще обойти вот этот пример: struct CachedComputingEngine: ComputingEngine { int get() const override { /*суперсложный расчет, который надо кэшировать */ } std::unique_ptr<std::unique_ptr<int>> container; };

привет, народ. есть русский текст и английский. надо искать там регулярки. регулярка на вход поступает как string val. текст тоже в string. пробовала icu - не работает с русским текстом - возможно, что-то идёт не так, когда я из string делаю UnicodeString. в общем, кто-нибудь может посоветовать, какими регулярками пользоваться?

у меня на проекте замечательно работает ICU, правда, порт на нее писал не я

я полагаю, что для std::string еще бы кодировку знать и проверить, что она читается как надо

ну для тестирования работы я просто насоздавала строк в коде. через string test("что-нибудь);. перевожу в UnicodeString через c_str(). по идее, там не может быть ничего, кроме UTF-8. разработка на Ubuntu.

вы точно уверены, что перекодировка не поломана?

UnicodeString это UTF-8, UTF-16 или UCS-2?

выведите побайтово строчку

до и после

и я крайне не уверен, что std::string будет в какой-то кодировке юникода

Я бы попробовал UnicodeString::fromUTF8().

Конструктор из const char * явно делает ерунду: http://icu-project.org/apiref/icu4c/classicu_1_1UnicodeString.html#ae436989ec7fc5a488e48f775cbfae711 > Uses the default converter (and thus depends on the ICU conversion code) unless U_CHARSET_IS_UTF8 is set to 1.

Конструктор из const char * явно делает ерунду: http://icu-project.org/apiref/icu4c/classicu_1_1UnicodeString.html#ae436989ec7fc5a488e48f775cbfae711 > Uses the default converter (and thus depends on the ICU conversion code) unless U_CHARSET_IS_UTF8 is set to 1.

им я и пользовалась

спасибо, попробую fromUTF8()

ERROR: S client not available

видимо, в этом вся ваша проблема

но я не уверен, что string на самом деле в UTF-8

но я не уверен, что string на самом деле в UTF-8

std::string это массив char'ов, у него нет кодировки. Если был файл, сохранённый в UTF-8, и он был прочитан в std::string, то там будут байты из файла. Без перекодировок.

std::string это массив char'ов, у него нет кодировки. Если был файл, сохранённый в UTF-8, и он был прочитан в std::string, то там будут байты из файла. Без перекодировок.

я бы в здравом уме не читал байты из файла в std::string

слишком долго думать, не написали ли мне U+FEFF первым символом и нет ли кода 0 в файле

Ну, это другой вопрос. В unix-среде обычно можно без проблем читать и отправлять в stdin/stdout данные в UTF-8, и использовать для них std::string вполне естественно.

Ну а в более других операционных системах могут возникнуть разные интересные проблемы.

Ну а в более других операционных системах могут возникнуть разные интересные проблемы.

Проблема не в операционной системе, а в том, что надо еще провалидировать кучу всего

Ну а в более других операционных системах могут возникнуть разные интересные проблемы.

Я крайне не уверен, что код U+B800 просто не положит мне программу

Ничо не надо валидировать, взял да и прочитал. std::string не имеет проблем с нулевыми байтами или ещё какими-то магическими последовательностями.

Я крайне не уверен, что код U+B800 просто не положит мне программу

Ну что ж, надо написать тест и убедиться :)

Ничо не надо валидировать, взял да и прочитал. std::string не имеет проблем с нулевыми байтами или ещё какими-то магическими последовательностями.

Тогда мне надо на входе каждый std::string валидировать, это же нарушение конвенции логического типа будет

std::string это враппер с удобствами вокруг массива байт, он не делает никаких предположений о кодировках.

а скажем, как прочитает boost xml-файл тоже зависит от кодировки xml-файла?

Так что проблемы я (здесь) не вижу.

у меня просто регулярки лежат в xml-файле.

Так что проблемы я (здесь) не вижу.

Я бы предпочел, что если я использую std::string как контейнер UTF-8 строк, у меня в коде все переменные std::string содержали исключительно UTF-8 строки

А код символа U+B800 не является корректной UTF-8 строкой

для массива байтов я предпочитаю писать std::vector<int8_t>

Ок, с этим соглашусь.

у меня просто регулярки лежат в xml-файле.

просто. проверьте. все. предположения.

лишний assert и тест в коде еще никому не мешал

для массива байтов я предпочитаю писать std::vector<int8_t>

std::vector<std::byte> !!!!!

std::vector<std::byte> !!!!!

да как угодно

просто. проверьте. все. предположения.

в частности, обязательно проверьте, что будет выполнена нормализация C перед поиском!

ребят , есть канал с работой на плюсах ?

Есть.

Есть.

подскажите

https://t.me/ProCxxJobs

хотел сказать - с няшными хедхантершами?