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

AK>Прошу прощения, что вырвано из контекста, но что ты под этим подразумеваешь?

В первую очередь -- связку auto/decltype для передаваемых/возвращаемых значений и всё что вокруг неё накручено.

Но на самом деле конфет там много: и разнообразные облегчающие жизнь хелперы вроде remove_reference и улучшенные шаблоны и пересмотренное метапрограммирование-light и пользовательские литералы и в перспективе -- концепты.

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

J>Ну вот когда мне будут платить за это — тогда и займусь, сразу же.
J>А пока платят за фичи — буду пилить фичи, а апгрейды компиляторов — это все в свободное от пиления фич время.
J>По той простой причине, что апгрейд компилятора сам по себе не принесет конторе больше денег, поэтому надо по крайней мере убедиться, что ты своим апгрейдом не делаешь хуже. И вот наши тесты показывают, что "не все так однозначно" и, стало быть, торопиться с апгрейдом особого смысла нету.
Ммм, если програмисты будут быстрей писать код, и код станет более надежным, то вроде как смысл есть.

J>В С++11/14 много замечательных фишек, но они не критичны, они больше для удобства программера. Того же быстродействия можно добиться и в С++03, пусть и более многословно. тем более что весь наш имеющийся код заточен под максимальное быстродействие в режиме С++03 — так что немедленного выигрыша просто от апгрейда версии языка точно не будет — мы не возвращаем по значению огромные объекты, чтобы rvalue references автоматом все ускорили.
Да, но с ними так приятно, не все фишки можно в С++03 делать, тот же override, меня уже 1 раз спас, а на С++03 в релиз пролезла ошибка из-за переименования метода базавого класа. Понятно что это кривость архитектуры, недостаточность тестов, и т.д., но такова жизнь.

J>Так что буду помаленьку смотреть, подкручивать опции, пробовать новые версии и компилятора, и библиотек, разные режимы компиляции, пока не добьюсь скорости кода не хуже имеющейся — а вот тогда уже и апгрейдиться можно.
Железный аргумент, могу только пожелать удачи в скорейшем переходе .

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

AG>Да, если у меня имеется семейная необходимость, то руководство всегда с пониманием относится к данной ситуации.
AG>И конечно же, если у меня что-либо критическое (тьфу-тьфу), то компания, соответственно, может подкорректировать планы!
наверное со мной что-то не так...
зачем внедрят в себя зависимость, называть ее нормальной повседневной практикой, а потом этой зависимости что-то объяснять и надеться на ее(зависимости) снисхождения?

AG>P.S. К сожалению, мы скатились в офф-топик
ага.

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

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

W>Здравствуйте. Наверное, мой вопрос затерт и банален, но все же решусь его повторить Я хочу получать код, который без особых костылей компилируется на Win7-8, MacOS, IOS, Android. На что я могу рассчитывать? Речь не о том, какую фичу поддерживает тот или иной компилятор, а об общем тренде — переходят ли на С++11 программисты кроссплатформенных игр?

Мы разрабатываем не совсем игры, но что-то похожее по структуре. Давно перешли.

X>про RVO ты похоже не слышал...
Как и ты. В приведенном примере возвращается копия члена класса, судя по префиксу "m_", RVO в данном случае работать не будет.

J>* Ну и самое главное — не видно пользы на переход в С++ 11, много противников, к примеру, у auto.
А какие есть аргументы у противников auto?

J>В С++11/14 много замечательных фишек, но они не критичны, они больше для удобства программера.

IMO — главная фича там, это как раз r-value ссылки, но не сами по себе, а в связке с std::unique_ptr. Можно вообще не знать про эту вашу move semantics и perfect forwarding но получать бенефиты, в виде простоты и производительности, от использования std::unique_ptr, особенно если код использует исключения. Второе место делят auto и расширеная стандартная библиотека, в которой, по сравнению с С++03 есть куча новых полезностей, те же смарт поинтеры.

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

J>>В С++11/14 много замечательных фишек, но они не критичны, они больше для удобства программера.

CG>IMO — главная фича там, это как раз r-value ссылки, но не сами по себе, а в связке с std::unique_ptr. Можно вообще не знать про эту вашу move semantics и perfect forwarding но получать бенефиты, в виде простоты и производительности, от использования std::unique_ptr, особенно если код использует исключения.

