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

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

ExternalProject в CMake очень похож на то, что хотелось бы иметь. Только там проблема с тем, что это CMake и если нет готового куска CMake-скрипта, откуда можно скопипастить себе фрагмент целиком, то тогда совсем грустно...

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

Почему? Более конкретно: в чем принципиальная невозможность того же conan?

Про static_assert слышал?

Это is_pod+static_assert не языковая возможность. Я говорю, что неплохо бы ввести это на совсем. Про многие вещи и до с++11 говорили «а сделай так, и вот так и мол отдельная конструкция не нужна».

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

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

А это неважно, что там внутри. И если мы пилим новый язык на основе с++, то это неважно вдвойне. Вы опять мыслите смесью си и си++. Мы же вроде обсуждаем идею о создание нового языка, который будет как си++, но без си.

is_pod+static_assert не языковая возможность

Это частный случай, который ты зачем-то хочешь запилить в виде ключевого слова. Кроме is_pod можно проверять еще много чего.

Можно внятное объяснение.

Вам нужно объяснение зачем нужен указатель на память? Разве это не очевидно?

Хинт: напишите энкодер/декодер jpeg на чистом *вставить скриптовый язык* и посмотрите на производительность этого чуда.

Хинт: напишите энкодер/декодер jpeg на чистом *вставить скриптовый язык* и посмотрите на производительность этого чуда.

На C# .Net я думаю все с производительностью будет ок. А если заюзать прекомпиляцию в натив код, то и вообще разницы не будет.

Есть std:array

Наркоман x2?

std:array имеет фиксированный размер. Вы вообще в курсе как устроен тот же vector? Понятие реалокации памяти вам знакомо?

Я считаю это правильно.

Вы не знаете основ С/С++ - следовательно ваше мнение не имеет веса.

Вам нужно объяснение зачем нужен указатель на память? Разве это не очевидно?

Мне нужна языковая конструкция на уровне ядра языка. Которая обладает свойствами shared_ptr, но при этом не является классом со всеми вытекающими. Возможная (не единственная) реализация такая: 8 байт на указатель + 2-4 байта на смещение в контексте программы(статическая память для всей программы) где хранится счетчик ссылок.

Ну потому что допустим, у тебя в зависимостях три библиотеки:
- первая использует autotools
- вторая qmake
- третья scons

И твоя прогармма - cmake.

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

Т.е. надо:
a) скачать, установить и настроить системы сборки
b) необходимые тулчейны
c) взять необходимые настройки сборки для каждого из проектов

Допустим, c) - не проблема, ты сам указываешь, как тебе надо собрать зависимости. Ну допустим можно решить чисто в теории a) и b), имея базу данных библиотек, для которой указан перечень ее зависимостей и в особенности утилит для ее сборки. Но на практике эти задачи не решаемы в общем, т.к. ну не заставишь ты всех вносить данные о своих библиотеках в твою систему зависимостей.

Вы не знаете основ С/С++ - следовательно ваше мнение не имеет веса.

Каких основ, давайте подробнее без балабольства. В

std:array имеет фиксированный размер. Вы вообще в курсе как устроен тот же vector? Понятие реалокации памяти вам знакомо?

Эммм, про std::aray вообще-то я начал в контексте выкидывая сишных массивов. Если пройдешься по истории, то увидишь, что я про std::aray вспомнил в контексте отказывания от массивов си. динамическая память это отдельная история.

Вы не знаете основ С/С++ - следовательно ваше мнение не имеет веса.

Да и вообще внятных аргументов я не вижу. Можно конкретно, чем наличие std::aray и его использование вместо обычных си массивов противоречит основам с++. Я всегда считал, что рекомендуют использовать только фичи с++ если пишешь на нем и избегать вещей из pure c.

На C# .Net я думаю все с производительностью будет ок.

Снимите с ушей лапшу маркетолухов.

Шарпу 16 лет, а все более/менее сложное так и пишут на С/С++.

Шарпу 16 лет, а все более/менее сложное так и пишут на С/С++.

Обоснование. Вы знали, что дотнет файлы можно скомпилить в натив код до момента исполнения?

Если вам нужна - создавайте и используйте. Другим она не нужна.

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

Это потому, что нет такой системы. Или хотя бы парочки самых распространенных таких систем.

Но даже если посмотреть на системы сборки, то CMake, не смотря на свою угребищность, распространена уже весьма широко. И если мой проект предоставляет CMakeFiles.txt, то взять мой проект для кого-то уже сильно проще.

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

