Можно ли Конструктор и Деструктор вызывать как метод класса?

@Artem_Pv · Регистрация: 31.03.2019

Студворк — интернет-сервис помощи студентам

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

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
class FirstClass   
{
public:
    FirstClass()
    {
    }
};
 
class SecondClass : public FirstClass   
{
public:
    SecondClass()
    {
      // ...
 
      FirstClass ();  // А здесь его можно вызвать?  
    }
 };

@rat0r · 01.07.2019, 00:34

Сообщение от Fulcrum_013

А коммитет то не в курсе. И все контейнеры налепили так что они на старом месте удаленных новые инстансы констрактят.

Ну, вообще говоря, стандартная библиотека не обязана быть реализуемой на переносимом C++.

@Fulcrum_013 · 01.07.2019, 00:37

Сообщение от IGPIGP

кроме экзальтированного призыва считать переинициализированный объект новым

Объект это нечто аки буфер памяти в данном случае. А то что в этом буфере живет это уже не объект. Это инстанс. И это термин уже не менеджера памяти/ресурсов а термин ООП. И вот он таки новый. Потому как старый обязан был при разрушении отвязаться от модели а новый при создании привязаться. Причем если его таки удаляют и создают то и привязываться к модели он будет по другому чем удаленный. Да кстати он же в принципе не обязан быть того же типа что и старый. Должен только помещаться в буфер старого. Т.е. в терминах ООП это таки другой инстанс. А вся путаница из за того что и object и instance почему то переводят как "объект", хотя это две огромные разницы.

IGPIGP · 01.07.2019, 00:42

Сообщение от Fulcrum_013

Ой ойо шо буде....

И не говорите.
Однако по чести говоря _stanislav, не говорил что нельзя использовать. Он говорил что нельзя использовать "как старый объект". А вы обрезали фразу:

Сообщение от _stanislav

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

и трольнули. Может и нечаянно.
А я вот не догадался.

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

Сообщение от rat0r

стандартная библиотека не обязана быть реализуемой на переносимом C++

Вот это и есть интеллектуальный суицид. Плюсы без библиотек это плюсы. И всё.

@Fulcrum_013 · 01.07.2019, 00:44

Сообщение от rat0r

Ну, вообще говоря, стандартная библиотека не обязана быть реализуемой на переносимом C++.

Вообще то говоря в переносимом С++ глобальный new не предназначен для создания буферов для единичных инстаносв, хотя и может для этого использоваться. Он предназначен для создания субкуч, обслуживающих структуры данных и имеющих более оптимальные для этих структур алгоритмы распределения чем глобальный new. т.е. то чтобы на месте старых инстансов можно было создавать новые это неотъемлимая часть дизайна языка. И примером такой субкучи к примеру является буфер вектора. Так что работает и стандартная библиотека и все нестандартные библиотеки контейнеров пересоздающие инстансы в субкучах абсолютно корректным для С++ образом.

IGPIGP · 01.07.2019, 00:49

Сообщение от Fulcrum_013

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

Это уже UB в большинстве случаев. Я не беру во внимание случаи когда выделялся буфер чаров в динамической памяти. Тут не тот случай. Fulcrum_013, вы рискуете спровоцировать контратаку на малочисленный лагерь сторонников светлой стороны. Но мы готовы.

@Fulcrum_013 · 01.07.2019, 01:06

Сообщение от IGPIGP

Это уже UB в большинстве случаев

UB оно только в случае если на старый инстанс останутся ссылки. Но поскольку при удалении инстанса из модели обязательно производится и вычистка ссылок на него то никакого UB не будет. Т.е. для всех остальных инстансов старый инстанс не существует и нет способа к нему обратится. Новые же ссылки при привязке нового инстанса к модели устанавливаются абсолютно корректно. Так что при корректной работе логики (обычно библиотечной автоматики) управления взаимосвязями UB не возможен в принципе.

IGPIGP · 01.07.2019, 02:49

Сообщение от Fulcrum_013

