Здравствуйте. Наверное, мой вопрос затерт и банален, но все же решусь его повторить Я хочу получать код, который без особых костылей компилируется на 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 то все будет хорошо. Ну может вылезет некоторое количество некритичных багов, но не более.
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, LaptevVV, Вы писали:
LVV>>На 2008 и 2010 прога, скомпилированная в Code::Blocks выигрывала по скорости.
A>в Code::Blocks он компилирует =\
Не придирайся...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, pik, Вы писали:
pik>только за счёт применения лямбды можно код намного проще и понятней писать.
Это не так, короче — да, но не проще и понятнее.
И если в приоритете не скорость написания, а отладка и развитие проекта, то широкое использование лямбд — это зло.
DZS>Это не так, короче — да, но не проще и понятнее.
как правило ламбда замещает boost, да и вообще новые фичи позволяют весь boost выкинуть, или почти весь
а это безусловно плюс в читаемости кода DZS>И если в приоритете не скорость написания, а отладка и развитие проекта, то широкое использование лямбд — это зло.
широкое и безумное использование лямбд, только ради выпендрится — это безусловно зло
Здравствуйте, Abyx, Вы писали:
W>>Здравствуйте. Наверное, мой вопрос затерт и банален, но все же решусь его повторить Я хочу получать код, который без особых костылей компилируется на Win7-8, MacOS, IOS, Android. На что я могу рассчитывать? Речь не о том, какую фичу поддерживает тот или иной компилятор, а об общем тренде — переходят ли на С++11 программисты кроссплатформенных игр?
A> 2014 год заканчивается, люди уже С++14 юзают, и собираются юзать C++1z A>а кто-то еще решает, писать им на С++2003 или нет
Вот так сразу бежать переписывать не компилирующиеся с новым стандартом куски кода? Зачем?
Здравствуйте, Abyx, Вы писали:
A>В хромиуме, (который собирается под Win, Mac, Lin, iOs, Android), разрешены вот эти фичи С++11: A>http://chromium-cpp.appspot.com/
Спасибо, дельная инфа
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, Went, Вы писали:
W>>Да я с радостью перейду. Но не окажется ли потом, что получу компилер-специфик код?
A>В хромиуме, (который собирается под Win, Mac, Lin, iOs, Android), разрешены вот эти фичи С++11: A>http://chromium-cpp.appspot.com/
BFE>а такой код в двенадцатой студии не скомпилился.
у тебя там что, десятки таких фрагментов? правда?
BFE>И с другой стороны, у той версией gcc, что мы используем (и если я правильно помню), типы std::uint16_t и std::uint8_t отсутствуют в cstdint.
это говорит о многом %)
и да, исходники gcc нынче можно проибрести только на черном рынке, и очень дорого. понимаю твое сложное положение. искренне сожалею.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
BFE>>а такой код в двенадцатой студии не скомпилился. X>у тебя там что, десятки таких фрагментов? правда?
Да.
BFE>>И с другой стороны, у той версией gcc, что мы используем (и если я правильно помню), типы std::uint16_t и std::uint8_t отсутствуют в cstdint. X>это говорит о многом %) X>и да, исходники gcc нынче можно проибрести только на черном рынке, и очень дорого. понимаю твое сложное положение. искренне сожалею.
Вот да. Сначала проапдейтим кросс-тулчейны, потом пересоберём gcc под все таргет платформы, потом под них пересоберём boost и прочие библиотеки, которые, быть может, тоже придётся проапгрейдить, а значит согласовать наш код с их изменениями и, если повезёт и эти библиотеки не будут конфликтовать друг с другом, то да, мы, наконец-то перейдём на С++11. А ничего, что сдача проекта через две недели?
Здравствуйте, B0FEE664, Вы писали:
BFE>Да.
и сколько тебе на это нужно времени? час? два?
BFE>Вот да. Сначала проапдейтим кросс-тулчейны, потом пересоберём gcc под все таргет платформы, потом под них пересоберём boost и прочие библиотеки, которые, быть может, тоже придётся проапгрейдить, а значит согласовать наш код с их изменениями и, если повезёт и эти библиотеки не будут конфликтовать друг с другом, то да, мы, наконец-то перейдём на С++11.
ох и жуть же %)
BFE>А ничего, что сдача проекта через две недели?
это единственный проект, над которым ты трудишься? переводи другие проекты!
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
BFE>>Да. X>и сколько тебе на это нужно времени? час? два?
Вопрос не только во времени. Нужно ведь, чтобы все смогли скомпилировать эти изменения.
BFE>>А ничего, что сдача проекта через две недели? X>это единственный проект, над которым ты трудишься? переводи другие проекты!
У нас все проекты используют общие библиотеки. Я тут в одном классе ошибочный public на private поменять второй месяц не могу, так как все проекты пересобирать придётся...
Здравствуйте, B0FEE664, Вы писали:
BFE>>>Вот так сразу бежать переписывать не компилирующиеся с новым стандартом куски кода? Зачем? A>>и много их у тебя?
BFE>Ну, по "наследству" мне достался код, где много инициализаций типа этого:
"много" — это обычно на 30 мин работы по механической замене одного текста на другой, при помощи регулярок и пары чашек чая.
люди код с Си на С++ без проблем переписывают, а уж с С++03 на С++11 — легко.
Здравствуйте, Dair, Вы писали:
D>Здравствуйте, Went, Вы писали:
W>>Здравствуйте. Наверное, мой вопрос затерт и банален, но все же решусь его повторить Я хочу получать код, который без особых костылей компилируется на Win7-8, MacOS, IOS, Android. На что я могу рассчитывать? Речь не о том, какую фичу поддерживает тот или иной компилятор, а об общем тренде — переходят ли на С++11 программисты кроссплатформенных игр?
D>Мы пока нет. Потому как основным инструментом остаётся (у коллег) VS2008. Вот если переходить на современные Студии, тогда да.
+100500
Я пишу на C++ (MFC). Использую VS2008. Смысла в переходе на более новую студию, на C++11 а также и на более новую библиотеку MFC не вижу.
Здравствуйте, Went, Вы писали:
W>Речь не о том, какую фичу поддерживает тот или иной компилятор, а об общем тренде — переходят ли на С++11 программисты кроссплатформенных игр?
Раз уже выяснили, что разговор не об играх, то нет, не перехожу. В Qt 4.8 это особого значения не имеет, на новый Qt тоже не стал переходить. С++ долгоживущий язык, если понадобится ещё успеется перейти на всё, что угодно. Тут нужно понимать, что не все используют STL. А в Qt к тому же можно использовать обобщённое-программирование, то есть шаблоны С++, только очень специфичным образом. Многому чего не было в C++03, но есть в C++11, есть замена. Впрочем спустя значительное количество времени, а счёт идёт на года, когда будут решены другие проблемы, вполне возможно перейду на новый стандарт, может он даже дефолтным к тому времени станет. Нет ничего страшного, что все сразу не кидаются на новую версию. С++ (1983) известен своей совместимостью ещё с Си (1972), речь о 3-4-ёх десятилетиях, а не 3-4-ёх годах.
Здравствуйте, Went, Вы писали:
W>Здравствуйте. Наверное, мой вопрос затерт и банален, но все же решусь его повторить Я хочу получать код, который без особых костылей компилируется на Win7-8, MacOS, IOS, Android. На что я могу рассчитывать? Речь не о том, какую фичу поддерживает тот или иной компилятор, а об общем тренде — переходят ли на С++11 программисты кроссплатформенных игр?
Я бы переформулировал: Если не озвучено чёткое обоснование, почему в проекте не используется C++11, стоит задуматься о вменяемости техлидов и менеджмента.
Здравствуйте, Abyx, Вы писали:
A> 2014 год заканчивается, люди уже С++14 юзают, и собираются юзать C++1z A>а кто-то еще решает, писать им на С++2003 или нет
У всех разные ситуации.
Вот у нас использовался раньше Managed C++, C++/CLI .
Так они прибиты к версии .NET , а посему можем использовать только компилятор от VS2008 , т.к. нужен максимум .NET 3.5 .
Даже если получим добро на .NET 4.0 то все равно выходит студия 2010...
Чтобы перейти на C++1x нужно этот весь код переписывать как-то, а на это время никто ,естественно, выделять не будет.
Здравствуйте, Abyx,
A>"много" — это обычно на 30 мин работы по механической замене одного текста на другой, при помощи регулярок и пары чашек чая. A>люди код с Си на С++ без проблем переписывают, а уж с С++03 на С++11 — легко.
Гм. Программисты крайне редко задумываются о том, будет ли от такого переписывания business value?
Здравствуйте, Went, Вы писали:
W>Здравствуйте. Наверное, мой вопрос затерт и банален, но все же решусь его повторить Я хочу получать код, который без особых костылей компилируется на Win7-8, MacOS, IOS, Android. На что я могу рассчитывать? Речь не о том, какую фичу поддерживает тот или иной компилятор, а об общем тренде — переходят ли на С++11 программисты кроссплатформенных игр?
Формально в последних GCC и Clang поддержка полного C++11 уже есть и для всех перечисленных вами платформ по крайней мере один из них есть, так что проблем у вас не будет. Технических проблем. Формальный ответ на ваш вопрос: "да, можете рассчитывать на нормальную кроссплатформенность, вообще без проблем". Ну если оставить за скобками майкрософт, конечно. У этих своё видение.
Собственно вся поддержка в нормальных компиляторах была готова уже больше года назад, и новый стандарт уже давно можно потихоньку привлекать для своих нужд, аккуратно следя за руками -- там rvalue ссылку воткнуть, в другом месте список инициализации использовать (жёстко отслеживая perf impact на каждое такое движение). Меня почему-то особенно радует механизм future/promise в стандартной библиотеке. Переход на стандартные треды с системно-зависимых конечно должен быть сделан. Опять же переключиться с бустовых регекспов на стандартные -- тоже дело.
Не знаю насчёт игр, а вот программистов, пишущих симуляторы архитектур, бинарную трансляцию, всё вот это, уже года два как заимствующих полезное из нового стандарта, я знаю много.
Но программирование не сводится к техническим проблемам. Самое сложное -- это новый концептуальный аппарат, делающий метапрограммирование реально простым и во многом смещающий фокус внимания с традиционного ООП на более ФП-шный стиль: constexpr, variadic templates, auto, лямбды, всё вот это. Никому больше не нужно год учить шаблонную магию чтобы на собеседовании написать на бумажке compile-time prime numbers, теперь это сделает любой студент (и делают).
И вот что касается этого когнитивного "переключения контекста", когда мы прекращаем думать на C++98 и начинаем думать на другом языке, гораздо более гибком в compile-time и с гораздо более дружественной системой типов... Вот это пока рановато. Вообще новый стандарт каждые три года это слишком быстрые изменения в языке, тут лучше взять паузу и дать комитету наиграться. Сейчас уже вышел C++14, там довольно много концептуальных новшеств, скажем variable templates и generic lambdas. Если он окажется более-менее финальным, то можно будет перелезть сразу на него.
Здравствуйте, Went, Вы писали:
W>Здравствуйте. Наверное, мой вопрос затерт и банален, но все же решусь его повторить Я хочу получать код, который без особых костылей компилируется на Win7-8, MacOS, IOS, Android. На что я могу рассчитывать? Речь не о том, какую фичу поддерживает тот или иной компилятор, а об общем тренде — переходят ли на С++11 программисты кроссплатформенных игр?
Ну вот мы в команде юзали старый, но быстрый STLport, а он не поддерживает С++11 ни в каком виде.
То есть надо сперва от него отвязаться.
Отвязался (перешел на стандартную гнутую), прогнал тесты — много чего просело. Вот мучаюсь набегами уже год, наверное. Где-то что-то как-то какие-то неочевидные особенности использовало и тюнилось конкретно под STLport, и с уходом на гну оно больше не работает.
Так до сих пор и не перешли, сидим на STLport.
Потому что С++11 — это обновление не только языка, но и стандартной библиотеки.
не кажется ли тебе, что использовать в качестве стандартной библиотеки нестандартную рализацию, эмм, как минимум не логично?
не, не ради троллига. мне действительно непонятно мышление, на основании которого, было решено использовать STLport %)
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, jazzer, Вы писали:
X>не кажется ли тебе, что использовать в качестве стандартной библиотеки нестандартную рализацию, эмм, как минимум не логично?
она вполне стандартна в рамках С++98.
И использовалась она весьма широко в свое время, потому что уделывала по скорости почти все современные ей реализации стандартной библиотеки.
Стандарт же на интерфейс библиотеки, не на реализацию.
X>не, не ради троллига. мне действительно непонятно мышление, на основании которого, было решено использовать STLport %)
она работала быстрее, чем встроенная в GCC 2.95 и GCC 3. Да и сейчас, в общем-то, в каких-то частях она все еще выигрывает, получается.
Здравствуйте, niXman, Вы писали:
X>не кажется ли тебе, что использовать в качестве стандартной библиотеки нестандартную рализацию, эмм, как минимум не логично? X>не, не ради троллига. мне действительно непонятно мышление, на основании которого, было решено использовать STLport %)
Скорее всего по причинам историческим. 15 лет назад STLPort был более, чем стандартным и, к тому же, рвал Студийную stl как тузик тряпку.
Мы STLPort'ом тоже пользовались. Правда у нас переход на штатную stl прошел безболезненно — "стандартные" контейнеры использовали только в некритичных по скорости кусках проекта.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, jazzer, Вы писали:
J>она вполне стандартна в рамках С++98.
в моем понимании, стандартная библиотека — это некий фундамент, основа, который должен быть фундаментом для всего остального, и делать это на разных компиляторах/платформах. посему, имхо, я бы ни за что не стал использовать стороннюю реализацию. поди знай, насколько она совместима или же несовместима, и когда ее перестанут поддерживать...
J>И использовалась она весьма широко в свое время, потому что уделывала по скорости почти все современные ей реализации стандартной библиотеки. J>она работала быстрее, чем встроенная в GCC 2.95 и GCC 3. Да и сейчас, в общем-то, в каких-то частях она все еще выигрывает, получается.
что, абсолютно все, что в STLport рализовано, работает быстрее? думается мне, наверняка это меньшая часть, возможно сильно меньшая. я бы в этом случае, просто написал(или скопипастил) в рамках проекта свои реализации, которые бы использовались по препроцессорному условию.
ну хз, не представляю, чтоб я взялся писать проект основываясь на сторонней реализации стандартной библиотеки...
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Скорее всего по причинам историческим. 15 лет назад STLPort был более, чем стандартным и, к тому же, рвал Студийную stl как тузик тряпку.
так STLPort это что, чисто вендовая реализация? или заточенная под студию?
просто, мне не разу не встречался проект, который бы испльзовал STLPort(но я несколько раз слышал об этом), вот и подумал...
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
SVZ>>Скорее всего по причинам историческим. 15 лет назад STLPort был более, чем стандартным и, к тому же, рвал Студийную stl как тузик тряпку. X>так STLPort это что, чисто вендовая реализация? или заточенная под студию? X>просто, мне не разу не встречался проект, который бы испльзовал STLPort, вот и подумал...
Обычная кроссплатформенная библиотека. Список компиляторов.
В проекте ничего особенного и не увидишь. Те же обращения к namespace std.
Просто в настройках компилятора будет ссылка не на "штатный" каталог с stl файлами, а на stlport.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Vlad_SP, Вы писали:
V_S>Здравствуйте, Abyx,
A>>"много" — это обычно на 30 мин работы по механической замене одного текста на другой, при помощи регулярок и пары чашек чая. A>>люди код с Си на С++ без проблем переписывают, а уж с С++03 на С++11 — легко.
V_S>Гм. Программисты крайне редко задумываются о том, будет ли от такого переписывания business value?
А некоторые не-программисты (и недопрограммисты) не очень понимают что такое надежность кода, как в коде появляются баги, и сколько может стоить их починка.
Также не всем понятно почему какие-то задачи делаются быстро, а какие-то медленно.
И не все кто знает умные слова типа "business value" знают умные слова типа "technical debt".
Здравствуйте, B0FEE664, Вы писали:
BFE>У нас все проекты используют общие библиотеки. Я тут в одном классе ошибочный public на private поменять второй месяц не могу, так как все проекты пересобирать придётся...
я слышал есть тулзы, которые позволяют автоматизировать сборку...
скрипты опять же всякие
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Обычная кроссплатформенная библиотека. Список компиляторов.
почему-то мне думается, что под большинство из перечисленных платформ можно собрать GCC и использовать единую стандартную библиотеку
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>>Обычная кроссплатформенная библиотека. Список компиляторов. X>почему-то мне думается, что под большинство из перечисленных платформ можно собрать GCC и использовать единую стандартную библиотеку
Здравствуйте, jazzer, Вы писали:
J>Отвязался (перешел на стандартную гнутую), прогнал тесты — много чего просело.
если это критично — надо писать самим. стандартные библиотеки в силу своей общности очень далеки от оптимальной реализации любого конкретного алгоритма
Здравствуйте, Константин, Вы писали: К>Я бы переформулировал: Если не озвучено чёткое обоснование, почему в проекте не используется C++11, стоит задуматься о вменяемости техлидов и менеджмента.
Я сам себе техлид, менеджер и программист. Сижу на 2005-ом вижуале, и чувствую себя в рамках С++03 вполне хорошо. Появилась возможность "абсолютно бесплатно" перелезть на 2013.4. Это заманчиво, и будет означать переход на С++11, но после того, что я прочитал про поддержку С++11 в этой студии, мне стало грустно. Получится, что гемор с перенастройкой всего пипелайна будет, а С++11 будет кастрированный.
Здравствуйте, Went, Вы писали:
W>Я сам себе техлид, менеджер и программист. Сижу на 2005-ом вижуале, и чувствую себя в рамках С++03 вполне хорошо. Появилась возможность "абсолютно бесплатно" перелезть на 2013.4. Это заманчиво, и будет означать переход на С++11, но после того, что я прочитал про поддержку С++11 в этой студии, мне стало грустно. Получится, что гемор с перенастройкой всего пипелайна будет, а С++11 будет кастрированный.
Странные места вы читали. В VS2013 поддержка C++11 очень даже неплохая.
Здравствуйте, niXman, Вы писали:
X>зачем с одного г*вна переползать на другое? юзай нормальные компиляторы: gcc, clang
Согласен, компиляторы неплохие. Но я слишком завязан на инфраструктуру вижуала как ИДЕ, поэтому дергаться без весомой причины никуда не буду.
Здравствуйте, 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.
-и буста. но реальные причины уже известны.
даже представлять не хочу, каково "работается" в вашей команде/конторе %)
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>даже представлять не хочу, каково "работается" в вашей команде/конторе %)
Можно бегать сколько угодно, но подавляющее большинство продакшн кода пишется в стиле понятном большинству кодеров, включая новичков. Это очень хорошее бизнес качество кода когда он прост.
Ты можешь перепрыгнуть через голову если у тебя standalone проект и за тобой никто не следит (плюшки прогеру, можно простить высокую зарплату — и риск для бизнеса). Но это не более чем упущение менеджмента.
J>Причины простые. J>* Разработка одной игры занимает полгода/год, за это время на бусте ты не успеешь разогнаться как проект уже закончится.
не понял аргумента. Буст — это набор очень разных либ. Скажем те же поинтеры — в чем проблема использовать? Ну и многие либы переехали в стандарт
J>* Соответствующая квалификация кодеров, проект за год не является слишком сложным, так что junior программисты смогут его осилить самостоятельно. С++ 11 из за своей сложности, к сожалению, превратился в язык для гиков. Чего смешить курей: уж если наши программисты не могут осилить возвращать vector<string> по константной ссылке, куда там до универсальных/r-value ссылкок.
Что такое "возвращать vector<string> по константной ссылке"? r-value дает профит даже без использования в прикладном коде
J>* Шаблоны почти не используются, шаблоны грешат избыточной кодогенерацией что неприемлемо для мобильного мира. Все компайл тайм трюки хорошо замещаются сторонними тулзами на питоне или C#.
шаблоны грешат избыточной кодогенерацией, если их использовать необдуманно. Это все равно что сказать "циклы грешат избыточным временем исполнения"...
Компайл-генерация сторонними тулзами конечно замещается, но а) сторонней тулзе очень сложно получить доступ к типам и прочей информации, доступной компилятору и б) чем писать такую тулзу и встраивать ее в билд, часто много проще написать шаблон или макрос. Хотя в некоторых случаях сторонние тулзы вполне рулят, согласен.
J>* Ну и самое главное — не видно пользы на переход в С++ 11, много противников, к примеру, у auto.
Это все последствия излишней свободы. Скажем среди программистов на питоне нет противников auto или исключений
Здравствуйте, enji, Вы писали:
J>>Причины простые. J>>* Разработка одной игры занимает полгода/год, за это время на бусте ты не успеешь разогнаться как проект уже закончится. E>не понял аргумента. Буст — это набор очень разных либ. Скажем те же поинтеры — в чем проблема использовать? Ну и многие либы переехали в стандарт
Мелочи пишем сами постепенно на коленке, по мере надобности. Для больших либ нужны большие проблемы, которые возникнуть не успевают либо возникают слишком поздно.
E>Что такое "возвращать vector<string> по константной ссылке"? r-value дает профит даже без использования в прикладном коде
Забыта ссылка.
Здравствуйте, johny5, Вы писали:
J>Мелочи пишем сами постепенно на коленке, по мере надобности.
J>Для больших либ нужны большие проблемы, которые возникнуть не успевают либо возникают слишком поздно.
ох уж этот дивный детский мир %)
E>>Что такое "возвращать vector<string> по константной ссылке"? r-value дает профит даже без использования в прикладном коде J>Забыта ссылка. J>
Здравствуйте, johny5, Вы писали:
J>Мелочи пишем сами постепенно на коленке, по мере надобности. Для больших либ нужны большие проблемы, которые возникнуть не успевают либо возникают слишком поздно.
такое впечатление, что каждый проект — как день сурка В одном проекте возникла проблема, пригодился какой-то код из буста. Дальше в следующем проекте используем его сразу же
J>
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, Kernighan, Вы писали:
K>>Язык (и любой другой инструмент) не будет писать за вас программу.
Ops>Ассемблер — наше все?
Как можно было сделать такой вывод из вышесказанного?
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, jazzer, Вы писали:
J>>Отвязался (перешел на стандартную гнутую), прогнал тесты — много чего просело.
BZ>если это критично — надо писать самим. стандартные библиотеки в силу своей общности очень далеки от оптимальной реализации любого конкретного алгоритма
Ну вот когда мне будут платить за это — тогда и займусь, сразу же.
А пока платят за фичи — буду пилить фичи, а апгрейды компиляторов — это все в свободное от пиления фич время.
По той простой причине, что апгрейд компилятора сам по себе не принесет конторе больше денег, поэтому надо по крайней мере убедиться, что ты своим апгрейдом не делаешь хуже. И вот наши тесты показывают, что "не все так однозначно" и, стало быть, торопиться с апгрейдом особого смысла нету.
В С++11/14 много замечательных фишек, но они не критичны, они больше для удобства программера. Того же быстродействия можно добиться и в С++03, пусть и более многословно. тем более что весь наш имеющийся код заточен под максимальное быстродействие в режиме С++03 — так что немедленного выигрыша просто от апгрейда версии языка точно не будет — мы не возвращаем по значению огромные объекты, чтобы rvalue references автоматом все ускорили.
Так что буду помаленьку смотреть, подкручивать опции, пробовать новые версии и компилятора, и библиотек, разные режимы компиляции, пока не добьюсь скорости кода не хуже имеющейся — а вот тогда уже и апгрейдиться можно.
Потому что, к сожалению, у того же GCC сплошь и рядом в оптимизаторе что-нть косячат, посмотри сам у них список багов от версии к версии.
С++11/14 — это фронт-энд и библиотека, но они ж не только их меняют в каждой новой версии, но и бэкэнд с оптимизатором тоже.
И глюки обычно в последних (это чтобы не показалось, что я утверждаю, что С++11 хуже, чем С++03. В компиляторе много компонентов, и улучшив один, вполне могут по ходу дела сломать другой — а у нас тест просядет, и думай — это из за изменений в библиотеке или в конкретном режиме оптимизации).
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, jazzer, Вы писали:
X>ты так говоришь, будто твоя работа заключается только в поддержке существующих проектов, и новые не пишешь... %)
Именно так. У нас большой проект с единым code base и кучей бинарников. Так что даже если я пишу новый компонент, а не добавляю фичу в имеющийся — он все равно будет использовать кучу имеющегося библиотечного быстрого оттестированного кода.
Я не фрилансер, у которого каждый месяц новый проект и пиши на чем хочешь.
Здравствуйте, enji, Вы писали:
E>такое впечатление, что каждый проект — как день сурка В одном проекте возникла проблема, пригодился какой-то код из буста. Дальше в следующем проекте используем его сразу же E>если забыта — надо исправить. Если забыта по незнанию — то, имхо, не зная такие вещи на плюсах писать нельзя. Кстати, rvalue тут спасет
Точнее используем то что на коленке — своё и подправить можно по надобности.
Я избегаю сильно флеймить, но вам нужно смотреть на проект с точки зрения бизнеса.
Что такое хороший код, это:
1. Дешёвый
2. Быстро сделанный
3. Легко заменяемые сотрудники (новый сотрудник, как правило, способен адекватно коммитить уже на 3й рабочий день).
Как этого добиться:
1. Индусы
2. Простота кода
3. Строгие стандарты кодирования
4. Пара пастухов
5. Мощный QA
Так что пишут, и даже с прибылью. Тут весь секрет в нахождении правильного баланса senior <-> junior. Некие маленькие проекты у нас были выполнены чисто только junior-ами. В проектах потолще сеньоров уже процентов 30.
По поводу rvalue, я понимаю, тут у вас неточно — он не сбиндится к const T, потому что обычно move методы принимают неконстантную r-ссылку T&&.
Здравствуйте, niXman, Вы писали:
X>это ужасно, ИМХО %)
Это вполне нормальная повседневная практика — работа над одним, достаточно крупным проектом.
У нас в компании, она также имеет место.
Вводить новый компилятор, тот же C++11, в подобных условиях будет непросто.
З.Ы. Помню, какой стоял "стон", когда мы переходили на C++03 (MSVS2008).
Бесспорно, какая-то часть работы при этом шла в корзину. Срыв сроков в это время был вполне обычным явлением.
Здравствуйте, AlexGin, Вы писали:
AG>Это вполне нормальная повседневная практика
вполне нормально проживать в стране в которой работаешь? да вы еще наверное и в офис ходите пять дней в неделю?
не вижу ничего нормального, ибо ваша жизнь — это жизнь ради работы. несчастные люди, чесслово...
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
AG>>Это вполне нормальная повседневная практика X>вполне нормально проживать в стране в которой работаешь? да вы еще наверное и в офис ходите пять дней в неделю? X>не вижу ничего нормального, ибо ваша жизнь — это жизнь ради работы. несчастные люди, чесслово...
Скатываемся в оффтопик, но не удержусь от вопроса.
А тебе приходится сопровождать твои проекты? Или ты состряпал проект с нуля, отдал и забыл как страшный сон ускакал на новый? Если так, то как ты узнаешь, что принятое тобой решение эффективно и правильно?
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, AlexGin, Вы писали:
AG>>Это вполне нормальная повседневная практика X>вполне нормально проживать в стране в которой работаешь? да вы еще наверное и в офис ходите пять дней в неделю? X>не вижу ничего нормального, ибо ваша жизнь — это жизнь ради работы. несчастные люди, чесслово...
Попытаюсь разложить Ваш, уважаемый niXman, поток сознания по полочкам. Пожалуй, начну с самого конца.
1) Наша жизнь — это постоянное движение. Движение вперед. Семья, работа, родители, друзья — впрочем все это не совсем по теме...
2) Ходить в офис, если нужно, то буду все семь дней в неделю. Это уже как потребует производственная необходимость.
3) Для меня работа — это не только (и не столько) способ прожить, но и возможность эффективного творческого самовыражения.
4) Творчество в работе — это не бессмыссленная погоня за жар-птицейновейшими технологиями/языками, а возможность гармонично развивать начатую разработку. Когда становится ясно, что для развития проекта необходим переход к новому языку, то именно этот переход и будет ложкой к обеду.
5) Мой Заказчик (end user) совсем не будет знать, на какой версии C++ сделан наш продукт, однако это не помешает ему оценить все возможности продукта.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>А тебе приходится сопровождать твои проекты? Или ты состряпал проект с нуля, отдал и забыл как страшный сон ускакал на новый? Если так, то как ты узнаешь, что принятое тобой решение эффективно и правильно?
большинство проектов я продолжаю поддерживать. некоторые дольше других, некоторые меньше. и это не от того, чтоб забыть, причин несколько: 1)интересность поддержки(некоторые проекты в поддержке совсем скучные), 2)наличие предложения влиться в разработку другого проекта.
подчеркну: почти каждый проект в котором я разрабатывал ту или иную часть — всегда имеет со мной связь, и если нужно, со мной связываются по разным вопросам(и по поддержке в том числе).
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
простой вопрос, который расставит все по местам: тебе, чтоб быть счастливым/успешным — нужно всю жизнь прожить в одной стране/городе? и, как неотъемлемая часть — тебе нужно ходить в офис?
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, AlexGin, Вы писали:
AG>2) Ходить в офис, если нужно, то буду все семь дней в неделю. Это уже как потребует производственная необходимость.
а производственная необходимость под тебя подстраивается, жертвует собой ради твоих целей?
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>простой вопрос, который расставит все по местам: тебе, чтоб быть счастливым/успешным — нужно всю жизнь прожить в одной стране/городе? и, как неотъемлемая часть — тебе нужно ходить в офис?
По моему, ты всё валишь в одну кучу. Работать над большим проектом, где нельзя "взять и всё переписать" — это одно. Работать удалённо или в офисе — другое. Я не понимаю почему у тебя эти вещи оказываются жестко связаны.
Кстати, "большой проект" — это совсем не обязательно "древнее легаси, где остался только фикс багов".
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, jazzer, Вы писали:
J>>э-э-э... почему? X>скучно, нудно, однообразно, етц...
хм. Почему?
У меня такое чувуство, что у тебя какие-то очень странные представления о работе программиста, но я их озвучивать пока не буду — вдруг ошибаюсь. Давай ты сначала скажешщь, почему работа в одном проекте — это "скучно, нудно, однообразно, етц", и как оно должно быть, заодно.
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, Dair, Вы писали:
D>>Зато за это платят денег. X>да, если за разработку не платят — то выхода нет, конечно.
что-то я не уловил связи этой фразы с темой разговора
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, AlexGin, Вы писали:
AG>>2) Ходить в офис, если нужно, то буду все семь дней в неделю. Это уже как потребует производственная необходимость. X>а производственная необходимость под тебя подстраивается, жертвует собой ради твоих целей?
Да, если у меня имеется семейная необходимость, то руководство всегда с пониманием относится к данной ситуации.
И конечно же, если у меня что-либо критическое (тьфу-тьфу), то компания, соответственно, может подкорректировать планы!
Здравствуйте, 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. К сожалению, мы скатились в офф-топик
ага.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
K>Язык (и любой другой инструмент) не будет писать за вас программу.
Да тут скорее сравнение ручной и электро- дрелей, и та и другая за вас сверлить не будет, однако, работать лучше со второй (хотя, конечно, иногда, может быть, при определенных условиях ручная дрель и будет лучше/удобнее).
Здравствуйте, Went, Вы писали:
W>Здравствуйте. Наверное, мой вопрос затерт и банален, но все же решусь его повторить Я хочу получать код, который без особых костылей компилируется на Win7-8, MacOS, IOS, Android. На что я могу рассчитывать? Речь не о том, какую фичу поддерживает тот или иной компилятор, а об общем тренде — переходят ли на С++11 программисты кроссплатформенных игр?
Мы разрабатываем не совсем игры, но что-то похожее по структуре. Давно перешли.
X>про RVO ты похоже не слышал...
Как и ты. В приведенном примере возвращается копия члена класса, судя по префиксу "m_", RVO в данном случае работать не будет.
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 есть куча новых полезностей, те же смарт поинтеры.
Здравствуйте, chaotic-good, Вы писали:
J>>* Ну и самое главное — не видно пользы на переход в С++ 11, много противников, к примеру, у auto. CG>А какие есть аргументы у противников auto?
Например фанаты венгерской нотации не переваривают auto.
Лично мне тоже не прельщает 2 два сайдэффекта:
* тип твоей переменной может непредсказуемо измениться (например int -> unsigned) в процессе рефакторинга. По сути ты теряешь в стабильности кода из-за того что твои типы стали плавающие — придётся 7 раз подумать и всё предвидеть.
* теряется читабельность кода, всё больше и больше придётся возюкать мышкой по переменным чтобы понять что там прячется.
Чтобы не пинали ногами вот вам примеры когда это хорошо. Всё это случаи когда мы не хотим знать тип:
* итераторы, мы никогда не хотим знать их тип, лишь бы они предлагали свой интерфейс доступа.
* всякие сложные функторы, порождённые лямбдой, boost::bind и прочей нечистью
Здравствуйте, 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.
Здравствуйте, sunheretic13, Вы писали:
S>Конечно пора. Перевёл все подконтрольные проекты на VS2013/g++4.8 и ничуть не жалею. Только не забывайте что в VS2013 есть баги с С++11.
А куда деваться? 15-ая вроде тестовая только.
Здравствуйте, kurchatov, Вы писали:
K>Забавно читать, как у Никсмана бомбит
не уверен, что это значит, но приблизительно догадываюсь... (и зачем люди опускают себя до уровня быдлошпаны используя такие словечки?... вопрос риторический, на самомо деле.)
K>из-за того, что кто-то не использует Boost
ты себе намеренно лжешь? или просто выдаешь желаемое за действительное?
я, как любой свободный и свободолюбивый человек, адекватно принимаю выбор каждого свободного человека, будь-то его любимым блюдом собственный кал, или любимым человеком — особь того же пола, а любимым делом — клепание велосипедов аналогичных бусту из-за своей ограниченности. (нет, это не относится к тем случаям, когда использование буста просто технически невозможно или запрещенно свыше)
я лишь против практики преподносить качественные минусы человеков как плюсы, в чем многие тут были замечены.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>ты себе намеренно лжешь? или просто выдаешь желаемое за действительное?
X>я, как любой свободный и свободолюбивый человек, адекватно принимаю выбор каждого свободного человека, будь-то его любимым блюдом собственный кал, или любимым человеком — особь того же пола,
Мда. Бывает же.
X> а любимым делом — клепание велосипедов аналогичных бусту из-за своей ограниченности. (нет, это не относится к тем случаям, когда использование буста просто технически невозможно или запрещенно свыше)
ограниченные в итоге клепают всю прибыль для компаний. Что поделаешь, метапрограммирование в С++ имеет ужасную семантику, и, как следствие — высокий порог вхождения.
Здравствуйте, johny5, Вы писали:
J> С++ 11 из за своей сложности, к сожалению, превратился в язык для гиков.
Не соглашусь. В С++11 есть фичи, облегчающие жизнь. Самый "gem" — это, конечно, move semantics.
Как раз теперь самый обычный кодер может не думать где что копируется, возвращая вектор из функции.
Еще мне нравится std::function — убрало тучу головной боли с указателями на функции. Ну и std::thread, std::atomic вполне удобны.
Насчет auto — да, спорный момент; по кр.мере удобно для итераторов
Здравствуйте, niXman, Вы писали:
X>не, не ради троллига. мне действительно непонятно мышление, на основании которого, было решено использовать STLport %)
Давным давно в STLport-е была очень вкусная вещь типа отладочного режима, когда в рантайме постоянно производились проверки валидности итераторов, переданных в алгоритмы аргументов и т.д. Сейчас уже это есть во многих реализациях STL, но я помню времена, когда это было только в STLport. И это было очень круто и полезно. Тогда его можно было выбрать только из-за одной этой фичи.
Здравствуйте, kurchatov, Вы писали:
K>ограниченные в итоге клепают всю прибыль для компаний.
т.е. клепание *надцатых низкокачественных лисапетов — это прибыль компании? что-то со мной определенно не так =)
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, kurchatov, Вы писали:
K>Мда. Бывает же.
совки — такие совки...
радует одно: большая часть мира таки понимает, что совки таки отстали в развитии лет эдак на 70, и снисходительно таки к ним относятся...
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
"Четвертые сутки пылают станицы и девочек..."
Короче, было не до девочек — мы на новый стандарт переходили.
Четверо суток вся контора в едином порыве ставила студии, правила Makefile'ы, код и инсталяторы, компилировала сторонние библиотеки, переходила на новый стандарт.
Четверо суток и победа снова за нами.
Особенно интересно было у меня. Visual Studio 2013 на Server 2003 ставится не захотела, так что пришлось переставить всё, начиная с нового винчестера. Особое удовольствие получил от компилирования Qt 4 — без патчей в Visual Studio 2013 фиг скомпилишь!
Здравствуйте, B0FEE664, Вы писали:
BFE>Особенно интересно было у меня. Visual Studio 2013 на Server 2003 ставится не захотела, так что пришлось переставить всё, начиная с нового винчестера. Особое удовольствие получил от компилирования Qt 4 — без патчей в Visual Studio 2013 фиг скомпилишь! BFE>Не верьте про 30 минут
По всей видимости это затраты на переход с одной студии на другую. То есть если бы в новой студии не было C++11, то при переходе вы бы получили практически те же затраты
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>По всей видимости это затраты на переход с одной студии на другую. То есть если бы в новой студии не было C++11, то при переходе вы бы получили практически те же затраты
Нет, не те же. Всё-таки исправление кода и перекомпиляция всех библиотек занимает существенное количество времени. К тому же, надо ещё инсталяторы править, так как новые dll'и и всё такое.
Ну а какая альтернатива? Запускать cl.exe из батников? Прикручивать новый компилятор к старой студии?
Здравствуйте, B0FEE664, Вы писали:
BFE> К тому же, надо ещё инсталяторы править, так как новые dll'и и всё такое.
ДЛЛки могли бы обновиться без изменения версии стандарта С++.
Речь о том, что переход с 2005 студии на 2008 (ни там ни там нет С++11) или с 2012 на 2013 (формально, С++11 есть и там и там) может такие же проблемы вызвать. Именно стандарт тут не при чём. Обновляться могли заставить более удобные инструменты или поддержка новый версий винды.
Здравствуйте, DarkEld3r, Вы писали:
DE>Речь о том, что переход с 2005 студии на 2008 (ни там ни там нет С++11) или с 2012 на 2013 (формально, С++11 есть и там и там) может такие же проблемы вызвать. Именно стандарт тут не при чём. Обновляться могли заставить более удобные инструменты или поддержка новый версий винды.
Компилятор и есть "более удобный инструмент". А вот собственно студия для меня ничем не лучше 2008-ого года выпуска.
Я хочу получать код, который без особых костылей компилируется на Win7-8, MacOS, IOS, Android. На что я могу рассчитывать? Речь не о том, какую фичу поддерживает тот или иной компилятор, а об общем тренде — переходят ли на С++11 программисты кроссплатформенных игр?
2014 год заканчивается, люди уже С++14 юзают, и собираются юзать C++1z
.
