Примерно так и есть. Сделано, кстати, в одном языке на R, 4 буквы в названии. Ооочень удобно, даже без yield — когда итерирование по коллекции — 1 метод, а не как минимум 3-4.
Потому что стандарт распух до неприличия — а многих действительно важных вещей нет до сих пор. А многих, таких как простого менеджера зависимостей и сборки, не будет никогда.
Поэтому С++ со временем выдавят. На это уйдёт куча времени, но его место займут другие языки. Что забавно, С, думаю, останется сильно дольше — т.к. он гораздо проще.
Во-первых, у begin-end нельзя взять ни длину, ни подмассив указанного размера.
Во-вторых, при сшивании со старым кодом часто нужно передать пачку элементов непрерывным буфером. begin-end тоже пасуют.
По поводу же строк, у них есть ряд методов, которых нет у не-строковых срезов.
Ну и наконец, моё сугубо личное мнение, что сама по себе идея делать 2 итератора на диапазон, да ещё и требовать от них совместимости по интерфейсу с указателями, была отвратительной. Потому что реально в случае с RandomAccessIterator, например, у нас не 2 итератора, а слайс — убого скрытый под 2-мя итераторами. А теперь городим костыли в виде разнотипных итераторов. И, кстати, в stdlib до сих пор нет шаблонов для конструирования этих самых итераторов.
string_view это как раз очень хорошо — но чертовски поздно. Как и array_view. Надеюсь, к 20-му году прикрутят. А должны были вкрутить ещё в самом начале, в крайнем случае в 11-й версии. Но не судьба.
Не в курсе, к сожалению. Реализовывал свой велосипедик на эту тему, чтобы работал на GCC 4.9 и не аллоцировал память. В результате пришёл к двум ограничениям — noexcept destructor и noexcept move constructor. На их основе можно делать variant который или будет всегда в валидном состоянии, или уронит программу std::terminate. Оба ограничения как по мне вполне адекватные. Кидаться исключениями из деструктора нехорошо, а из мув-конструктора — просто глупо. Кстати, noexcept default ctor в таком случае не нужен.
Они таки вставили null state. Не очень хорошо, честно говоря. Я так понимаю, это жертва для обеспечения exception safety. Хотя могли бы потребовать noexcept для деструкторов и move конструкторов.
inline для переменных — если в разных единицах трансляции присутствует переменная с внешней линковкой с одним и тем же именем, то оставить и использовать только одну переменную (без inline будет ошибка линковки);
Извините, но это капитальнейшая подстава и здоровенная пуха, которая теперь будет отстреливать ноги всем и по самую шею!
Небольшая добавка. Любой кто жалуется на большой размер бинарников в русте может сделать статически слинкованную программу на C++ — и посмотреть на размер. Была статья (перевод был на днях на хабре), где разбиралось, почему Rust делает такие толстые бинарники.
По вопросу же Vtbl. У Rust есть в этом плане киллер-фича — явный полиморфизм. Если Trait Object — значит динамика.
Отвечал в соседней ветке, чуть выше. Несколько месяцев назад натыкался на возмущения по поводу того, что Rust кушает на синтетиках сильно много памяти. Вкратце, оказалось что jemalloc при запуске выделяет большой пул. Т.е. к тому, сколько "кушает" Rust, это не имеет прямого отношения. Переключаемся на системный аллокатор (уже можно) — и имеем паттерн работы с памятью как в C++.
Rust "кушает больше" памяти из-за особенностей jemalloc — аллокатора. Если быть точнее, он не кушает больше — просто при старте jemalloc резервирует довольно большой пул под свои задачи по умолчанию. Т.е. этот "отжор" константный и к коду на русте прямого отношения не имеет.
Во-первых, на стабильной ветке уже можно собраться с системным аллокатором.
Во-вторых, обсуждение большого стартового пула jemalloc было, и меры собираются принять. К сожалению, ссылку сейчас не найду.
1) По поводу структурированности можно поспорить, т.к. не везде и не всегда. Но не будем разводить холивар.
2) Я написал "2 вида". Мне только непонятно, почему эти два вида — суть калька с "заголовок-реализация". Как я написал, вполне можно делать всё одним экраном — но сортировать элементы по месту, позволять экспанд-коллапс и т.п.
В целом, среды, хранившие исходники в отличном от текста представлении, уже были. Не взлетели. Потому что для текста инструментария для текста завались. А вот для вашего гипотетического представления — когда появится дифф, блэйм и т.д.?
Определение 5-го поколения, в вики, Вам привели выше в https://habrahabr.ru/post/305444/?reply_to=9696938#comment_9696044
Так где Ваш концепт языка умеет решать проблему по набору ограничений и условий? Я например, как и многие другие, вижу тот же Delphi/C#/QtQuick/etc. без принципиальных отличий. Делать же интерактивные объектные вставки можно и на базе текстового представления. Посмотрите например инспект элементов в студии.
И, кстати, по вашему концепту
Почему опять ООП всего и вся? Чем плохи обычные свободные функции? Зачем Main делать классом?
Если у вас такое всё из себя объектное представление, почему нужны 2 вида файла с исходниками, в стиле "заголовок-имплементация"? Почему не давать доступ к исходнику на уровне функции? Или хотя бы держать всё в одном "файле", но при этом сортировать по какому-то критерию?
Центр в дополнительном измерении :) В начале текста есть неплохая аналогия с воздушным шариком. Т.е. мы живём в трёхмерной «поверхности» 4 или более мерного «воздушного шарика» — который что-то «надувает». Центр есть, но он вне нашего пространства.
Не избавятся. Потому как эти ПМы работают для питона/руста/голанга/чего-нибудь ещё. Не для линукса. И их задача — давать единый доступ к пакетам и на Windows, и на Ubuntu, и на MacOS, и на воон той кофеварке. Для решения таких косяков надо просто не пускать (условно) питоновские пакеты в DEB/PPA/whatever. Им там не место.
Примерно так и есть. Сделано, кстати, в одном языке на R, 4 буквы в названии. Ооочень удобно, даже без yield — когда итерирование по коллекции — 1 метод, а не как минимум 3-4.
Cargo. Просто Cargo. И все эти 3 либы будут использовать один набор типов из крейта 3d-geometry.
Упс, мы же про С++. Нет, не судьба.
Потому что стандарт распух до неприличия — а многих действительно важных вещей нет до сих пор. А многих, таких как простого менеджера зависимостей и сборки, не будет никогда.
Поэтому С++ со временем выдавят. На это уйдёт куча времени, но его место займут другие языки. Что забавно, С, думаю, останется сильно дольше — т.к. он гораздо проще.
Во-первых, у begin-end нельзя взять ни длину, ни подмассив указанного размера.
Во-вторых, при сшивании со старым кодом часто нужно передать пачку элементов непрерывным буфером. begin-end тоже пасуют.
По поводу же строк, у них есть ряд методов, которых нет у не-строковых срезов.
Ну и наконец, моё сугубо личное мнение, что сама по себе идея делать 2 итератора на диапазон, да ещё и требовать от них совместимости по интерфейсу с указателями, была отвратительной. Потому что реально в случае с RandomAccessIterator, например, у нас не 2 итератора, а слайс — убого скрытый под 2-мя итераторами. А теперь городим костыли в виде разнотипных итераторов. И, кстати, в stdlib до сих пор нет шаблонов для конструирования этих самых итераторов.
string_view это как раз очень хорошо — но чертовски поздно. Как и array_view. Надеюсь, к 20-му году прикрутят. А должны были вкрутить ещё в самом начале, в крайнем случае в 11-й версии. Но не судьба.
Не в курсе, к сожалению. Реализовывал свой велосипедик на эту тему, чтобы работал на GCC 4.9 и не аллоцировал память. В результате пришёл к двум ограничениям — noexcept destructor и noexcept move constructor. На их основе можно делать variant который или будет всегда в валидном состоянии, или уронит программу std::terminate. Оба ограничения как по мне вполне адекватные. Кидаться исключениями из деструктора нехорошо, а из мув-конструктора — просто глупо. Кстати, noexcept default ctor в таком случае не нужен.
Проблема в том, что можно схлопотать алиасинг на одну переменную там, где это не нужно. Для шаблонов это работает вынужденно.
Они таки вставили null state. Не очень хорошо, честно говоря. Я так понимаю, это жертва для обеспечения exception safety. Хотя могли бы потребовать noexcept для деструкторов и move конструкторов.
std::array_view я так понимаю не будет?
Извините, но это капитальнейшая подстава и здоровенная пуха, которая теперь будет отстреливать ноги всем и по самую шею!
Небольшая добавка. Любой кто жалуется на большой размер бинарников в русте может сделать статически слинкованную программу на C++ — и посмотреть на размер. Была статья (перевод был на днях на хабре), где разбиралось, почему Rust делает такие толстые бинарники.
По вопросу же Vtbl. У Rust есть в этом плане киллер-фича — явный полиморфизм. Если Trait Object — значит динамика.
Отвечал в соседней ветке, чуть выше. Несколько месяцев назад натыкался на возмущения по поводу того, что Rust кушает на синтетиках сильно много памяти. Вкратце, оказалось что jemalloc при запуске выделяет большой пул. Т.е. к тому, сколько "кушает" Rust, это не имеет прямого отношения. Переключаемся на системный аллокатор (уже можно) — и имеем паттерн работы с памятью как в C++.
Rust "кушает больше" памяти из-за особенностей jemalloc — аллокатора. Если быть точнее, он не кушает больше — просто при старте jemalloc резервирует довольно большой пул под свои задачи по умолчанию. Т.е. этот "отжор" константный и к коду на русте прямого отношения не имеет.
Во-первых, на стабильной ветке уже можно собраться с системным аллокатором.
Во-вторых, обсуждение большого стартового пула jemalloc было, и меры собираются принять. К сожалению, ссылку сейчас не найду.
1) По поводу структурированности можно поспорить, т.к. не везде и не всегда. Но не будем разводить холивар.
2) Я написал "2 вида". Мне только непонятно, почему эти два вида — суть калька с "заголовок-реализация". Как я написал, вполне можно делать всё одним экраном — но сортировать элементы по месту, позволять экспанд-коллапс и т.п.
В целом, среды, хранившие исходники в отличном от текста представлении, уже были. Не взлетели. Потому что для текста инструментария для текста завались. А вот для вашего гипотетического представления — когда появится дифф, блэйм и т.д.?
Определение 5-го поколения, в вики, Вам привели выше в
https://habrahabr.ru/post/305444/?reply_to=9696938#comment_9696044
Так где Ваш концепт языка умеет решать проблему по набору ограничений и условий? Я например, как и многие другие, вижу тот же Delphi/C#/QtQuick/etc. без принципиальных отличий. Делать же интерактивные объектные вставки можно и на базе текстового представления. Посмотрите например инспект элементов в студии.
И, кстати, по вашему концепту
Это качественная IDE, с интеграцией кучи объектов в код. Где тут язык пятого поколения, я не увидел.