Какой алгоритм разбивает массив на части по типу split и принимает функтор?

Из буста, конечно же

Привет всем. У меня очень много раз выполняется вызов функции. Так вот, когда я её убрал и весь этот кусок кода вставил прямо в цикл, то код стал в 2 раза быстрее. Вот скриншот http://imgur.com/a/5Goiqav , там же и результаты

можно было бы просто forceinline поменить каким-либо

так так, libreverseengine, так и запишем

Всем привет, есть ли среди Вас те, кто разбирается или использовал Стрибог?

Есть ли реализация на с/с++ потокового алгоритма?

Есть ли реализация на с/с++ потокового алгоритма?

Вы имеете в виду алгоритм шифрования ?

Да, именно. те реализации, что я нашел, являются блочными, они считают конечный хэш от строки. Возможно, где-то есть готовые реализации за подсчет промежуточного хэша

Я к тому, что как нам получить хэш от очень большого файла? Если будем считывать его построчно, то и получим число хэшей == числу строк

так так, libreverseengine, так и запишем

Можешь записать как scanmem

Да, именно. те реализации, что я нашел, являются блочными, они считают конечный хэш от строки. Возможно, где-то есть готовые реализации за подсчет промежуточного хэша

Попробуйте посмотреть в сторону потоковых шифрований основанных на РСЛОС , только с усложнением , например нелинейная комбинация генераторов

Да, именно. те реализации, что я нашел, являются блочными, они считают конечный хэш от строки. Возможно, где-то есть готовые реализации за подсчет промежуточного хэша

шифр не равно хешу, шифр бывает поточный и блочный, а любой хеш поточный

Попробуйте посмотреть в сторону потоковых шифрований основанных на РСЛОС , только с усложнением , например нелинейная комбинация генераторов

Спасибо, посмотрю

так что стрибогу получится скормить файл построчно

шифр не равно хешу, шифр бывает поточный и блочный, а любой хеш поточный

Извиняюсь, я могу путаться в определениях

так что стрибогу получится скормить файл построчно

Получится, просто придется писать свою реализацию, которая будет запоминать внутренние состояния массивов, пока не вызовем метод финализации. Вот может уже кто-нибудь уже реализовал такую библиотеку?

так оно и должно быть так реализовано изначально

Сейчас смотрю гитхабе реализацию от Дегтярева. Тот, алгоритм, что был у меня, увы, такое не умеет

Ты ошибаешься.

Точно говорю. Вот как должна себя вести extern inline функция в С? Я не знаю

Шутка про decltype в лямбдах

Точно говорю. Вот как должна себя вести extern inline функция в С? Я не знаю

Воот! Вносим пропозал имзенения C на C++ всем стандартом и готово!

Пропозал принимают и теперь ты знаешь C.

Точно говорю. Вот как должна себя вести extern inline функция в С? Я не знаю

inline просто игнорируется когда не нужен

inline просто игнорируется когда не нужен

неа

игнорируется и когда нужен, в Atmel Studio помню без реализации в хидере не инлайнилось никак

сейчас святотатство скажу

макрос бы написал и не мучался

cp->utf32->tolower

а если графема состоит из нескольких code-point?

а если графема состоит из нескольких code-point?

Значит тот коде-поинт, который отвечает за букву, будет преобразован, а модификаторы останутся как есть.

Значит тот коде-поинт, который отвечает за букву, будет преобразован, а модификаторы останутся как есть.

я не уверен что это будет верно, хотя кто знает, вообще в юникоде много чего есть

Точно говорю. Вот как должна себя вести extern inline функция в С? Я не знаю

какой-такой inline в C? (ну т.е. в каждом компиляторе это так или иначе можно написать, но это не часть стандарта)

какой-такой inline в C? (ну т.е. в каждом компиляторе это так или иначе можно написать, но это не часть стандарта)

https://en.cppreference.com/w/c/language/inline

макрос бы написал и не мучался

на самом деле вопрос про inline extern - это из рассылки ядра Линукс. И ведёт оно себя по разному в зависимости от флагов О_О