Меня убивают местные анонимусы и оппозиция мне и ОПу.

Еще раз

МЫ НЕ ОБСУЖДАЕМ ТУТ СОЗДАНИЕ С++21(25,30...). И что можно в него добавить выкинуть. Здесь идет обсуждение создание НОВОГО, мать его, языка. Который будет обладать синтаксисом и фичами с++ без си.

Поэтому говорить про то что pure pointer или C-style array незамиенимы - просто глупо. Реализуй std::aray на уровне компилятора и все! Реализуй новый тип данных с подсчетом ссылок на уровне компилятора и все.

А еще можно задействовать SSE100500, так как можно определять все фичи проца перед запуском. Только все проги на шарпе тугие, и все всё равно пишут на С. Парадокс.

Если вам нужна - создавайте и используйте. Другим она не нужна.

В С++ возможно. Но я бы хотел видеть в НОВОМ языке (а именно это здесь обсуждается) четкое разделение на pod/не под. Еще раз, мы здесь не обсуждаем, что надо выкинуть/добавить в новый стандарт с++. Мы вроде как фантазируем о новом языке «с++ без си».

Только все проги на шарпе тугие

Я думаю это уже от программистов зависит.

Ну и да, в некоторых ситуациях С++ может иметь проблемы с производительность, которых нет в .NET. Например связанное с очисткой памяти. Если мы имеем некий объет, который держит множество ресурсов. То при его удаление будут взываны и его деструкторы и класов его членов и все внешние ресурсы будут высвобождены сразу. То есть все случиться в одно время. В .net/java за счет наличия GC виртуальная машина может подобрать оптимальное время для удаления объекта, что бы не вызывать «подвисаний».

Если вам нужна - создавайте и используйте. Другим она не нужна.

Многие (я даже лично знаю) считают, что и final не нужен.

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

Уже несколько раз писали: не нужно - не используй.

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

Из всех вышеперечисленных «проблем» С++, нет ни одной реальной проблемы. У них у всех есть свои причины и история. И если во всем разобраться, то окажется что так и должно быть, и по другому никак.

МЫ НЕ ОБСУЖДАЕМ ТУТ СОЗДАНИЕ С++21(25,30...). И что можно в него добавить выкинуть. Здесь идет обсуждение создание НОВОГО, мать его, языка

Создавать новый язык форком текущей спецификации Си++ как минимум глупо.

В .net/java за счет наличия GC виртуальная машина может подобрать оптимальное время для удаления объекта, что бы не вызывать «подвисаний».

Очередная лапша. stop-the-world в произвольное время зачастую хуже детерминированного деструктора. Тем более в C++ вы можете передать этот блок памяти в другой поток и очистить когда угодно без подвисаний основного потока, прям как в жабке. Но не на оборот.

проблемы с производительность

Это не проблема. ОС одна и та же. Если нужно выделить/очистить память, то не важно насколько это хитро делается, это все равно делается. И это не имеет отношения к производительности.

У них у всех есть свои причины и история.

Обычно это связанно с тем чтобы была возможность юзать функции из Си с совместимыми типами, ну или копипастить код из Си. Я понимю, что это исторически обоснованно. Но времена меняются. И если сделать новый язык, то от си можно отказаться.

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

Использование std::aray (тоже реализованного на уровне языка), тоже многое бы упростило.

Создавать новый язык форком текущей спецификации Си++ как минимум глупо.

Форком да, тут согласен. Но про форк и не я говорил. Поэтому я и так реазко реагирую на фразы вроде «без голых указателей никуда». Мне нравится с++ и мне нравится си, но с++ страдает от совместимости с си. Я праткически ничего не использую в работе и сишного, разве что printf, и то меня тут навели на boost::format уже.

Это не проблема. ОС одна и та же. Если нужно выделить/очистить память, то не важно насколько это хитро делается, это все равно делается. И это не имеет отношения к производительности.

К общей да, но если мы хотим избавиться от «подвисаний»/латентности, то когда очищается память - важно.

И дело тут да не в друго потоке, а в вопросе когда.

Ну вот есть CMake, но куча людей, продолжают упарываться еще более угребищными автотулзам и автомейками, по сравнению с которыми CMake просто идеален. Почему вдруг при появлении твоей системы зависимости они переведут свои проекты на нее? Найдут причину какую-нибуь типа «не gpl3, не bsd, не mit лицензия!», «автор - фанат/не фанат FSF» и т.п.

зы под вендой есть nuget, из которого даже буст можно утащить.

