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

Корутины хотелось бы видеть.

а в ней нельзя связывать GUI сигналы со слотами в дизайнере.

Оно в QtCreator'е настолько убого сделано, что лучше бы и не было.

Лорчую. Ну и модули, да.

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

Только вот у всяких питонов есть эталонная реализация, а у крестов нет.

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

Это не дело стандарта, систем сборки и ide.

а систем сборки и ide.

Ну в общем, мне нравится как GUI превращается в код в дизайнере Windows Forms

Хочу так же для нативных плюсов

Ну в общем, мне нравится как GUI превращается в код в дизайнере Windows Forms

Хочу так же для нативных плюсов

продолжай хотеть :)

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

Ну, посмотрим.

cargo - разрабатывается авторами rust, был доступен ещё до rust 1.0, единственная официальная сборочная система.

npm - представлен авторами node.js ещё до версии 1.0, фактически первая крупная вещь, которая была сделана авторами с момента публичной демонсторации ноды.

pip - всё бы было ничего, но это просто уже третий менеджер пакетов python. Первым был distutils, он существовал ещё во времена python 1.0, т.е. где-то в 1993 году. С середины нулевых его начали заменять на setuptools. И только потом появился pip.

gem - первый, на ком стройный ряд слегка споткнётся. ruby вышел в 1995, а gem появился только в 2004. Казалось бы - ага. Но не всё так просто. Если взглянуть на историю языка, то до 1998 года он был чисто японским развлечением, пусть и популярным там, но всё-таки японским. Тем не менее, появление англоязычной документации не сделало его всемирно-известным а один день. В 2003 выходит известная версия 1.8, открывается сайт rubyforge.org и начинается разработка пакетного менеджера. В 2004 первый релиз gem, в 2005 - широко известные рельсы.

Т.е. появление пакетного менеджера совпало с началом всемирного распространения ruby. Хотя на родине его знали давно, все остальные люди видели его уже с gem.

Maven - тут всё ещё сложнее. Я не очень разбираюсь, т.к. далёк от мира Java. Maven умеет скачивать и устанавливать пакеты? У Java вообще есть центральный репозиторий? Если нет, то говорить фактически не о чем. Нет тут менеджера пакетов. Хотя сами пакеты в языке есть. Jar появились в jdk 1.2.1, в 1998 году. Но они были сами по себе.

И того. Четыре языка, в которых менеджер пакетов был или с рождения или практически с рождения, или с момента обретения известности в мире. И один пример языка, в котором менеджера пакетов вобщем-то нет.

Вы что-то сказать хотели?

Вы бы composer назвали. Пока он единственный у кого есть возможность поломать мои слова и догнать уходящий поезд. Судя по тому, как лих народ начал переписывать под него новые версии своих продуктов. Но и то, ещё очень долго будет больше php-кода, не использующего composer, чем использующего.

Maven умеет скачивать и устанавливать пакеты?

Да, подтягивает зависимости для сборки проекта и кладет в кеш.

У Java вообще есть центральный репозиторий?

maven central

Опровергнутые pip. gem, npm, Maven, cargo.

Ну, посмотрим.
cargo - разрабатывается авторами rust

cargo не разрабатывается авторами Rust. Главного разработчика зовут Yehuda Katz - возможно, ты слышал о нем. И с ранним cargo (который в самом деле написал Грейдон Хоар) у нынешнего общего только название.

npm - представлен авторами node.js ещё до версии 1.0

Язык JavaScript представлен в 1995.

pip - всё бы было ничего, но это просто уже третий менеджер пакетов python. Первым был distutils

distutils никогда не был менеджером пакетов.

gem - первый, на ком стройный ряд слегка споткнётся. ruby вышел в 1995, а gem появился только в 2004. Казалось бы - ага

Без всяких «казалось».

до 1998 года он был чисто японским развлечением, пусть и популярным там, но всё-таки японским. Тем не менее, появление англоязычной документации не сделало его всемирно-известным а один день. В 2003 выходит известная версия 1.8, открывается сайт rubyforge.org и начинается разработка пакетного менеджера. В 2004 первый релиз gem

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

Maven - тут всё ещё сложнее. Я не очень разбираюсь, т.к. далёк от мира Java. Maven умеет скачивать и устанавливать пакеты?

Да, умеет.

У Java вообще есть центральный репозиторий?

Центральный репозиторий есть у Maven.

Вы что-то сказать хотели?

Уже сказал, см. выше.

OK, у нас есть один контрпример. :) Хотя хотелось бы услышать мнение разбирающегося в Java и её мире человека: Насколь он популярне? Хотя бы в рамках открытого ПО? Сколько примерно в процентах современных проектов используют его?

И с ранним cargo (который в самом деле написал Грейдон Хоар) у нынешнего общего только название.

OK, ладно, это я пропустил, это были два разных cargo. Тем не менее, текущий был ещё до 1.0. Я прав? Т.е. к моменту отмашки «можно писать спокойно» он уже был, центральный репозиторий был, пакеты были?

Язык JavaScript представлен в 1995.

Как клиентский язык, для работы внутри html страничек в браузере? Ну... Node.js имеет общего с JavaScript в браузере только синтаксис. У ноды свои задачи, свои модули и т.д.

distutils никогда не был менеджером пакетов.

Ну, я не знаю... На его странице написано, что «Distutils is a mechanism to distribute Python packages and extensions». А в примере видно, что он занимался проверкой версий и зависимостей. Я даже не знаю тогда, как назвать то, что предназначено для распространения пакетов и контролирует зависимости...

