LINUX.ORG.RU
ФорумTalks

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

 , , ,


0

6

Доброго времени суток всем форумчанам.

Хотелось бы услышать от Вас раздумий на данную тему : как вы считаете, что войдет в стандарт 17 плюсовый, а что отложат на потом? Все ли фичи нужны или язык на помойку отправить пора(ведь есть же всякие D и Rust)?

Чего я жду от 17 стандарта:

  1. Модули (ибо классная вещь, но скорее всего их не введут так быстро)
  2. Концепты (точнее Concepts Lite - очень удобная вещь для обобщённого программирования. Вроде как должны успеть в этом стандарте)
  3. Нормальный менеджер пакетов - вот об этом ни слуху, ни духу. Вообще такое планируется хоть когда-нибудь? А то у питонщиков имеются всякие pip, а мы чем хуже?
  4. Нормальную стандартную библиотеку с модулями для файловых систем, работы по сети и так далее - вроде как работы ведутся в этом направлении, но когда ожидать результатов - неизвестно.

И да, плюсы ещё долго будут жить. ИМХО, естественно.

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

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

Deleted ()

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

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

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от zamazan4ik

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

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от GblGbl

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

zamazan4ik ★★ ()
Ответ на: комментарий от GblGbl

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

intelfx ★★★★★ ()
Ответ на: комментарий от vazgen05

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

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

zamazan4ik ★★ ()

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

Deleted ()

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

Gvidon ★★★★ ()
Ответ на: комментарий от zamazan4ik

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

vazgen05 ★★★ ()

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

XMs ★★★★★ ()
Ответ на: комментарий от annulen

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

XMs ★★★★★ ()
Ответ на: комментарий от XMs

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

annulen ★★★★★ ()

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

WRG ★★★★ ()

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

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

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

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

MKuznetsov ★★★★★ ()
Ответ на: комментарий от MKuznetsov

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

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

i-rinat ★★★★★ ()
Ответ на: комментарий от tailgunner

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

/fixed 2

Uter ()
Ответ на: комментарий от MKuznetsov

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

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

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

stevejobs ★★★★☆ ()

Мечтаю чтобы к какой нибудь версии был единый стандартный 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

Uter ()

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

Deleted ()

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

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

morse ★★★★★ ()

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

Deleted ()
Ответ на: комментарий от vazgen05

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

Deleted ()
Ответ на: комментарий от zamazan4ik

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

invy ★★★★★ ()
Ответ на: комментарий от XMs

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

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

invy ★★★★★ ()
Последнее исправление: invy (всего исправлений: 1)
Ответ на: комментарий от stevejobs

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

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

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

invy ★★★★★ ()
Ответ на: комментарий от invy

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

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

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от invy

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

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

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

ilammy ★★★ ()
Ответ на: комментарий от invy

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

stevejobs ★★★★☆ ()
Ответ на: комментарий от Deleted

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

zamazan4ik ★★ ()

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

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

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

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

atrus ★★★★★ ()
Ответ на: комментарий от Deleted

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от Deleted

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

Reset ★★★★★ ()
Последнее исправление: Reset (всего исправлений: 1)
Ответ на: комментарий от stevejobs

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

invy ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.