на самом деле вопрос про inline extern - это из рассылки ядра Линукс. И ведёт оно себя по разному в зависимости от флагов О_О

красотища

падает с duplicate symbol в отдельных случаях?

ах да, C99 (на который VC кладет с прибором. Хотя и реализовал большую часть фич) Спасибо что напомнили

какой-такой inline в C? (ну т.е. в каждом компиляторе это так или иначе можно написать, но это не часть стандарта)

С11: " 6.7.4 Function specifiers Syntax function-specifier: inline _Noreturn "

не линкуется то есть

https://www.fluentcpp.com/2018/09/28/auto-stick-changing-style/

не линкуется то есть

Ну вот тут боль описана https://lkml.org/lkml/2014/10/19/217 И это всё gnu89 -> gnu99 боль, даже не не c11

ах да, C99 (на который VC кладет с прибором. Хотя и реализовал большую часть фич) Спасибо что напомнили

не совсем так, они не собираются вообще поддерживать С, то что не входит в С90 или не является подмножеством С++

https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/

Ну вот тут боль описана https://lkml.org/lkml/2014/10/19/217 И это всё gnu89 -> gnu99 боль, даже не не c11

ну что я и говорил

но однако же они (втихую) реализовали designated initializers для структур (и это была самая большая боль)

и в тот момент это еще не было подмножеством Си++

О! Веселье в GCC подъехало: https://github.com/gcc-mirror/gcc/blob/e3cb810239595334bc66762574cb539af28bc1e6/gcc/testsuite/g%2B%2B.dg/cpp2a/constexpr-virtual11.C

О! Веселье в GCC подъехало: https://github.com/gcc-mirror/gcc/blob/e3cb810239595334bc66762574cb539af28bc1e6/gcc/testsuite/g%2B%2B.dg/cpp2a/constexpr-virtual11.C

ух

https://www.fluentcpp.com/2018/09/28/auto-stick-changing-style/

Theoretically, the expression Widget{42} creates a temporary Widget which is then moved to myWidget. So this syntax could incur the price of a move. But even then, the compiler is allowed (and compilers are getting very good at that) to elide this move, and direclty construct the Widget{42} inside the memory space of myWidget. как будто бы allowed != should != will, и при потенциальной компиляции моего хитрозакрученного с++11 кода дряхлым но c++11-compliant компилятором, юзер оного может внезапно влететь в просадки по производительности

Theoretically, the expression Widget{42} creates a temporary Widget which is then moved to myWidget. So this syntax could incur the price of a move. But even then, the compiler is allowed (and compilers are getting very good at that) to elide this move, and direclty construct the Widget{42} inside the memory space of myWidget. как будто бы allowed != should != will, и при потенциальной компиляции моего хитрозакрученного с++11 кода дряхлым но c++11-compliant компилятором, юзер оного может внезапно влететь в просадки по производительности

можно кстати проверить на godbolt старые gcc

О! Веселье в GCC подъехало: https://github.com/gcc-mirror/gcc/blob/e3cb810239595334bc66762574cb539af28bc1e6/gcc/testsuite/g%2B%2B.dg/cpp2a/constexpr-virtual11.C

разве это си?

Theoretically, the expression Widget{42} creates a temporary Widget which is then moved to myWidget. So this syntax could incur the price of a move. But even then, the compiler is allowed (and compilers are getting very good at that) to elide this move, and direclty construct the Widget{42} inside the memory space of myWidget. как будто бы allowed != should != will, и при потенциальной компиляции моего хитрозакрученного с++11 кода дряхлым но c++11-compliant компилятором, юзер оного может внезапно влететь в просадки по производительности

В C++17 компилятор обязан в этом месте elide делать

В C++17 компилятор обязан в этом месте elide делать

обратите внимание на explicitly specified версию стандарта :)

а так да, согласен, как будто бы если живём на острие прогресса по заветам Винтерса - то всё ок