Если мы имеем некий объет, который держит множество ресурсов. То при его удаление будут взываны и его деструкторы и класов его членов и все внешние ресурсы будут высвобождены сразу.

Если это действительно проблема, то можно использовать пулы, чтоб для удаления большого дерева с данными, например, вообще не пришлось ничего удалять. Просто сбросить указатель на начало пула.

В .net/java за счет наличия GC виртуальная машина может подобрать оптимальное время для удаления объекта, что бы не вызывать «подвисаний».

Ага, а за то время, пока GC ждет, добавилась еще пачка объектов на удаление, и еще, и еще. В итоге будет не просто подвисание, а жесткое подвисание. Чем Java программы, кстати, и славятся, когда выжирают всю память.

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

Они есть, но их все меньше и меньше.

Почему вдруг при появлении твоей системы зависимости они переведут свои проекты на нее?

Не вдруг. А если будет удобный инструмент, то дело само пойдет.

Вот как с git-ом и github-ом. Подавляющее большинство OpenSource проектов сейчас там. Нравится это кому-то или нет, что будет в будущем, выживет ли github, когда инвестиции закончатся или нет — никого не волнует, размещают на github-е что ни попадя. Потому, что большинству удобно.

Вот так же и с менеджером зависимостей. Попробовали сделать biicode. Не взлетело, т.к. не удобно. Сейчас пробуют conan. Тот же NuGet пробуют. Чем больше будут пробовать, тем больше шансов чему-то стрельнуть.

Это если C++ еще нужен будет.

Это потому, что нет такой системы.

Имхо, такая система, это уже не система сборки. Это уже ближе к пакетному менеджеру. А в этом классе уже выступает portage.

Мне нужна языковая конструкция на уровне ядра языка. Которая обладает свойствами shared_ptr, но при этом не является классом со всеми вытекающими.

Зачем?

Ну потому что допустим, у тебя в зависимостях три библиотеки:
...

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

Не понимаю, чем вам D не угодил. Отличный язык же. Поскольку вопрос IDE уже неактуален - осталась только проблема с GUI.

Имхо, такая система, это уже не система сборки.

Так я изначально говорил, что нужно две разных системы:

- кроссплатформенная система управления зависимостями;

- кроссплатформенная система сборки.

Зависимости даже в разных Linux-ах по разному разруливаются. А кроме Linux-а есть и остальной мир. И нужно, чтобы под Linux-ом можно было написать либу со 100500 зависимостями, которая элементарно подключается к пользовательскому проекту как под MacOS, так и под Windows. Вместе со всеми 100500 зависимостями.

Система сборки тут отдельно стоит. И, судя по тому, как события развиваются, CMake таки все заборет.

Не понимаю, чем вам D не угодил. Отличный язык же. Поскольку вопрос IDE уже неактуален - осталась только проблема с GUI.

Тем что бы хотелось всю стандартную либу из с++ с минимальными правками перенести

Зачем?

Чтобы выделять память и не задумываться о delete?

А чем phobos хуже, чем stl?

А чем phobos хуже, чем stl?

Что бы не переучиваться, точнее переучиваться с минимальными потерями.

Что бы не переучиваться

Расходимся.

Расходимся.

Зачем вообще сходились?

Читаем ОП пост

Преимущества подхода: а). Программистам в целом не придется переучиваться, библиотеки тоже портировать легче

Что вы тогда вообще делаете в этом треде, если вам в этом контексте разговор не интересен?

Увы, но не задумываться получится только для примитивных объектов или линейных контейнеров. Любая древовидная структура или граф сразу убивает любой счетчик ссылок.

В том же расте ни одного нормально парсера xml так и нет, так как или unsafe или RefCell (по крайней мере так было когда я последний раз смотрел).

Что вы тогда вообще делаете в этом треде, если вам в этом контексте разговор не интересен?

Т.е. взять D вместо С++ - это норм, а взять еще и стандартную библиотеку - не норм? Либо у тебя каша в голове, либо ты не понимаешь какая большая разница между этими языками.

Любая древовидная структура или граф сразу убивает любой счетчик ссылок.

Можно в примерах. Возможно я туплю. Мне правда интересно.

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

Любая древовидная структура или граф сразу убивает любой счетчик ссылок.

Любая древовидная структура

Почему это?

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

Как минимум еще одной проблемой shared_ptr является хранение счетчика в отдельном аллоцируемом блоке памяти.

Если нужно что бы один элемент дерева ссылался на другой, то получаем циклические ссылки.