https://habr.com/post/166201/ ?

я дал ссыль за это, там треш

(ушел спать)

В boost есть какой-то алгоритм, чтобы просто применить функтор для пар элементов по типу adjacent_find()?

В boost есть какой-то алгоритм, чтобы просто применить функтор для пар элементов по типу adjacent_find()?

Трансформ принимающий два рядом стоящих итератора не подходит?

Или я задачу не так понял)

Тут демку borrow checker показывают для крестов

Пока что выглядит очень неплохо

Реализации есть в msvc и шланге

я тут сегодня вижел пример, как на корутинах бинарный поиск оптимизировали ?

Я не понял почему версия на корутинах получилась быстрее ручного префетча.

Тут демку borrow checker показывают для крестов

На прошлой неделе же еще показывали - https://herbsutter.com/2018/09/20/lifetime-profile-v1-0-posted/

На прошлой неделе же еще показывали - https://herbsutter.com/2018/09/20/lifetime-profile-v1-0-posted/

Без lifetime annotitions много чего не сделать

https://github.com/Efrit/str_switch/blob/master/str_switch.h

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

На прошлой неделе же еще показывали - https://herbsutter.com/2018/09/20/lifetime-profile-v1-0-posted/

Да, я знаю

Сейчас на коне демонстрация с разрабами этой фичи

Я не понял почему версия на корутинах получилась быстрее ручного префетча.

Так там же ручной префетч и есть

Да, я знаю

Ну я про первую версию которая была с префетчем но без корутин, почему-то она медленнее работала чем версия с корутинами.

Трансформ принимающий два рядом стоящих итератора не подходит?

Да, но что бы в новый контейнер не копировать

А изменять текущий

вопрос: template <typename AlwaysVoid, typename, typename...> struct invoke_result { }; template <typename F, typename...Args> struct invoke_result<decltype( void( detail::INVOKE( std::declval<F>(), std::declval<Args>()... ) ) ), F, Args...> { using type = decltype( detail::INVOKE( std::declval<F>(), std::declval<Args>()... ) ); }; Вот это: decltype( void( detail::INVOKE( std::declval<F>(), std::declval<Args>()... ) ) ) Нафига нужно ?

Чисто, чтобы подсветка ошибки была во время неверного использования ?

вполне вероятно..

ведь важно, чтобы INVOKE не был илл-формед, а если он илл-формед, то мы его в деклтайпе и поймаем. Но я не совсем уверен в этом

Ну, я вот собственно говоря того сюда и кидаю, чтобы послушать варианты, отличные от оного. Авось такие есть ?

Чисто, чтобы подсветка ошибки была во время неверного использования ?

чтобы ошибка была SFINAE-friendly а не hard

Ога, Merci Beacoup !

чтобы ошибка была SFINAE-friendly а не hard

this

А где можно почитать про C2X, и вообще над этим работают?

На сайте рабочей группы 14

На сайте рабочей группы 14

http://www.open-std.org/jtc1/sc22/wg14/

(очень утонченная шутка)

но у этих Сишников так медленно идут дела, что я и не нашел никаких планов на 20ые

https://isotc.iso.org/livelink/livelink?func=ll&objId=19027346&objAction=browse&viewType=1

но у этих Сишников так медленно идут дела, что я и не нашел никаких планов на 20ые

ну как это

встречаются пару раз в десятилетие

Additional C++ harmonization Consider whether the following C++ changes should be made in C. Note that these items need proposals submitted as WG 14 papers to progress further. Drop trigraphs (C++17) Add u8'x' literals (C++17) Expand static_assert (details needed)

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2257.htm

так (надеюсь) это не про 20е, а на более близкую перспективу

так (надеюсь) это не про 20е, а на более близкую перспективу

да кто их знает

так (надеюсь) это не про 20е, а на более близкую перспективу

3020е

так (надеюсь) это не про 20е, а на более близкую перспективу

учитывая С11 и С17 ну, в 2023 надо ждать :)

а судя по пейперам там да, печально все, несклько человек

@antoshkka го десант еще и туда устроим

почему бля эту прекрасную вещь не приняли ( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2035.pdf

почему бля эту прекрасную вещь не приняли ( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2035.pdf

ой, не надо этих UTF-16 и UTF-32

с UTF-8 бы сначала разобраться

UTF-8 же самый сложный сабсет, хотя бы потому, что он переменной длины

UTF-16 полехче, но там гемор с сурогатными парами

UTF-32 самый изи, но он самый толстущий

UTF-32 самый изи, но он самый толстущий

а как же графема vs. code-point?

UTF-16 полехче, но там гемор с сурогатными парами

не, 16 как раз самый сложный

собирает костыли одновременно и utf-8 и utf-32

а какие костыли из утф-32 он собрал?

а какие костыли из утф-32 он собрал?

избыточность размера наверное (правда хз можно ли считать это костылём)

Интересно, что раньше будет Elementary string conversions в Clang или Coroutines TS в GCC ? Coroutines TS давно оказывается из коробки в Clang, а я думал надо будет запариваться и из сорсов собирать ?

Это networking ts надо из сорсов собирать(хоть для gcc, хотя для clang)?

Не понимаю людей, советующих всюду включать зависимость на ICU. Там дикий оверхед во-первых, а во вторых всего-то нужны функции конвертации utf8-utf16-utf32 и tolower, которые лично у меня получились простые, понятные и с O(N).

встречаются пару раз в десятилетие

И такие: "ну чего, парни, нам ещё не хватает в нашем идеальном языке С?" И сразу хор: "Наш язык и так прекрасен в своём минимализме!" "РАСХОДИМСЯ !"

Не понимаю людей, советующих всюду включать зависимость на ICU. Там дикий оверхед во-первых, а во вторых всего-то нужны функции конвертации utf8-utf16-utf32 и tolower, которые лично у меня получились простые, понятные и с O(N).

и там в этих простых есть поддержка всех европейских языков?

Не понимаю людей, советующих всюду включать зависимость на ICU. Там дикий оверхед во-первых, а во вторых всего-то нужны функции конвертации utf8-utf16-utf32 и tolower, которые лично у меня получились простые, понятные и с O(N).

А какой там оверхед?

В каком смысле поддержка? Если надо рисовать буквы, то тогда — harfbuzz. А юникод он и в африке юникод. Если нужна конвертация из старых codepage, то легковесный iconv/WidecharToMultibyte.

а tolower?

А какой там оверхед?

Эта зависимость на 35 мегабайт.

а tolower?

cp->utf32->tolower

Additional C++ harmonization Consider whether the following C++ changes should be made in C. Note that these items need proposals submitted as WG 14 papers to progress further. Drop trigraphs (C++17) Add u8'x' literals (C++17) Expand static_assert (details needed)

Будем что-то в С менять? Ну, давайте добавим триграфы. А зачем нам триграфы? Ну, чтобы потом мы могли их удалить...

UTF-32 самый изи, но он самый толстущий

Зато самый используемый

Зато самый используемый

Самый используемый - utf-16, к сожалению( спасибо MS и жаве

Самый используемый - utf-16, к сожалению( спасибо MS и жаве

Я имел в виду, самый используемый из полноценных.

Самый используемый - utf-16, к сожалению( спасибо MS и жаве

Ну да, ещё и Qt туда добавить же надо

Будем что-то в С менять? Ну, давайте добавим триграфы. А зачем нам триграфы? Ну, чтобы потом мы могли их удалить...

Илья, ты говоришь как прапор

@antoshkka го десант еще и туда устроим

Не. Я в чистом C вообще не разбираюсь. Это давайте без меня :)