UB оно только в случае если на старый инстанс останутся ссылки. Но поскольку при удалении инстанса из модели обязательно производится и вычистка ссылок на него

Если память на стеке выделена автоматически, то вы полагаете будет корректно обращаться к старому типу ссылкой или указателем нового типа?

C++
1
2
3
4
A a;
a.~A();
new (&a) B();//sizeof(A)==sizeof(B) : true
//обращаемся к a как объекту типа B ? :D

@Fulcrum_013 · 01.07.2019, 03:33

Сообщение от IGPIGP

Если память на стеке выделена автоматически, то вы полагаете будет корректно обращаться к старому типу ссылкой или указателем нового типа?
C++

Ну вот это как раз корректно работать и не должно. Но и никакой необходимости так делать никогда и нет. Особенно с буферами на стеке. Максимум какая необходимость может возникнуть - пересадить в буфер стстически композированного объекта другого потомка того же абстрактного предка. Тогда при достаточном размере буфера все будет тип-топ. А во всех остальных юсе-кейсах единственный смысл подобной пересадки - экономия на вызове new/delete. Но при этом инстанс разрушается и все ссылки старого типа уничтожаются до пересадки. Новые же создаются уже нового типа.

IGPIGP · 01.07.2019, 09:55

Сообщение от Fulcrum_013

Ну вот это как раз корректно работать и не должно.

Так и я же об этом. Похоже, вы не поняли о чем тут был разговор. А разговор был о том, считать ли объект сконструированный на месте прежнего объекта - тем же самым объектом. То есть память выделяется изначально под объект типа. Непосредственно. Вы же понимаете разницу между:

C++
1
A *pa = new A();

и

C++
1
char *pbf = new char[sizeof(A)];

?
На стеке оно выделяется тоже типизировано. Хотя где-то внизу всё это байты, биты, атомы кремния... Неоправдонный спуск вниз не будет уместен.

@Fulcrum_013 · 01.07.2019, 10:08

Сообщение от IGPIGP

То есть память выделяется изначально под объект типа

Там где планируется пресадка пересаживатель как минимум в момент пересадки работает с безтиповым буфером. Все остальные имеют ссылки только типа который актуально находится в объекте. Во всяком случае если пересаживается какой абсолютно сторонний тип а не полиморфно совместимый. Иначе такая пересадка убивство процесса чистейшей воды.
Но опять же язык это средство описания тех или иных правил поведения. Есть четкие правила ООП. А именно уничтожения объекта. После вызова деструктора объект считается несуществующим в модели данных. А соответсвенно никто кроме менеджера памяти (в данном случае пересаживателя) ссылок на него иметь после вызова деструктора не должен. А соответственно вопроса со старыми ссылками просто не может существовать если следовать правилам именно ООП а не лисопетидь релятивсистского коня в сферическом вакууме.

IGPIGP · 01.07.2019, 10:26

Сообщение от Fulcrum_013

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

Ну я же всё объяснил и оговорил:

Сообщение от IGPIGP

Неоправдонный спуск вниз не будет уместен.

Fulcrum_013, то что там внизу оно всё - цепочки байт, это не просто не существенно. Оно разрушительно если приводится не в тему. А тема забавная, кстати. Интересно было бы услышать, что вы о ней думаете. А вы - о другом стали говорить.

@Fulcrum_013 · 01.07.2019, 11:20

Сообщение от IGPIGP

Оно разрушительно если приводится не в тему

Ну вот я как раз об этом. Вернее о том чтобы приводняться всегда в тему.

Сообщение от IGPIGP

А вы - о другом стали говорить.

