зачем с одного г*вна переползать на другое? юзай нормальные компиляторы: gcc, clang

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

W>Я сам себе техлид, менеджер и программист. Сижу на 2005-ом вижуале, и чувствую себя в рамках С++03 вполне хорошо. Появилась возможность "абсолютно бесплатно" перелезть на 2013.4. Это заманчиво, и будет означать переход на С++11, но после того, что я прочитал про поддержку С++11 в этой студии, мне стало грустно. Получится, что гемор с перенастройкой всего пипелайна будет, а С++11 будет кастрированный.

Странные места вы читали. В VS2013 поддержка C++11 очень даже неплохая.

Есть:
— lambda
— move/rvalue ref
— variadic templates
— upgraded STL (threads/random/smart pointers/...)
— final/override/default/delete/...
— range-based-for
— initializer_list

Нет (из того, что вспомнилось и важное):
— constexpr
— automatic generation of move constructor/assignment

Чтобы войти во вкус, этого более чем достаточно. Из ключевых нововведений нет только constexpr

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

X>зачем с одного г*вна переползать на другое? юзай нормальные компиляторы: gcc, clang
Согласен, компиляторы неплохие. Но я слишком завязан на инфраструктуру вижуала как ИДЕ, поэтому дергаться без весомой причины никуда не буду.

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

J>нет варианта "в процессе перехода"

C++(03+11)/2?

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

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

Пишем игры, iOS, Android, Win8. C++ 11 не используем, про него пока ходят только слухи. Все наши тулсеты суммарно поддерживают только auto.
Под запретом находится также и буст.

Причины простые.
* Разработка одной игры занимает полгода/год, за это время на бусте ты не успеешь разогнаться как проект уже закончится.
* Соответствующая квалификация кодеров, проект за год не является слишком сложным, так что junior программисты смогут его осилить самостоятельно. С++ 11 из за своей сложности, к сожалению, превратился в язык для гиков. Чего смешить курей: уж если наши программисты не могут осилить возвращать vector<string> по константной ссылке, куда там до универсальных/r-value ссылкок.
* Шаблоны почти не используются, шаблоны грешат избыточной кодогенерацией что неприемлемо для мобильного мира. Все компайл тайм трюки хорошо замещаются сторонними тулзами на питоне или C#.
* Ну и самое главное — не видно пользы на переход в С++ 11, много противников, к примеру, у auto.

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

J>Под запретом находится также и буст.
уже неоднократно объясняли реальные причины неиспользования буста, но для некоторых(не только меня) — проще сменить работу, чем становиться членом касты г*внокодеров. (об этом тоже писали)

J>Причины простые.
J>* Разработка одной игры занимает полгода/год, за это время на бусте ты не успеешь разогнаться как проект уже закончится.
1. получается так, что на каждый проект новые кодеры? т.е. после завершения проекта, кодеры "все понимают" и бегут?
2. что значит "разогнаться"?

J>* Соответствующая квалификация кодеров, проект за год не является слишком сложным, так что junior программисты смогут его осилить самостоятельно. С++ 11 из за своей сложности, к сожалению, превратился в язык для гиков. Чего смешить курей: уж если наши программисты не могут осилить возвращать vector<string> по константной ссылке, куда там до универсальных/r-value ссылкок.
1. да, особенно константную ссылку на локальный вектор.
2. ну да, как я и предположил выше — кодеры, понимая тупиковость развития в вашей команде — просто сбегают.

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

даже представлять не хочу, каково "работается" в вашей команде/конторе %)

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

X>даже представлять не хочу, каково "работается" в вашей команде/конторе %)

Можно бегать сколько угодно, но подавляющее большинство продакшн кода пишется в стиле понятном большинству кодеров, включая новичков. Это очень хорошее бизнес качество кода когда он прост.

Ты можешь перепрыгнуть через голову если у тебя standalone проект и за тобой никто не следит (плюшки прогеру, можно простить высокую зарплату — и риск для бизнеса). Но это не более чем упущение менеджмента.

Соответственно С++11й пока ещё не в стриме.

не выдавайте желаемое за действительное, — это низко, ибо оправдание.

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


J>Причины простые.
J>* Разработка одной игры занимает полгода/год, за это время на бусте ты не успеешь разогнаться как проект уже закончится.
не понял аргумента. Буст — это набор очень разных либ. Скажем те же поинтеры — в чем проблема использовать? Ну и многие либы переехали в стандарт

