множественное наследование

не трожь!

голую арифметику указателей без compile-time проверок

это как?

zero-terminated strings

выкинули давно, теперь там std::string

C массивы

нужны, иначе как подноготную тех же векторов и пр. реализовывать?

с остальным согласен

нормальный кроссплатформенный менеджер зависимостей

Что это и с чем едят?

И нормальный кроссплатформенный билд-тул (более вменяемый, чем CMake).

Чем невменяем CMake?

struct, имеющие методы

Так, этого до проектирования языков не допускать.

давно пора для class оставить полноценные классы, а для struct — исключительно POD типы. понятие POD в С++ есть, а ключевого слова нет.

тем, что маке-файлы нужно ручками писать? криво напишешь/сгенерируешь — получишь непортируемый проект.

Что это и с чем едят?

Что-то вроде Maven-а для Java, cabal для Haskell, cargo для Rust, RubyGems для Ruby и т.д.

Чем невменяем CMake?

Идеями. Синтаксисом. Крайне убогой штатной документацией.

Что-то вроде Maven-а для Java

Емнип, мавен умеет С++

Вроде как умеет. Но с такими умениями лучше оставить его для кровавого Java Ынтырпрайза :)

и естественно, добавить улучшательств.

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

Это не говоря о том, что с выкидыванием «груза совместимости» тоже не всё так просто.

это как?

Как сейчас вестимо. Указатели вообще не нужны в языке уровня c++

нужны, иначе как подноготную тех же векторов и пр. реализовывать?

Это вообще уже не важно, что там внутри.

давно пора для class оставить полноценные классы, а для struct — исключительно POD типы. понятие POD в С++ есть, а ключевого слова нет.

вот кстати да, не мешала бы стандартизированная проверка классов/структур на POD в компайл-тайм.

А лучше разделить на структуры и классы и не мучаться больше (правда конструкторы у структур часто юзаю, удобно же, но это все еще POD).

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

множественное наследование

Так есть же уже, причём давно.

голую арифметику указателей без compile-time проверок

Что это?

C массивы

Не трожь!

struct, имеющие методы

А это тебе зачем (сильно) нужно?

C массивы

Не трожь!

Покажи пример, где тебе не хватит std::array.

современный язык должен компилироваться в натив, JVM/CLI, JavaScript, LLVM-байткод

Есть пример живого языка, который это делает? И чтобы это востребовано было, а не как в какой-нибудь скале, где реализацию под .Net сделали, но она оказалась никому не нужна.

Есть большие сомнения, что оно полезно будет. Всё-таки JVM/CLI - это не «просто платформы», это целая сложившаяся инфраструктура. И если на неё завязываешься, то перенос на другую платформу становится очень не тривиальным.

Это вообще уже не важно, что там внутри.

Это важно, если мы хотим написать свою реализацию.

Насчет D

В моем варианте, портирование кода на этот новый C++ делается методом: взяли современный плюсовый проект, попробовали собрать, поправили ошибки компиляции и предупреждения - и все работает. D такого не обеспечивает, это другой язык.

ШОК! СЕНСАЦИЯ! Программисты на C++ годами скрывали эту тайну от общественности!

Я сейчас тебе открою страшный секрет (только тсссс, никому не говори!): можно не использовать те фичи C++, которые тебе не нравятся! Да, всё именно так просто!

Это просто удобно, а главное - это не ломает никаких концепций.

чем тебя cmake обидел?

Указатели вообще не нужны в языке уровня c++

Наркоман?

Это вообще уже не важно, что там внутри.

Как только понадобится свой контейнер - посмотрим.

не мешала бы стандартизированная проверка классов/структур на POD в компайл-тайм.

С разморозкой: std::is_pod

например, устаревшая дрянь это дефайны. но чем их заменить?

static const?

Тогда уже enum или constexpr. static const != #define

чем тебя cmake обидел?

Пользоваться неудобно.

Наркоман?

Нет, зачем они там? Можно внятное объяснение.

Вон в objective-C/Swift тоже не парятся с ручным освобождением памяти

Это ты где такую ересь прочитал? Еще как парятся. Пляшут вокруг этого ARC, отыскивают «петли» в ссылках — ничуть не лучше, чем, скажем, в python.

Как только понадобится свой контейнер - посмотрим.

Ну значит сам будешь делать по другому. Есть std:aaray неважно что внутри у него. Все свои контейнеры можно делать вокруг него. Хватит мыслить тем смесью си и си++ уже.

С разморозкой: std::is_pod

Это немного не то что я имел в виду. Я имел в виду например

class A POD
{
};

И если pod условия нарушены - ошибка компиляции. std::is_pod - это рантайм.

Это важно, если мы хотим написать свою реализацию.

Еще раз, есть std::array. Он обладаем мимнимум функций аналогичных сишному массиву, но гораздо лучше ложиться в модель с++, ибо классс с вменяемым интерфейсом. Свою реализацию можно строить вокруг него. Я считаю это правильно.

std::is_pod - это рантайм.

WAT?

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

std::array
гораздо лучше ложиться в модель с++
классс с вменяемым интерфейсом

Лол :-)

std::is_pod - это рантайм

http://en.cppreference.com/w/cpp/experimental/type_trait_variable_templates#i...

сейчас conan делают

А им кто-то пользуется, кроме авторов?

WAT?

http://en.cppreference.com/w/cpp/types/is_pod

Код компилится. А я хотел бы не задумываться раньше времени о условиях соответствия POD (ну или защитить себя от тех кто после меня кодит) и переложить это на компилятор, что бы он мне сказал, что я делаю что-то не так. Здесь же это немного другое.

Лол :-)

Аргументировано можно?

Понятия не имею. Но сам факт того, что этим занимаются, не может не радовать. Тот же biicode был интересен, но он был гвоздями прибит к CMake и непросто было к biicode присобачить проект, который CMake не использовал. В conan-е этот просчет, вроде как, устранили.

Понятно, что constexpr, я возможно неверно выразился, я хочу что бы класс объявленный как pod не компилился если я нарушаю условия. Так же как не компилится наследование от final.

вот кстати да, не мешала бы стандартизированная проверка классов/структур на POD в компайл-тайм.

std::is_pod?

Код компилится. А я хотел бы не задумываться раньше времени о условиях соответствия POD (ну или защитить себя от тех кто после меня кодит) и переложить это на компилятор, что бы он мне сказал, что я делаю что-то не так. Здесь же это немного другое.

#include <type_traits>

struct A
{
};

static_assert( std::is_pod<A>::value, "DON'T TOUCH MY STRUCT, ASSHOLES!!!!!" );

int main()
{
};

class A POD
{
   virtual funct() {}
};

Хочу что бы это не собиралось. Так понятнее?

Костыль=)

Костыль=)

А зачем тогда вообще static_assert, если не для таких случаев?

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

Например?

Про static_assert слышал?

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

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

Написание std::array

Написание std::array

Ну так и упомянутый выше std::is_pod тоже реализуется на уровне компилятора, а не библиотеки.

Или пытаетесь сказать, что решение такой задачи в принципе не возможно?

this

Это невозможно в кроссплатформенном виде и в общем случае.