Обзор новых возможностей С++14: Часть 2

    На этот раз нововведений гораздо меньше, чем в первой части. Все-таки С++14 считается незначительным релизом, нацеленным скорее на устранение недочетов С++11, чем привнесение новых возможностей.

    Краткий перечень:
    • Освобождение памяти определенного размера
    • Одинарная кавычка, как цифровой разделитель
    • Аттрибут [[deprecated]]
    • Пользовательские литералы для std::complex
    • Filesystem API
    • Преобразование сетевого порядка байт

    Обзор новых возможностей С++14: Часть 1
    Текущий черновик стандарта


    Изменения в самом языке


    Освобождение памяти определенного размера


    В C++11 программисты могут определить статический метод класса operator delete, который бы принимал параметром размер удалямого объекта. Теперь же в стандарт был добавлен соответствующий глобальный оператор delete. Это изменение призвано повысить производительность современных распределителей памяти.

    Добавленные операторы имеют следующие сигнатуры:
    void operator delete(void* ptr, std::size_t size) noexcept;
    void operator delete(void* ptr, std::size_t size, const std::nothrow_t&) noexcept;
    void operator delete[](void* ptr, std::size_t size) noexcept;
    void operator delete[](void* ptr, std::size_t size, const std::nothrow_t&) noexcept;
    

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

    Одинарная кавычка, как цифровой разделитель


    Теперь можно будет использовать одинарные кавычки для обособления порядков чисел. Например, числа 1048576, 1'048'576, 1'0'4'8'5'7'6, 0X100000, 0x10'0000, и 0'004'000'000 имеют одно и тоже значение.
    Однако это изменение приводит к следующим проблемам:
    Во-первых, изменяется поведение расширения макросов. Например:
    #define M(x, ...) __VA_ARGS__
    int x[2] = { M(1'2,3'4) }; 
     // C++11: int x[2] = {};
     // Now:   int x[2] = { 3'4 };
    

    А во-вторых, множество редакторов и других утилит, предназначенных для подсветки синтаксиса, будут теперь неправильно парсить код. Даже Хабрахабр не устоял, сравните:
    int testing_habrahabr_syntax_highlighter = 1000;
    

    int testing_habrahabr_syntax_highlighter = 1'000;
    

    int testing_habrahabr_syntax_highlighter = 1'000'000;
    

    int testing_habrahabr_syntax_highlighter = 1'0'0'0'0'0'0;
    

    Аттрибут [[deprecated]]


    В C++11 был стандартизирован синтаксис объявления аттрибутов, ранее известных как __attribute__ для gcc/clang и __declspec для VC++. В C++14 был добавлен аттрибут, позволяющий пометить любой из следующих токенов: класс, переменную, нестатический член класса, функцию, перечисление, специализацию шаблона или typedef — как устаревший, если по каким-либо причинам дальнейшее их использование нежелательно. В результате, при использовании программистом помеченных таким аттрибутом токенов, компилятор будет выдавать предупреждение. Опциональный параметр аттрибута позволяет указать свое дополнительное сообщение (например, предложение о подходящей замене), которое будет выведено вместе с предупреждением компилятора.
    void foo();
    [[deprecated("use 'foo' instead")]] void bar();
    

    Допускается переобъявление токенов с этим аттрибутом, если Вы, например, хотите запретить своей команде разработчиков использовать некоторые функции из сторонних библиотек, однако снять действие этого аттрибута переобъявлением нельзя.
    #include <GL/gl.h>
    [[deprecated("use 'glDrawArrays' instead")]] void glBegin(GLenum);
    

    На усмотрение разработчиков STL, все подходящие токены, указанные в дополнении D к стандарту C++ (Compatibility features), могут быть помечены этим аттрибутом.

    Изменения в стандартной библиотеке


    Пользовательские литералы для std::complex


    Добавлены следующие литералы для быстрого создания комплексных чисел, состоящих только из мнимой части:
    namespace std {
    inline namespace literals {
    inline namespace complex_literals {
    constexpr complex<long double> operator""il(long double);
    constexpr complex<long double> operator""il(unsigned long long);
    constexpr complex<double> operator""i(long double);
    constexpr complex<double> operator""i(unsigned long long);
    constexpr complex<float> operator""if(long double);
    constexpr complex<float> operator""if(unsigned long long);
    }}}
    

    В результате можно легко и просто создавать комплексные числа привычными арифметическими операциями:
    using namespace std;
    complex<double> a = 1.5 + 0.3i;
    auto b = 2.3 - 0.2i;
    

    Технические спецификации


    image
    Как показано на изображении, до 2011 комитет использовал «монолитную» модель, где все новые возможности попадали в единственный черновик стандарта.
    Начиная с 2012 комитет перешел на более «распределенную» модель, где основные направления разработки стандарта ведутся независимо от самого стандарта со своей скоростью и могут быть выпущены как только будут готовы, не дожидаясь выхода основного стандарта, в виде технических спецификаций (ТС), с последующим слиянием вместе с ним через некоторое время. Такая модель позволяет комитету представлять работу публике небольшими частями более быстрым и предсказуемым способом. Это также должно ускорить выпуск новых версий самого стандарта.

    На данный момент уже одобрен черновик технической спецификации API для работы с файловой системой, основанный на Boost.Filesystem v3, включая итерацию по файлам и директориям.

    Активно ведется доработка следующих спецификаций:
    1. Networking TS. На данный момент содержит в себе:
      • Функции для преобразования порядка байт между сетевым (big-endian) и используемым на локальной машине, основанные на функциях htonl(), htons(), ntohl(), ntohs() стандарта POSIX. Уже одобрено комитетом.
      • API для работы с URI. Еще ожидает одобрения комитета.
    2. Library Fundamentals TS: Представляет из себя набор расширений основной части стандартной библиотеки. Сюда были вынесены optional<> и другие фундаментальные утилиты для доработки.
    3. Array Extensions TS: Расширения языка и библиотеки связанные с массивами. Сюда были вынесены runtime-sized arrays и dynarray<> для доработки.
    4. Concurrency TS: Изначально включает в себя поддержку исполнителей (executors) и планировщиков (schedulers) и поддержку неблокирующих операций для std::future, таких как .then() и .when_*(). Позже сюда могут быть добавлены расширения языка, типа await, и расширения библиотеки, типа параллельных хэш-контейнеров.
    5. Расширения для параллелизма: Изначально включает в себя параллельную STL библиотеку с поддержкой параллельных алгоритмов, использующих несколько ядер процессора, и векторизуемых (vectorizable) алгоритмов, использующих всю мощь наборов инструкций процессоров.

    Все технические спецификации используют пространтсво имен std::experimental.

    Также недавно начала свою работу группа, занимающаяся графикой, с целью стандартизировать «2D Lite» API для рисования. Небольшое обсуждение графики и C++ можно посмотреть в презентации Герба Саттера с GoingNative2013, начиная с 42:30 здесь.

    Заключение


    Следующая встреча комитета запланирована на февраль 2014 года. После чего мы получим некоторое подобие релиз кандидата следующего — С++14 стандарта, также известного, как С++1y.
    По последним данным, Clang вместе с libc++ в SVN уже полностью реализуют текущий черновик стандарта, GCC несколько отстает. Убедиться в этом можно здесь: Clang, libc++, GCC.

    Обзор новых возможностей С++14: Часть 1
    Текущий черновик стандарта

    P.S. swap оператор


    Среди всех прочих предложений для стандартизации, прошлой весной появилось предложение внести в С++ специальный оператор обмена :=:, чтобы заменить функцию стандартной библиотеки std::swap. Тогда некоторые восприняли это как первоапрельскую шутку, но в конце августа предложение обновилось до версии 2. Мне пока не известно мнение комитета о данном операторе, но его еще пока не одобрили для стандартизации. Подробнее прочитать о нем можно здесь.

    Only registered users can participate in poll. Log in, please.

    Как Вы считаете, нужен ли в С++ оператор :=:?

    • 48.5%Да, он будет полезен.549
    • 51.5%Нет, он будет лишним.584
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 84

    • UFO just landed and posted this here
        +17
        жесть, ну не нужен «специальный оператор обмена» :=:. И так разобраться во всём, что добавили трудно, учитывая, что сколько не работай с С++03 — «каждый день что-то новое узнаёшь».
          0
          Да, бессмыслица. В C# были разговоры чтобы сделать :=: binding operator, но там это возможно и имеет смысл. А как сокрашение для swap — сомнительно.
          –2
          Почему не нужен? swap неудобен, потому что обобщённая версия находится в namespace std. Из-за этого приходится писать:

          using std::swap; swap(a, b); // a & b - два шаблонных типа

          С оператором :=: можно будет просто:

          a :=: b;
            +3
            а если я хочу, чтобы swap действительно был выбран из std? Вы ответите — тогда просто пишем std::swap(a, b). А теперь в коде появляется и swap и :=:. И swap более заметен, чем :=:(это как с советом «определяйте функция преобразования operator T() только в крайних случаях»).
            Согласитесь, что не нужно делать изменения в языке, чтобы избежать одной только, понятной всем, маленькой строчки кода using std::swap;. Это излишне. В С++ и так слишком много штук, которые можно сделать в слишком много способов, не нужно добавлять избыточности.
          +55
          In C++14 you just write «auto auto(auto auto) { auto; }». The compiler infers the rest from context.
            –24
            Пока они там тупили, куча народу убежала на шарп и уже никогда не вернется.
              +8
              Да, C++ имеет фатальный недостаток, и именно поэтому MS родили C#
              Шарп это не кроссплатформенное (очередная закрытая платформа от MS без фатального недостатка), к тому же тормозное решение, с непредсказуемо работающим сборщиком мусора, и не дающее прямой доступ доступ к железу. Единственно для чего полноценно пригоден шарп это написания гуй приложений под винду, и в общем то всё, т.е. никаких высоких нагрузок, никаких встраиваемых решений. Если бы MS сделала C++ библиотеку для работы со своей системой, сопоставимую по уровню удобства использования со стандартными либами C#, то шарп использовался бы гораздо-гораздо реже.
              p.s: да и вообще не понятно зачем писать в этом топике о шарпе, напишите статью сравнение, раскройте нам глаза, покажите насколько убогий С++, и почему C# лучше
                +1
                > с непредсказуемо работающим сборщиком мусора
                А что, есть предсказуемые?
                  +4
                  Нет, но это не важно. Ведь в C++ есть только ручное управление памятью, а именно эти два языка и сравниваем.
                    0
                    И при этом забываем, что необходимо использовать аллокаторы, умные указатели, которые еще потребляют памяти, влияют на производительность, чтобы хоть как-то «правильно» управлять памятью.

                    Например, парсер CSS, написанный на C#, выдает следующие результаты (с полным построением объектной модели):
                    1) 30 Mb/s для файлов более 7 Mb.
                    2) 61 Mb/s для файлов размером до 128 Kb.

                    Разница между объемами происходит из-за размеров поколений объектов (а любой парсер выдает огромное кол-во токенов).

                    Те же данные для парсера от Mozilla:
                    1) 30 Mb/s (стабильно).

                    Для реальных сценариев, когда файлов много, а их размер до 128 кб, вариант C# работает намного быстрее.
                      +6
                      скажу вам по секрету, помимо shared_ptr есть еще и unique_ptr ;)

                      > парсер CSS, написанный на C#
                      да что вы удивляетесь-то? есть примеры, когда программы написанные на Си, выполняются медленнее чем аналог, написанный на bash.
                        0
                        да я не удивляюсь, т.к. пишу на обоих языках и занимаюсь разработкой данного парсера.

                        просто в большинстве случаев, как только доходит дело до реального проекта, начинаешь понимать, что огромным плюсом сборки мусора является обработка графа объектов.

                        Все же move semantics не является панацеей, более того unique_ptr не всегда приемлем.
                          +2
                          Почему-то у меня от реальных проектов впечатление строго противоположное. Хотя, возможно, это происходит потому, что мы с вами как бы на несколько разных уровнях работаем.

                          То есть, да, то что парсер XML «с полным построением объектной модели» работает на C# вдвое быстрее — это круто, но когда в «реальном сценарии» версия на C# (или Java) использует свой суперскоростной парсер, а версия на C++ использует ну, скажем, Cap'n Proto через shared memory и работает этак в 10 (а то и в 100) раз быстрее, то неожиданно оказывается что те 10% случаев где XML парсер всё же сохраняется погоды уже не делают.
                            0
                            > более того unique_ptr не всегда приемлем.
                            там, где неприемлем unique_ptr, есть shared_ptr. все, третьего не дано. либо, реализатор чего-то не понимает, и, таким образом, выдумывает невыдумываемое.

                            ну, или, я таки чего-то дейтствительно не понимаю — тогда — объясните, пожалуйста.
                              +1
                              вы все правильно понимаете, здесь вопрос на два комментария выше заключался в том, что существует overhead для некоторых операций (вызов конструктора/деструктора и копирование), кроме разыменования указателя.

                              просто по сравнению со C#, постоянная работа с указателями несколько отквлекает от самого процесса разработки.

                              ну вот например, shared_ptr — самый настоящий ref-counted object. кроме того произодит аллокацию 3 объектов: счетчика, самого объекта и deleter'a. еще и необходимо использовать make_shared функцию, чтобы избежать выделения двух блоков памяти.

                              если же рассматривать именно std::shared_ptr и версию из boost, то производительность у первого будет больше из-за rvalue references.

                              статья на хабре раскрывает более наглядно вопрос.
                                0
                                > постоянная работа с указателями несколько отквлекает от самого процесса разработки.
                                я не могу согласиться, что в с++ постоянно приходится работать с указателями/смарт-указателями. большинство кода, все же, выполняется в стеке. указатели/смарт-указатели — это довольно таки редкий случай.(говорю о себе)
                                  +1
                                  Тут дело не только в удобстве разработки. Дело в том, что delete отрабатывает часто медленнее, чем new. Миллион последовательных вызовов delete сделает кучу ненужно работы, пытаясь каждый вызов упорядочить кучу, подключить осводождённый блок в смежный свободный.
                                  А сборщик мусора может сразу объединить все смежные свободные блоки в один (тем более, что он может работать в другом потоке).
                                    0
                                    > delete отрабатывает часто медленнее, чем new.
                                    не знаю, не проверял. к тому же, это зависит как от ОС, так и от используемого аллокатора. в добавок к этому, программа может использовать свой менеджер памяти поверх того что в системе.

                                    к тому же, разговор шел о смарт-указателях.
                                      +1
                                      Нет. Разговор шёл о том, почему парсер на C# может обогнать C++ по скорости
                                        0
                                        вы правда думаете, что из-за смарт-указателей?
                                          0
                                          да и вообще, при чем тут new/delete? в ваших программах, все объекты располагаются в куче?
                                            0
                                            Потому что память сейчас — узкое место в вычислениях. Обычная арифметика не важно, оптимизирована ли.
                                            0
                                            Нет, смарт-указатели лишь удобство. Можно и руками вызывать delete и проигрывать на этом.
                                              0
                                              в обычном С++ коде(кроме Qt) — большинство данных располагается в стековой памяти. да и аллокаторы, алоцирующие стек — тоже не новинка.
                                              я правда, сомневаюсь, что программы «тормозят» из-за new/delete. по крайней мере — мне такие задачи не встречались. да и если бы встретились — пул объектов рулит.
                                            0
                                            > почему парсер на C# может обогнать C++ по скорости
                                            факт кривых рук.
                                              0
                                              Можно сразу на ассемблере писать. Там уж точно никакой компилятор не будет оправданием тормозов, только факт кривых рук.
                                                0
                                                в кривых руках, любой инструмент «враг» =)
                                      0
                                      Что вы имеете в виду под аллокацией deleter'а?
                                      У shared_ptr есть указатель на счетчик и указатель на объект, конструктор, деструктор, конструктор копирования и оператор присваивания, в которых и работает вся его логика. Какая необходимость в аллоцировании некоего deleter'а?
                                        0
                                        Smart Pointer Programming Techniques.
                                        Preventing delete px.get()
                                        Using a shared_ptr to hold another shared ownership smart pointer
                                          0
                                          но ведь можно не задавать этот вложенный функтор-делетер бустовскому shared_ptr'у.
                                          К тому же туда третьим параметром передается НЕ ОБЪЕКТ, а АДРЕС ОПЕРАТОРА (), т.е. УКАЗАТЕЛЬ НА ФУНКЦИЮ вложенного класса deleter.
                                          class deleter
                                          {
                                          public:

                                          void operator()(X * p) { delete p; }
                                          };

                                          вот этот void operator()( бла-бла ) {бла-бла} — это описание метода по сути

                                          поэтому здесь
                                          shared_ptr px(new X, deleter());
                                          третий параметр deleter() — это передача указателя на оператор-метод.

                                          Здесь может возникнуть вопрос — почему не передается указатель на объект в котором находится operator(), т.е. deleter*, и перед этим даже не инстанцирован?
                                          Я пока ответа не знаю, думаю, потому, что operator() как бы статический метод, потому что он не имеет права обращаться к полям класса deleter наверное. Надо покурить мануалы.
                                            0
                                            в добавлении ко всему, сложно сказать что будет если вызвать
                                            delete 'указатель_на_функцию';
                                            Думаю, неопределенное поведение, seg_fault'ы и т.д.
                                –1
                                Лучше бы MS написали сборщик мусора для C++ и вошли бы в комитет по стандартизации C++ и включили бы этот сборщик в стандарт C++ Тогда бы плюсовый парсер выдавал бы >61Mb/s
                              +1
                              Да, инкрементальные и realtime сборщики. Многим можно устанавливать продолжительность максимальной паузы или запускать сборку когда удобно, что делает процесс предсказуемым
                                +1
                                В этом смысле да, но я говорил несколько про другое. Если рассмотреть вопрос более подробно, то при ручном управлении ресурсами в принципе не может возникнуть ситуации когда после какой либо работы софт может потреблять память, которая ему уже не нужна, однако со сборщиком, такие ситуации происходят часто и являются нормой. Исключением тут является, верно указанный Вами, сборщик реального времени, аналогом которого являются умные указатели в C++, и который, в общем то сборщиком является лишь формально. Помимо этого сборщики создают проблемы тогда, когда оборудование загружено полностью, и свободных ресурсов на сборку нет, что в итоге приведёт к задержкам, которые могут не приемлемы в принципе. В качестве примера можно взять геймдев, где стараются добиться максимального контроля над всеми возможными ресурсами для избежания «лагов».
                              +3
                              Единственно для чего полноценно пригоден шарп это написания гуй приложений под винду

                              Веб забыли.
                                +1
                                Благодарю, да забыл, но веб только под Windows. Ибо любой, кто работал с Mono скажет, что использовать его на *nix скорее извращение, чем реальный продакшн, да и придирки со стороны MS по поводу патентов были.
                                  +1
                                  В современном мире веб под виндой — это не оксюморон; ось вообще вторична. Какие придирки?
                                    0
                                    Это просто уточнение, ибо NET всё время заявляется маркетологами MS как кроссплатформенное решение, а на деле это не соответствует реальности. Вообще лично я вижу только одну проблему для web на Windows — это более дорогие решения (из-за лицензии на сам Windows).
                                    Какие придирки?

                                    Ошибаюсь, не было, но теоретически возможны.

                                    p.s: у меня у самого веб на Windows, правда без .NET, там только PHP, и там только готовые решения. Но он такой просто потому что так получилось, ибо уже было оборудование с Windows на борту.
                                    +2
                                    Не говорите того, чего не знаете, Mono на мобильных платформах уже очень крутое, мы на работе даже на нем пишем под ios, android.
                                      0
                                      Благодарю, рад, что ситуация изменилась в лучшую сторону. Года два назад, именно тогда для меня была важна данная тема, ситуация обстояла совсем не в пользу использования Mono, хотя мне до сих пор народ иногда жалуется на проблемы при использовании кода для 4 — 4.5 версий.
                                  +9
                                  На C# можно писать и приложения для высоких нагрузок. Необходимо иметь хорошую культуру кода и придерживаться определенных правил (к примеру отказ от исключений может быть необходим). Но и как любой инструмент имеет свои преимущества и недостатки. В некоторых компонентах не обойтись без нативной реализации на C++. Но в последнее время, как мне кажется, плата за написание на C# становится более приемлемой в все большей части компонент и необходимости в C++ меньше.

                                  Основное достоинство C# по сравнению с C++ — скорость разработки. На C++ банально медленнее писать код. И компиляция намного медленнее. Старая система C++ с include-ами создает массу проблем статического анализа кода, с которой у C# проблем вообще нет. Это позволяет использовать автоматические утилиты, которые упрощают написание кода. К тому же в C# есть возможность перевести GC в режим реального времени (возможность гарантировать выполнение кода последовательно без перерыва на сборку мусора).

                                  Проприетарность C# также позволяет внедрять новинки намного чаще. Это немаловажно. И к счастью это понял комитет С++. С++14 — тому подтверждение. Что не может не радовать.

                                  Ещё раз подчеркну, у каждого инструмента свое применение. У C++ свое, у C# свое. Но не надо поливать грязью инструмент которым вы не умеете решать определенную задачу, если вы умеете это делать другим. И про скорость, надеюсь вы не будете спорить что разработка на C# (или Python к примеру) не будет на порядок быстрее чем разработка на C++.
                                    +5
                                    И не забываем, что в C# есть PInvoke, который позволяет отлично интегрироваться с unmanaged библиотеками, что в сочетании дает довольно мощный инструмент! На C# можно даже службы писать, удобство программирования которых много больше того прироста скорости, который дал бы C.

                                    И чертовски согласен с этой фразой:
                                    >> Ещё раз подчеркну, у каждого инструмента свое применение
                                      +1
                                      Благодарю за развёрнутый ответ.
                                      Безусловно разработка на С++ реально менее быстрая и удобная чем на C#, или на каком либо другом языке, не обременённым грузом обратной совместимости. С Python, к примеру, ещё более занятно получается, собственно я даже часто прототипы именно на нём делаю, а потом переписываю на C++.

                                      На C# можно писать и приложения для высоких нагрузок.

                                      Да можно, и на Java можно, да и не только на них, но далеко не для всех областей — для сурового геймдева (расписал подробнее в другом комментарии), и встраиваемых решений фактически везде можно использовать C/С++, а вот Java и C# получится не везде.

                                      Необходимо иметь хорошую культуру кода и придерживаться определенных правил

                                      По хорошему это вообще относится к любому языку, и любой области, а не только к высоким нагрузкам.

                                      к примеру отказ от исключений может быть необходим

                                      Для высоких нагрузок это к С++ вполне применимо.

                                      Но не надо поливать грязью инструмент которым вы не умеете решать определенную задачу, если вы умеете это делать другим

                                      Так я и не поливаю C# грязью, более того, я и на нём тоже пишу, мой комментарий это строго ответ на комментарий mynameco:
                                      Пока они там тупили, куча народу убежала на шарп и уже никогда не вернется.

                                      поскольку никто никуда не бегал, и как Вы очень верно верно написали
                                      Ещё раз подчеркну, у каждого инструмента свое применение.

                                      Помимо этого, и более развёрнуто на тему того, что MS должна была сделать, но не сделала для C++, возложив при этом эти задачи на C# расписал тут, т.е. фактически мой комментарий тонко толсто :( намекает на то, что можно было сделать несколько по другому, т.е. вполне можно было всю базовую часть компонентов сразу сделать библиотеками на C/C++, т.е. в нативном коде, и эти библиотеки лишь были бы обёрнуты API прослойкой в C#. Таким образом удалось бы сократить разницу в версиях самого C#, и значительно упростить его реализацию для разных систем. Помимо этого наличие именно нативных библиотек решает многие современные проблемы Windows (по ссылке я как раз расписал одну из самых заметных проблем, которую мы сейчас имеем — это абсолютно разношёрстный GUI в приложениях).
                                        0
                                        Я кстати тоже не поливал грязью С++, ибо пишу на обоих языках, мое высказывание связанно с опытом. Я видел кучу людей которые ушли из с++ и не вернутся туда уже никогда. Тем не менее потерял кучу кармы, ну да ладно, дело наживное.
                                      +3
                                      >>C++ имеет фатальный недостаток, и именно поэтому MS родили C#
                                      Вот это поворот: шарп теперь уже калька с C++.
                                      Про жабу, тащемта, уже забыли?
                                        0
                                        Нет, не забыли, жаба, по всей видимости, имеет такой же фатальный недостаток, как и плюсы, ибо MS могли вполне использовать, и при этом как угодно допиливать, жабу вместо разработки своего закрытого решения.
                                          0
                                          Пытались, en.wikipedia.org/wiki/Microsoft_Java_Virtual_Machine
                                          Но SUN запретил им реализовывать свою JavaVM, а зависеть от чужой MS не мог себе позволить.
                                            0
                                            Ого, благодарю, ибо этого я даже не знал.
                                          0
                                          p.s: и шарп не калька с C++, просто если посмотреть на те «удобные» библиотеки для C++ от MS, в качестве яркого примера можно взять ATL (WTL) для программирования GUI, то становится видно, что MS на поддержку C++ просто забила, и вместо этого, не помимо этого, а именно вместо предпочла реализовать шарп, но уже с блекджеком и профурсетками.
                                            0
                                            Возможно, вы не понимаете назначение и суть WTL. Это всего лишь тонкая обёртка над WinAPI. И она прекрасно справляется со своей задачей: даёт объектную модель контролов, управляет доставкой сообщений. То, что WTL не выдерживает конкуренции с другими gui-фреймворками, это вина устаревшего WinAPI, а не обёртки.

                                            Почему MS не стала делать новый GUI-фреймворк на Native code, а сделала WPF в Managed — другой вопрос.
                                              0
                                              Почему MS не стала делать новый GUI-фреймворк на Native code, а сделала WPF в Managed — другой вопрос.

                                              Вот собственно в этом и проблема. Суть и назначение WTL я понимаю, но обратите внимание, что у MS для нативной реализации нет удобного редактора для GUI, и полноценной библиотеки, для конечного использования (без необходимости дописывания элементарных вещей), тоже нет. Собственно, имхо конечно, но в т.ч. из-за того, что MS пренебрегла поддержкой нативного GUI мы сейчас имеем под Windows адский зоопарк и полное отсутствие единообразия в интерфейсе приложений, ибо абсолютно у всех крупных компаний используется свои велосипеды, а у остальных что то другое (кютэ, вэикс-виджеты, или что угодно ещё).
                                                0
                                                Вот собственно в этом и проблема.

                                                В чём? В том, что WPF — managed? Он доступен из managed c++, где наряду с обычными объектами можно создавать .net-овские.

                                                обратите внимание, что у MS для нативной реализации нет удобного редактора для GUI

                                                Есть обычный редактор ресурсов, его возможности соответствуют возможностям WinAPI 25-летней давности. А что ещё надо? Создать обработчик нажатия кнопки по двойному клику на неё? Это было в MFC. Слишком мелкий сервис, по сравнению с остальными ограничениями API пустяк. Несложно обработчик написать руками. Кстати, в WPF при MVVM опять всё пишется руками :)

                                                из-за того, что MS пренебрегла поддержкой нативного GUI мы сейчас имеем под Windows адский зоопарк и полное отсутствие единообразия в интерфейсе приложений, ибо абсолютно у всех крупных компаний используется свои велосипеды, а у остальных что то другое (кютэ, вэикс-виджеты, или что угодно ещё)

                                                У MS особая роль. Она не может делать фреймворк, заточенный под один язык (как сделал Borland) или кросс-платформенный, но активно построенный на языковых фичах (куда двигаются Qt, wxWidgets и т.п.). Я считаю, у неё особо и выбора не было делать лучше, чем есть сейчас. Перекос в сторону одного языка (c++, например) может завалить всю платформу. Не появился бы Delphi, Visual FoxPro и т.п., т.к. не выдержал бы конкуренцию с языком, интегрированным в ОС посредством IDE от производителя ОС.
                                                  0
                                                  В чём? В том, что WPF — managed? Он доступен из managed c++, где наряду с обычными объектами можно создавать .net-овские.

                                                  Безусловно можно, вот только когда у, вроде как нативного, приложения появляется зависимость от очень толстого (сотни мегабайт) NetFramework, который не является обязательной частью системы и имеет множество возможных версий, то у разработчиков возникают проблемы на ровном месте.

                                                  Перекос в сторону одного языка (c++, например) может завалить всю платформу.

                                                  Так в том то и дело, что не будет никакого перекоса, ведь С/C++ библиотеки это фактически нативный код на котором, наверняка, написан и C#, да и многие другие компоненты. Т.е. если сказать по другому вместо того, что бы делать C# монолитным, MS вполне могла сделать его двухслойным — первый слой либы на C/C++, являющиеся в итоге и частью нового системного API библиотекой для Visual C++, а вторым слоем уже именно C#. В принципе это даже сейчас можно сделать, поскольку данная прослойка всё равно есть, просто мы её не видим :) А C# этого даже не заметил бы

                                                  Не появился бы Delphi, Visual FoxPro и т.п., т.к. не выдержал бы конкуренцию с языком, интегрированным в ОС посредством IDE от производителя ОС.

                                                  Появились бы :)

                                                  p.s:
                                                  Это было в MFC.

                                                  В том то и дело, что было, да сплыло.
                                                    +3
                                                    вместо того, что бы делать C# монолитным, MS вполне могла сделать его двухслойным

                                                    Нет, большая часть WPF уже опирается на CLR.
                                                    Запустить этот гуи без CLR не получится.
                                                    А зависимость от «очень толстого (сотни мегабайт) NetFramework» актуальна разве что при написании приложений под WinXP и компьютеры 8-10 летней давности.
                                                      0
                                                      Благодарю за разъяснения.

                                                      p.s: я видимо не точно выразился, проблема просто в том, что на Windows нет менеджера пакетов, и соответственно тут нет нормального механизма установки софта, т.е. что бы просто указать зависимость в пакете, а дальше «оно само». В итоге приходится либо с собой носить дистриб фреймворка, либо самому же подгружать его, если его вдруг не оказалось. Проблема актуальна не только под XP ибо пользователи как только не «оптимизируют» свои системы :) Можно конечно просто в инсталляторе написать, что нужен NET, и всё, но вот только эти сообщения никто не читает толком, и в итоге проблема ляжет на техподдержку.
                                      +10
                                      Мне вот интересно, как комитет выбирает — добавить новое ключевое слово или добавить новую разрывающую мозг конструкцию из спецсимволов?
                                      Например, почему constexpr — это слово, auto — это слово, а лямбда — не lambda, а []?
                                      И если для && для move-sematics это еще ладно, амперсенд ассоциируется только с ссылками, но квадратные скобки-то как с функцями связаны?

                                      Соответственно, имхо, swap написать тупо быстрее, чем :=: (учитывая, что нужно до шифта тянуться, символов всего на один меньше, а ясности меньше).
                                      Еще интересно, почему в качестве разделителя выбрали одинарную кавычку, а не нижнее подчеркивание (которое макросы не сломало бы, вроде).
                                        0
                                        видимо в случае, когда ожидается тип переменной или модификаторы типа распарсить несколько дополнительных слов несложно
                                        если же речь о lambda, то непонятно как ее тогда отличать от обычной функции или объекта с таким именем
                                          0
                                          Очевидно, запретить использование ключевого слова lambda в любом другом качестве. Насколько я понимаю, нельзя ведь создать переменную double int или функцию void auto(void).
                                            +4
                                            > запретить использование ключевого слова lambda
                                            ага, и обязать всех рефакать свой код, которого, в сумме, больше чем людей на планете в несколько раз.

                                            хорошо, что не Вы принимали это решение.
                                              0
                                              Почему же введенные в С++11 новые ключевые слова вас не смущают? Они ведь тоже наверняка использовались как названия.

                                              Понятное дело, что нужен какой-то компромисс, я всего лишь хотел подчеркнуть, что ключевое слово обычно понятнее, чем хитрое сочетание спецсимволов.
                                                0
                                                > Почему же введенные в С++11 новые ключевые слова вас не смущают?
                                                какие слова? auto? я об этом слове знаю со времен моей молодости, т.е. лет 14 назад. это слово уже было, изменился лишь его смысл.
                                                  0
                                                  Да, то что auto уже было я, признаться, подзабыл.
                                                  А constexpr?
                                                    0
                                                    а про constexpr — я уже не подумал. прошу меня простить, уж.

                                                    ну, тогда я не знаю, как еще обосновать такое поведение комитетчиков. быть может, кто-то более осведомленный в сих вопросах, таки просветит нас, заблуджших.
                                          +4
                                          Видимо логика строилась на том, что ключевого слова function для функций нет, стало быть и для лямбд его не надо. А скобки просто для передачи контекста в лямбду.
                                            +1
                                            Похоже на правду, спасибо.
                                          0
                                          А кто читал вот это? dlang.ru/Why-D-is-Better
                                          На сколько можно верить тому, что на D код пишется быстрее?
                                            +7
                                            D хорош в теории. Пока, к сожалению, не на практике. И, чего лукавить, вряд ли когда-нибудь будет.
                                              +2
                                              Можно(нужно) собрать на кикстартере необходимую сумму и наконец пробустить Ди как минимум в плане рекламы. Хороший толчкок — вот что поможет няшке Ди выбраться из замкнутого круга: язык не развивается, потому что низкая популярность, потому что язык не развивается, потому что...
                                                –1
                                                Аргументируйте
                                                  +7
                                                  Что именно? Что плох на практике? А где библиотеки? Или вы всё будете с нуля реализовывать? А где пользователи, огромное сообщество на SO, кучи гайдов? Или с каждой проблемой вы будете сами разбираться? Всё может быть сколько угодно красиво в теории, но использовать подобое «в продакшине» — нет, извините.

                                                  Языку больше 10 лет, а факт того, что один из его главных идеологов закоммитил 5 тысяч строк, использующих D, в код фэйсбука, преподносится как нечто невероятное. По-моему, очевидно, что не взлетел и уже вряд ли взлетит.

                                                  EDIT: и нет, не поймите меня неправильно. Я двумя руками был бы за то, чтобы D «выстрелил». У плюсов горы недостатков и большое количество из них D таки закрывает. Но вот пока как-то не очень вышло.
                                                    +1
                                                    Малопопулярность и неприменимость на практике — это все-таки разные вещи.

                                                    Питон был маргинальным языком больше 10 лет. Хаскель — больше 15, хотя по вашим меркам, наверное, он и сейчас маргинальный.
                                                  0
                                                  На практике он тоже весьма хорошо. Просто много времени было упущено на метания между D1 и D2.
                                                  +1
                                                  Однозначно быстрее. Если взять для сравнения С++ и Python. На D код пишется так же быстро как и на питоне.
                                                  –6
                                                  У меня складывается все более стойкое ощущение, что современные стандарты C++, это не «C++», а «C» с костылями… Хотя некоторые возможности действительно полезны.
                                                    –5
                                                    внести в С++ специальный оператор обмена :=:

                                                    Давайте уж сразу оператор :=, чтобы C++-ники совсем от стыда сгорели…
                                                      0
                                                      не обязательно := можно просто сравнение по-другому было бы описать. Однако стандарт плюсов создают так чтобы не ломать обратную совместимость, поэтому вряд ли такое предложение поддержат.
                                                      +1
                                                      Библиотеки для работы с сетью, файловой системой и для написания конкурентного кода — это очень хорошо. Спасибо за обзор!
                                                        –1
                                                        Filesystem в бусте на моей памяти вызывал гораздо больше проблем чем решал. Сама библиотека нужная, но бустовую реализацию делают какие-то странные люди. Может, если она таки войдет в стандарт, из нее уберут все то кривое что там есть, но на мой взгляд достаточно показательно что из 54-го буста с 2013-й вижлстудией проблемы возникли только у Filesystem.
                                                        Отдельного упоминания заслуживает тот факт, что на линуксе кодировка имен файлов Filesystem является вполне логичным UTF8, на виндовс-платформах — wchar. Что порождает целый класс неочевидных ошибок даже на стыке с каким-нибудь Qt.
                                                          0
                                                          Кхм кхм. wchar это юникод. Более того, это не кодировка, а тип данных, хранящий юникод-символ. Не путайте тёплое с мягким.
                                                            +1
                                                            Для платформы Windows wchar_t это вполне себе «кодировка», а не просто хранилище двухбайтных символов. Потому что Windows трактует содержимое этих 32-битов однозначным (и не сильно портируемым) образом.

                                                            В стандарте по юникоду сказано буквально следующее:
                                                            «The width of wchar_t is compiler-specific and can be as small as 8 bits. Consequently, programs that need to be portable across any C or C++ compiler should not use wchar_t for storing Unicode text. The wchar_t type is intended for storing compiler-defined wide characters, which may be Unicode characters in some compilers.»

                                                            Я был бы очень рад, если бы boost::filesystem позволял абстрагироваться от платформы и использовать один тип данных как для *nix, так и для Windows платформ. Использовать кодировку UTF-8 (как Qt например), а конвертацию в платформозависимый вид поддерживать как опцию. Потому что на данный момент количество неудобств из-за несоответствия зашкаливает.
                                                              +1
                                                              >> Потому что Windows трактует содержимое этих 32-битов
                                                              Но ведь wchar_t в компиляторе от MS всегда 16-ти битный.

                                                              И utf-8 не шибко удобно использоваться при плотной работе с WinAPI — это будет кошмар и ад постоянных переконвертаций. А модуль FS, я на так понимаю, будет постоянно дергать функции вроде FindFirstFile и т.д.

                                                        Only users with full accounts can post comments. Log in, please.