Замену C++ делают неправильно

Qt Creator умеет.

В реальном времени - нет, зачем? График потребления можно посмотреть в massif-visualizer.

Замена C++ не нужна, лучше заменить программистов, которые в него не могут.

Замена цпп существует ещё задолго до его появления.

Сказал человек к программированию отношения не имеющий.

Зато имеющий отношение к пользованию софтом, который пишут программисты.

Вроде бы вопрос был в том, зачем нужны POD в Си++.

И я не получил на него ответа.

Повторю, с точки зрения C++, POD — это то, что ведёт себя как сишная структура. Зачем нужно то, что ведёт себя как сишная структура, если мы выкидываем сишную часть?

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

Про патенты не знаю... Но код точно под MIT лицензией.

Попробую отрезюмировать свою позицию:

1. Надо выкинуть голые указатели. Заменить их встроенными умными указателями.

2. Выкинуть адресную арифметику в текущем виде. Допустить упрощенное использование адрессной арифметики только у указателей приватных/защищенных членов классов.

3. Ввести вектор, строки, std::aray в ядро языка (с облегченным интерфейсом, для облегчения создания своих контейнеров).

4. Выкинуть сишные массивы.

5. Пересмотреть концепции наследования. Убрать нафиг проблемы с ромбовидным наследованием.

6. Убрать косяки вроде сокрытия всех переопределний функций базового класса, если переопределена хотя бы одна.

7. Разделить типы на pod/не под. Допустить у структур наличие только дефолт конструктора, параметричеческих конструкторов. Запретить наследование для структур.

8. Ввести модули.

9. Пересмотреть концепт хедеров, не производить компиляцию если изменения в h файле коснулись приватных/протектед частей.

Зачем нужно то, что ведёт себя как сишная структура, если мы выкидываем сишную часть?

Затем, что то, что ведет себя как сишная структура, можно копировать через memcpy. И это здорово помогает при написании контейнеров. Если std::vector, например, при росте всегда выделяет новый буфер и копирует поочередно элементы, то, зная достаточно о типе, можно просто использовать realloc. Насколько это быстрее, думаю, объяснять не надо.

не производить компиляцию если изменения в h файле коснулись приватных/протектед частей.

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

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

Текущая идея инклудов порочная бай дизайн, пересобирать весь проект из-за изменений в .h файле, даже если эти изменения касаются малую его часть

Или зачем пересобирать потомков при публичном наследование если были произведены изменения приватных полей?

Затем, что размер экземпляра класса, смещения в нем и vtable были изменены.

Вроде бы вопрос был в том, зачем нужны POD в Си++.

И я не получил на него ответа.

Получил.

Зачем нужно то, что ведёт себя как сишная структура, если мы выкидываем сишную часть?

Зачем нужно - я уже ответил.

Зачем [...]

См. выше.

Затем, что размер экземпляра класса, смещения в нем и vtable были изменены.

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

Ты опять напираешь на то что с++ сделан вокруг концепций Си. В контексте совместимости с Си, да, по другому не сделать.

Если вам хочется иметь нативный ОО-язык, нормально построенный без оглядки на C, то возьмите Eiffel. Если же ООП не важно, то альтернативы C++ можно найти среди Go, Rust, OCaml и Haskell.

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

Если вам хочется иметь нативный ОО-язык, нормально построенный без оглядки на C, то возьмите Eiffel

Там есть что-то вроде с++ шаблонов? (в виде с++11/14)

Там есть генерики, что-то вроде шаблонов.

Что-то вроде это как в c#/java? Но они же куда слабее плюсовых...

Зато они есть здесь и сейчас, можно брать и использовать. А не излагать на форумах смутные мечты о C++ без наследия C.

Здесь и сейчас я использую с++=)

Представь такой код.

void X() {
A a;
...
}

В A добавили приватное поле int x; Надо пересобирать?

Бери Common Lisp. Там есть CLOS и макросы. И ещё много плюшек.

Нужно как минимум отказаться от аллокации на стеке, делать доступ к полям только через акксессоры, акксессоры очень умно вытирать на этапе линкера, что приведет по сути к полной перекомпиляции, превращению линкера в компилятор и убивании твоей идеи. Может просто так перекмпиляция, которую ты не хочешь будет быстрее. Ну или перейти на VM, как в Java

Нужно как минимум отказаться от аллокации на стеке

Те, кому это нужно, давно свалили на JVM или еще куда-то.

По сути из-за того что Java приложение - zip архив с аналогами .o файлов и работой линкера в рантайм, то не исключена оптимизация с аллокацией на стеке в том числе. Много чего сделать можно

Только делается всё это ценой толстого и плохо предсказуемого рантайма. Что, внезапно, немного не вписывается в цели Си++.

Кто-то просто не осилил указатели вот и бесится.

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

Нет, зачем? Я говорю про логику, а не про реализацию (мол размер объекта изменился).

Не обязательно. Достаточно специфицировать порядок размещения данных в объекте. Мол сначала идут паблики в порядке декларации, потом протектед, потом приват, потом таблица виртуальных методов. Тогда расположение публичных данных всегда будет в одном месте (при неизменных опциях выравнивания).

Кто-то просто не осилил указатели вот и бесится.

Осилил. Но почему бы не пофантазировать?

Нормальные алгебраические типы занести.

Я же говорю, аллокацию на стеке надо отменить?

Есть еще вариант - отказ от промежуточных объектных файлов в текущем виде и переложить вычисление адресов в объекте на который ссылаются на линкер.

Я выше писал о перекладывании этой обязанности еа линкер. Проблема в том, что линкер почти становится компилятором. Главное чтобы реально компиляция стала быстрее. Доказательств что точно станет быстрее нету.

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

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

Ты хочешь pimpl.

вы точно понимаете, что такое сишные структуры и чем они от классов отличаются?

а нужен этот тип хотя бы для упрощённой линковки с сишными либами

строки

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

на банальном str[] большинство строк либо тормозит, либо неправильно работает

Убрать нафиг проблемы с ромбовидным наследованием.

их и не было никогда

вы точно понимаете, что такое сишные структуры и чем они от классов отличаются?

Я не понимаю, зачем сишные структуры и линковка с сишными либами языку, из которого мы выкинули совместимость с си.

затем, что а) системщину всё ещё активно пишут на Си 2) сишная линковка достаточна проста, и в неё умеют большинство ЯП. как следствие язык обязан её поддерживать, если вы хотите обеспечить совместимость с другими языками простым образом.

Шаблоны же

Все использования макросов ими не заменить. Можно начать с реализации какого-нибудь BOOST_SCOPE_EXIT без макросов.

берешь одну из ранних версий С++, которую еще называли C with classes.
Или велосипедишь вручную ооп в C.

Можно заменить дефайны на инклюды же! И никакие шаблоны не нужны! XDXDXD

А это неважно, что там внутри.

Важно. Хотя бы для того, чтобы понимать в каких случаях использование std::array будет оптимальным, а в каких ни-ни.

Мы же вроде обсуждаем идею о создание нового языка, который будет как си++, но без си

А давайте ещё указатели со ссылками отберём. И перегрузку методов отберём. И множественное наследование. И шаблоны. И получим c-- :D

Удваиваю!!!!!!!!!

Сказал человек, пишущий хелловорды.

Для себя да, хелловорды, на всём до чего дотягиваюсь. И кложура на arbeit.