Окей, не вопрос.

Не столько не вопрос, столько «подавляющее большинство программистов по миру и совсем подавляющее за пределами Японии никогда не видели ruby без gem».

Центральный репозиторий есть у Maven.

Я там ответил. Хороший контрпример, но я без понятия насколько он хотя бы де факто.

Уже сказал, см. выше.

Всё ещё не впечатлён. :) Даже java на момент первого релиза Maven имела лишь четырёхлетнюю историю. (До 1.2 это просто недоразумение было. :) А тут речь о том, чтобы впилить такое в язык, которому 32 года и у которого, в отличие от перечисленных, есть минимум четыре независимых, не слишком совместимых компилятора.

Ну я в яве так, dabbling.

Если я правильно понимаю, в плане стандартизации тут все не так красиво как хотелось бы. :)

Основных систем сборки три: ant (+ivy?) (самый старый), maven и gradle (самый новый и модный). Можно утверждать что 100% нормальных проектов используют как минимум один из них. Хотя ант вроде как уходит в прошлое, а maven vs gradle - предмет холиваров.

Центральный публичный репозиторий на всех по сути один - maven central. Само собой можно делать свои личные/корпоративные репы через тот же мавен или ivy. Про ant толком ничего не знаю, честно говоря. Gradle умеет работать со всеми типами реп (ivy, maven, flat directory).

Тем не менее, текущий был ещё до 1.0. Я прав?

Да.

Т.е. к моменту отмашки «можно писать спокойно» он уже был, центральный репозиторий был, пакеты были?

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

Язык JavaScript представлен в 1995.

Как клиентский язык, для работы внутри html страничек в браузере?

Это не мешало ему иметь библиотеки. И встраиваться JS начал задолго до появления Node.js.

distutils никогда не был менеджером пакетов.

Ну, я не знаю...

А я знаю (пользователь Python с 2002 года). Если distutils - пакетный менеджер, то pip - нет, и наоборот. distutils - это make на стероидах.

Не столько не вопрос, столько «подавляющее большинство программистов по миру и совсем подавляющее за пределами Японии никогда не видели ruby без gem».

Возможно (хотя я лично учил Ruby по версии 1.6, еще до Pickaxe book). Но, опять же, изначально пакетного менеджера в языке не было.

Даже java на момент первого релиза Maven имела лишь четырёхлетнюю историю. (До 1.2 это просто недоразумение было. :)

Ну тогда конечно. Правда, Wikipedia учит, что Java 1.2 вышла в 1998 году, а Maven в 2004, но 4 года или 6 - какая, в сущности, разница.

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

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

Можно утверждать что 100% нормальных проектов используют как минимум один из них.

OK, т.е. у нас вот что есть. Ant, если я правильно помню, появился в 2002. Значит 14 лет спустя, внедрение менеджера пакетов в язык, который до этого серьёзно использовался четыре года, можно считать завершённым.

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

Как бы в этот момент сам синтаксис был нестабилен.

Это не мешало ему иметь библиотеки. И встраиваться JS начал задолго до появления Node.js.

Разумеется. Только нода и npm это отдельное самостоятельное болото. Или я опять не в курсе? Сколько, интересно, людей, которые не пользуют ноду, но занимаются веб-разработкой используют npm для управления браузерными библиотеками, типа jquery? Потому что, если никто или практически никто, то за пределами ноды JavaScript так и остался без пакетного менеджера.

distutils - это make на стероидах

Хм... Пакетный менеджер по идее должен скачивать, разворачивать пакеты, компилировать внешние библиотеки, контролировать зависимости. Что из этого не делал distutils? Не скачивал и не распаковывал сам?

но 4 года или 6 - какая, в сущности, разница

Моя ошибка. Ant в голове держал. :)

это _может_ облегчить разработку пакетного менеджера.

Да ладно, пусть делают. Хоть будет на что посмотреть, жуя попкорн. :)

Это не мешало ему иметь библиотеки. И встраиваться JS начал задолго до появления Node.js.

Разумеется. Только нода и npm это отдельное самостоятельное болото.

Самостоятельное, не самостоятельное... какая нафиг разница? Ты утверждал:

atrus> он или должен быть в языке изначально или его в принципе не может быть.

А изначально его не было.

Пакетный менеджер по идее должен скачивать, разворачивать пакеты, компилировать внешние библиотеки, контролировать зависимости. Что из этого не делал distutils? Не скачивал и не распаковывал сам?

У тебя и make будет пакетным менеджером.

Самостоятельное, не самостоятельное... какая нафиг разница?

Ну, как... Вот сейчас читаю на хабре статью о random-генераторах. В ноде: crypto.randomBytes(), в браузере: crypto.getRandomValues(). Т.е. как ни крути, нельзя просто взять и перенести код.

А изначально его не было.

Ладно, поздравляю, уел меня. :)

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

Поздравляю, у меня не корректная формулировка.

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

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

Поздравляю, у меня не корректная формулировка.

Формулировка вполне выражает то, что ты хотел сказать. Сказанное («либо с самого начала, либо вообще не может») неверно.

Я бы хотел форматирование пробелом, как в питоне, вместо операторных скобок.

Нормальный utf8 в stl. И не wstring, а именно utf8 в std::string, чтобы были встроенные функции валидации, разбора по codepoint, caseinsensitive-сравнение и т.п.

ну это откровенно бред) Вам с такими запросами в питончик только)

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