указатели и очистка памяти

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

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

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

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

0

Сообщение от ntny то старые данные потеряются навсегда но будут занимать место?

Да (если, конечно же, у Вас не "умные" указатели)

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

А не легче

Сообщение от ntny К слову читал, что в С++ есть сборщики мусора.

В C++ или в C++/CLI?

0

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


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

0

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

0

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

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

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

0

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

0

Сообщение от DU но тех, которые есть в стандарте вполне достаточно.

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

0

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

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

0

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

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

0

Сообщение от ntny В java есть очень удобный пакетный доступ для этих целей.

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

0

Сообщение от gray_fox В С++ такого нет

Сообщение от ntny В java есть очень удобный пакетный доступ для этих целей.

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

0

Сообщение от ntny В отличии от java в с++ память по умолчанию нужно очищать самостоятельно. Понятно, что если память зарезервированная неким указателем не нужна его следует просто удалить. но если указатель например р1 ссылается на структуру, мне же нужно присвоить указателю другую структуру того же типа содержащуюся в адресе р2. Т.е. если я просто присвою указателю р1 который уже содержит структуру адрес новой структуры указателя р2, то старые данные потеряются навсегда но будут занимать место? Правильно ли я поступлю, если создам новый новый указатель р0, сделаю присвоения р0 = р1; затем delete* р0; и далее p1 = p2 ? К слову читал, что в С++ есть сборщики мусора. Насколько они используются ? Это экзотика или же стандартная фича?

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

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

Сообщение от ntny р0 = р1; затем delete* р0; и далее p1 = p2 ?

правильно, но избыточно. .

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

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

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

0

Сообщение от taras atavin Если класс должен быть закрыт, его можно прописать внутри другого класса и закрыть по protected, или по private

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

Сообщение от taras atavin а пакет вообще не понятно что вообще такое

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

0

Сообщение от silent_1991 Если один класс описан внутри другого, то мы логически связываем его с этим другим классом.

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

0

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

0

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

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

Добавлено через 2 минуты

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

С чего ты взял? Наследование помянул ТС, читай:

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

. Нужны комментарии?

0

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

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

0

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

Добавлено через 2 минуты

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

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

0

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

Добавлено через 1 минуту

Сообщение от taras atavin У джаванутых приняты специальные классы, оборачиваемые даже вокруг функции, являющейся точкой входа в программу.

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

0

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

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

0