Ну как бы разговор об объектах вне правил ООП - сапоги в смятку. А по правилам ООП вопроса просто не существует. После вызова деструктора объект в модели не существует. Как когда и будет ли буфер вообще переиспользован модели уже все равно. Потому что до или во время вызова деструктора (а в плюсах сделано все чтобы автоматически и именно в дестркуторе) объект должен быть извлечен из модели. Т.е. никакого старого объекта в модели уже не существует. Его все забыли как будто его никогда не было. В этом и есть смысл деструктора. Остался только буфер. причем неважно где - на стеке или в куче или еще где. Дальше забота той части алгоритма которая управляет пошлыми пассивными буферами, а не объектами с большой буквы(ну теми которые экземпляры классов).
И это уже забота этой части алгоритма сделать так чтобы все срослось после пересадки (что для типизированных автоматически управляемых буферов практически унриал - автоматика стека неуправляемая). Полноценно работать это может только с управляемой программистом автоматикой - т.е. буферами на куче, алгоритм удаления которых полностью кастомизируем. А пересадка в них ничем не отличается от вызова delete для старого объекта и new для нового, кроме экономии времени на синхронизацию доступа и рытье по куче.
Точно так же если new вернул тот же адрес который был у удаленного старого объекта (а такое происходит на каждом шагу - куча это хранилище буферов старых объектов для последующего переиспользования) - это будет старый объект или новый?

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

Сообщение от vlisp

только вот кто вам разрешит напрямую распоряжаться памятью?

Взял знач я у оси страниц скока мне надо. А потом с ними что хочу то и ворочу. Это моя память что хочу с ней то и делаю - захотел инстансы селю захотел оси отдал. Никто мне в этом не указ. Это так менеджер памяти мыслит.
Взял я знач у менеджера памяти буфер скока мне надо. А потом с ним что хочу то и ворочу. Это моя память что хочу с ней то и делаю - захотел инстансы селю захотел менеджеру кучи отдал. Никто мне в этом не указ. Это так вектор думает.
И эту цепочку можно до бесконечности вкладывать одно в другое как матрешки.
А откуда пришел буфер конструктору того знать не положено, так же как и деструктору то что с буфером после него будет. У одного задача сделать из вот конкретно этого куска памяти инстанс. А у второго сделать чтобы инстанса вот в этом конкретном куске больше не было. А чей этот кусок и кто решил там инстанс поселить/выселить - не их забота.

IGPIGP · 01.07.2019, 11:36

Сообщение от Fulcrum_013

После вызова деструктора объект в модели не существует.

Что вы понимаете под моделью? Вызов деструктора - это деинициализация и он ни чего не разрушает. Если предположить, что за кулисами ещё чего-то деется то плюсы становятся ларцом чудес (их и так достатчно).
Модель ООП требует определения, для использования в данном разговоре. Объект его похоже уже утратил. Поэтому разговор столь холиварен. Однако если модель, как вы говорите - это такие кулисы с тем что им может быть "всё равно", то сборщик мусора, это мелочь.

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

Сообщение от Fulcrum_013

автоматика стека неуправляемая

Вот об этом ещё ни кто не сказал. Я понимаю, что даже если между вызовом деструктора и новым placement new нет ни каких явных действий на стеке (новых определений, например), то автомат стека - не ограничен в том, чтобы занять старую память какой-то служебной информацией. В общем случае это возможно. Но ведь разговор не о том, корректен ли (гарантирован ли от UB) такой код на стеке. Разговор о том, что если он сработает (в большинстве случаев так и есть) то считать ли старый объект и новый одним и тем же объектом.
Для кучи это не актуально. Там вызов деструктора ни как не должен повлечь скрытый delete. Или может и такое статься? Именно эти соображения и могут быть решающими аргументами в данном разговоре. Но с точки зрения корректности.
Если автомат столь своенравен, то работа с ним напоминает ковыряние пальцами в скоростной мясорубке. На ходу. Нужны понимание и хорошая реакция.
А с точки зрения считать ли их одним объектом в случае успеха - это не аргумент, мне кажется.

@Fulcrum_013 · 01.07.2019, 11:52

Сообщение от IGPIGP

Что вы понимаете под моделью?

Иерархия взаимосвязанных объектов (инстансов) которые моделируют поведение/взаимодействие сущностей предметной области. После вызова деструктора объект для этой иерархии не существует.

Сообщение от IGPIGP

