А если нет, то там есть целая пачка инструкций ассемблерных для перевода туда сюда.

А если не компайл тайм, а где то там вычисляется ? Вот я сижу пробую понять что там происходит ....

должен переводить

Я больше соглашусь с Матвеем - так как, это логично звучит, да и команды такие я встречал и в SIMD в т.ч

Вот если бы экспоненты у флоата и дабла были одной длины .... И мантисы под выравниваение попадали ...

CVT*

Мантисы и экспоненты разной длины. Совершенно точно

Ну это да, увы :( Так бы просто добавил 4 байтика и дело в шляпе - то есть просто в xmm

http://www.felixcloutier.com/x86/CVTSS2SD.html

Я тут буквально три недели назад погорел на том, что существует инструкция для пакетного преобразования 32-битных целых во float-ы. А для 16-битных нету пакетной инструкции :(

Ну это да, увы :( Так бы просто добавил 4 байтика и дело в шляпе - то есть просто в xmm

На мой взгляд это было бы по меньшей мере странно. Размер мантиссы отвечает за относительную точность задания числа, а размер экспоненты за интервал чисел, которые можно задать. Логично, что если я перехожу от 4 байт к 8 байтам, я бы хотел, чтобы у меня одновременно стало и по точнее, и чисел побольше.

Да, меня больше забавляет long double - у MSVC он равенобычному даблу, а у GCC и Интела - юзает только 80 бит !

А не 128 как можно было бы ожидать :)

Я тут буквально три недели назад погорел на том, что существует инструкция для пакетного преобразования 32-битных целых во float-ы. А для 16-битных нету пакетной инструкции :(

А в SSE разве тоже нету ?

А в SSE разве тоже нету ?

В SSE и нету как раз

Да, меня больше забавляет long double - у MSVC он равенобычному даблу, а у GCC и Интела - юзает только 80 бит !

если правильно помню, то 80 бит - это размер аккумулятора для операций с плавающей точкой на 32-битных x86.

Ой вей! https://www.reddit.com/r/cpp/comments/6qphdf/stdoptional_view/

Привет парни. Если кто может, скиньте какую-нибудь библиотеку для работы с ВК API

Привет парни. Если кто может, скиньте какую-нибудь библиотеку для работы с ВК API

https://github.com/search?l=C%2B%2B&q=vk+api&type=Repositories&utf8=%E2%9C%93

Привет парни. Если кто может, скиньте какую-нибудь библиотеку для работы с ВК API

Почему на c++? На питоне тьма их

Почему на c++? На питоне тьма их

Именно потому, что я пишу на С++

Что нового в С++17 посравнению с С++11?

а С++14 куда пропал?

@polinahr https://habrahabr.ru/company/yandex/blog/323972/

а С++14 куда пропал?

С++11 текущая, сейчас переходим на С++17 есть ли смысл

больших изменений в языке не было.

больших изменений в языке не было.

спасибо

@polinahr тут подробнее https://isocpp.org/files/papers/p0636r0.html

есть более кошерная ссылка

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0636r1.html

@polinahr тут подробнее https://isocpp.org/files/papers/p0636r0.html

у меня свежее редакция :D

Чтобы обидно не было пошла читать и ту и другую

С++11 текущая, сейчас переходим на С++17 есть ли смысл

Напишу лично для меня важные изменния. Для начала С++11 -> C++14 Вот на вскидку - нормальные constexpr функцих ограничений на один return и отсутсвие циклов - инициализация захватываемых переменных в лямбдах. теперь можно в лямбду перемещать переменные используя std::move, а значит и захватывать некопируемые переменные - return type deduction. теперь в сигнатуре функции может быть auto в качестве возвращаемого значения. auto foo() { return 15; } тип автоматически выведится. очень сильно помогает писать обобщённый код

А так же делать higher-order функции, которые генерируют лямбды. в С++11 с этим были проблемы

- Появились обобщённые лямбды, принимающие в качестве параметров auto. [] (auto x, auto y) { return x + y; } Хотя лично я этим редко пользуюсь

ну такой фикс С++11 вышел, С++17 повкуснее

Почему сейчас не стоит переходить на 17 плюсы: 1. Многие и на старых плюсах программируют не очень 2. Нужен спец в команду кто хорошо их знает, так как вещь новая, то выльется в доп. траты 3. Придется поднимать зарплату другим сотрудникам, как мотиватор лучше осваивать новый стандарт 4. Нет, ну вы только посмотрите на пункт 1 - я серьезно, даже сеньоры, так себе это делают.

С++14 -> C++17 - template argument deduction for class templates тут просто. std::pair p(1, "one"); вместо std::pair<int, const char*> p(1, "one'); - folding expressions. свёртка для вариадиков. тоже полезная штука template<typename Args...> auto sum(Args... args) { return args + ... + args; } - constexpr лямбды - inline переменны - гарантированное copy ellision! (крутая фича) - if constexpr (тоже крутая фича :)

5. Так как стандарт новый, много багов в компиляторах, а самое главное то, как это оптимизируется.

.Тьфу, не то вставил

ой, все

Почему сейчас не стоит переходить на 17 плюсы: 1. Многие и на старых плюсах программируют не очень 2. Нужен спец в команду кто хорошо их знает, так как вещь новая, то выльется в доп. траты 3. Придется поднимать зарплату другим сотрудникам, как мотиватор лучше осваивать новый стандарт 4. Нет, ну вы только посмотрите на пункт 1 - я серьезно, даже сеньоры, так себе это делают.

Соглашусь с вами. Но есть и желательные требования.Поэтому приходиться вникать во все детали

Обычно, доводы которые программисты приводят на новый стандарт - мелочны. И называть это полным переходом на новый стандарт - язык не повернется: пару фич и все. Ну, у меня так. И не едижды, и не в одном месте.

Мы в команде с переходом на С++14 смогли довольно быстро релизовать DSL (для парадигмы ECS), который на C++03 было сделать куда сложнее

5. Так как стандарт новый, много багов в компиляторах, а самое главное то, как это оптимизируется.

Бред.

Так что ваш аргумент очень странный. У нас в руках появился мощный инструмент и мы должны отказаться от него? Ради чего? Из-за того, что есть те, кому лень прочитать пару статей в интернете и покопаться в cppreference? А зачем такие люди в команде?

Мы в команде с переходом на С++14 смогли довольно быстро релизовать DSL (для парадигмы ECS), который на C++03 было сделать куда сложнее

Ну так вы явно не весь функционал из 14 взяли. Даже больше - он не весь и не полный в компиляторах, ну то есть бажный.

Почему сейчас не стоит переходить на 17 плюсы: 1. Многие и на старых плюсах программируют не очень 2. Нужен спец в команду кто хорошо их знает, так как вещь новая, то выльется в доп. траты 3. Придется поднимать зарплату другим сотрудникам, как мотиватор лучше осваивать новый стандарт 4. Нет, ну вы только посмотрите на пункт 1 - я серьезно, даже сеньоры, так себе это делают.

Тоже бред.

Ну так вы явно не весь функционал из 14 взяли. Даже больше - он не весь и не полный в компиляторах, ну то есть бажный.

Про бажность пруф пожалуйста

Ну так вы явно не весь функционал из 14 взяли. Даже больше - он не весь и не полный в компиляторах, ну то есть бажный.

чот какие-то суеверия

Ну так вы явно не весь функционал из 14 взяли. Даже больше - он не весь и не полный в компиляторах, ну то есть бажный.

И что, что не весь?)

Лол

Ну то, что разработка не должна превращаться в массовое заучивание стандарта. Ну мое видение именно такое. И у меня была возможность все это испытывать и на окружающих и на себе.

Я, конечно, студент, но плюсы вроде как обратно совместимы, и переписывать все вокруг на новый стандарт заставлять не надо. А вот фичи использовать - почему нет?

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

Ну то, что разработка не должна превращаться в массовое заучивание стандарта. Ну мое видение именно такое. И у меня была возможность все это испытывать и на окружающих и на себе.

Ну вот захотели мы заюзать новое API для 3д графики Vulkan. Но это тоже подпадает под все пункты, почему его нельзя использовать. И что отказываться?

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

Ну так вы явно не весь функционал из 14 взяли. Даже больше - он не весь и не полный в компиляторах, ну то есть бажный.

ага, некоторые баги висят годами из старых стандартов

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71367

так что это не повод

Ну то, что разработка не должна превращаться в массовое заучивание стандарта. Ну мое видение именно такое. И у меня была возможность все это испытывать и на окружающих и на себе.

anecdotal evidence

называется такая штука

так что это не повод

Нет софта без багов)

Нет софта без багов)

Нет софта - нет багов

Нет софта - нет багов

Есть баг - софта нет))

