Вот в std добавили несколько типов умных указателей.
Ок, а почему бы не добавить шибко вумный универсальный, чтобы с его использованием все работало как в современных ЯП типа Java/C#/Swift/Dart? Ну т.е. ту самую сборку мусора.
А почему нет? Вот не хочу думать о выделении памяти и мне не нужна такая уж экономия ресурсов — не беда если сборка мусора произойдет спустя 30 сек, к примеру, а не сразу.
Вы скажете что лучше используй современные языке? Но что если мне нужна фишка, которых в этих языках нет — а именно полноценная кроссплатформенность, возможность использовать кодовую базу (а не дергать через обертки) и независимость от установки фреймворков?
Здравствуйте, Shmj, Вы писали:
S>Вот в std добавили несколько типов умных указателей.
S>Ок, а почему бы не добавить шибко вумный универсальный, чтобы с его использованием все работало как в современных ЯП типа Java/C#/Swift/Dart? Ну т.е. ту самую сборку мусора.
Начиная с C++11 кое-что было для сборки мусора (см declare_reachable, undeclare_reachable) но оно оказалось никому не нужно в стандартной бибилотеке и тем более в ядре языка.
Здравствуйте, Shmj, Вы писали:
S>Ок, а почему бы не добавить шибко вумный универсальный, чтобы с его использованием все работало как в современных ЯП типа Java/C#/Swift/Dart? Ну т.е. ту самую сборку мусора. S>А почему нет? Вот не хочу думать о выделении памяти и мне не нужна такая уж экономия ресурсов — не беда если сборка мусора произойдет спустя 30 сек, к примеру, а не сразу.
Ты другие форумы зафлудил уже чуть ли не полностью, теперь и до плюсов добрался. Ты даже не разобрался еще в базовых понятиях языка, но уже генерируешь какие-то идеи космического масштаба и космической же глупости. Никто не станет прогибать язык под то, что тебе лично нужно или ненужно.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, 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.
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.
Патриот здравого смысла
Re[8]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, rg45, Вы писали:
S>>Потихоньку разбираюсь — у меня просто другого выхода нет — иначе останусь без средств к существованию в чужой стране R>Вот и молодец, разбирайся потихоньку.
Ну почему вам интересно только обсуждать личности и переходить на личности? Давай по делу — вопрос вполне конкретный.
Re[9]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, Shmj, Вы писали:
S>Ну почему вам интересно только обсуждать личности и переходить на личности? Давай по делу — вопрос вполне конкретный.
В том-то и дело, что совсем не по делу. Что с тобой можно обсужадать, когда ты теплое с мягким путаешь? Твое предложение: "давай флудить вместе". У меня встречное предложение: "прекращай флудить". Хотя бы в профильных форумах. Загадил уже все.
--
Не можешь достичь желаемого — пожелай достигнутого.
S>Вот в std добавили несколько типов умных указателей.
S>Ок, а почему бы не добавить шибко вумный универсальный, чтобы с его использованием все работало как в современных ЯП типа Java/C#/Swift/Dart? Ну т.е. ту самую сборку мусора.
По-моему gc это не фишка языка, а фишка компиляции и времени исполнения. Или в самом языке чего-то не хватает для его реализации?
А так — беги кланг да делай на его основе gc для плюсов. Судя по обилию таких проектов, вещь «нужная» всем.
Re[7]: Про умные указатели а лучше сборщик мусора...
Здравствуйте, koenjihyakkei, Вы писали:
K>Раньше спрашивали: ты гуглил прежде чем задать вопрос. Теперь гугл умер, и я спрашиваю ты поговорил с ChatGPT прежде чем задать вопрос на форуме?
А он задает вопросы не для того, чтобы получить ответы. Для него важен сам процесс общения, остальное — несущественная побочка.
--
Не можешь достичь желаемого — пожелай достигнутого.
