LINUX.ORG.RU

Планы на C++17

 


0

2

Thoughts about C++17 by Bjarne Stroustrup. Список обсуждаемых фич большой, его часть:

So here is my top-ten list for C++17 (no order within the list):

  • Concepts (they allows us to precisely specify our generic programs and address the most vocal complaints about the quality of error messages)
  • Modules (provided they can demonstrate significant isolation from macros and a significant improvement in compile times)
  • Ranges and other key STL components using concepts (to improve error messages for mainstream users and improved the precision of the library specification “STL2”)
  • Uniform call syntax (to simplify the specification and use of template libraries)
  • Co-routines (should be very fast and simple)
  • Networking support (based on the asio in the TS)
  • Contracts (not necessarily used in the C++17 library specification)
  • SIMD vector and parallel algorithms
  • Co-routines
  • Library “vocabulary types”, such as optional, variant, string_view, and array_view

Еще предлагаются паттерн-матчинг, транзакционная память и operator.().

Надеются успеть к 17, и уже планируют корректирующий C++20.

★★★★

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

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

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

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

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

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

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

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

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

А почему, собственно?

mix_mix ★★★★★
()

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

Модули - это откомпилированные сборки со стандартизированным ABI (как в .NET) или тупо файлы как в быдлопаскале.

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

Модули - это откомпилированные сборки со стандартизированным ABI (как в .NET) или тупо файлы как в быдлопаскале.

Ты спрашиваешь или утверждаешь? Ну и чем тебе не угодили «тупо файлы»? Они много где, не только в паскале. И это куда удобнее, чем набор хедеров и цпп файлов.

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

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

Возможно будет вместе с ADT (в терминалогии C++ type-safe union)

anatolat
()
Ответ на: комментарий от bipolar_disorder

Как я понял, нет. Это похоже на сигнатуры ML.

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

я бы всё же сделал приоритетом

С модулями есть одна большая сложность, о которой Старуструп уже где-то писал (или говорил). Все знают, что они нужны, но спросив у 3-х человек, как их нужно реализовать ты получишь 4 несовместимых мнения.

Похожая ситуация была с концептами. Все знают, что они нужны, но написать простую и функциональную спецификацию так и не смогли (потому они не вошли в C++11).

APVS
()

Интересно, сколько кода на С++, который пишут сегодня, использует большинство фич из последнего стандарта. Включая библиотеки. В Qt например как дела обстоят, кто знает? В KDE?

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

накатить

Co-routines

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

Корутины довольно общее теоретическое понятие. Половина функционала корутин может быть реализована в C++ уже сейчас (switch, функторы, https://en.wikipedia.org/wiki/Duff's_device). Оставшаяся часть (типа GO-рутин) отлично реализуется поверх boost::context (только не надо использовать boost::coroutine). Вместо этого MS активно пихает в качестве корутин свои async/await, потому что у них это реализовано в .NET.

IMHO, для реализации корутин в C++ нужно стандартизировать что-то типа boost::context и поверх уже строить кому что нравится.

APVS
()
Ответ на: комментарий от Legioner

В Qt например как дела обстоят, кто знает?

Как минимум в Qt есть variadic templates и списки инициализации.

anonymous
()
Ответ на: комментарий от Legioner

Включая библиотеки.

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

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

Насколько мне известно, в самом Qt только C++98 only код. Обусловлено кросс-платформенностью.

Нет, например, тут, хотя, наверняка, #ifdef-ами окружено. Ещё в Qt используются override и final (через макросы для переносимости).

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

Насколько мне известно, в самом Qt только C++98 only код. Обусловлено кросс-платформенностью.

Возможность сборки C++98 не означает, что нет поддержки С++11. Разруливается ес-но препроцессором.

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