Вызов деструктора - это деинициализация и он ни чего не разрушает.

НУ а деинициализация это и есть разрушение инстанса. Т.е. логическое уничтожение объекта. А физическое уничтожение буфера это уже вопрос управления памятью, а не взаимодействия объекта с моделью, и никаким боком к ООП не относится.
Т.е. erase у вектора инстанс уничтожает? Уничтожает. А буфер нет.
Вообще буфер и инстанс в общем случае абсолютно независимы в плане времени жизни. К примеру в том же векторе при вызове erase инстанс уничтожается а буфер нет. т.е. буфер живет дольше инстанса. А при реаллоке вектора инстансы переселяются в новый буфер а старый буфер уничтожается. т.е. инстансы живут дольше буфера.
Вообще именно поэтому в англоязычной литературе для экземпляра класса используется термин инстанс а не объект (строго говоря экземпляр класса вообще субъект а не объект). Т.е. instance это термин из ООП а object из описания языка/менеджмента памяти. И ничего общего они вообще не имеют. Единственное что их связывает - перед уничтожением буфера из него должны быть так или иначе выселены все инстансы ( уничтожены или переселены в другой буфер).
А суть их уничтожения соответственно разная. Уничтожение инстанса это отвязка его от модели, высвобождение владеемых ресурсов и т.д. манипуляции обеспечивающие безопасность перзаписи буфера другими данными. Ну а уничтожение буфера это банально занесение его в очередь пустых буферов годных к переиспользованию (для кучи или кастомных субкуч) или вообще банально откат регистра sp для буферов на стеке.

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

Сообщение от IGPIGP

Я понимаю, что даже если между вызовом деструктора и новым placement new нет ни каких явных действий на стеке (новых определений, например), то автомат стека - не ограничен в том, чтобы занять старую память какой-то служебной информацией.

Дело даже не в этом. В пределах скопа он буфер не тронет. А в том что автомат ничего не знает о том что мы вызвали деструктор а потом placement new другого типа и никаких способов ему это сообщить у нас нет . И как следствие в любом случае вызовет деструктор для исходного типа сколько пересадок мы бы не совершили. и даже полиморфные объекты не помогут, потому что тип точно известен в компайлтайме и деструктор или заинлайнен или вызывается напрямую. тут если и пересаживать что то, то только trivially destructable как исходный так и результирующий тип.
А после скопа когда отработает автоматика стека мы то и пересадить ничего не сможем потому что адрес буфера уже не доступен (прицельный выстрел термоядерной бомбой в ногу путем запоминания адреса в указателе из вышестоящего скопа как вариант не рассматриваем ). Так что лучше этот вопрос оставить автомату стека который именно этим вопросом и занимается, а не чем то другим.

IGPIGP · 01.07.2019, 12:10

Сообщение от Fulcrum_013

Иерархия взаимосвязанных объектов (инстансов) которые моделируют поведение/взаимодействие сущностей предметной области. После вызова деструктора объект для этой иерархии не существует.

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

Сообщение от Fulcrum_013

Вообще буфер и инстанс в общем случае абсолютно независимы в плане времени жизни.

Говоря о механизме стека вы говорили иное и не без оснований.
Ну хорошо. Fulcrum_013, давайте сузим вопрос, чтобы сохранить корректность и сблизить семантику противостоящих сторон. Вот так ссылка указывает на один объект или на разные, с вашей точки зрения и почему:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
#include <iostream> 
using namespace std;
struct Phoenix
{
Phoenix(int p=0)
:ph(p)
{}
int ph;
};
void main()
{   
char *pch=new char[sizeof(Phoenix)];
Phoenix *phoenix_ptr=reinterpret_cast<Phoenix *>(pch);
Phoenix &phoenix=*phoenix_ptr;
new(phoenix_ptr)Phoenix(123);
cout<<phoenix.ph<<endl;
 
phoenix.~Phoenix();
new(phoenix_ptr)Phoenix(234);
cout<<phoenix.ph<<endl;
 
phoenix.~Phoenix();
new(phoenix_ptr)Phoenix(345);
cout<<phoenix.ph<<endl;
cout<<endl;
delete [] pch;
system("pause");    
}

