C++ кто-нить сейчас использует, новые фичи, по-полной?

[Alexandr]

Последние 3 кода каждый день C++11. Последний год С++14.

Самое ходовое: auto, constexrp, default constructors, lambdas, move-semantics, decltype, variadic templates, ну и C+11 stdlib.

= delete

[Pantigalt]

Просто хочу понять - нужно ли читать про всякие там C++14, move semantics и т.д. Впечатление какое-то противоречивое складывается - вроде бы и неплохие фичи, но ещё больше грузят и без того перегруженного монстра, не загнулся бы под собственным весом...

Гляньте книжку "C++11 Rocks: GCC Edition"
move semantics - Лучше поискать примеры статей. Если знакомиться по книжке Майерса, то как раз путаница и происходит.

Вы говорите про новую книжку Майерса?
Effective Modern C++ 42 Specific Ways to Improve Your Use of C++11 and C++14
По С++ 11 я читал только Джосаттиса, у него все достаточно сухо написано, читать скучновато.

[Мальчик-Одуванчик]

Просто хочу понять - нужно ли читать про всякие там C++14, move semantics и т.д. Впечатление какое-то противоречивое складывается - вроде бы и неплохие фичи, но ещё больше грузят и без того перегруженного монстра, не загнулся бы под собственным весом...

Гляньте книжку "C++11 Rocks: GCC Edition"
move semantics - Лучше поискать примеры статей. Если знакомиться по книжке Майерса, то как раз путаница и происходит.

Вы говорите про новую книжку Майерса?
Effective Modern C++ 42 Specific Ways to Improve Your Use of C++11 and C++14
По С++ 11 я читал только Джосаттиса, у него все достаточно сухо написано, читать скучновато.

Майерс конечно неплох как популяризатор языка.

[Andriy777]

Если Вам "пользоваться" move, а не разрабатывать шаблоны (templates) то я могу Вам расписать Привет-Сообщение без всяких "понтов".

[turic]

Неужели так нужен был "move" в c++ чтобы выдать это за новую версию? По-моему, нужно было добавить поддержку асинсхонности (как в JS).

[Andriy777]

Move офигенно как был нужен в связи с устоявшимися предыдущими концепциями. Возьмем vector<shared_ptr<MyClass>>. Когда вектор растет в размере нужно скопировать объекты на новое место. Нужно вызвать копирующий конструктор, а не просто скопировать память, так как в общем случае для vector<T> мы не можем даже гарантировать что будет в этой памяти (только Plain Old Data (POD) struct гарантируется).

Для shared_ptr случая это означает InterlockedIncrement, InterlockedDecrement вызовы на каждый указатель. А это уже L3 cache операции с большим кол-вом инструкций.

А если что-нибудь как unordered_map<tuple<...>, set<>> ситуация еще печальней.

Без move народ нарывался на проблемы с производительностью с STL библиотекой. Искал обходные пути и часто избегал STL. А так все ранее написанные идеи просто "устаканились".

Про асинхронность... Она достигается за счет библиотек. В Windows, Concurrency namespace или Parallel Patterns Library делает много чего хорошего. Но, я слышал, такие вещи как await уже на подходе. В принципе в C# await раньше эмулировался через yield return. В C++ yield return тоже эмулируется. Так что асинхронность в стиле await можно было писать с более длинным кодом. Многие не кодируют в стиле await, а просто в стиле task.then.then.then и пр. Без task-ов тоже было плохо, но не смертельно.

Вот, без move было реально плохо. Народ избегал STL. А это катастрофа. Это все равно что на C# избегать .NET framework (для Java придумайте свой аналог). Move - моя любимая особенность в 11. Наряду с function<> и лямбдами конвертирующимися в них.

[Andriy777]

Блин, в предыдущем письме не закончил мысль о растущем, векторе... Короче, не копируем мы shared_ptr - ы, а просто двигаем из содержимое. Interlocked не вызывается.

В общем виде можно в любой программе найти места где объекты лучше передвинуть, а не скопировать. std::move и все. Написать класс поддерживающий move тоже просто.

Но... да, по сравнению с Java или C# набор концепций растет.

[Andriy777]

