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

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

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

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

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

С чего это вдруг? На корень то никто не ссылается.

И этого говорит человек, который жалуется на совместимость с С в С++. Да у вас шизофрения.

Стиль D намного проще и короче. Если писать «максимально в стиле плюсов» - зачем тогда переходить?

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

Я предложил решение, выделять в начале работы программы статический сегмент памяти (контекст программы). А наш «новый указатель» будет ссылаться и на память объекта и хранить смещение в контексте, где хранится счетчик.

Стиль D намного проще и короче. Если писать «максимально в стиле плюсов» - зачем тогда переходить?

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

И этого говорит человек, который жалуется на совместимость с С в С++. Да у вас шизофрения.

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

Проблема не в совместимости с «неким языком», проблема именно в совместимости конкретно с Си=)

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

Ааа, ну да. Но это не «любое дерево» же.

#ifdef так не сделать, например

В С# есть указатели на память, именно указатели, не ссылки

#ifdef так не сделать, например

Ну это можно оставить. А вот некоторые люди частенько целые куски кода запихивают в дефайны (ну шоб не копипастить же!). Это похуже констант через дефаны и ifdef, это вообще трындец.

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

Не понимаю, чем вам D не угодил.

Полюбопытствую - ты сам-то на D пишешь?

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

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

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

Чего то серьезного - нет. Осваиваю, хочу обмазаться Vibe.d

vala уже есть

Бенчмарки, а не балобольство про маркетолухов будут?

В том же расте ни одного нормально парсера xml так и нет, так как или unsafe

Почему unsafe делает парсер ненормальным?

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

make_shared, пусть это и не требуется в стандарте, но (как правило) использует один кусок памяти.

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

В моем случае скорее в отладке.

Я предложил решение

Дык, в твоём решении точно так же будет два блока памяти.

Дык, в твоём решении точно так же будет два блока памяти.

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

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

Да вроде и сейчас рекомендуется использовать умные указатели, вместо голых. А голые только если точно надо.

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

https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=csharp&lan...

А вот некоторые люди частенько целые куски кода запихивают в дефайны (ну шоб не копипастить же!)

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

не будет издержек на выделение/удаление памяти в куче.

Речь о блоке памяти для подсчёта ссылок? Ну используй make_shared. Сам объект всё равно надо где-то хранить.

Ну и на запуск различных копирующих конструкторов. и всякого такого.

А их-то почему не будет?

А голые только если точно надо.

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

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

Умные указатели - это не значит, что о памяти думать не надо. Каждый раз «приходится думать» о том можно ли создать объект на стеке, будет ли у него один владелец или много, возможно ли циклические ссылки и т.д.

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

Во первых, не для всех структур данных нужен unsafe. Во вторых, я надеюсь код не целиком из этих «структур данных» состоит? Интерфейс у них вполне может быть безопасным. Ну и в конце-концов, даже в unsafe-блоках раст проверяет больше вещей.

Какие петли в ссылках - там при включенном ARC нельзя вручную память освобождать. Или ты намекаешь, что у них память течёт из-за этого ARC? Так там профайлеры есть, которые и не снились под Линуксом - бери ищи где накосячил и правь баги - ARC прекрасно отрабатывает. В питоне ARC простой как пень - там может быть всё что угодно, если студенты сядут писать. Между прочим, питон один из лучших «скриптовых» языков по потреблению памяти.

Но я бы хотел видеть в НОВОМ языке (а именно это здесь обсуждается) четкое разделение на pod/не под.

А зачем в си++ без си POD, который, по сути, является структурой, которую можно безболезненно использовать в си?

Ну, я с тобой относительно согласен, просто ТС хочет D, но чтобы он был популярный и с хорошей IDE, и чтобы позеры там были :) писали и коммитили толпами всякие хипстеры, появлялись новые движки на этом языке и т.п. Это все хотят. Но сейчас настало время новых языков, которые нужно поддерживать, вон гугл с эплом деньги вливают в 2 языка - и только они и выстрелили. Это печальная ситуация, ведь, есть ещё неплохие поделия, которые должны развиваться, слишком много трудов в них вложено.

Сравнивать надо не поделку mono на коленке, а виндовый .Net с виндовым С++.

А зачем в си++ без си POD

Чтобы задавать форматы данных в памяти.

нет, нельзя. в винде кругом i386 в нативкоде, а С# умеет в Jit, с другой стороны — на линуксе apt в нескольких вариантах + есть вообще source-based дистрибутивы. поэтому, картина на онтопике у плюсов в среднем лучше.

Так там профайлеры есть, которые и не снились под Линуксом

Про valgrind слышать доводилось?

Чтобы задавать форматы данных в памяти.

POD не задаёт формат данных в памяти: есть платформоспецифичные размеры и выравнивания.

Тогда уж надо packed-структуру, в которой можно использовать только (u|)int(8|16|32|64|128)_t.

POD не задаёт формат данных в памяти

Отлично задает.

есть платформоспецифичные размеры и выравнивания.

Не противоречит.

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

Шаблоны же

Так вот если нужны свои структуры данных - то без указателей никак, поэтому и выбросить их нельзя

В с++ это так, но в сферическом с++ без си не обязательно

И как его прикрутить к Clion, например? Он может в режиме реального времени показывать сколько жрёт прога/отдельные thread'ы? Я с ним не сталкивался, но мне он показался несколько чудоковатым по докам. Тупо из терминала запускать и смотреть трейсы?

С точки зрения чтения блобов/гифок — бесполезно.

есть платформоспецифичные размеры и выравнивания.

Не противоречит.

Непривязанность к Си и платформозависимость — противоречит.

С точки зрения чтения блобов/гифок — бесполезно.

Щито?

Непривязанность к Си и платформозависимость — противоречит.

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

Clion
режим реального времени

Рассмешил, содомит!

Я с ним не сталкивался

Ну если ты привык «прогать мышкой», то да, будет тяжко, ибо дело обстоит примерно так:

Тупо из терминала запускать и смотреть трейсы

Но, конечно, не настолько хардкорно, как, например, у gperf

Так ведь есть уже C#, вполне себе нормальный язык для таких хипстерских перушков.

Был бы он свободным и кроссплатформенным, без анальной протекции МС - то так и было бы, язык то вроде отличный.

.net опен сурс же

И давно? И можно любой софт на .net с винды спокойно и без грабель с винды перетащить на онтоп?