Планы на C++17

Без паттерн-матчинга не нужно.

Ни слова про GC, кстати. И еще где-то было интересное предложение по рефлексии, тоже не видно.

паттерн-матчинг

Его уже даже в C# готовят. <troll>А поскольку плюсы только и делают что тырят фичи из ML и C#...</troll>

Ты раскрыл тайный план Страуструпа:) Теперь придётся свернуть проект C#.

Ни слова про GC, кстати.

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

Похоже, что кресты стремятся занять место PL/1.

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

Просто ссылки надо явно обьявлять, но так же оно и в C++/CLI, например.

И еще где-то было интересное предложение по рефлексии, тоже не видно.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3814.html

Как сильно хочет корутины-то. И ни слова про ABI.

Сколько там уже страниц набегает в последнем стандарте цепепе?

GC не нужен, от него уже даже в Objective-C отказались. Есть другие способы достижения счастья.

А вот это:

Modules (provided they can demonstrate significant isolation from macros and a significant improvement in compile times)

я бы всё же сделал приоритетом, причем без всяких «provided». ИМХО это одна из тех мелочей, которая реально мешает распространению языка.

Откатить все новомодное УГ вплоть до 11-х креств включительно и накатить

Co-routines

Будет идеальный язык.

Откатить все новомодное УГ вплоть до 11-х креств включительно

Слишком толсто.

Concepts

Нужно, компайл-тайм дак-тайпинг это несерьезно.

Modules

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

Ranges and other key STL components using concepts

Умеренно нужно, рейнджы явно удобнее итераторов.

Uniform call syntax

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

Co-routines (should be very fast and simple)

Если stackless то наверно кому-то нужно.

Networking support (based on the asio in the TS)

Имхо не нужно в стандартной библиотеке, они бы еще GUI туда добавили.

Contracts (not necessarily used in the C++17 library specification)

Не нужно совсем, контракты не взлетели, лучше бы юниттестинг как-нибудь встроили.

SIMD vector and parallel algorithms

Наверно нужно, но лучше бы tbb в стандарт включили.

Library “vocabulary types”, such as optional, variant, string_view, and array_view

Явно нужно, с ними веселее.

В общем и целом: очень нужно, ждем с нетерпением.

Модули? Ну слава богу.

Модули-то первоклассные будут или как обычно?

что местный гений имеет ввиду?

Сколько там уже лет прошло с последнего стандарта общелишпа?

него уже даже в Objective-C отказались

и давно?

Да, похоже. Интересная же штука; возможно, заменила бы препроцессор Qt. Но в списке отсутствует.

Четыре года как: https://en.wikipedia.org/wiki/Automatic_Reference_Counting . В Swift изначально GC нет.

С версии 10.8 макоси он deprecated.

это я что-то спутал, извиняюсь.

я невнимательно читал, да.

GC

он не нужен в C++, для этого есть java

in soviet programming boost steals features from c++.

Сколько там уже лет прошло с последнего стандарта общелишпа?

общелисп почти идеален и легко расширяем. инфа 146%

Ни слова про GC, кстати. И еще где-то было интересное предложение по рефлексии, тоже не видно.

Зачем GC должен быть непременно стандартизован? Кому нужен GC, тот может реализовать его сам, использовать чужой вариант (если он ему подойдет) или продолжить писать на Java/C#.

Co-routines (should be very fast and simple)

Интересно, на основе чего они будут реализованы.

И если stackless, это как?

И если stackless, это как?

анончик тупит. если stackless, то он ещё с ansi c имеется — setjmp/longjmp

А корутины же давно в бусте есть: http://www.boost.org/doc/libs/1_58_0/libs/context/doc/html/index.html и вот чуть более высокоуровневая обертка http://www.boost.org/doc/libs/1_58_0/libs/coroutine/doc/html/index.html

Знаю.

Просто вижу, что идет постепенное движение языка на фичи скриптовых языков, буст и STL-библиотеки, как ядра Си++

Чего тебе непонятно?

А как ты предлагаешь реализовать «самому» отслеживающий gc? И какие есть чужие варианты? Boehm - это несерьезно.

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

Вообще речь о том, что про добавление GC высказывался сам Комитет, или кто-то из него.

Объясните, зачем на практике нужны Concepts и Co-routines.

Объясните, зачем на практике нужны Concepts

Concepts (they allows us to precisely specify our generic programs and address the most vocal complaints about the quality of error messages)

А compile-time рефлексия будет? В gcc вроде даже можно какой-то опцией врубить.

Это вода, а хочется конкретики.

Concepts (they allows us to precisely specify our generic programs and address the most vocal complaints about the quality of error messages)

Это вода, а хочется конкретики.

Хм. Интересно, что для тебя было бы достаточно конкретным ответом на вопрос «зачем нужны концепты»?

зачем нужны корутины?

Генераторы делать Для некоторых алгоритмов очкнь удобно

А как ты предлагаешь реализовать «самому» отслеживающий gc?

Для него нужен свой рантайм, да и реализация получится очень нетривиальной. Если в C++ добавлять высокоуровневые сущности в итоге может получится еще один раздутый C#, отягощенный скопившимся тяжелым наследием крестов. Зачем делать это из C++ непонятно. Хочешь рефлексию, GC, LINQ и прочие ништяки - используй соответствующий язык. Требуется высокая производительность, умеренное потребление памяти и ты умеешь управлять памятью вручную - используй C++. Можешь еще поэкспериментировать с D, там есть GC. Только все почему-то ждут, когда кто-то другой начнет писать на D серьезный проект и тем самым докажет его юзабельность.

Концепты - это compile-time интерфейсы шаблонных параметров. Сейчас они прописываются только в документации, а будут в языке. Если интерфейс не соблюдается, то вместо простыни ошибок как сейчас ты получишь ясное сообщение типа «bar is not Allocator».

Корутины позволяют, например, лапшу из асинхронных коллбеков превратить в псевдосинхронный код. Примеры есть в boost.

Интересная же штука; возможно, заменила бы препроцессор Qt.

Да-да, именно на это и смотрел разработчик moc'а :)

http://woboq.com/blog/reflection-in-cpp-and-qt-moc.html

Уже нашел конкретный ответ https://isocpp.org/blog/2013/02/concepts-lite-constraining-templates-with-pre...

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

GC опциональный*

Я думаю что можно обойтись без тяжелого рантайма. В соответствии с «механизм, а не политика» сам сборщик мог бы быть самописным классом, а язык просто будет предоставлять необходимую информацию - например, список отслеживаемых ссылок на стеке и т. п. Это повлечет некоторые расходы и будет опционально включаемой фичей. Примерно как с RTTI.

Я когда-то пытался сделать mark-n-sweep для плюсов. Ссылки на стеке более-менее отслеживаются умными указателями, но проблема в том как из объекта вытащить ссылки на другие объекты.

Зачем это нужно? Не знаю, просто because we can. Вернее, could :)

Если stackless то наверно кому-то нужно.

stackless сопрограммы делаются довольно легко сейчас. Нужны как раз stackfull.