Значит это фича:)

Ещё стандарты какие-то учить, на крестах писать, нунаф

лучше каждые шесть недель обновлять код под новую версию раста :)

Ещё стандарты какие-то учить, на крестах писать, нунаф

Будущий начальник:)

😂

Я, конечно, студент, но плюсы вроде как обратно совместимы, и переписывать все вокруг на новый стандарт заставлять не надо. А вот фичи использовать - почему нет?

Фичи использовать - я за. Да. Но это не полный переход на 17 стандарт. Полным назовем ту ситуацию когда на собесе тебя опрашивают именно по 17 плюсам.

Так он ещё только-только приготовился

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

Профи да. В команде обычно есть и профи и не профи. Ну типа джуны

чето помойму уже в холивар скатываетесь

Так он ещё только-только приготовился

Ну так я потому и оформил свое мнение. Но например в сипровер спрашивают и такое, но и платят соотв.

Наши джуны всё схватывают на лету и умеют осваивать новые технологии

А если джун не такой, то гнать его надо в универ.

Наши джуны всё схватывают на лету и умеют осваивать новые технологии

вы их бьёте

?

Нашел куда гнать. В универах сегодня еле 03 дают. И тот через шаг.

Ну так я потому и оформил свое мнение. Но например в сипровер спрашивают и такое, но и платят соотв.

Вообще человек спросил какие новые фичи в С++17 появились со времнёс С++11. Я хотел обсудить эту интересную тему. Но ты зачем то отвлёк разговор на тему С++17 не нужен