Здравствуйте, о_О, Вы писали:
о_О>Прювет.
о_О>Что вы думаете по поводу использования новых возможностей сегодня? constexpr, auto, nullptr, RV-ссылки, лямбды — какие за и против?
против — не везде реализовано, а где реализовано, частенько реализовано криво.
всё остальное только за.
Так что если убедишься, что твои компиляторы правильно поддерживают то, что тебе надо, и не планируется перенос на другие компиляторы, то смело юзай и наслаждайся
Здравствуйте, о_О, Вы писали:
о_О>Что вы думаете по поводу использования новых возможностей сегодня? constexpr, auto, nullptr, RV-ссылки, лямбды — какие за и против?
А чего думать? Использую как только появились в компиляторе, под который пишется проект.
Не всё конечно. Nullptr нигде ещё не понадобился, NULL более чем достаточно. Constexpr в ICC ещё нет, лямбды не пригодились — foreach на цикле for с auto удобнее в разы.
Static_assert, auto, decltype и && — очень полезные, да.
Ну а вообще смотри по задаче, что из нововведений может пригодиться а что нет.
Здравствуйте, о_О, Вы писали:
о_О>Прювет.
о_О>Что вы думаете по поводу использования новых возможностей сегодня? constexpr, auto, nullptr, RV-ссылки, лямбды — какие за и против?
я вот сегодня заюзал рэндж цикл и несказанно рад так как код под кланг, никто не требует работы с другими компиляторами, потому можно
и использую авто, так приятно
Of course, the code must be complete enough to compile and link.
Здравствуйте, о_О, Вы писали:
о_О>Что вы думаете по поводу использования новых возможностей сегодня? constexpr, auto, nullptr, RV-ссылки, лямбды — какие за и против?
Я считаю, не надо никуда торопиться. Ничего особо прекрасного в новом стандарте нет, так сахара подсыпали, так что совсем не к спеху. Компиляторы должны устояться, баги там должны быть отловлены -- это время. Это много времени. И лучше если о сырость реализации новой фичи споткнётся не мой код, я слишком часто попадал на отладку багов в GCC и представляю себе, что это такое.
Здравствуйте, Banned by IT, Вы писали:
BBI>А чего думать? Использую как только появились в компиляторе, под который пишется проект. BBI>Не всё конечно. Nullptr нигде ещё не понадобился, NULL более чем достаточно.
а я вот думаю, что с nullptr делать — внедрять или не внедрять. пока думаю, что рано
Здравствуйте, о_О, Вы писали:
о_О>Прювет.
о_О>Что вы думаете по поводу использования новых возможностей сегодня? constexpr, auto, nullptr, RV-ссылки, лямбды — какие за и против?
использовать.
никаких "против" нет и не может быть.
обычно те кто "против" просто не знают что это за фича и зачем ее ввели в стандарт.
Здравствуйте, о_О, Вы писали:
BBI>>А чего думать? Использую как только появились в компиляторе, под который пишется проект. BBI>>Не всё конечно. Nullptr нигде ещё не понадобился, NULL более чем достаточно. о_О>а я вот думаю, что с nullptr делать — внедрять или не внедрять. пока думаю, что рано
о_О>Что вы думаете по поводу использования новых возможностей сегодня? constexpr, auto, nullptr, RV-ссылки, лямбды — какие за и против?
против только — опасения в качестве реализации, не хочется быть бета тестером
необходимость миграции на другую студию — это некоторые затраты
Здравствуйте, о_О, Вы писали:
о_О>Что вы думаете по поводу использования новых возможностей сегодня? constexpr, auto, nullptr, RV-ссылки, лямбды — какие за и против?
Что тут думать? Если целевые платформы позволяют — потихоньку начинать использовать. Если нет — не использовать.
Здравствуйте, Banned by IT, Вы писали:
BBI>Здравствуйте, о_О, Вы писали:
BBI>>>А чего думать? Использую как только появились в компиляторе, под который пишется проект. BBI>>>Не всё конечно. Nullptr нигде ещё не понадобился, NULL более чем достаточно. о_О>>а я вот думаю, что с nullptr делать — внедрять или не внедрять. пока думаю, что рано
BBI>Полезность его как то не очевидна.
полезность такая же как у const и static_assert — дополнительная проверка времени компиляции
Здравствуйте, rm822, Вы писали:
о_О>>Что вы думаете по поводу использования новых возможностей сегодня? constexpr, auto, nullptr, RV-ссылки, лямбды — какие за и против? R>против только — опасения в качестве реализации, не хочется быть бета тестером R>необходимость миграции на другую студию — это некоторые затраты
Дык не надо менять студию, смени компилятор в той же студии.
Здравствуйте, rm822, Вы писали:
BBI>>Дык не надо менять студию, смени компилятор в той же студии. R>и какой компилятор кроме студийного умеет C++ CLR?
Ты таки определись, что тебе надо: С++ или CLR?
Здравствуйте, Abyx, Вы писали:
BBI>>>Дык не надо менять студию, смени компилятор в той же студии. R>>и какой компилятор кроме студийного умеет C++ CLR?
A>сейчас прибегут пять человек и скажут что C++\CLR не нужен
Как склейка managed и unmanaged — нормально.
Писать целиком на нём: уже лучше сразу C# взять.
Код ms компилер для MC генерит поганенький.
BBI>Ты таки определись, что тебе надо: С++ или CLR?
мне и того и другого
CLR это интерфейс для гуя, у нас гуй на шарпе рисуется а ядро на плюсах.
Ща конечно набегут и будут что-то лопотать про QT, HTMLayout и прочие непотребства
Здравствуйте, rm822, Вы писали:
BBI>>Ты таки определись, что тебе надо: С++ или CLR? R>мне и того и другого R>CLR это интерфейс для гуя, у нас гуй на шарпе рисуется а ядро на плюсах.
Ну так и нафига вам тогда MC?
Из C# можно нормально дёргать native DLL, которые можно собрать более эффективно чем это делает МС.
R>Ща конечно набегут и будут что-то лопотать про QT, HTMLayout и прочие непотребства
Как вы могли такое подумать! Исключительно чистейший спирт WinAPI!!!
BBI>Ну так и нафига вам тогда MC? BBI>Из C# можно нормально дёргать native DLL, которые можно собрать более эффективно чем это делает МС.
Это ты из маркетинговых материалов почерпнул?
Давай посмотрим как у тебя получится дернуть метод вот с такой сигнатурой
Здравствуйте, о_О, Вы писали:
о_О>Прювет.
о_О>Что вы думаете по поводу использования новых возможностей сегодня? constexpr, auto, nullptr, RV-ссылки, лямбды — какие за и против?
)
по прошествии еще месяца с небольшим могу добавить:
* целевая платформа обрела gcc 4.6 (было 4.5) поэтому круг возможных фич расширяется, что не может не радовать
* в gcc 4.6 реализован документ N3053, что привело к тому, что куча кода используещго boost перестала собираться (хотя до этого все нормально собиралось на 4.5) -- после ресеча "проблемы" стали чаще пользоваться defaulted and deleted functions
* почуствовал вкус от применения decltype (http://rsdn.ru/forum/cpp/4442630.1.aspx
) -- особенно в сравнении с аналогичным "мясом" сделаным в библиотеке TTI от следующего boost
* raw string literals получили большее распространение. в основном по прежнему в юнит тестах.
* после ознакомления с Саттеровской заметкой (http://herbsutter.com/elements-of-modern-c-style/) чаще стали применять auto, но сила привычки видеть явное объявление типа, все еще дает о себе знать
* std::unique_ptr и его специализация для массивов std::unique_ptr<T[]> практически полностью вытеснили boost::scoped_ptr и boost::scoped_array (вычищаем остатки по мере того как дело касается рефакторинга уже написанного кода), не все так гладко получается с заменами shared_ptr -- некоторые части boost, к сожалению завязаны только на свои смарт-поинтеры... ;( хотя есть и неожиданные открытия -- boost::signals2 способна понимать std::shared_ptr для trackable сигналов )
* буквально вчера в коде появились variadic templates -- в классе-обертке шаблонный конструктор, который прокидывает нужное число параметров в базовый, заранее не известный, тип...
* Initializer Listы оказались полезны не только для контейнерных типов
* несколько разочаровывает std::bind... placeholderы находтся в отдельном пространстве имен, а using namespace у нас сцуко запрещен в code policy ;( с другой стороны упаришься следить за тем чтобы не было конфликтов с boost::bind, который неявно подключается кучей бустерных библиотек... boost::bind пока все еще не выпилили до конца из нашего кода -- повода не было рефачить существующий код
* наткнувшись на неприятность задумываемся о применении nullptr... правда все осложняется тем, что неприятность находится в коде который должен компилиться не только gccой... ;(
* ждут своего часа куски кода в которых уместно было бы constexpr -- как только там надо будет что-то порефачить, заодно и это приделаем... пока обходимся вздохами типа "ах было бы здорово если бы там был constexpr" -- но, т.к. пока не критично не лезем туда...
* ну и в конце повторюсь еще раз Rvalue references + move constructors = щастье!
