Стандарт C++17 официально сегодня

Как-то так, например:

std::string t = "中國πολλοί";
assert(t[2] == 'π');
assert(t.length( ) == 8);
assert(t.size( ) == 18);

ICU же

Без Qt жизни нет:

QString text("中國πολλοί");
Q_ASSERT(text[2] == QChar(0x03c0)); // С++ не умеет в "длинные" символы
Q_ASSERT(text.size() == 8);
Q_ASSERT(text.toUtf8().size() == 18); // лишние копирование

    QString test = QString::fromUtf8( "𝓐𝓑𝓒𝓓" );
    qInfo() << test;
    test[1] = '!';
    qInfo() << test;

"𝓐𝓑𝓒𝓓" 
"\uD835!𝓑𝓒𝓓" 

отличная поддержка!

U+D835 is not a valid unicode character.

http://www.fileformat.info/info/unicode/char/d835/index.htm

отличная поддержка!

Тут дело не в QString, а в том, что ты ему подсунул, дай ему указатель на char* с валидным UTF-8.

не знаю что это за жуть, но Rust её нормально пережевывает.

нет, ты не угадал. "𝓐𝓑𝓒𝓓" это валидная utf8 строка. Ты же видишь, что ее твой брузер показывает, верно? Проблема именно в QString.

Оно всё равно понимает его как 8 символов, ибо utf16.

ее даже мой игрушечный язык нормально пережевывает

>>> let test = "𝓐𝓑𝓒𝓓" 
  > test | len
4
>>> test[1] = '!'
  > test | len 
4
>>> io.puts(test)
𝓐!𝓒𝓓

С std::string всё ещё хуже.

Рад за вас. Только большая часть языков создавалась до unicode.

Она утонула, же.

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

модули несовместимы ни с одной из существующих систем сборок под С++, но они нужны, да

пруфы утверждают, что фортран медленнее С++

http://benchmarksgame.alioth.debian.org/u64q/fortran.html

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

Как ты напишешь его деструктор без if?

Как ты напишешь его деструктор без if?

Задать отдельный деструктор с простым delete, если используется дефолтный std::default_delete.

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

Никто хедеры точно выкидывать не собирается.

Однако перфекционисты смогут не использовать препроцессор вообще.

Ну это наврдяд ли :-)

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

Конечно, не приобрели ведь библиотечная реализация выглядит как говно. Стандартные лямбды очень даже используются.

SFINAE нах не нужен. с ним точно проще не стало.

И когда по твоему эта штука появилась?

когда компилишь даже очень большой проект, он не пересобирается весь (конечно, если всё правильно поделено на модули и библиотеки и в хэдерах нет мусора).

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

SFINAE нах не нужен.

А я ведь считал тебя гуру :-(

А я ведь считал тебя гуру

Были основания? Серьезно спрашиваю, может есть темы, где Iron_Bug какими-то полезными сведениями делилась, хочется почитать.

Были основания?

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

Experts on LOR these days...

подозрение что эта уверенность наработана тяжелым опытом.

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

Но вот по поводу общих взглядов на плюсы и их развитие

Какое такое развитие? :-) if constexpr в 2017 году? :-) Fold expressions, чтобы через с помощью операции запятая можно было фолдить код? :-) filesystem в стандартной библиотеке в 2017 году? :-) О, да, развитие :-) Лол :-)

А ты хотел VR API в стандартной библиотеке или что?

А ты хотел VR API в стандартной библиотеке или что?

Хотел макросы на уровне языка :-) Хотел модули на уровне языка :-) Механизмы отражения и метаклассы бы хотел :-)

А в библиотеке хотел бы простой, но расширяемый HTTP-сервер (несколько стратегий по умолчанию - трэд на коннекшн, или трэд пул) с неблокируемым вводом/выводом :-) Также нужен HTTP-клиент и JSON-парсер из коробки :-)

Ага. А еще в стандартную библиотеку необходимо засунуть поддержку modbus, компьютерного зрения и навигации по луне.

Хотел макросы на уровне языка :-)

Ну так шаблоны вполне себе справляются. Разве что имя файла/номер строки/дата компиляции/... не доступны

