Здравствуйте, Shmj, Вы писали:
S>Ок, а почему бы не добавить шибко вумный универсальный, чтобы с его использованием все работало как в современных ЯП типа Java/C#/Swift/Dart? Ну т.е. ту самую сборку мусора. S>А почему нет? Вот не хочу думать о выделении памяти и мне не нужна такая уж экономия ресурсов — не беда если сборка мусора произойдет спустя 30 сек, к примеру, а не сразу.
Ты другие форумы зафлудил уже чуть ли не полностью, теперь и до плюсов добрался. Ты даже не разобрался еще в базовых понятиях языка, но уже генерируешь какие-то идеи космического масштаба и космической же глупости. Никто не станет прогибать язык под то, что тебе лично нужно или ненужно.
--
Не можешь достичь желаемого — пожелай достигнутого.
S>А почему нельзя добавить это в старый язык всего то?
Шымж, ты когда-нибудь новые фичи добавлял в очень старый продукт, многими версиями которого пользуются очень много клиентов? А еще лучше — менял в тех же условиях какую-то базовую архитектурную часть?
Я вот не знаю стандарт плюсов, не знаю деталей его имплементацию, но могу представить, насколько это сложно, геморно, долго, больно для юзеров, еще и с просадками в производительности и увеличении требований к ресурсам. А ведь такое потом надо будет реализовать для всяких там железок и для кучи разных платформ и даже разных архитектур процессоров. Ну и главное — зачем? Зачем туда тащить фичи, которые противоречат самой идеологии языка?
Performance as the top priority is the defining aspect of C++ for our users. No other programming language provides the performance-critical facilities of C++. This should be the unique value proposition of the C++ programming language.
Provide the programmer control over every aspect of performance. When faced with some performance problem, the programmer should always have tools within C++ to address it. This does not mean that the programmer is necessarily concerned with ultimate performance at every moment, but in the most constrained scenarios they must be able to “open up the hood” without switching to another language.
Code should perform predictably. The reader (and writer) of code should be able to easily understand its expected performance, given sufficient background knowledge of the environment in which it will run. This need not be precise, but instead can use heuristics and guidelines to avoid surprise. The key priority is that performance, whether good or bad, is unsurprising to users of the C++ language. Even pleasant surprises, when too frequent, can become a problem due to establishing brittle baseline performance that cannot be reliably sustained.
Support maintaining and evolving software written in C++ for decades. The life expectancy of some software will be long and the software will not be static or unchanging in that time. Mistakes will be made and need to be corrected. New functionality will be introduced and old functionality retired and removed. The design of C++ must support and ease every step of this process. This ranges from emphasizing testing and continuous integration to tooling and the ability to make multi-step changes. It also includes constraints on the design of the language itself: we should avoid, or at least minimize, language features that encourage unchangeable constructs. For example, any feature with a contract that cannot be strengthened or weakened without breaking the expected usage patterns is inherently hostile to refactoring. Similarly, features or conventions that require simultaneously updating all users of an API when extending it are inherently hostile towards long-term maintenance of software.
Support maintaining and evolving the language itself for decades. Historically, we have not gotten the design of most language features correct on our first or second try. And we shouldn’t expect that to change going forward either. As a consequence, there must be a built-in plan and ability to move C++ forward at a reasonable pace and with a reasonable cost. Simultaneously, an evolving language must not leave software behind to languish, but bring software forward. This requirement should not imply compatibility, but instead some (likely tool-assisted) migratability.
Be mindful of legacy. We support several 100s of millions of lines of C++ code. Globally, there may be as many as 50 billion lines of C++ code. Any evolution of C++ that fails to account for the human investment (training) and legacy code (representing significant capital) is doomed from the start. Note that our _priority_ is restricted to legacy _source code_. Full support, whether across the full language feature set or with full performance, for legacy code beyond that (such as precompiled binaries we call out below) is not a prioritized goal. While that still leaves many options open (such as dedicated and potentially slower features), it does limit the degree to which legacy use cases beyond source code should shape the language design.
Здравствуйте, rg45, Вы писали:
R>А он задает вопросы не для того, чтобы получить ответы. Для него важен сам процесс общения, остальное — несущественная побочка.
Тем не менее, вам было интересно про мой опыт с GCPtr<T>, а если бы Shmj не задал вопрос, то вы про это никогда бы не узнали.
Re[9]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, Shmj, Вы писали:
S>Пусть опубликует, даст ссылку на откашливание.
Я бы вам мог бесплатно дать в лицо, чтобы вы могли прокашлялся от своей темноты. Всякое желание пропадает что-либо публиковать после общения с такими уродами благодарными людьми как ты.
Re[15]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, Shmj, Вы писали:
S>Это все ля-ля. Это тебе интересно переходить на личности, обсуждать личности и т.д. Мне это не интересно абсолютно — ибо я знаю что все в мир — одна единая личность, находящаяся в разных контекстах реальности. Ты это я а я это ты. Врач и палач, царь и раб — как в песне. Мне это понятно абсолютно и все твои эмоции мне легко понятны и уже даже поднадоели. То что у тебя сама эта мысль вызывает отвращение — мне тоже абсолютно понятно — сам таким был.
"Ля-ля-ля" это вот ^^^^^это все^^^^^^
S>Меня больше интересует вопрос вполне конкретный — возможно ли создать умный указатель с функционалом, аналогичным сборщику мусора без изменения компилятора и рантайма. И если да — то почему до сих пор этого не сделали.
Врешь ты все, ни хрена тебя не интересует, кроме словоблудия. Люди, которые поначалу еще пытались тебя воспринимать всерьез, уже все поняли.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, Shmj, Вы писали:
S>Ок, а почему бы не добавить шибко вумный универсальный, чтобы с его использованием все работало как в современных ЯП типа Java/C#/Swift/Dart? Ну т.е. ту самую сборку мусора.
Когда-то давно я писал для С++ гибридный сборщик мусора. По своей сути он был основан на подсчете ссылок, но умел при этом разрывать циклические ссылки, решая таким образом основную проблему простого подсчета ссылок. Это умение возвышало его из ранга самодельного smart pointer'a до ранга полноценного сборщика мусора.
Этот мини-GC не включался для всего проекта глобально. Вместо этого, программист должен был использовать специальные GCPtr<T> указатели в тех местах, где он хотел видеть сборку мусора.
Исходник этого GC был очень маленьким и работал предельно шустро, решая возложенные на него задачи. Писался он чтобы решить дилемму сложных многоуровневых циклических ссылок, которая то тут, то там возникала в проектах над которыми я работал.
Re[7]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, Shmj, Вы писали:
S>Вот мой вопрос как раз в том — возможно или это принципиально. Т.е. не изменяя рантайм и компилятор — внедрить такой умный указатель с полноценным GC.
Конечно возможно. Я еще хотел тогда опубликовать этот проект, но как-то руки тогда не дошли. А, видимо, зря.
Но там был один момент. В GCPtr<T> помимо самого указателя на обьект, нужно было передавать опциональный указатель на тот обьект, который его создает. Это было нужно для того, что получалось строить внутренний граф, который затем использовался для разрыва ссылок.
Было бы удобнее, если бы сам язык умел бы такой синтаксический сахар, но тогда это было невозможно и приходилось передавать этот указатель вручную при создании GCPtr<T>, что слегка загромаждало код.
Re[5]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, Shmj, Вы писали:
S>А это смотрели: https://hboehm.info/gc/ ?
S>Аналогично вашему работает?
Смотрел и пытался использовал, не понравилось. Boehm GC — это вешь из другой вселенной и с совершенно другим подходом.
Не понравилось потому, что Boehm GC является недетерминированный сборщиком мусора, который работает с помощью сканирования содержимого выделенных блоков памяти на наличии указателей. Причем если какой-нибудь int где-нибудь на стеке случайно будет иметь такое же значение как и один из выделенных указателей, Boehm GC будет принимать это за чистую воду, думая что этот стек "ссылается" на блок. И поэтому такой блок может зависнуть навечно, и никогда не будет освобожден. Только из-за случайного совпадения какого-то int с каким-то указателем! Если это 128 байт, то ерунда, но представьте что-то более ёмкое.
Поэтому считаю, что Boehm GC годится только для определенных задач, которые не требуют каких-либо высоких характеристик и прогнозируемости поведения. Плюс реализация Boehm GC намного "жирнее" чем то, что делал я, где-то на порядок.
Re[2]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, koenjihyakkei, Вы писали:
K>Раньше спрашивали: ты гуглил прежде чем задать вопрос. Теперь гугл умер, и я спрашиваю ты поговорил с ChatGPT прежде чем задать вопрос на форуме?
А он задает вопросы не для того, чтобы получить ответы. Для него важен сам процесс общения, остальное — несущественная побочка.
--
Не можешь достичь желаемого — пожелай достигнутого.
Re[2]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, koenjihyakkei, Вы писали: K>Раньше спрашивали: ты гуглил прежде чем задать вопрос. Теперь гугл умер, и я спрашиваю ты поговорил с ChatGPT прежде чем задать вопрос на форуме?
Очень раздражает что пишет медленно и уходит от ответа. А иногда еще и обрывается текст.
По сути не ответила:
Скрытый текст
Причины по сути нет — можно добавить такой gc_ptr.
Re[2]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, Aquilaware, Вы писали:
A>Обход делался при каждом вызове деструктора GCPtr<T> в том случае, если счетчик ссылок для конкретного обьекта оставался больше 0.
Чёт квадратичная сложность получается.
Re[6]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, Aquilaware, Вы писали:
A>Поэтому считаю, что Boehm GC годится только для определенных задач, которые не требуют каких-либо высоких характеристик и прогнозируемости поведения. Плюс реализация Boehm GC намного "жирнее" чем то, что делал я, где-то на порядок.
Что-то не верится что все так просто — неужели ваше решение лучшее в мире и может из С++ сделать что-то даже лучше Rust-a? Наверное просто что-то не учли и оно не всегда работает.
Re[6]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, B0FEE664, Вы писали:
S>>Не думаю что это возможно в принципе, иначе бы уже написали. BFE>Aquilaware уже написал.
Ага. А Ферма доказал Великую Теорему
Пока не увижу — не поверю.
BFE>>>И вообще, Shmj, при использовании Qt и других подобных библиотек задача сборщика мусора не возникает и будет ему противоречить. S>>С чего бы? BFE>С того, что Qt хранит внутри себя указатели, а не смарт-указатели и вызывает delete для объектов, когда считает нужным. Это означает, что сборщик мусора не будет совместим с Qt, так как Qt ничего не знает про сторонний сборщик мусора.
Что мешает из QT использовать не QT-объекты и применять любой удобный для вас способ управления памятью
Re[9]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, rg45, Вы писали:
R>Зачем тебе какие-то ссылки, когда тебе информацию дает непосредственный представитель того самого сознания, которому ты доверяшешь. Ты же доверяешь?
Это не так работает, бро. Вот тебе, для практического примера, поддержка целостности блокчейна. Ты можешь не доверять никому конкретно — но система так устроена, что при желании любого обмануть — обман быстро будет обнаружен.
Примерно так и с библиотеками. Чел. выкладывает, смотрят многие, пробуют заюзать в своих сложных кейсах — и сразу всплывает лажа, если она есть.
Re[16]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, Shmj, Вы писали:
S>Мне это не интересно абсолютно — ибо я знаю что все в мир — одна единая личность, находящаяся в разных контекстах реальности. Ты это я а я это ты.
Несколько дней назад я уже задавал вам прямой вопрос в другом обсуждении о том, а все ли в порядке с вашей головой.
За этот вопрос меня забанили, а сам вопрос удалили.
Если бы вы такое откровение выдали бы раньше, то обошлось бы и без вопроса, и без бана.
ЗЫ. Переходы на личность временами полностью оправданы, ибо если личность невменяема, то остается лишь вспомнить крайне актуальное в этом случае изречение: "Один дурак задаст столько вопросов, что и сто мудрецов не ответят".
Вот в std добавили несколько типов умных указателей.
Ок, а почему бы не добавить шибко вумный универсальный, чтобы с его использованием все работало как в современных ЯП типа Java/C#/Swift/Dart? Ну т.е. ту самую сборку мусора.
А почему нет? Вот не хочу думать о выделении памяти и мне не нужна такая уж экономия ресурсов — не беда если сборка мусора произойдет спустя 30 сек, к примеру, а не сразу.
Вы скажете что лучше используй современные языке? Но что если мне нужна фишка, которых в этих языках нет — а именно полноценная кроссплатформенность, возможность использовать кодовую базу (а не дергать через обертки) и независимость от установки фреймворков?
Здравствуйте, Shmj, Вы писали:
S>Вот в std добавили несколько типов умных указателей.
S>Ок, а почему бы не добавить шибко вумный универсальный, чтобы с его использованием все работало как в современных ЯП типа Java/C#/Swift/Dart? Ну т.е. ту самую сборку мусора.
Начиная с C++11 кое-что было для сборки мусора (см declare_reachable, undeclare_reachable) но оно оказалось никому не нужно в стандартной бибилотеке и тем более в ядре языка.
Здравствуйте, rg45, Вы писали:
R>Ты другие форумы зафлудил уже чуть ли не полностью, теперь и до плюсов добрался. Ты даже не разобрался еще в базовых понятиях языка, но уже генерируешь какие-то идеи космического масштаба и космической же глупости. Никто не станет прогибать язык под то, что тебе лично нужно или ненужно.
Ну а чем конкретно эта идея глупа? Вот, люди пишут что уже есть: Boehm GC. Выше же ответ — уже были попытки внедрения.
Re[3]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, Shmj, Вы писали:
S>Ну а чем конкретно эта идея глупа? Вот, люди пишут что уже есть: Boehm GC. Выше же ответ — уже были попытки внедрения.
Глупа эта идея уже хотя бы тем, что сгенерирована человеком, который не потрудился разобраться даже в основах. Ты занимаешься маниловщиной, кто бы там ни предпринивал какие бы то ни было попытки.
--
Не можешь достичь желаемого — пожелай достигнутого.
Re[4]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, rg45, Вы писали:
S>>С чего ты решил, что не разобрался в основах?
Потихоньку разбираюсь — у меня просто другого выхода нет — иначе останусь без средств к существованию в чужой стране
R>http://rsdn.org/forum/cpp/8442729.1
Даем компилятору инфу о типах, но не указываем значение (для переменной) или реализацию (для функций, классов). По сути имя и тип данных, связанный с этим именем.
Для глобальных переменных нужно добавить слово extern, если хотим объявить без определения, иначе автоматом произойдет выделение памяти т.е. определение.
R>определение,
— конкретное заполнение — для переменных это установка значения, для функций — добавление тела, для классов — объявление всех членов (без определения видимо).
R>связывание,
— когда идентификатору сопоставляем адрес.
R>линковка...
Когда из отдельно скомпиленных файлов создается единый исполняемый файл/библиотека.
R>Не разобравшись в азах, ты начинаешь дискуссии о фундаментальных переделках языка.
Про такое уже подумали до тебя, и заложили это как требование в новый язык на базе C++.
The language, and implementations thereof, should provide support for software engineering principles such as strong type checking, array bounds checking, detection of attempts to use uninitialized variables, and automatic garbage collection. Software robustness, durability, and programmer productivity are important.
Здравствуйте, rg45, Вы писали:
S>>Потихоньку разбираюсь — у меня просто другого выхода нет — иначе останусь без средств к существованию в чужой стране R>Вот и молодец, разбирайся потихоньку.
Ну почему вам интересно только обсуждать личности и переходить на личности? Давай по делу — вопрос вполне конкретный.
Re[9]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, Shmj, Вы писали:
S>Ну почему вам интересно только обсуждать личности и переходить на личности? Давай по делу — вопрос вполне конкретный.
В том-то и дело, что совсем не по делу. Что с тобой можно обсужадать, когда ты теплое с мягким путаешь? Твое предложение: "давай флудить вместе". У меня встречное предложение: "прекращай флудить". Хотя бы в профильных форумах. Загадил уже все.
--
Не можешь достичь желаемого — пожелай достигнутого.
S>Вот в std добавили несколько типов умных указателей.
S>Ок, а почему бы не добавить шибко вумный универсальный, чтобы с его использованием все работало как в современных ЯП типа Java/C#/Swift/Dart? Ну т.е. ту самую сборку мусора.
По-моему gc это не фишка языка, а фишка компиляции и времени исполнения. Или в самом языке чего-то не хватает для его реализации?
А так — беги кланг да делай на его основе gc для плюсов. Судя по обилию таких проектов, вещь «нужная» всем.
Re[7]: Про умные указатели а лучше сборщик мусора...
K>Раньше спрашивали: ты гуглил прежде чем задать вопрос. Теперь гугл умер, и я спрашиваю ты поговорил с ChatGPT прежде чем задать вопрос на форуме?
А он хорош Все четко расписал, плюс немного и водой разбавил, чтобы текста для Шымжа побольше было.
Патриот здравого смысла
Re[2]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, Aquilaware, Вы писали:
A>Исходник этого GC был очень маленьким и работал предельно шустро, решая возложенные на него задачи. Писался он чтобы решить дилемму сложных многоуровневых циклических ссылок, которая то тут, то там возникала в проектах над которыми я работал.
Вот мой вопрос как раз в том — возможно или это принципиально. Т.е. не изменяя рантайм и компилятор — внедрить такой умный указатель с полноценным GC.
Честно сказать не уверен что это вообще возможно, по этому, видимо, и не добавили. Видимо только менять рантайм нужно, добавлять мини вирт. машину — иначе будут проблемы вылазить.
Re[3]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, T4r4sB, Вы писали:
TB>А как он их определял, кстати? Причём как он понимал, что эта ссылка никогда не будет использована?
Ссылка может быть использована только тогда, когда на неё существует хотя бы один GCPtr<T>, который её "держит".
Параллельно GC строит граф зависимостей. Каждое создание GCPtr<T> — это создания вершины в графе. Если обьект, который создает GCPtr<T> сам лежит в GCPtr<T>, то между двумя вершинами создается ребро в графе. В определенные моменты происходит обход этого графа, определяляются циклы и иницируются их разрывы.
Вся это схема работала исключительно поверх подсчета ссылок, как слоенный пирог. Например, чтобы сделать разрыв цикла, GC делал определенным обьектам release, и когда счетчик ссылок достигал ноля, память освобождалась. Чтобы знать каким обьектам нужно помочь в разрыве цикла, держался граф.
Re[4]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, T4r4sB, Вы писали:
A>>По своей сути он был основан на подсчете ссылок, но умел при этом разрывать циклические ссылки
TB>А как он их определял, кстати? Причём как он понимал, что эта ссылка никогда не будет использована?
Тут можно перенять у .NET его модель корневых ссылок. Для каждого объекта ссылочного типа при его создании создается корневая ссылка, через которую осуществляется асинхронный мониторинг всех ссылок на объект. Когда CLR находит изолированный граф ссылок, она грохает все объекты, принадлежащие этому графу.
--
Не можешь достичь желаемого — пожелай достигнутого.
Re[5]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, T4r4sB, Вы писали:
TB>Аааа, ясно. А этот обход делался по принципу "стоп мир", или как-то по 4 итерации на каждый gc_new?
Обход делался при каждом вызове деструктора GCPtr<T> в том случае, если счетчик ссылок для конкретного обьекта оставался больше 0. Это состояние говорило о том, что возможно где-то есть циклическая зависимость и поэтому пора запустить GC.Collect(). Таким образом, это был полностью детерминированный GC с характеристиками сходными с ручным управлением памятью, но с удобством характерным для полноценного GC.
Re[6]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, Aquilaware, Вы писали:
A>Обход делался при каждом вызове деструктора GCPtr<T> в том случае, если счетчик ссылок для конкретного обьекта оставался больше 0. Это состояние говорило о том, что возможно где-то есть циклическая зависимость и поэтому пора запустить GC.Collect(). Таким образом, это был полностью детерминированный GC с характеристиками сходными с ручным управлением памятью, но с удобством характерным для полноценного GC.
А GC в отдельном потоке работал или в том же, что и деструктор?
--
Не можешь достичь желаемого — пожелай достигнутого.
Re[7]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, rg45, Вы писали:
R>А GC в отдельном потоке работал или в том же, что и деструктор?
В том же, иначе бы не получилось детерменированности. А это было одной из целей, чтобы на ровном месте не возникало таких ситуаций как вызов конструктора из одного потока, а вызов деструктора из какого-то другого потока, о котором приложение ничего не знает.
Re[8]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, Aquilaware, Вы писали:
A>В том же, иначе бы не получилось детерменированности. А это было одной из целей, чтобы на ровном месте не возникало таких ситуаций как вызов конструктора из одного потока, а вызов деструктора из какого-то другого потока, о котором приложение ничего не знает.
Ну да, про детерминированность понятно, я потому и поинтересовался. А как по производительности — не сильно било?
--
Не можешь достичь желаемого — пожелай достигнутого.
Re[9]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, rg45, Вы писали:
R>Ну да, про детерминированность понятно, я потому и поинтересовался. А как по производительности — не сильно било?
На своих задачах никаких проседаний не замечал. Но, конечно же, если обьекты создаются и удаляются очень часто, то может возникать дополнительная нагрузка вызванная обходом графа. Из положительного, обход графа локальный и происходит только по тем верщинам, которые имеют связь с обьектом, который удаляется.
Re[3]: Про умные указатели а лучше сборщик мусора...
S>Очень раздражает что пишет медленно и уходит от ответа.
Ты просто не смог внятно объяснить боту почему тебя не заботит расход памяти и перформанс, но в то же самое время смущает использование обёрток над плюсовыми библиотеками.
Re[4]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, Shmj, Вы писали:
S>Вот мой вопрос как раз в том — возможно или это принципиально.
В общем случае сборщик мусора для С++ невозможен. В частном случае, когда используются только умные указатели, сборщик мусора для них может быть написан.
И вообще, Shmj, при использовании Qt и других подобных библиотек задача сборщика мусора не возникает и будет ему противоречить.
И каждый день — без права на ошибку...
Re[4]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, B0FEE664, Вы писали:
S>>Вот мой вопрос как раз в том — возможно или это принципиально. BFE>В общем случае сборщик мусора для С++ невозможен. В частном случае, когда используются только умные указатели, сборщик мусора для них может быть написан.
Вопрос выше конктретно об умных указателях, просьба читать внимательнее:
не изменяя рантайм и компилятор — внедрить такой умный указатель с полноценным GC
Не думаю что это возможно в принципе, иначе бы уже написали.
BFE>И вообще, Shmj, при использовании Qt и других подобных библиотек задача сборщика мусора не возникает и будет ему противоречить.
С чего бы?
Re[5]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, Shmj, Вы писали:
S>Не думаю что это возможно в принципе, иначе бы уже написали.
Aquilaware уже написал.
BFE>>И вообще, Shmj, при использовании Qt и других подобных библиотек задача сборщика мусора не возникает и будет ему противоречить. S>С чего бы?
С того, что Qt хранит внутри себя указатели, а не смарт-указатели и вызывает delete для объектов, когда считает нужным. Это означает, что сборщик мусора не будет совместим с Qt, так как Qt ничего не знает про сторонний сборщик мусора.
И каждый день — без права на ошибку...
Re[7]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, Shmj, Вы писали:
S>Что-то не верится что все так просто — неужели ваше решение лучшее в мире и может из С++ сделать что-то даже лучше Rust-a? Наверное просто что-то не учли и оно не всегда работает.
Оно не лучшее. Недостаток я уже описывал — церемония с передачей владельца помимо указателя в GCPtr<T>. Но если это делать более профессионально для широкого круга пользователей, то, наверное, можно было бы придумать какой-то автомат, который сам бы понимал в каком блоке-владельце выделенном GC лежит или не лежит конкретный GCPtr<T>. Например, это можно сделать если все GC блоки и обьекты выделять из специального пула памяти о котором нам всё известно — начало каждого выделенного блока и его длина, но это подразумевает создание спец. allocator'a памяти с отдельным оператором выделения памяти gc_new.
Возможно что-то не было учтено и в других сценариях использования начали вскрываться бы просчеты. Именно поэтому я и не стал делать публикацию тогда. Но то, что это по своему новаторское и оригинальное решение — я осознаю сейчас еще лучше. В то время (2008) я думал что к 2020 году все такие проблемы будут уже решены умными бородатыми дядями.
Re[7]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, T4r4sB, Вы писали:
TB>Чёт квадратичная сложность получается.
Важный момент: сборка мусора делается только для одного обьекта. Для того, который в данный момент потенциально удаляется.
Сложность такой сборки мусора равна сложности алгоритма нахождения циклов в графе. Она в общем виде составляет O(|V| + |E|), где |V| — кол-во вершин (обьектов), |E| — кол-во ребер (связей между обьектами). В реальности еще меньше, так как работа ведется не со всем графом, а только с его подграфом который относится к обьекту, для которого делается сборка мусора.
Если же удалять все обьекты сразу, то да, общая сложность такой операции будет O(|V|^2 + |V|*|E|).
Здравствуйте, Aquilaware, Вы писали:
A>Возможно что-то не было учтено и в других сценариях использования начали вскрываться бы просчеты. Именно поэтому я и не стал делать публикацию тогда. Но то, что это по своему новаторское и оригинальное решение — я осознаю сейчас еще лучше. В то время (2008) я думал что к 2020 году все такие проблемы будут уже решены умными бородатыми дядями.
А что мешает опубликовать это сейчас — все-равно без дела лежит?
Re[7]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, Shmj, Вы писали:
S>Ага. А Ферма доказал Великую Теорему S>Пока не увижу — не поверю. Shmj, ещё скажите, что вы проверяли доказательство Эндрю Уайлсона!
BFE>>С того, что Qt хранит внутри себя указатели, а не смарт-указатели и вызывает delete для объектов, когда считает нужным. Это означает, что сборщик мусора не будет совместим с Qt, так как Qt ничего не знает про сторонний сборщик мусора. S>Что мешает из QT использовать не QT-объекты и применять любой удобный для вас способ управления памятью
С того, что он так написан!
Хотите переписать все указатели из Qt на умные указатели?
И каждый день — без права на ошибку...
Re[4]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, B0FEE664, Вы писали:
BFE>И вообще, Shmj, при использовании Qt и других подобных библиотек задача сборщика мусора не возникает и будет ему противоречить.
Как пример, GC отлично дружится с COM, потому что там есть счетчик ссылок. Если же счетчика ссылок или другого подобного механизма нет, то GC будет несовместим с такой моделью управления памятью.
Но такие кардинальные подходы какие предлагает, например, Boehm GC всё равно могут быть до определенного уровня совместимы даже с такими библиотеками, т.к. там функция free — становится по сути no-op. Это то, что касается C. Но что делать, например, с деструкторами и функцией delete в С++ в таком случае — не понятно, деструкторы не будут правильно работать с GC.
Re[8]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, B0FEE664, Вы писали:
BFE> Shmj, ещё скажите, что вы проверяли доказательство Эндрю Уайлсона!
Зачем же лично? И тут я лично не собираюсь проверять — доверяю коллективному сознанию.
BFE>С того, что он так написан! BFE>Хотите переписать все указатели из Qt на умные указатели?
А что мешает в QT использовать не QT библиотеки?
Re[10]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, rg45, Вы писали:
R>Тебе в других форумах не раз советовали показаться специалистам. Ты напрасно пренебрегаешь, по-моему, прогрессирует.
Коллективное сознание не видело этой библиотеки и не дало ей оценку. Пусть опубликует, даст ссылку на откашливание. Ну или попробует продать. Сразу найдут что не так с либой и почему это УГ.
Re[11]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, Shmj, Вы писали:
S>Коллективное сознание не видело этой библиотеки и не дало ей оценку. Пусть опубликует, даст ссылку на откашливание. Ну или попробует продать. Сразу найдут что не так с либой и почему это УГ.
Зачем тебе какие-то ссылки, когда тебе информацию дает непосредственный представитель того самого сознания, которому ты доверяшешь. Ты же доверяешь?
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, Aquilaware, Вы писали:
S>>Пусть опубликует, даст ссылку на откашливание.
A>Я бы вам мог бесплатно дать в лицо, чтобы вы могли прокашлялся от своей темноты. Всякое желание пропадает что-либо публиковать после общения с такими уродами благодарными людьми как ты.
Ну ясно — теперь можно не писать, ведь причина есть поля книги слишком узки для него — я во всем виноват
Re[13]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, Shmj, Вы писали:
S>Это не так работает, бро. S>Это не так работает, бро. Вот тебе, для практического примера, поддержка целостности блокчейна. Ты можешь не доверять никому конкретно — но система так устроена, что при желании любого обмануть — обман быстро будет обнаружен. S>Примерно так и с библиотеками. Чел. выкладывает, смотрят многие, пробуют заюзать в своих сложных кейсах — и сразу всплывает лажа, если она есть.
Какой я тебе бро. Ты к соседу по горшку можешь так обращаться.
Я не пойму, ты ко мне в учителя набиваешься, или что? Тебе самому еще учиться и учиться — молча, широко открыв рот.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, rg45, Вы писали:
R>Какой я тебе бро. Ты к соседу по горшку можешь так обращаться. R>Я не пойму, ты ко мне в учителя набиваешься, или что? Тебе самому еще учиться и учиться — молча, широко открыв рот.
Это все ля-ля. Это тебе интересно переходить на личности, обсуждать личности и т.д. Мне это не интересно абсолютно — ибо я знаю что все в мир — одна единая личность, находящаяся в разных контекстах реальности. Ты это я а я это ты. Врач и палач, царь и раб — как в песне. Мне это понятно абсолютно и все твои эмоции мне легко понятны и уже даже поднадоели. То что у тебя сама эта мысль вызывает отвращение — мне тоже абсолютно понятно — сам таким был.
Меня больше интересует вопрос вполне конкретный — возможно ли создать умный указатель с функционалом, аналогичным сборщику мусора без изменения компилятора и рантайма. И если да — то почему до сих пор этого не сделали.
Re[17]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, Aquilaware, Вы писали:
A>Я, например, лично шокирован проявленным невежеством Shmj. Какие-то наезды, заламывания рук.
Я знаю его по другим форумам не первый год и это его обычный стиль. Все его сообщения замаскированы под вопросы, но никакие ответы ему не нужны, на самом деле. Любое общение с ним неминуемо сваливается в бессмысленный флуд.
--
Не можешь достичь желаемого — пожелай достигнутого.
Re[4]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, Aquilaware, Вы писали:
A>Параллельно GC строит граф зависимостей. Каждое создание GCPtr<T> — это создания вершины в графе. Если обьект, который создает GCPtr<T> сам лежит в GCPtr<T>, то между двумя вершинами создается ребро в графе. В определенные моменты происходит обход этого графа, определяляются циклы и иницируются их разрывы.
Выделил ключевой момент. Как это отслеживалось (или задавалось программистом)?
Здравствуйте, Shmj, Вы писали:
BFE>>С того, что он так написан! BFE>>Хотите переписать все указатели из Qt на умные указатели? S>А что мешает в QT использовать не QT библиотеки?
Ничего не мешает. А к чему этот вопрос? Какая связь между сторонними библиотеками и использованием умных указателей в Qt?
И каждый день — без права на ошибку...
Re[10]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, B0FEE664, Вы писали:
S>>А что мешает в QT использовать не QT библиотеки? BFE>Ничего не мешает. А к чему этот вопрос? Какая связь между сторонними библиотеками и использованием умных указателей в Qt?
Умные указатели вы можете использовать не везде а лишь для сторонних библиотек, не поддерживающих парадигму удаления объектов, принятую в QT.
Re[11]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, Shmj, Вы писали:
S>Умные указатели вы можете использовать не везде а лишь для сторонних библиотек, не поддерживающих парадигму удаления объектов, принятую в QT.
Ну да, первое моё сообщение в этой теме как раз об это и было:
И вообще, Shmj, при использовании Qt и других подобных библиотек задача сборщика мусора не возникает и будет ему противоречить.