@Fulcrum_013 · 01.07.2019, 12:57

Сообщение от IGPIGP

Вот так ссылка указывает на один объект или на разные, с вашей точки зрения и почему:

Это разные инстансы. Потому что инстанс уничтожается и потом создается заново. А в каком буфере не столь важно.
мало того в чем разница вот с этим?

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#include <iostream> 
using namespace std;
struct Phoenix
{
    Phoenix(int p = 0)
        :ph(p)
    {
        std::cout << this << ":instance created" << std::endl;
    }
    int ph;
};
void main()
{
    auto* pch = new Phoenix(123);
    delete pch;
    pch = new Phoenix(456);
    delete pch;
    pch = new Phoenix(789);
    delete pch;
    system("pause");
}

выхлоп:

00CFAA90:instance created

00CFAA90:instance created

00CFAA90:instance created

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

Исключительно в том что буфер был занесен в очередь и извлечен из нее между разрушением старого и созданием нового инстанса.

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

Сообщение от IGPIGP

Говоря о механизме стека вы говорили иное и не без оснований.

Ну буфера на стеке в общем то как буфера и не воспринимаются то. С ними автомат работает и это его головняк и никакого смысла в это вмешиваться нет. А мысли естественно вокруг того где поселение и переселение инстансов моя зона ответственности. А они все на куче или trivially destructible типа статически композированные в класс который селит/выселяет в них инстансы другого типа - т.е. по ходу ничем от буферов на куче в плане обработки изнутри класса не отличаются кроме невозможности ресайза.
Хотя в общем и на стеке можно те же финты ушами творить с поселением в буфер инстансов и т.д. только смысла нет самому ловить когда оные инстансы похоронить не забыть надо. Проще этот буфер в класс обернуть, описать как выселять, поселить на стек и не парится по поводу когда выселять.

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

Сообщение от IGPIGP

Первую можно воплотить на театральной сцене, а вторая - механизм языка программирования.

Они очень сильно взаимосвязаны. Механизм языка программирования построен с целью воплощения этой второй абстракции на театральной сцене так сказать. Это и называется поддержка ООП. Т.е. не просто там ключевое слово class и т.д. а именно автоматика управление жизненным циклом объектов соответсвующая правилам ООП (конкретно - автоматическая обработка статической композиции) и помогающая реализовать такую автоматику для динамических объектов по полному набору правил взаимосвязей (для динамических еще есть и агрегация и сложная композиция когда владельцев уничтожающих подчиненный инстанс вместе с собой несколько). И такой поддержки по большому счету нигде больше нет разве что кроме ады. Даже в хваленых мусоросборниках управления жизненным циклом нет от слова совсем.

Добавлено через 7 секунд

Сообщение от IGPIGP

Первую можно воплотить на театральной сцене, а вторая - механизм языка программирования.

Они очень сильно взаимосвязаны. Механизм языка программирования построен с целью воплощения этой второй абстракции на театральной сцене так сказать. Это и называется поддержка ООП. Т.е. не просто там ключевое слово class и т.д. а именно автоматика управление жизненным циклом объектов соответсвующая правилам ООП (конкретно - автоматическая обработка статической композиции) и помогающая реализовать такую автоматику для динамических объектов по полному набору правил взаимосвязей (для динамических еще есть и агрегация и сложная композиция когда владельцев уничтожающих подчиненный инстанс вместе с собой несколько). И такой поддержки по большому счету нигде больше нет разве что кроме ады. Даже в хваленых мусоросборниках управления жизненным циклом нет от слова совсем и все там ручками надо аки в паскалях.

@Undisputed · 01.07.2019, 13:19

Сообщение от hoggy

ты писал, что код содержит UB

