memory leak?

Според вас как може да се предотврати мемори лийк в тази програма, дали въобще има някакъв начин?

class A {
public:
A() { throw int(); }
};

A *a = new A;

От доста време въобще няма memory leak.

Сигнатура!

Начи по принцип и мен не ми хрумва как ще стане лийк щом не се е стигнало до присвояване, ама щом казваш, че от доста време е така, значи не винаги е било така.

Значи в BCB по принцип си се хвърля екс. и при липса на памет, та там нема тъпи проверки за 0. Ама си мисля, че ако при създаване на обект изтрещи не е нормално да има лийк. Ако си заделил памет в конструктора не би требвало да има проблем пак, щото се вика деструктура. Ако си си инициализирал променливите с 0 преди да заделяш немаш грижа.

System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_

Ми не помня дали беше по-стар стандарт или просто бъг в популярен С++ компилатор (демек MSVC :) ама се получаваше, че паметта се заделя, и после след като конструктурът хвърли екс., няма кой да я освободи, щото не се стига до присвояването въобще.

Сигнатура!

Странното е, че _CrtDumpMemoryLeaks наистина не засича лийк ама не мога да разбера защо става така - нали преди извикването на конструктора се заделя памет.

Начи по принцип и мен не ми хрумва как ще стане лийк щом не се е стигнало до присвояване, ама щом казваш, че от доста време е така, значи не винаги е било така.

Не те разбирам нещо, значи това
int main() {
new int[10];
}
ще доведе до лийк - присвояване няма обаче..


Значи в BCB по принцип си се хвърля екс. и при липса на памет, та там нема тъпи проверки за 0. Ама си мисля, че ако при създаване на обект изтрещи не е нормално да има лийк. Ако си заделил памет в конструктора не би требвало да има проблем пак, щото се вика деструктура. Ако си си инициализирал променливите с 0 преди да заделяш немаш грижа


Пак не те разбирам май ;), ако exception-a се хвърли в конструктора няма въобще да се викне деструктора, ще се викне ако обекта е auto и exception се хвърли след завършването на конструктора и преди края на живота на обекта, това ли имаш предвид?

Няма memory leak.
От това, което е написано, не се алокира никакъв ресурс в конструктора.
Хвърля се изключение от конструктора -> непълно конструиран обект -> няма викане на деструктора -> системата се грижи за освобождаване на вече алокираната памет за А.

Ми въобще не е странно. Тя памет се заделя, ама и се освобождава после . Виж в MSDN има статии колкото искаш там Depp C++ серията.

Сигнатура!

... то и аз не разбирам какво съм искал да кажа :-)))

Начи по принцип и мен не ми хрумва как ще стане лийк щом не се е стигнало до присвояване, ама щом казваш, че от доста време е така, значи не винаги е било така.

Ми тука идеята ми требе да е била, че докато не приключи операцията по създаването на обекта нямаме собственост върху паметта все още за да я загубим.


Значи в BCB по принцип си се хвърля екс. и при липса на памет, та там нема тъпи проверки за 0.

Ми тук съм казал нещо вярно без връзка с темата щото съм направил асоциация. Безсмислица, трябва да се игнорне.


Ама си мисля, че ако при създаване на обект изтрещи не е нормално да има лийк. Ако си заделил памет в конструктора не би требвало да има проблем пак, щото се вика деструктура. Ако си си инициализирал променливите с 0 преди да заделяш немаш грижа


Ми тук очевидно съм в дълбока дългогодишна заблуда и много се радвам че ми обърна внимание на това.

Винаги съм си мислел, че деструкторът на обекта чийто конструктор гръмне се вика. Заблудата ми иде от там, че деструкторите на конструираните членове ( и само техните ) се викат.

Стига съм се опитвал да си тълкувам действията на пияно и заблудите. Сега малко да разсъждавам по въпроса.

Имаме конструиране:

1. Заделяне на памет.
2. Конструиране на обектите.
2.1 Конструиране на обект 1
2.2 Конструиране на обект 2 // Да речем, че тва гръмва
2.3 Конструиране на обект 3
3. Конструиране на себе си.

Разрушаване:

1. Собствен деструктор
2. Деструктор на обектите.
2.1 на 3
2.2 на 2 // След тоя код влизаме
2.1 на 1
3. Освобождаване на памет.

Явно на всяка изпълнена операция се променя възвратната точка, която се движи от т.3 към т.1 Тук ако всичко върви линейно няма да има проблем. Обаче ако гръмне деструктора ми изглежда значително по-страшно.

System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_

То ако ти гръмне конструктора, имаш непълно конструиран обект - деструктора не се вика.

В отговор на:

---

Винаги съм си мислел, че деструкторът на обекта чийто конструктор гръмне се вика. Заблудата ми

---

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

System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_

След изключение хвърлено при изпълнение на конструктура "през" оператор new:
- дали ще има неосвободена памет(memory leak)...
- дали оператора new ще "пропусне" изключението хвърлено от конструктура...
- дали оператора new ще върне NULL или ще хвърли изключение при недостиг на памет за създаване на бъдещия обект...

Тези неща не зависят ли от от реализацията на операторите new и delete?

След изключение хвърлено при изпълнение на конструктура "през" оператор new:

- дали оператора new ще "пропусне" изключението хвърлено от конструктура...

Значи оператор new вика operator new (различни неща са) за да задели паметта - извикването на конструкторите е извън пълномощията на operator new :), съответно и пропускането на изключения хвърлени от тях

- дали оператора new ще върне NULL или ще хвърли изключение при недостиг на памет за създаване на бъдещия обект...

Да, това зависи от реализацията на operator new. По принцип хвърля изключение, има и nothrow версия която не хвърля изключение, май беше
int *a = new (nothrow) int;

Определено знам, че по стандарт при изключение от конструктора, деструктора не се вика.
Паметта за обекта се алокира преди викането на конструктора му и ще бъде деалокирана, ако той хвърли изключение.
А за NULL/exception от оператор new: ами зависи - по-стари (много стари) компилатори могат да дават само NULL. За съвременните компилатори: май зависи как го викаш - стандартно дава exception.

То за това читавите библиотеки не разчитат на деф. конструктори ми си правят инит и прочие методи, които да вършат същата работа.
Дали има мемъри лийк или не - тва е подробност, щото при един компилатор може да мине, а при друг не. Майната и на преносимостта на кода, ама такъв код и между две поредни версии на компилатора може да даде разлики.

Хех по твойта логика доста библиотеки не са читави, примерно STL.

Ебаси пак тема с един ред отговор се изроди в набор от 'компетентни' съвети.

Сигнатура!

Ееее, знаеш за какво ти говоря. Много ясно, че всичко според случая. Аз говорех за класове при които по времето на изпълнение на конструктора може нещо да се издъни и понеже той не може да върне стойност трябва да се мислят заобиколни начини.

Да бе ама пак въпросът е доста спорен - феновете на RAII да се обадят

Сигнатура!

Виж, че в момента няма активен флейм и форумът пустее от седмица. Не може ли да заформим нещо, а? Аре, че в тоя студ никъде не ми се ходи, филми не ми се гледат, а у нас кво друго да правя?

Аз например съм фен н а конструкторите - там им е мястото на инициализациите. Недостатъците са в езика - не може от един конструктор да викаш друг.

System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_

Ми ходи в 'Готварски рецепти' .

Там от 2-3 седмици се водят войни за модераторствене, компромати, флеймове квото ти душа иска

Иначе и аз съм фен на конструктурите, ама ме изнудват да пиша init() .

Сигнатура!