а в конструкциях вида const ... &map = get(); for (auto it = map[a][b].begin(); it != map[a][b].end(); ++it) компилятор может сообразить, что map изменяться не собирается, .end() сдвигаться не будет, и operator[]x2 и end() можно соптимизировать прочь до for (auto it = .begin(), e =.end(); it != e; ++it) ?

или в цикле на тыщу элементов мы будем честно делать каждый раз два поиска по дереву?

Как правильно прочитать int* (*p[10]), и валидно ли это вообще?

http://c-faq.com/decl/spiral.anderson.html C Spiral / Clockwise Rule

@betraydeath а если лень напрягать мозги, то https://cdecl.org/

а в конструкциях вида const ... &map = get(); for (auto it = map[a][b].begin(); it != map[a][b].end(); ++it) компилятор может сообразить, что map изменяться не собирается, .end() сдвигаться не будет, и operator[]x2 и end() можно соптимизировать прочь до for (auto it = .begin(), e =.end(); it != e; ++it) ?

там вроде даже str.size() в for() каждый раз вызывается...

ребята, кто знает - если std::sort вызывается с компаратором который не соответсвует Compare, то все, UB? sort имеет право крашнуться? у меня на маке улетает за границы вектора сорт. как то это жестоко. понятно конечно что ничего хорошего оно не насортирует, но все же.

там вроде даже str.size() в for() каждый раз вызывается...

сайз - да, в данном случае я и .end() могу потенциально стерпеть, меня больше интересует map[][]

сайз - да, в данном случае я и .end() могу потенциально стерпеть, меня больше интересует map[][]

пардон, я пропустил const. Возможно что и оптимизирует.

Ну конкретно в твоем случае есть 100% вариант const auto& current = map[a][b]

На оптимизацию тут я бы не полагался

Ну конкретно в твоем случае есть 100% вариант const auto& current = map[a][b]

вариант то безусловно есть, я уже завернул ревью с таким чудом) мне больше интересно, о чём догадается или не догадается компилятор, если оставить как есть

А почему завернул, если не секрет? Норм же. Вроде его никто не обязывает догадываться, оптимизация — дело добровольное.

вариант то безусловно есть, я уже завернул ревью с таким чудом) мне больше интересно, о чём догадается или не догадается компилятор, если оставить как есть

не пробовал на годболте проверить?

А почему завернул, если не секрет? Норм же. Вроде его никто не обязывает догадываться, оптимизация — дело добровольное.