Еще я, наверное, перегнул палку о том что STL не пользовались из-за отсутствия move. Это была причина с производительностью, да, но народ еще хочет без exceptions. Ну... тяжело им...

[turic]

Блин, в предыдущем письме не закончил мысль о растущем, векторе... Короче, не копируем мы shared_ptr - ы, а просто двигаем из содержимое. Interlocked не вызывается.

shared_ptr и interlocked -- брызги с т.з производительности. interlocked реализован на уровне CPU в одну инструкцию.

Тормоза возникают, когда прога лишний раз в сеть ходит, из файла читает или что-то тяжёлое в цикле вычисляет.

В современном с++ все осталось от 80-90х -- один поток. К примеру, открыл файл, прочитал, вычислил, закрыл. А ведь файловое операции асинхронны и прога могла бы делать что-то полезное пока, к примеру, идет чтение. Это сейчас решается только "в ручную" через threads, а поддержки на уровне языка нету, а могла бы быть.

[Medium-rare]

В современном с++ все осталось от 80-90х -- один поток. К примеру, открыл файл, прочитал, вычислил, закрыл. А ведь файловое операции асинхронны и прога могла бы делать что-то полезное пока, к примеру, идет чтение. Это сейчас решается только "в ручную" через threads, а поддержки на уровне языка нету, а могла бы быть.

Фича std::async, которую собрались отменять, может разбросать выполнение кода по другим потокам.

[M. Ridcully]

Фича std::async, которую собрались отменять, может разбросать выполнение кода по другим потокам.

Гы, можно поподробней?
А как пели, как пели...
Впрочем, сейчас она по-моему довольно примитивно имплементирована - либо всё последовательно, либо тупо запускать поток.
Что в-принципе и логично, ИМХО - есть рантайма никакого нет, то каким боком библиотека может распределить задачи лучше, чем ОС?

[Medium-rare]

Гы, можно поподробней?
А как пели, как пели...
Впрочем, сейчас она по-моему довольно примитивно имплементирована - либо всё последовательно, либо тупо запускать поток.

Да, standard committee пару лет назад вдруг засобирался объявить std::async deprecated. Ну, недодумана была фича в корне.
Я читал всякие рассылки. Сейчас погуглил, в C++ 14 точно остаётся. Вот тут пишет один из разработчиков стандарта: http://open-std.org/jtc1/sc22/wg21/docs ... /n3780.pdf

Как раз пару лет назад в конкретном проекте, так и так потыкали в std::async, вообще работает, но не все требования удовлетворяет, особенно, по отмене исполнения, и вообще абстрагирована от thread pool, слишком глубоко зарыт. И решили использовать MS Parallel Patterns.

Что в-принципе и логично, ИМХО - есть рантайма никакого нет, то каким боком библиотека может распределить задачи лучше, чем ОС?

Ну, ведь никто не запрещает к API обращаться не непосредственно из пользовательского кода. Просто трудно тогда сделать фичу consistent для разных платформ.

[Andriy777]

Блин, в предыдущем письме не закончил мысль о растущем, векторе... Короче, не копируем мы shared_ptr - ы, а просто двигаем из содержимое. Interlocked не вызывается.

shared_ptr и interlocked -- брызги с т.з производительности. interlocked реализован на уровне CPU в одну инструкцию.

Тормоза возникают, когда прога лишний раз в сеть ходит, из файла читает или что-то тяжёлое в цикле вычисляет.

В современном с++ все осталось от 80-90х -- один поток. К примеру, открыл файл, прочитал, вычислил, закрыл. А ведь файловое операции асинхронны и прога могла бы делать что-то полезное пока, к примеру, идет чтение. Это сейчас решается только "в ручную" через threads, а поддержки на уровне языка нету, а могла бы быть.

Пример с shared_ptr был дан как показательный, что даже с такой простой вещью как shared_ptr move оптимизация применима. В последний раз я читал, что interlocked идет за 9 тактов, когда как L0 операции за 2-3. Более реальные оптимизации в случаях вроде контейнера контейнеров (привел пример).

Мы работаем с кодом в котором сложные циклы, оперируют с контейнерами и пр. Асинхронность за счет библиотек.

[Andriy777]

A... еще, чтобы сделать этот долбанный Interlocked нужно сначала зареференсить память со счетчиком.

