Здравствуйте!

Пишу какой-нибудь класик — пишу на 03, его буль менее изучил.
11/14/17 пытаюсь, только если уж реально много на 03ем писать.

03 — он же просто узаконил 98ой вариант с мелочью. Вышел 11ый — я не пересаживался, ждал пока устаканится. В 14 устаканилось — но я уже тогда не писал на плюсиках. Сейчас пишу, но опять местами только 11 и без либ/с либами 03. В итоге на 03 так и пишу, иногда тока что-то новое используя. Ну, либы может стали пооптимальнее — ну, это такое, и вообще не факт. А компиляторы — так они и 03 код оптимальнее сделают

Просто типа боль

M>Просто типа боль
1. Если в дебри не залезать, то много мелких приятных мелочей, которые можно использовать на счет раз.
auto, лямбды, инициализация, for для контейнеров, новые перечисления, tuple, random, интеллектуальные указатели...
Просто на cppreference залезаешь — и там дофига можно просто посмотреть.
2. Семантика перемещения не сразу укладывается. Особенно, если Скотта Меерса читать... )))))))
Да и не везде нужна.
3. Новые шаблоны и все, что с ними связано — тут надо Александреску перечитать и сравнить как было и как стало.
Тут много чего для программирования на этапе компиляции.
Мне, например, не нужно пока — я и не влезаю сильно вглубь.

Первое надо просто использовать повсеместно. Код упрощается и уменьшается.
Второе мы со студентами на динамических классах смотрим.
И заставляю грубо померить время на 10000000 элементах контейнера — приятная библиотека chrono.
Сразу видят разницу.
Ну, из третьего реально пока только шаблоны с переменным числом параметров...

Да, еще и функциональное программирование на С++ потихоньку почитываем...
Но это — хобби такое...

Здравствуйте, Marty, Вы писали:

M>11/14/17 пытаюсь

А зачем, если не секрет?

Здравствуйте, Marty, Вы писали:

M>Просто типа боль

Не понимаю. Не нужна какая-нибудь move-семантика или вариадики — ну не используй.
А выкинули и задепрекейтили только действительно худшие фичи, вроде auto_ptr и старых биндов, типа bind1st.

Пишу на VS 2015, где есть как бы весь C++11 и немного С++14, но типа апдейт на 2019 не за горами.
Накапливаются TODO про:
* Прежде всего C++14 constexpr, где можно писать нормальные циклы, сейчас кое-что на рекурсии, ещё кое-что вынесено в рантайм
* <bit>овая магия без интринсиков и местами в компайл-тайме
* Некоторые SSE2 и AVX2 интринсики (в VS 2015 как бы есть, но некоторых почему-то нет, в 2017 уже их завезли)
* Выравнивание аллокаций не вручную, когда alignas не только можно написать, но ещё он работает для new по умолчанию
* Удобства для аллокаций вручную, где всё же надо вручную, вроде std::uninitialized_default_construct
* Атрибуты [nodiscard]] и [fallthrough]], местами и пару других бы воткнул

Здравствуйте, Marty, Вы писали:

M>Просто типа боль

Кому-то много прогресса, а кому-то его мало.

Поучаствовал в появлении некоторых важных фич С++20 в MSVC:
https://github.com/microsoft/STL/pull/593
https://github.com/microsoft/STL/pull/843

И ликвидации некоторого легаси:
https://github.com/microsoft/STL/pull/1194

Здравствуйте, LaptevVV, Вы писали:

LVV>2. Семантика перемещения не сразу укладывается. Особенно, если Скотта Меерса читать... )))))))
LVV>Да и не везде нужна.

Применение семантике перемещения в своих программах я так и не нашел. Поэтому наверное и не до конца понимаю — практики нет, а для практики нужна мотивация, ее тоже нет — непонятно зачем мне это нужно если можно тупо передать по ссылке или указателю.

Здравствуйте, x-code, Вы писали:

XC>Применение семантике перемещения в своих программах я так и не нашел.

Если в коде используются объекты и контейнеры из стандартной библиотеки, то семантика перемещения уже используется автоматически. Т.е. о ней можно ничего и не знать, но она применяется и ускоряет работу программы.

Здравствуйте, ArtDenis, Вы писали:

AD>Если в коде используются объекты и контейнеры из стандартной библиотеки, то семантика перемещения уже используется автоматически. Т.е. о ней можно ничего и не знать, но она применяется и ускоряет работу программы.

pre-C++11 некоторые реализации STL делали внутри swaptimization — например при росте vector<vector<T>> внутрений вектор не копировался, а swap'ался.
В Boost'овских контейнерах (boost::container::vector и т.п.) move-семантика была вообще pre-C++ (см. Boost.Move, MOJO).

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>pre-C++11 некоторые реализации STL делали внутри swaptimization — например при росте vector<vector<T>> внутрений вектор не копировался, а swap'ался.

Я в курсе. Только в случае

struct Item
{
    std::string str1;
    std::string str2;
};

std::vector<Item> items;

это уже не работало на автомате.

Здравствуйте, Alexander G, Вы писали:

AG>А выкинули и задепрекейтили только действительно худшие фичи, вроде auto_ptr и старых биндов, типа bind1st.

и вместо этого в 20 стандарте внесли bind_front

Здравствуйте, Alexander G, Вы писали:


AG>Пишу на VS 2015, где есть как бы весь C++11 и немного С++14, но типа апдейт на 2019 не за горами.


те вы решили пропустить 2017 ? я думаю на что переходит 17 или 19

Здравствуйте, sergey2b, Вы писали:

S>те вы решили пропустить 2017 ? я думаю на что переходит 17 или 19

Смысл сейчас на 2017 переходить.
Если будет проблема с 2019, есть шанс на быстрый фикс после репорта.
(У них сейчас обновления частые, а кому совсем невтерпёж, есть превью версия, опереждающая на ~месяц)

Кроме того, cmake и clang в коробке очень привлекает.
И С++20 тоже.

Здравствуйте, sergii.p, Вы писали:

AG>>А выкинули и задепрекейтили только действительно худшие фичи, вроде auto_ptr и старых биндов, типа bind1st.

SP>и вместо этого в 20 стандарте внесли bind_front

Вот когда я в 2007 использовал boost::bind вместо std::bind1st, уже тогда хотел bind_front и лямбды.
Ну после лямбд как-то bind_front даже перехотелся.

Здравствуйте, Alexander G, Вы писали:

AG>Вот когда я в 2007 использовал boost::bind вместо std::bind1st, уже тогда хотел bind_front и лямбды.
AG>Ну после лямбд как-то bind_front даже перехотелся.

как я понимаю предназначение bind1st и bind_front — это поддержка карринга. Карринг только тогда имеет смысл, когда он синтаксически минимален (ну имхо конечно). И в этом смысле лямбды никак не могут служить заменой

int sum (const int fst, const int snd)
{
    return fst + snd;
}

void main()
{
    std::vector<int> integers = { 1, 2, 3, 4, 5 };
    const int seed = 5;
    const auto lambda = integers | view::transform([seed](const auto v){ return v + seed; });
    const auto front  = integers | view::transform(std::bind_front(sum, seed));
    const auto fst    = integers | view::transform(std::bind1st(sum, seed));
    //  и хаскель       map (sum seed) integers   для сравнения
}

если смотреть с этой точки зрения, bind1st лучше всего делал свою работу. Но его решили убить, ничего не дав взамен в 17. А потом типа раскаялись. В общем для меня это выглядит как метания комитета из стороны в сторону.

Здравствуйте, sergii.p, Вы писали:

AG>>Вот когда я в 2007 использовал boost::bind вместо std::bind1st, уже тогда хотел bind_front и лямбды.
AG>>Ну после лямбд как-то bind_front даже перехотелся.

SP>как я понимаю предназначение bind1st и bind_front — это поддержка карринга.

Ну с обычным bind как бы не карринг из-за плейсхолдеров, но в итоге ту же задачу -- ин-плейс адаптер -- решает.
Собсна и лямбды тоже.

Здравствуйте, sergii.p, Вы писали:

SP>как я понимаю предназначение bind1st и bind_front — это поддержка карринга. Карринг только тогда имеет смысл, когда он синтаксически минимален (ну имхо конечно).

Ну и если считать буквы в строке с биндом, а не настаивать на карринге C++11 решение не более громоздко, чем bind1st:

using namespace std::placeholders;

const auto bind   = integers | view::transform(std::bind(sum, seed, _1));