Да, думаю твой код действительно содержит UB.
Хотя изначально я указал не правильную причину содержания UB, за что приношу свои извинения.
Изначальный мой "аргумент" был таков что UB будет из-за того что был вызван деструктор, но это не так.
Тем не менее, UB все же есть, но по другой причине. Разберемся почему:
Тот прием который ты использовал вполне легальный, но только если объект для которого использован данный прием отвечает определенным требованиям, иначе это UB. В твоем примере используется std::string, реализация которого не определена по стандарту.
А раз реализация не определена, значит и не определено то, попадает ли реализация std::string под те самые правила, которые являются исключением при использовании этого приема. Вот эти правила:
https://timsong-cpp.github.io/... sic.life#8
там так же написано что этот объект является новым.

Сообщение от hoggy

ты же пишешь об этом так, словно есть какая то принципиальное различие.
в чем различие, ты объяснить конечно не сможешь.

почему не смогу? я вроде уже объяснил свою позицию ссылаясь на стандарт
есть документ исходя из которого определяется что есть что в С++
так вот, в этом документе сказано что теперь в storage который был reused, находится новый объект
другое дело если тебе это кажется не логичным - тогда я тебя где-то пойму
но ты так говоришь словно выдаешь это за "В С++ это считается одним и тем же объектом"
а это создает впечатление что у тебя какой то свой С++, вот с этим я и не согласен
какие еще тебе объяснения нужны, если в официальном документе это считается новым объектом

IGPIGP · 01.07.2019, 13:58

Сообщение от Fulcrum_013

Это разные инстансы. Потому что инстанс уничтожается и потом создается заново.

Там происходит деинициализация и реинициализация. С точки зрения той памяти что вы называете буфер, это перезапись.
Но семантически ссылка - синоним объекта и если код валиден, то ссылка указывает на разные объекты, иначе нужно считать ссылку просроченной (невалидной). Другой поддержки для вашей логики я не вижу.
А вот это:

Сообщение от Fulcrum_013

в чем разница вот с этим?

с моей точки зрения разные вещи уж точно. Память выделена как char[] и у компилятора нет оснований для самовольного её освобождения. Запуск деструктора на объекте сконструированном в этом массиве не имеет значения.
Fulcrum_013, я уж не говорю о том, что освобождение памяти и в случае когда она выделялась для конструктора объекта, непосредственно, не выгодна если есть только запуск деструктора. Это просто неэффективно. Да и практика это показывает. Но я согласен, и решил данный вариант не рассматривать намеренно. Разрабы компиляторов не идиоты. Но конкретный разраб может иметь мотивы в виде обострения геморроя или денег от конкурента... или еще что-то. Поэтому пусть речь именно о буфере в куче.
Тут модель ООП не убеждает. Компилятор её реализует и нужны убедительные доводы, которые показывают механизмы такой реализации (на самом верхнем уровне, - хотя бы логику). То есть, зачем компилятору это желать. Слепая вера (в ООП), живущая в его сердце - не аргумент. Аргументы - быстродействие, надёжность, экономия памяти.

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

Сообщение от Fulcrum_013

Вообще буфер и инстанс в общем случае абсолютно независимы в плане времени жизни. К примеру в том же векторе при вызове erase инстанс уничтожается а буфер нет. т.е. буфер живет дольше инстанса.

Fulcrum_013, речь в теме об объектах. В векторе происходит их копирование (объектов), при сортировкаx, свопах, реалоках. Я не вижу смысла в инстансах для данной темы. Ссылка это синоним объекта. Как только программист потеряет возможность доступа к объекту, - половина уйдёт в Java-подобные языки (большая), а остальные в С. Шутка (почти).

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

Сообщение от Undisputed

какие еще тебе объяснения нужны, если в официальном документе это считается новым объектом

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

@Fulcrum_013 · 01.07.2019, 14:05

Сообщение от IGPIGP

Память выделена как char[] и у компилятора нет оснований для самовольного её освобождения.

У него в любом случае нет никаких оснований для ее высвобождения. Управление кучей ручное. Это означает что пока программист сам не назначит алгоритм автоматического высвобождения никакого автоматического высвобождения не будет в принципе.

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

