Здравствуйте. Наверное, мой вопрос затерт и банален, но все же решусь его повторить Я хочу получать код, который без особых костылей компилируется на Win7-8, MacOS, IOS, Android. На что я могу рассчитывать? Речь не о том, какую фичу поддерживает тот или иной компилятор, а об общем тренде — переходят ли на С++11 программисты кроссплатформенных игр?
Здравствуйте, rumia, Вы писали:
R>Здравствуйте, ML380, Вы писали:
ML>>Здравствуйте, Went, Вы писали:
ML>>Тоже интерсно, создал голосование.
R>а вариант "воздержаться"? Я не пишу игры.
Ну, игры не главное. Речь именно о кросс-компиляторном "промышленном" программировании в массовой среде. Понятно, что есть и будут экзотические или старые платформы и компиляторы, которые всегда будут сильно отставать.
Здравствуйте, Went, Вы писали:
W>Здравствуйте. Наверное, мой вопрос затерт и банален, но все же решусь его повторить Я хочу получать код, который без особых костылей компилируется на Win7-8, MacOS, IOS, Android. На что я могу рассчитывать? Речь не о том, какую фичу поддерживает тот или иной компилятор, а об общем тренде — переходят ли на С++11 программисты кроссплатформенных игр?
Мы пока нет. Потому как основным инструментом остаётся (у коллег) VS2008. Вот если переходить на современные Студии, тогда да.
Здравствуйте, Dair, Вы писали:
D>Мы пока нет. Потому как основным инструментом остаётся (у коллег) VS2008. Вот если переходить на современные Студии, тогда да.
мы тоже, хотя и есть возможность, но особого гешефта после перехода просто не видим
Здравствуйте, Went, Вы писали:
W>Здравствуйте. Наверное, мой вопрос затерт и банален, но все же решусь его повторить Я хочу получать код, который без особых костылей компилируется на Win7-8, MacOS, IOS, Android. На что я могу рассчитывать? Речь не о том, какую фичу поддерживает тот или иной компилятор, а об общем тренде — переходят ли на С++11 программисты кроссплатформенных игр?
2014 год заканчивается, люди уже С++14 юзают, и собираются юзать C++1z
а кто-то еще решает, писать им на С++2003 или нет
Здравствуйте, Abyx, Вы писали:
A> 2014 год заканчивается, люди уже С++14 юзают, и собираются юзать C++1z A>а кто-то еще решает, писать им на С++2003 или нет
А есть ли где-нибудь сравнение производительности С++03 vs С++11? А то мой гугл нашел только одно сравнение на SO и то — не в пользу С++11.
Желательно для Студийного компилятора. А то может и не стоит слезать с VS2008?
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>А есть ли где-нибудь сравнение производительности С++03 vs С++11?
Производительности чего конкретно?
Если производительность программиста, то тут в C++11 код можно писать короче и проще.
Если производительность скомпилированного кода, то в компиляторах backend не меняется в зависимости от выбранной версии языка. Изменения вроде перемещаемых конструкторов (идущих с новой STL или сгенерированные компилятором) влияют положительно даже без переписывания остального кода под C++11.
Если производительность компилятора, то тут опять же в C++11 можно записать код короче и проще — меньше парсить и анализировать (хорошо видно на примерах, где десятки шаблонных функций, необходимые в C++03, схлопываются в один variadic template в новой версии).
Ну то есть, конечно, всему этому верить слепо нельзя, и нужно тестировать конкретные сценарии, если это важно. Но похоже, что сам переход с одной версии компилятора на другую даст большее изменение в производительности (как самого компилирования, так и его результата), чем смена версии языка в рамках одного компилятора.
A> 2014 год заканчивается, люди уже С++14 юзают, и собираются юзать C++1z A>а кто-то еще решает, писать им на С++2003 или нет
тоже слегка шокировала сама постановка такого вопроса, только за счёт применения лямбды можно код намного проще и понятней писать.
enum class и инициализация вектора, переменных в теле класса а не конструкторе. как можно без всего этого? конечно это вопрос денег
и перехода на новую студио но язык в последнее время с новыми фичами сильно развился и я вполне могу себе прeдставить что вчерашние гуру с++
без практического применения новейших фич могут просто новый код не понять
Здравствуйте, watchmaker, Вы писали:
SVZ>>А есть ли где-нибудь сравнение производительности С++03 vs С++11? W>Производительности чего конкретно?
Разверну свой вопрос.
Очень заманчиво пересесть на Студию поновее и отметить в портфолио, что близко знаком с С++11, но для этого надо обосновать руководству, что же мы от этого поимеем, кроме эстетического удовольствия.
W>Если производительность программиста, то тут в C++11 код можно писать короче и проще.
Насчет производительности программиста... Если рассматривать тот же auto, то писать проще, это верно, но читабельности он не добавляет. Проще сделать осмысленный typedef и использовать его по месту.
Наверное в каких-то проектах, где шаблон на шаблоне и шаблоном погоняет это важно, в моих проектах больше времени тратится на рисование на бумажке и написание комментариев, чем на собственно код. И тут auto мне совсем не помощник, и даже наоборот. А вот range-for, действительно, кой-какой код упростит.
W>Если производительность скомпилированного кода, то в компиляторах backend не меняется в зависимости от выбранной версии языка. Изменения вроде перемещаемых конструкторов (идущих с новой STL или сгенерированные компилятором) влияют положительно даже без переписывания остального кода под C++11.
Вот скорость сгенерированного компилятором кода интересует прежде всего.
Про упомянутый std::move писали много. Я согласен, что в определенных условиях он должен дать какой-то прирост в производительности. А есть ли где-нибудь сравнение старой стандартной библиотеки и новой? Скажем, применительно к здоровенному std::vector, заполненному POD структурами? Естественно, считаем, что код написан нормально, т.е., как минимум, здоровенные массивы по значению не возвращаются Единственный тест, который я нашел, показал проседание из-за того, что определенные функции в новом компиляторе не заинлайнились. Но это на gcc, что покажет новая Студия —
W>Если производительность компилятора, то тут опять же в C++11 можно записать код короче и проще — меньше парсить и анализировать (хорошо видно на примерах, где десятки шаблонных функций, необходимые в C++03, схлопываются в один variadic template в новой версии).
А производительность компилятора беспокоит меньше всего. Лишние полминуты можно и подождать. Шаблоны используем очень мало и в очень простых конструкциях.
W>Ну то есть, конечно, всему этому верить слепо нельзя, и нужно тестировать конкретные сценарии, если это важно. Но похоже, что сам переход с одной версии компилятора на другую даст большее изменение в производительности (как самого компилирования, так и его результата), чем смена версии языка в рамках одного компилятора.
Собственно, сейчас сидим на 2008 Студии и есть резонный вопрос — есть ли надежда, что переход на новую Студию себя оправдает. Если кто-то сам сравнивал MSVS2008 vs MSVS2013 или поделится ссылкой, было бы здорово.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Вот скорость сгенерированного компилятором кода интересует прежде всего.
пару лет назад приводил сравненительные тесты: http://www.willus.com/ccomp_benchmark2.shtml
используются: MinGW(gcc-4.6.3), msvc2010, icc11
стОит отметить, что MinGW в сравнении с msvc — идет почти один в один, и это даже с учетом того, что gcc-4.6.3 имел довольно таки незначительные отптимизаторы.
сейчас же, использование MinGW на базе gcc-4.8.3/4.9.2 — должно дать более сещественный прирост. но нужно тестить, и жаль, но исходников для этих тестов я не нашел.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
SVZ>Вот скорость сгенерированного компилятором кода интересует прежде всего. SVZ>Собственно, сейчас сидим на 2008 Студии и есть резонный вопрос — есть ли надежда, что переход на новую Студию себя оправдает. Если кто-то сам сравнивал MSVS2008 vs MSVS2013 или поделится ссылкой, было бы здорово.
Вот мой скромный опыт.
Задача у меня по процессам перколяции и работает на пределах возможностей моего ноeта (Core i3, 4 гига памяти).
Матрица размером 25000 на 25000 элементов — недостаточно большая, хотелось бы больше...
Задача состоит в тупом заполнении матрицы случайным образом отрезками из целого числа узлов.
Статистика собирается на 1000 прогонов проги — хотелось бы 10000 (для уменьшения погрешности).
Требование заказчика — использовать ТОЛЬКО стандартный С++, чтобы можно было компилировать в Windows и Linux.
С самого начала сидел на 2008 студии и параллельно на Code::Blocs c MinGW+gcc — тоже в Windows.
C самого начала выставлял все возможные оптимизации по скорости в обоих системах.
На 2008 и 2010 прога, скомпилированная в Code::Blocks выигрывала по скорости.
На 2012 студии картина получается обратная — компилятор студии делает программу быстрее, чем gcc в Code::Blocks.
Правда там версия компилера не самая последняя — что то 4.7.3 примерно или чуть больше (не 4.8).
Ну так и Студия у меня не самая последняя.
Ну и стандартная библиотека стала существенно лучше!
Я треды стал использовать — существенно ускорил некоторые части проги.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Abyx, Вы писали:
A> 2014 год заканчивается, люди уже С++14 юзают, и собираются юзать C++1z A>а кто-то еще решает, писать им на С++2003 или нет
Да я с радостью перейду. Но не окажется ли потом, что получу компилер-специфик код?
Здравствуйте, Abyx, Вы писали:
A> 2014 год заканчивается, люди уже С++14 юзают, и собираются юзать C++1z A>а кто-то еще решает, писать им на С++2003 или нет
Язык (и любой другой инструмент) не будет писать за вас программу.
Здравствуйте, Went, Вы писали:
W>Здравствуйте, Abyx, Вы писали:
A>> 2014 год заканчивается, люди уже С++14 юзают, и собираются юзать C++1z A>>а кто-то еще решает, писать им на С++2003 или нет W>Да я с радостью перейду. Но не окажется ли потом, что получу компилер-специфик код?
Что? Специфичный код только для 1 компилятора можно сделать на любом компиляторе. Меньше всего стандарт поддерживается в MSVC поэтому если програмить в ней а потом проверять допустим на mingw то все будет хорошо. Ну может вылезет некоторое количество некритичных багов, но не более.