Хотел модули на уровне языка :-)

В плане ускорения компиляции может быть бы помогло. А в плане модульности, то для С++ уже давно существуют сторонние менеджеры пакетов: apt, yum, dnf, zypper, (you name it). Нет, я серьезно.

Механизмы отражения и метаклассы бы хотел :-)

Спорно. С++ от самых корней статический. Раньше с RTTI вообще боролись. Некоторые фичи конечно было бы полезно иметь: например имена типов как статические константы в коде. Но не full-blown рефлексию.

в библиотеке хотел бы простой, но расширяемый HTTP-сервер ... HTTP-клиент и JSON-парсер из коробки

Хоть веб сейчас довольно большая ниша рынка, не стоит забывать что далеко не всем С++ поделиям в рантайме нужно вот это вот. Пускай лучше остается сторонними библиотеками (как сейчас).

Ну так шаблоны вполне себе справляются. Разве что имя файла/номер строки/дата компиляции/... не доступны

А ещё они Тьюринг полные, а потому и самодостаточны :-) И на них можно спрограммировать что угодно, бла-бла... :-) Даже сам цепепе не нужен, достаточно шаблонов и можно писать что угодно :-) Лол :-)

Ну а если серьёзно, давай я тебе подкину мысль :-) Вот мне банально надо в цикле пройтись по членам класса и сгенерировать некий код, например, код для создания GUI формы по членам класса :-) Давай, сделай это на шаблонах без макросов и отражения :-)

В плане ускорения компиляции может быть бы помогло.

Нужно на уровне языка :-)

А в плане модульности, то для С++ уже давно существуют сторонние менеджеры пакетов: apt, yum, dnf, zypper, (you name it). Нет, я серьезно.

И если у меня есть либа, в которой очевидны 5 модулей, то я должен сделать 5 библиотек и пользоваться (you name it) ? :-) Очень удобно, да :-) Лол :-)

Спорно. С++ от самых корней статический.

Ну и что, что статическая типизация? :-)

Раньше с RTTI вообще боролись.

Это такая разновидность развития :-)

Некоторые фичи конечно было бы полезно иметь

А мне надо по членам класса пройтись в цикле в компайл-тайме :-) Без отражения тут никак :-)

Хоть веб сейчас довольно большая ниша рынка, не стоит забывать что далеко не всем С++ поделиям в рантайме нужно вот это вот.

Лол :-) Многим в рантайме и std::cin/std::cout не нужны, мирятся же :-) А сегодня HTTP-клиент/HTTP-сервер - такие же банальные насущные необходимости, как и cin/cout 20 лет назад :-) А то и более нужные :-)

Пускай лучше остается сторонними библиотеками (как сейчас).

Нет таких, которым можно было бы доверится :-) Есть какие-то подозрительные поделия, из-за которых не хочется потом отгребать люлей в продакшене :-) Такие вещи, как HTTP-сервер должны быть в стандарте :-)

Ага. А еще в стандартную библиотеку необходимо засунуть поддержку modbus, компьютерного зрения и навигации по луне.

Нет :-) Из стандартной библиотеке нужно убрать cin/cout, заменив их на HTTP-клиент/HTTP-сервер, XXI век тут у нас :-) Без навигации по Луне :-)

XXI век тут у нас

Вот-вот. А вы какое старое гавнище в стандартную библиотеку тащите. :) Лол.

Без эксепшенов плюсы неюзабельные в принципе. Разве что если аварийный вызов exit(100500) вместо исключения является приемлемым.

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

некий код, например, код для создания GUI формы по членам класса

valid point, и не идет вразрез со статичностью С++. Было бы полезно также и для всякого рода DAO. Думаю с появлением if constexpr уже недалеко до такого рода интроспекции (осталось только подождать еще немного)

в которой очевидны 5 модулей, то я должен сделать 5 библиотек и пользоваться

Это уже на усмотрение автора. Хочешь — делай, хотешь — нет. Сделать отдельной библиотекой — не сильно сложно. Problems?

Многим в рантайме и std::cin/std::cout не нужны, мирятся же :-) А сегодня HTTP-клиент/HTTP-сервер - такие же банальные насущные необходимости, как и cin/cout 20 лет назад