С этим всю дорогу отлично справлялся std::auto_ptr, мир праху его.
std::unique_ptr, безусловно, удобнее, но я именно об этом и говорил выше.

CG>Второе место делят auto и расширеная стандартная библиотека, в которой, по сравнению с С++03 есть куча новых полезностей, те же смарт поинтеры.

Опять же, это 100 лет как есть в Boost.

You will always get what you always got
  If you always do  what you always did

J>С этим всю дорогу отлично справлялся std::auto_ptr, мир праху его.
J>std::unique_ptr, безусловно, удобнее, но я именно об этом и говорил выше.

Отлично справлялся?

J>Опять же, это 100 лет как есть в Boost.

Ну вот некоторым нельзя буст, или не хочется буст, зато можно C++11.

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

J>>* Ну и самое главное — не видно пользы на переход в С++ 11, много противников, к примеру, у auto.
CG>А какие есть аргументы у противников auto?

Например фанаты венгерской нотации не переваривают auto.

Лично мне тоже не прельщает 2 два сайдэффекта:
* тип твоей переменной может непредсказуемо измениться (например int -> unsigned) в процессе рефакторинга. По сути ты теряешь в стабильности кода из-за того что твои типы стали плавающие — придётся 7 раз подумать и всё предвидеть.

* теряется читабельность кода, всё больше и больше придётся возюкать мышкой по переменным чтобы понять что там прячется.

Чтобы не пинали ногами вот вам примеры когда это хорошо. Всё это случаи когда мы не хотим знать тип:
* итераторы, мы никогда не хотим знать их тип, лишь бы они предлагали свой интерфейс доступа.
* всякие сложные функторы, порождённые лямбдой, boost::bind и прочей нечистью

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

Короче, начал я работать с С++11 и понял, что переходить стоит!

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

W>Короче, начал я работать с С++11 и понял, что переходить стоит!

Вчера приняли решение о внедрении некоторых возможностей C++1x.
Так что я тоже тут нырнул, и сразу в variadic templates, теперь голову ломаю

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

CG>А какие есть аргументы у противников auto?

Может внезапно измениться тип переменной при перегрузке:

#include <cmath>
....
int x = 0;
auto a = std::abs(x);

Какой тип будет у переменной a?
Правильный ответ — хз.
1. Если больше никаких инклудов нет, то... double!
2. Если где-нибудь явно или опосредованно заинклуден <cstdlib>, то int.
Лично мне такое поведение не нравится.

Здравствуйте, Dair, Вы писали:
D>Так что я тоже тут нырнул, и сразу в variadic templates, теперь голову ломаю
Так как я сейчас занят чисто прикладным кодом (база в общем-то давно более-менее устоялась), то шаблонных улучшений пока что не касался. Но и лямбд + auto + range-based loop + initializer lists уже достаточно, чтобы задышалось легче

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

N>Может внезапно измениться тип переменной при перегрузке:
N>

N>#include <cmath>
N>....
N>int x = 0;
N>auto a = std::abs(x);
N>

N>Какой тип будет у переменной a?
N>Правильный ответ — хз.
N>1. Если больше никаких инклудов нет, то... double!
N>2. Если где-нибудь явно или опосредованно заинклуден <cstdlib>, то int.

Мейерс рекомендует тут вот такой синтаксис:

auto a = static_cast<int>( std::abs(x) );

Конечно пора. Перевёл все подконтрольные проекты на VS2013/g++4.8 и ничуть не жалею. Только не забывайте что в VS2013 есть баги с С++11.

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

S>Конечно пора. Перевёл все подконтрольные проекты на VS2013/g++4.8 и ничуть не жалею. Только не забывайте что в VS2013 есть баги с С++11.
А куда деваться? 15-ая вроде тестовая только.

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

J>Мейерс рекомендует тут вот такой синтаксис:
J>

J>auto a = static_cast<int>( std::abs(x) );
J>

О, как это по сишному! Сначало придумать фичи, а потом костыли под них
А почему бы тогда не так было сделать?

auto a = int(std::abs(x));

Или сир Мейерс презирает всё чисто-сишное?

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

V>А почему бы тогда не так было сделать?
V>

auto a = int(std::abs(x));

V>Или сир Мейерс презирает всё чисто-сишное?

В чистом Си нет синтаксиса `int(...)`. Можно `(int)(...)`.