@ntny

В отличии от java в с++ память по умолчанию нужно очищать самостоятельно.

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

Правильно ли я поступлю, если создам новый новый указатель р0, сделаю присвоения р0 = р1; затем delete* р0;
и далее p1 = p2 ?

К слову читал, что в С++ есть сборщики мусора.
Насколько они используются ?
Это экзотика или же стандартная фича?

0

Croessmah

Да (если, конечно же, у Вас не "умные" указатели)
А не легче В C++ или в C++/CLI?

0

@ntny

Хотя delete же освобождает память, но не стирает указатели.
Можно ли так написать
delete* p1;
p1 = p2;


Программа просто негортова в целом для компиляции.
Потому пока не способен проверить все)

0

@DU

со сборщиками ни разу не имел дело и не очень хочется.
смарт-поинтеры подходят в большинстве случаев. так что перед сборщиками поизучайте смарт-поинтеры
std::auto_ptr
std::shared_ptr
std::unique_ptr
...
их много всяких, если не ограничиваться стандартом и бустом.

0

@ntny

Croessmah, не слышал о с++/cli

Умные указатели это дополнительные библиотеки?

Добавлено через 3 минуты
DU,
Croessmah,
спасибо)

0

@DU

все что в пространстве имен std:: - это стандартная библиотеки. точно так же, как std::string, std::vector и т.п.
есть нестандартные, но тех, которые есть в стандарте вполне достаточно.

0

Croessmah

Уточню, что в стандарте C++11.

0

@ntny

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

С аналогичными вопросами на с++ пока не сталкивался.
Кто может посоветовать?

0

silent_1991

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

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

0

@gray_fox

В С++ такого нет. Можно описать подкласс в файле реализации, и его описание будет доступно только там. Обычно всё, относящееся к реализации просто складывают в отдельное пространство имён, например detail, impl и т.д..

0

silent_1991

Только теперь понял, что речь шла об уровне доступа пакета. Тогда да, в плюсах этого действительно нет.

0

@taras atavin

Есть массив/список/дерево/любой другой контейнер, а есть указатель на текущий элемент. Их нельзя путать. Если ты выделил , то p1 - указатель на контейнер, либо служебный указатель самого контейнера на элемент и присваивать ему ничего нельзя до или , если же ты хочешь заресайзить массив без потери инфы, то сначала надо выделить память в промежуточный указатель, потом скопировать сохраняемые элементы, потом удалить делитом старый указатель и только потом присвоить ему промежуточный. . Если же ты присвоил указателю некий адрес, то это только текущий указатель и его нельзя делитить. Хранение и перебор - две разные задачи. И ни кто в здравом уме деструкторы сам не вызывает, это обязанность компилятора, а прописать в деструкторе, что такой указатель надо освободить, а по такому пройти и обнулить встречный может только автор, ни какой сборщик ни когда об этом не догадается.

Добавлено через 4 минуты
правильно, но избыточно. .

Добавлено через 4 минуты
В чём же его удобство? Если класс должен быть закрыт, его можно прописать внутри другого класса и закрыть по protected, или по private, или вообще не выносить в голову, или вынести в отдельную голову и инкладить её не везде, а если пишешь библиотеку, то клиенту можно эту отдельную голову вообще не выдавать, она и будет закрыта, а а пакет вообще не понятно что вообще такое и для чего нужен.

0

silent_1991

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

А зачем тогда отвечать на этот вопрос?

0

@taras atavin

А потомок логически не связан с предком?

0

silent_1991

taras atavin, а вы признаёте только наследование?

0

@taras atavin

Здесь пойдёт отдельная голова для себя и отдельная для всех. В одной голове описываешь те классы, которые должны быть доступны в приладе, а в другой те, которые должны быть доступны только в библиотеке.

Добавлено через 2 минуты
С чего ты взял? Наследование помянул ТС, читай: . Нужны комментарии?

0

silent_1991

taras atavin, да, может, это и выход. Но всё же доступ только в пределах пространства имён мне видится более привлекательным и удобным.

Добавлено через 1 минуту
taras atavin, если вы объявите один класс внутри другого как защищённый, то доступ к нему будут иметь только наследники. ТС, как я понял, имеет ввиду, что класс этот можно использовать где угодно в пределах пакета.

0

@taras atavin

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

Добавлено через 2 минуты
У джаванутых приняты специальные классы, оборачиваемые даже вокруг функции, являющейся точкой входа в программу. Так почему бы не перенять этот обычай и не завести специальный оболочечный класс только для управления доступом к другим классам?

0

silent_1991

taras atavin, почему обсуждение каких-ибо подобных функций всегда скатывается в безопасность? privat тоже не фактор безопасности, всё это лишь надстройки языка. Про безопасность в случае с пакетным доступом вряд ли идёт речь, речь идёт об удобном предоставлении/непредоставлении доступа разработчику/пользователю соответственно.

Добавлено через 1 минуту
Это не у "джаванутых" принято, а в любом полностью ОО-языке. А в вашем примере получается "прощай, проектирование архитектуры!"

0

@taras atavin

Это джава то ОО? Хоть на грош? С удалением объекта после единственной операции с ним. Вот плюсы действительно полностью ОО, но не навязывают искусственных классов. Вся программа целиком экземпляром известного ей самой класса по ООП быть вообще не может, так как для неё это будет единственный класс такой абстракции, а она сама - единственный его экземпляр. Она ведь не видит ничего вокруг и не знает, что есть ещё какие то внешние сущности. Вот для пользователя действительно есть класс "приложение". Но этот класс включает в себя одновременно экзел и нидфоспид. А отдельно для экзела класса быть не может и с точки зрения пользователя. Этот класс - искусственная конструкция, примерно как карта, на которой было бы обозначено положение нашей вселенной. Относительно чего его обозначать? Такая суперкарта не нужна и не несёт информации, а вселенную с равным успехом можно обозначить хоть в центре её, хоть возле угла. Или попробуй описать класс "моё сознание". Не сможешь, так как не можешь посмотреть на собственное сознание со стороны.

0