Как будто большинство реализаций HTTP сервера не отдают контент через stdout.

Такие вещи, как HTTP-сервер должны быть в стандарте

lets agree to disagree

в Гугле, такой стайлгайд,

Ага, всегда считал стайлгайд гугла немного долбанутым. Конечно во всем есть свои плюсы (pun intended), но я пожалуй останусь с исключениями.

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

Ну там сказано, «On their face, the benefits of using exceptions outweigh the costs, especially in new projects. However, for existing code, the introduction of exceptions has implications on all dependent code.»

и

«Our advice against using exceptions is not predicated on philosophical or moral grounds, but practical ones. Because we'd like to use our open-source projects at Google and it's difficult to do so if those projects use exceptions, we need to advise against exceptions in Google open-source projects as well. Things would probably be different if we had to do it all over again from scratch.»

Так что это я не к тому, что исключения — зло, и не надо их использовать, а к тому, что да, бывают большие проекты от серьезных разработчиков, которые их не используют (по своим причинам).

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

Да, это рационально. Но в такой способ просто увеличивается обьем кода, который не умеет в исключения и те «остальные» проеты уже не кажутся на их фоне такими ущербными. Уменьшается количество факторов хоть как-то завтавляющих авторов недо-компиляторов для своих недо-железок писать рантайм для исключений и/или поддерживать их аппаратно.

Я бы лучше следовал политике «минимальная поддержка» компиляции без исключений. Т.е. какие-то основы доступны, а остальное — или велосипедьте сами или платите $$$ за поддержку (может даже не до конца) вашего убожества.

Короче, прогнулись под изменчивый мир.

Да, но объем кода адский, у меня абсолютных чисел нет, но, например, за последний год суммарный дифф с++ чейнджлистов — примерно 1 миллиард строк.

А вообще да, есть план по возвращению исключений обратно.

Для этого придумано много разного i18n. В Qt вообще рекомендуют использовать его даже для английского языка а в строки писать какие нибудь программисто понятные строки не для отображения

если у меня есть либа, в которой очевидны 5 модулей, то я должен сделать 5 библиотек

Настало всеря восхитительных историй. Умученый от с++ рукожоп сейчас расскажет нам, как распространять 5 неких модулей по отдельности но в виде одного файла

А еще терминал выкинуть и заменить его на браузер. и линукс выкинуть как устаревший

Настало всеря восхитительных историй. Умученый от с++ рукожоп сейчас расскажет нам, как распространять 5 неких модулей по отдельности но в виде одного файла

Не в виде одного файла, а виде нескольких подключаемых модулей :-) В скольких файлах эти модули лежат мне по сараю :-) Работа с зависимостями должна быть столь же простой, как в каком-нибудь Quicklisp, или в npm :-)

А еще терминал выкинуть и заменить его на браузер. и линукс выкинуть как устаревший

Нет, просто нужен HTTP-сервер в стандарте :-) Сейчас уже любая железяка размером 50x50 мм спокойно может предоставлять Web-интерфейс, который я не хочу реализовывать с помощью доморощенной библиотечки, изготовленной каким-нибудь студентом в рамках курсовой работы :-) Мне не нужен NGINX в стандарте, мне нужен простой, компактный, легковесный, но расширяемый HTTP-сервер :-)

Ты там определись для начала: наплевать тебе сколько файлов или у тебя бомбит от пяти библиотек.

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

Ты там определись для начала: наплевать тебе сколько файлов или у тебя бомбит от пяти библиотек.

Чего определяться, мне плевать сколько «файлов» :-) Я вообще не хочу думать о «файлах» :-) Я хочу работать с модулями и классами :-)

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

Лол :-) Конечно же я не знаю что такое линковка :-) Зато я знаю Лисп и ещё десяток языков, включая твой любимый ущербненький цепепе :-) А про линковку не, не слышал :-) Лол :-)

fastcgi для тебя было слишком сложно. Okay. Тогда да, действительно надо срочно ради тебя такого красивого сделать вебсервер вместо консоли. И еще библиотеки заменить на некие модули, и линковку заменить на волшебство чтоб лисперы не страдали