Ну и, короче,... я уже говорил что провел 2 года на C++ 11 проекте, закончил в perf команде? Работает move. Особенно там, где даже не надо явно его вызывать (rvalue in expressions) и как часть STL, где они им пользуются вовсю.

[Alexandr]

В современном с++ все осталось от 80-90х -- один поток. К примеру, открыл файл, прочитал, вычислил, закрыл. А ведь файловое операции асинхронны и прога могла бы делать что-то полезное пока, к примеру, идет чтение. Это сейчас решается только "в ручную" через threads, а поддержки на уровне языка нету, а могла бы быть.

есть на уровне библиотек, все почти как в .net и java. В С++ даже не напряглись новые названия придумать

[Alexandr]

по поводу move еще словечко:
очень важный класс объектов, которые нельзя копировать, но можно мувать
Тот же класс сокета, копировать нельзя (что делать с дескриптором непонятно), а вот мувать пожалуйста

[Alexandr]

и еще словечко,
если кому надо, вот тут introductional description неплохой
http://thbecker.net/articles/rvalue_ref ... on_01.html

[Andriy777]

А для тех, кто думает, что врубился в move, вот, новомодный coding pattern, попробовать осознать:

1. Нафига
2. Сколько теряем производительности в случае, когда цель "нафига" не достигается.

class X
{
string _a;
string _b;
string _c;

public:

// No... not this way... even though earlier it was a pattern
// X(const string& x,
// const string& y,
// const string& z)
// : _a(x), _b(y), _c(z)
//{
//}


// Here is some new pattern...
X(string x,
string y,
string z)
: _a(move(x)), _b(move(y)), _c(move(z))
{
}

// Other useful logic is skipped...
};

[Medium-rare]

Зачем? Очень сильно печёмся о производительности? Представляется вполне уместным в сигнатуре конструктора сказать string&& x? Или если речь пойдёт о можно/нельзя со стороны caller, тогда ещё и альтернативный традиционный конструктор иметь, хоть с const string&, хоть с string и последующим явным move.

[AndreyT]

А для тех, кто думает, что врубился в move, вот, новомодный coding pattern, попробовать осознать:
1. Нафига

Хм... Если вы удосужидись узнать об этом паттерне, то почему вы не удосужились поинтереосваться "нафига"?

"Being movable" является намного более слабым требованием, чем "being copyable". Данный паттерн снимает с параметра жесткое требование "being copyable", т.е. не требует безусловной копируемости объекта. А исходный вариант всегда безусловно жестко требует копируемости.

2. Сколько теряем производительности в случае, когда цель "нафига" не достигается.

Это в каком случае? В случае, когда копирование все-таки используется?

Code: Select all

string a, b, c;
X x(a, b, c);

Да, в таком случае возможна некоторая потеря производительности на том, что сразу за копированием будет выполняться еще и move. Это много? Учитывая, что стоимоость move обычно коррелирована со стоимостью copy, но при этом move обычно как минимум на порядок дешевле, ясно, что негативный эффект от лишнего move будет все равно практически не заметен на фоне затрат на copy.

При этом не надо забывать, что ситуация соврешенно симметрична со "старым" вариантом - в старом варианте была потеря производительности из-за того, что делалось копирование в ситуации, когда можно было обойтись последовательностю construct+move. Например

Code: Select all

X x("a", "b", "c");

дает нам очевидный потенциальный выигрыш в производительности именно в новом варианте.

[Andriy777]

Вопрос мой был специально для "новичков" в move, чтобы они разобрались. Правильно, эти новые прототипы используют для возможности двигания памяти. И не только в конструкторах, но и в нормальных функциях, когда неохота возиться с шаблонами или overloads. С функциями одного аргумента пишут overloads (см. push_back(const T&), push_back(T&&)). A с 2-мя и выше - как написал.

Те, кто не смотрит в Intellisense прототипы вызовов, в общем, почти ничего не теряют (правда, в случае со строкой там 16 символов (или байт) все таки зарезервировано не на heap, а как часть объекта - small string optimization). А те кто смотрит, может соптимизировать руками типа так:

if (condition...)
{
string text = BuildText();
cout << text;
return new X(BuildMoreText(), move(text), "abc");
}