for ( const auto &input : inputs ) { for( const Json::Value &channel : input ) { string resolution = channel["params"]["resolution"]; int fps = channel["params"]["fps"]; for (auto it = channel["params"]["sub"]; it != channel["params"]["sub"].end(); ++it) { ... прям жирное, капсом, с подчёркиванием "не хотеть!" лишние разы бегать по дереву json в трижды-вложенном цикле

а в чём проблема написать int size = something.size() перед циклом и не гадать?

в оптимизаторе тупо баг могут добавить

Я просто так понял сообщение, что ты забанил на ревью код с const auto&

вариант то безусловно есть, я уже завернул ревью с таким чудом) мне больше интересно, о чём догадается или не догадается компилятор, если оставить как есть

Я просто так понял сообщение, что ты забанил на ревью код с const auto&

не, наоборот)

не пробовал на годболте проверить?

вылетело из головы, попробуем-с

for ( const auto &input : inputs ) { for( const Json::Value &channel : input ) { string resolution = channel["params"]["resolution"]; int fps = channel["params"]["fps"]; for (auto it = channel["params"]["sub"]; it != channel["params"]["sub"].end(); ++it) { ... прям жирное, капсом, с подчёркиванием "не хотеть!" лишние разы бегать по дереву json в трижды-вложенном цикле

а там итератор в теле действительно нужен?

а там итератор в теле действительно нужен?

неа, итератор там лежит со времён "auto уже есть, а range for пока не завезли"

не пробовал на годболте проверить?

если взять стандартную мапу, то творится чёрная магия, мне не хватает скиллов ассемблера чтобы разобраться в этих перепрыгиваниях https://godbolt.org/z/t5sjZQ но если взять свои типы без определений методов, чтобы компилеру было видно только call, то действительно дёргает два [] в цикле, не кэшируя( https://godbolt.org/z/_2FgIq

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

потому что даже при сигнатуре const& fun(...) const, под капотом всё равно могут возвращаться ссылки на разные объекты, в зависимости от всяких глобальных условий и статических счётчиков?

Привет всем. У меня очень много раз выполняется вызов функции. Так вот, когда я её убрал и весь этот кусок кода вставил прямо в цикл, то код стал в 2 раза быстрее. Вот скриншот http://imgur.com/a/5Goiqav , там же и результаты

Inline function не пробовал?

Привет всем. У меня очень много раз выполняется вызов функции. Так вот, когда я её убрал и весь этот кусок кода вставил прямо в цикл, то код стал в 2 раза быстрее. Вот скриншот http://imgur.com/a/5Goiqav , там же и результаты

А в чем вопрос?

Всем привет, есть ли среди Вас те, кто разбирается или использовал Стрибог?

У нас Дажьбог только...

эх, прям захотелось модификатор pure в терминах классической функциональщины, "при одном и том же параметре функция возвращает один и тот же результат, йа горонтирую это" ...хотя он наверняка неприменим к возврату ссылок и указателей на элементы контейнеров, которые допускают реаллоцирование памяти, перебалансировку и прочее жонглирование своим содержимым, при котором старые указатели становятся невалидными

Точно говорю. Вот как должна себя вести extern inline функция в С? Я не знаю

Из там просто нет!

макрос бы написал и не мучался

Именно так и делают...

потому что даже при сигнатуре const& fun(...) const, под капотом всё равно могут возвращаться ссылки на разные объекты, в зависимости от всяких глобальных условий и статических счётчиков?

Там может быть printf или вообще любой side effect

хм auto &e = map.at(x); map.insert(y); func(e); // бабах, да?

ребята, кто знает - если std::sort вызывается с компаратором который не соответсвует Compare, то все, UB? sort имеет право крашнуться? у меня на маке улетает за границы вектора сорт. как то это жестоко. понятно конечно что ничего хорошего оно не насортирует, но все же.

. Да. Все. Но как правило он просто не сортирует ничего. Но может и зависнуть.

ребята, кто знает - если std::sort вызывается с компаратором который не соответсвует Compare, то все, UB? sort имеет право крашнуться? у меня на маке улетает за границы вектора сорт. как то это жестоко. понятно конечно что ничего хорошего оно не насортирует, но все же.

А чем вызван вопрос?

for ( const auto &input : inputs ) { for( const Json::Value &channel : input ) { string resolution = channel["params"]["resolution"]; int fps = channel["params"]["fps"]; for (auto it = channel["params"]["sub"]; it != channel["params"]["sub"].end(); ++it) { ... прям жирное, капсом, с подчёркиванием "не хотеть!" лишние разы бегать по дереву json в трижды-вложенном цикле

Чем ты там json парсишь?

Чем ты там json парсишь?

jsoncpp, сходу версию не скажу

хм auto &e = map.at(x); map.insert(y); func(e); // бабах, да?

Почему-же сразу бабах?

ну там внутри сорт оно выходит за vector::end(), это жестко, может мем корапт сделать. если бы просто зависло я бы еще понял. немного странно для стандартной либы. я думал может им надо отрепортить. просто libstdc++ хэндлит такое. но конечно если UB то не сожгла мой жесткий диск и ладно вобщем.

ну там внутри сорт оно выходит за vector::end(), это жестко, может мем корапт сделать. если бы просто зависло я бы еще понял. немного странно для стандартной либы. я думал может им надо отрепортить. просто libstdc++ хэндлит такое. но конечно если UB то не сожгла мой жесткий диск и ладно вобщем.

С чего ты взял, что выход за границы массива может быть спровоцирован плохим компаратором?