J>* Соответствующая квалификация кодеров, проект за год не является слишком сложным, так что junior программисты смогут его осилить самостоятельно. С++ 11 из за своей сложности, к сожалению, превратился в язык для гиков. Чего смешить курей: уж если наши программисты не могут осилить возвращать vector<string> по константной ссылке, куда там до универсальных/r-value ссылкок.
Что такое "возвращать vector<string> по константной ссылке"? r-value дает профит даже без использования в прикладном коде

J>* Шаблоны почти не используются, шаблоны грешат избыточной кодогенерацией что неприемлемо для мобильного мира. Все компайл тайм трюки хорошо замещаются сторонними тулзами на питоне или C#.
шаблоны грешат избыточной кодогенерацией, если их использовать необдуманно. Это все равно что сказать "циклы грешат избыточным временем исполнения"...
Компайл-генерация сторонними тулзами конечно замещается, но а) сторонней тулзе очень сложно получить доступ к типам и прочей информации, доступной компилятору и б) чем писать такую тулзу и встраивать ее в билд, часто много проще написать шаблон или макрос. Хотя в некоторых случаях сторонние тулзы вполне рулят, согласен.

J>* Ну и самое главное — не видно пользы на переход в С++ 11, много противников, к примеру, у auto.
Это все последствия излишней свободы. Скажем среди программистов на питоне нет противников auto или исключений

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

J>rvalue references и move semantics в бане

У них и исключения в бане. Гуглостайл.

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

K>Язык (и любой другой инструмент) не будет писать за вас программу.

Ассемблер — наше все?

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

J>>Причины простые.
J>>* Разработка одной игры занимает полгода/год, за это время на бусте ты не успеешь разогнаться как проект уже закончится.
E>не понял аргумента. Буст — это набор очень разных либ. Скажем те же поинтеры — в чем проблема использовать? Ну и многие либы переехали в стандарт

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


E>Что такое "возвращать vector<string> по константной ссылке"? r-value дает профит даже без использования в прикладном коде
Забыта ссылка.

const vector<string>  GetItems() const { return m_items; }

Кстате. MSVC2010й вроде поддерживает r-value ссылки. Нужно тестировать качество поддержки — попробовать подпилить наши контейнеры.

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

J>Мелочи пишем сами постепенно на коленке, по мере надобности.


J>Для больших либ нужны большие проблемы, которые возникнуть не успевают либо возникают слишком поздно.
ох уж этот дивный детский мир %)

E>>Что такое "возвращать vector<string> по константной ссылке"? r-value дает профит даже без использования в прикладном коде
J>Забыта ссылка.
J>

J>const vector<string>  GetItems() const { return m_items; }
J>

про RVO ты похоже не слышал... и вот такие люди размышляют о высоком %)

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

J>Мелочи пишем сами постепенно на коленке, по мере надобности. Для больших либ нужны большие проблемы, которые возникнуть не успевают либо возникают слишком поздно.

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

J>

J>const vector<string>  GetItems() const { return m_items; }
J>

если забыта — надо исправить. Если забыта по незнанию — то, имхо, не зная такие вещи на плюсах писать нельзя. Кстати, rvalue тут спасет

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

T>с гораздо более дружественной системой типов...

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

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

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

K>>Язык (и любой другой инструмент) не будет писать за вас программу.

Ops>Ассемблер — наше все?

Как можно было сделать такой вывод из вышесказанного?

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

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

J>>Отвязался (перешел на стандартную гнутую), прогнал тесты — много чего просело.

BZ>если это критично — надо писать самим. стандартные библиотеки в силу своей общности очень далеки от оптимальной реализации любого конкретного алгоритма

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

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

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

Потому что, к сожалению, у того же GCC сплошь и рядом в оптимизаторе что-нть косячат, посмотри сам у них список багов от версии к версии.
С++11/14 — это фронт-энд и библиотека, но они ж не только их меняют в каждой новой версии, но и бэкэнд с оптимизатором тоже.
И глюки обычно в последних (это чтобы не показалось, что я утверждаю, что С++11 хуже, чем С++03. В компиляторе много компонентов, и улучшив один, вполне могут по ходу дела сломать другой — а у нас тест просядет, и думай — это из за изменений в библиотеке или в конкретном режиме оптимизации).

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

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

ты так говоришь, будто твоя работа заключается только в поддержке существующих проектов, и новые не пишешь... %)

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

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

X>ты так говоришь, будто твоя работа заключается только в поддержке существующих проектов, и новые не пишешь... %)

Именно так. У нас большой проект с единым code base и кучей бинарников. Так что даже если я пишу новый компонент, а не добавляю фичу в имеющийся — он все равно будет использовать кучу имеющегося библиотечного быстрого оттестированного кода.
Я не фрилансер, у которого каждый месяц новый проект и пиши на чем хочешь.

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

это ужасно, ИМХО %)