Сообщение от IGPIGP

Аргументы - быстродействие, надёжность, экономия памяти.

А это заложено в методологии проектирования. К примеру строгость ООП в плане определения правил возможности прододжения существования инстансов каждого конкретного типа в каждой конкретно взятой ситуации повышает как надежность так и быстродействие и снижает при этом оверхед по памяти присущий ФП, которому требуется GC в следствие недостаточно строгого описания предметной области.

@Undisputed · 01.07.2019, 14:08

Сообщение от IGPIGP

При такой аргументации тема мертва.

Я просто не могу понять, какие еще аргументы нужны?
Вы когда пишите код на С++ вы не принимаете во внимание стандарт?
С каких пор вообще стандарт это не аргумент понять не могу

Сообщение от IGPIGP

Я хочу понять логику.

вот это уже совсем другой вопрос, который не касается напрямую правил С++
насчет логики я выразил свою позицию здесь https://www.cyberforum.ru/cpp-... st13691470
и чем она "не подходит" я тоже не понимаю
думаю проблема понимания логики в том что вы зациклились на С++ и рассуждаете с той точки зрения что у вас есть доступ к памяти
в языках с виртуальными машинами над адресами реже думают когда рассуждают объектами
каждый new - приводит к конструированию нового объекта о чем свидетельствует вызов конструктора
а конструктор не вызывается никак иначе кроме тех случаев когда вы формируете новый объект

Новые блоги и статьи Все статьи Все блоги /
Локальный http сервер Argus19 17.10.2026 Локальный http сервер На работе, на двух локальных компьютерах круглосуточно работают программы опроса приборов с записью в книги Excel,которые раз в сутки записываются на сервер компании. Т. к. . . .	Копировать Windows на новый диск на UEFI damix 17.10.2026 https:/ / uriesk. wordpress. com/ 2016/ 11/ 01/ move-window-10-to-ssd-on-a-uefi-dualboot-system-with-basic-linux-tools/ TL DR Вставляем диск, а старый подключаем через переходник, грузимся с лайва. . .	ИИ не может найти нужный язык в списке Supersumestria 05.10.2026 Я ему даю вот такое изображение и прошу найти и подчеркнуть немецкий язык. Возвращает он вот это: https:/ / i. **********/ vqBWLe2. png Нужную строчку в 3й колонке просто выдумал. . Это. . .	Новая последняя моя музыка в SUNO zorxor 05.10.2026 Здравствуйте, дорогие мои друзья! С большой радостью я хотел бы представить вам свою новую последнею музыку, которую сгенерировала мне по моей просьбе нейросеть SUNO. С уважением, zorxor. Это. . .
Программный домашний кинотеатр russiannick 27.09.2026 Сподобился на программный домашний кинотеатр. В качестве ЯВУ по традиции выбрал js. В помощники взял Яндекс-Алису. Было создано три зала на разные интересы. исторические и ретро сериал Хичкок. . .	Беседа с ИИ о программистах, недопускающих к созданию и правке кода генеративные ИИ и причины этого zorxor 21.09.2026 Раньше я радовался или получал некоторые эмоции, пусть небольшие, но всё же, от самого процесса написания кода, рекомпиляции и запуска, видя постепенное развитие программы и прочее. А теперь лень. . .	Мобильное приложение ColorStep pavlinmavlin 17.09.2026 Реализовал приложение Красный, Зеленый, Синий в Unity3d + c#. Название изменил на ColorStep. Приложение прошло модерацию и теперь доступно для скачивания. Делал его сам, шаг за шагом — и вот,. . .	Запрет дублирования строк в табличной части Maks 13.09.2026 Реализация из решения ниже выполнена на нетиповом справочнике "Нормы ТО" с табличной часть "Виды ТО", разработанного в КА2, со следующими реквизитами: - ВидТО (СправочникСсылка. ВидыТО); - ВидГСМ. . .