Кто чего ожидает от C++17 ?

что войдет в стандарт 17 плюсовый

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

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

Кыш из моих плюсов. Только менеджера пакетов не хватало!

Да вообще пофиг.

а что Вы видите в этом плохого?

Он не должен быть встроен в стандарт языка. Лучше его отдельно держать, как мавен у джавы.

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

с модулями для файловых систем, работы по сети

Хотеть! В остальное не вникал еще.

в принципе, я согласен с Вами. Но он должен хотя бы просто быть и работать)

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

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

Кстати ещё идут разговоры по поводу STL2.0, которая будет по идее переписана через концепты

то есть вы за путь установки либ через apt-get?

Модули мне запили.

Ничего не жду. Мне на работу до сих пор даже С++11 не завезли, 17 — это вообще что-то из области фантастики.

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

мда, без 11 вообще грустно жить...

Да.

Я бы хотел, чтобы в STL-классах были комфортные интерфейсы, как в Qt. Хотел бы классы для работы с сетью и файлами. И хочу, чтобы не было зоопарка std::string/std::wstring

И хочу, чтобы не было зоопарка std::string/std::wstring

std::basic_string же

Можно в хомяк ставить

А как оно с юникодом? В том же QString гарантировано два байта на символ, в STL же оно зависит от платформы (насколько я знаю)

UTF16 не нужен, UTF8 победил

basic_string - это шаблон, какой тип поставишь, столько байтов и будет в символе :)

Ожидаю работы с фс.

Кто чего ожидает от C++17 ?

1. введения китайских иероглифов, потому что символов уже нехватает

2. отмены костыльно-нешаблонной функции main()

3. выхода трехтомника «краткий курс STL»

введения китайских иероглифов

Так это уже с C++98 можно было же?

выхода трехтомника «краткий курс истории STL»

/fixed

выхода трехтомника «краткий курс истории STL(с)»

/fixed 2

забавно что в Java и C# коллекциями просто пользуются, документацию не читают, и очень малое количество людей представляет что там под капотом

но как только речь об STL, начинают многотомники истории, итп

расскажите, эта самая STL настолько убого сдизайнена, что без чтения многотомников никак?

Мечтаю чтобы к какой нибудь версии был единый стандартный GUI.
У шарпа есть System.Windows.Forms для простого и WPF (правда win-only) для извратов, а у нас зоопарк какой то.

Мечтаю о нормальной работе со строками и вводом выводом.
Попытка выяснить допустимые локали для создания std::locale ввергнула меня в крайнее уныние. Кроме того под win юникод сделан как UTF-16 и именно его надо использовать в именах файлов, чего STL не предусматривает (стандарт требует только basic_ifstream(const char* name, ...) а basic_ifstream(const whar_t* name, ...) нет

Qt кажется хорошим вариантом, но не нравится Qt Creator - под win студия для меня удобнее (нет, это не попытка IDE срача), а в ней нельзя связывать GUI сигналы со слотами в дизайнере.
Но в Qt пока что есть MOC и он создает некие проблемы.
Так что мечтаю о Qt 6 без MOC

Вообще не понимаю смысла в лишних менеджерах пакетов. Зачем они нужны, когда есть стандартный системный (apt-get, portage, homebrew, ...)?

Кто чего ожидает от C++17 ?

Ожидаю много баттхерта, нытья про «уже не торт», и троллинга со стороны лисперов/джавистов/дотнетчиков с одной стороны, и кондовых сишников с другой.

Ну нам не нужны, а вендорабы там говорят плачут и горюют.

В венде не было в своё время.

Мне лично пофиг. Как был недоЯП по мне, так и останется.

Так зачем в стандарт такое тянуть из-за одной лишь ОС? Вантузятники как-нибудь справлялись и дальше будут справляться: либо вручную, либо через сторонний ПМ.

А ты предлагаешь развести зоопарк из пакетных мэнэджэров? Со своими pip-ами, gem-ороями бардак разводите в системе. А потом будешь ловить проблемы совместимости по системе, почему вдруг используется не одна библиотека, а другая и почему заголовки не те подключаются.

wstring и wide character не нужен. Закопать и забыть.

Если нужно работать с utf-16/utf-32 code-point'ами, то куда удобнее считать их в vector<int>, а если нужна строка, то конвертируешь в std::string и возвращаешь. Потому что, когда происходит неявная работа с кодировками, ты обязательно в каком-то месте наступишь на грабли. Плавали, знаем.

Где-то я уже это видел... дей вспомню. А вот, как-то так:
забавно что windows просто пользуются, документацию не читают, и очень малое количество людей представляет что там под капотом

но как только речь о linux, начинают многотомники истории, итп

расскажите, этот самый linux настолько убого сдизайнен, что без чтения многотомников никак?

А ты предлагаешь развести зоопарк из пакетных мэнэджэров? Со своими pip-ами, gem-ороями бардак разводите в системе.

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

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

Я думаю, никто не предлагает разрешать language-specific пакетному менеджеру инсталлировать пакеты system-wide.

А ты предлагаешь развести зоопарк из пакетных мэнэджэров?

Так уже развели. Зоопарк дистрибутивов. Разработчики библиотек хотят разрабатывать свои библиотеки и использовать другие библиотеки на этом языке, а не мейнтейнить десяток пакетов со своей библиотекой. Им легче насрать на дистрибутивы, сделать свой пакетный менеджер, и мейнтейнить один пакет.

Тем более, что у современных языков из-за их выразительности обычно всё очень печально с бинарной совместимостью, так что толку от system-wide бинарных дистрибутивов готовых библиотек мало.

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

а как быть видузятникам? я слышал, что там тоже есть что-то подобное, но не знаю толком про это. Про мак ос также не знаю - не юзал

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

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

Что вы будет делать со 100500 программ, которые его не используют, библиотек, которые сделаны без него. И в половине минимум случаев авторы будут саботировать его, потому что формат описания не тот, что любит автор; утилиту написал Поттеринг; фундаментальный недостаток или ещё какое обострение.

Заворачивать сторонними майнтейнерами? С тем же успехом можно использовать девел-пакеты в дистрибутиве.

Windows: Cygwin, Chocolatey и другие; OS X: Homebrew, MacPorts, Fink, ZeroInstall и другие.

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

Пафосные глупости. Опровергнутые pip. gem, npm, Maven, cargo.

Этот ответ, наверное, не мне предназначался.

Не тебе, а atrus. Давний глюк ЛОР.

1. Концепты 2. Статическая рефлексия

Затем, что стандартный системный подходит только для софта, идущего с системой. Я хочу менеджер пакетов в compile time как maven. В настройках проекта указываю нужные либы нужных версий, всё засасывается из интернетов и кладется куда-то в кеш, далее из кеша я утягиваю результат в бандл вместе с экзешником. Затем бандл деплою на машины. Это было бы идеальным вариантом.

Писать код без изучения языка и документации по нему - признак говнокодера.
Так понятнее? :)