Искам да попитам ако съм заделил динамично памет и после променя размера без да изтрия предишното заделяне memory leak ли е. Давам примерен код

int main()

{

char* tmp = new char[10];

tmp = new char[25]; // memort leak ?

 

delete [] tmp;

}

преди 1 час, RandomGuy написа:

char* tmp = new char[10];

tmp = new char[25]; // memort leak ?

Мемори лийк е. Ти не променяш размера по този начин, ами правиш изцяло ново заделяне, след което при присвояването изтриваш указателя към старата памет, като по този начин правиш освобождаването ѝ невъзможно.  Използвай т.нар. умни указатели (shared_ptr, unique_ptr), ако искаш да правиш такава врътка. Или още по-добре вектор. него може да го преоразмеряваш както искаш.

С STL-ските вектори я карай по-полека. Не дай си Боже, във вектора да има пойнтери... Вектора като се понапълни и реалоква, а пойнтерите си остават да висят... Отново празове из паметта... Та, с векторите, само внимателно!

преди 33 минути, darkterminal написа:

С STL-ските вектори я карай по-полека. Не дай си Боже, във вектора да има пойнтери... Вектора като се понапълни и реалоква, а пойнтерите си остават да висят... Отново празове из паметта... Та, с векторите, само внимателно!

Това с указателите не е проблем на STL, ами принципен. Каквато и структура от данни да реалокираш, пойнтерите към нея си увисват.

Благодаря много за отговора. И последно искам да попитам ако изтривам преди това ще избегна ли проблема.

char* tmp = new char[10];

delete [] tmp;

tmp = new char[25]; 

преди 1 час, RandomGuy написа:

Благодаря много за отговора. И последно искам да попитам ако изтривам преди това ще избегна ли проблема.

char* tmp = new char[10];

delete [] tmp;

tmp = new char[25]; 

Да, само че в реална програма е трудно да се следи.

По добре ползвай STL.

Господ за това я е измислил.

преди 9 часа, flare написа:

Това с указателите не е проблем на STL, ами принципен. Каквато и структура от данни да реалокираш, пойнтерите към нея си увисват.

Номера е, че първо трябва да се знае, че точно вектора реалоква. Второ, трябва да се знае, какви са последствията от реалокването. Трето, трябва да се има предвид, че има и по-благородни структури от вектора, дето не реалокват така безотговорно. За това и предупреждавам - внимателската преди да се хвърли младежа да ползва векторите и STL-a. Не защото проблема е в STL-a, ами защото този език, принципно толкова си може. Мислех да го спестя, но някак си сърце не ми дава. Четвърто, има езици, които до голяма степен спестяват целия този гювеч с ръчното управление на паметта. Та, ако младежа иска да програмира, а не да брои байтове и пойнтери, да се преориентира навреме...

Редактирано 6 юни 201610 г. от darkterminal (преглед на промените)

току що, darkterminal написа:

Номера е, че първо трябва да се знае, че точно вектора реалоква. Второ, трябва да се знае, какви са последствията от реалокването. Трето, трябва да се има предвид, че има и по-благородни структури от вектора, дето не реалокват така безотговорно. За това и предупреждавам - внимателската преди да се хвърли младежа да ползва векторите и STL-a. Не защото проблема е в STL-a, ами защото този език толкова си може. Мислех да го спестя, но някак си сърце не ми дава. Четвърто, има езици, които до голяма степен спестяват целия този гювеч с ръчното управление на паметта. Та, ако младежа иска да програмира, а не да брои байтове, да се преориентира навреме...

В Джава, арей листа и вектора да не би да не реалокват ?

Какъвто и да е езика, на масивите, като им се запълни капацитета, няма как да не реалокват, ако трябва да се увеличи.

В противен случай, ако няма реалокване, се нарушава изискването за последователно разполагане на елементите на масива.

преди 4 минути, darkterminal написа:

 Не защото проблема е в STL-a, ами защото този език, принципно толкова си може.

Това е така, ама все още има области, където си трябва броенето на байтове и ръчната работа с пойнтери и т.н.

А за знаенето - еми сега ако не си прочете документацията... - а там тия работи ги пише.

Редактирано 6 юни 201610 г. от flare (преглед на промените)

преди 3 минути, flare написа:

Това е така, ама все още има области, където си трябва броенето на байтове и ръчната работа с пойнтери и т.н.

А за знаенето - еми сега ако не си прочете документацията... - а там тия работи ги пише.

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

А ако масива ти е разпокъсан, той вече не е масив и нямаш произволен достъп

току що, Реджеп Иведик написа:

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

А ако масива ти е разпокъсан, той вече не е масив и нямаш произволен достъп

Не е въпроса в реалокирането, ами в това средата да се усети и да ти пренареди указателите. (ако изобщо има такава конструкция на съответния език)

Редактирано 6 юни 201610 г. от flare (преглед на промените)

преди 8 часа, Реджеп Иведик написа:

В Джава, арей листа и вектора да не би да не реалокват ?

Какъвто и да е езика, на масивите, като им се запълни капацитета, няма как да не реалокват, ако трябва да се увеличи.

В противен случай, ако няма реалокване, се нарушава изискването за последователно разполагане на елементите на масива.

В езици като C и C++, подредбата е важна за да може с прости адресни операции и елементарна аритметика да достъпиш следващия (или желания) елемент. В Жабата и в Шишарката такива гимнастики не са предвидени във фичърите на езика! Така, че всички тези колекции са така направени, че да рънкат бързо и да са удобни за ползване. Най-вече няма лесен начин да се застреляш (като например да натъпчеш Вектор с елементи от тип АутоПойнтер). Колкото и да реалокваш, като кажеш .get(3), ще получиш третия елемент на колекцията и няма начин да затриеш съдържимото, докато габидж колектора отчита поне една активна референция към този обект! Най-многото, което  можеш да сториш е да натъпчеш колекцията с хендъли към незатворени системни ресурси и да се заровиш в празове! Не, че е малко, но е стотици пъти по-малко от това, което има шанс неопитен програмист да натвори на  Це Плюс Пляса...

преди 8 часа, flare написа:

Това е така, ама все още има области, където си трябва броенето на байтове и ръчната работа с пойнтери и т.н.

А за знаенето - еми сега ако не си прочете документацията... - а там тия работи ги пише.

Правилно! Ако трябва да се пишат драйвери, приложения рънкащи на състемно ниво или свръхсветлинни ОС-ки, апки и алгоритми - асемблера, Це-то и Це Плюс Пляса са незаменими! Но опита в мен говори, че тогава обектното и темплейтното програмиране стават мръсни думи. Въобще, критерия общо взето е - притрябват ли ти темплейти, значи C++ не е езика, на който би трябвало да си пишеш кода...

П.П. Никъде не пише кво ше стане ако натъпчеш с вектор а аутопойнтери и той междувременно вземе, че реалокне! Трябва и да се мисли... Гад ли съм

преди 4 часа, darkterminal написа:

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

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

Иначе какво става. Както в каменната ера, ще пишеш на лист с молив, и ако имаш грешки в алгоритъма ?

преди 54 минути, Реджеп Иведик написа:

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

Иначе какво става. Както в каменната ера, ще пишеш на лист с молив, и ако имаш грешки в алгоритъма ?

Когато искаш да изстискаш всяка капка мощ от желязото, а паметта в чипчето е толкова малко, че дори и таблиците на виртуалните методи на класовете дават овърхед, се зарязват всякакви лиготии и се пише на кор Це. Тогава се пише толкова тънко, че за СТЛ няма място дори да се помисли. Няма ексепшъни, няма тредове. Всичко се пише в един процес, с една нишка. Паметта се пълни отзад напред... И куп такива "трикове", които отличават кор програмирането от бизнес ориентираното програмиране.

П.П. Когато искаш да си пробваш програмката, компилираш я с компилатора за съответното желязо и си я рънкаш или на емулатор и дебъгваш или директно на железцето и дебъгваш през ДжейТаг (модерните умни железа по милост може и да поддържат дебъг стрийм през ЮСБ) интерфейс. Няма нужда да космясваме като маймунките в каменнта ера. Хората са ни улеснили достатъчно, за да може макар и въоръжени само с беден инструментасриум, пак да си свършим работата технологично.

преди 34 минути, darkterminal написа:

Когато искаш да изстискаш всяка капка мощ от желязото, а паметта в чипчето е толкова малко, че дори и таблиците на виртуалните методи на класовете дават овърхед, се зарязват всякакви лиготии и се пише на кор Це. Тогава се пише толкова тънко, че за СТЛ няма място дори да се помисли. Няма ексепшъни, няма тредове. Всичко се пише в един процес, с една нишка. Паметта се пълни отзад напред... И куп такива "трикове", които отличават кор програмирането от бизнес ориентираното програмиране.

Не е баш така. Примерно, като пишеш за "желязо", обикновено скоростта и последователността с която реагираш на евент са много важни и обикновено се пише на много нишки. Обаче се ползват други или модифицирани ОСи.

После нещата не са черно-бели - тоест не е тук е C и тук е dotNet. Има и помежду тях. И там хората искат да пишат на близко до C, ама да ползват някои от благинките на обектното програмиране. Щото става така (както в Линукс ядрото хората правят на C имитации на обекти - което (лично мнение) е ужасТ)

преди 16 минути, flare написа:

Не е баш така. Примерно, като пишеш за "желязо", обикновено скоростта и последователността с която реагираш на евент са много важни и обикновено се пише на много нишки. Обаче се ползват други или модифицирани ОСи.

После нещата не са черно-бели - тоест не е тук е C и тук е dotNet. Има и помежду тях. И там хората искат да пишат на близко до C, ама да ползват някои от благинките на обектното програмиране. Щото става така (както в Линукс ядрото хората правят на C имитации на обекти - което (лично мнение) е ужасТ)

Много нишки се ползват на по-големки железца разни АРМове и други дето имат сила да дишат и за тях. Рутери разни и суичове, и дуги по-малки и специализирани железца, рънкат даже и без ОСка и без тредове, а гледай какъв перформънс дават. И най-вече, защото е писано, разумно и пестеливо, с броене на байтове и без СТЛ

Инак, за мен нещата са доста черно-бели, никой не пише драйвери или кернели на Жаба или Шишарка. Никой не пише цели ентерпрайз приложенния на асемблер и Це. Разбира се има и други видове приложения, които може да се напишат дори на ЖабаСкрит и да се рънкат през Рино или на Пипон. Няма лошо. Като ми трябва да налепя нещо набързо и аз ползвам ПъХъПъ. Ма стигне ли се до сериозни обекти и нужда от темплейти си ползвам правилните езици...

П.П. Е, ми ти като фен на ГИМП-ата, погледни как е написано ГТК-то. Стойни като войници функции, подредени по име на структурата дето манипулират, с първи параметър въпросната структура (чиста проба селф/дис/ми или както искаш го кажи) и последващи параметри. Да ти е кеф да му туриш един обектен рапър и да си го  ползваш с удоволствие (те различните скриптинг байндинги - Питон, ПХП, Перл - това и правят де)

току що, darkterminal написа:

Много нишки се ползват на по-големки железца разни АРМове и други дето имат сила да дишат и за тях. Рутери разни и суичове, и дуги по-малки и специализирани железца, рънкат даже и без ОСка и без тредове, а гледай какъв перформънс дават. И най-вече, защото е писано, разумно и пестеливо, с броене на байтове и без СТЛ

Инак, за мен нещата са доста черно-бели, никой не пише драйвери или кернели на Жаба или Шишарка. Никой не пише цели ентерпрайз приложенния на асемблер и Це. Разбира се има и други видове приложения, които може да се напишат дори на ЖабаСкрит и да се рънкат през Рино или на Пипон. Няма лошо. Като ми трябва да налепя нещо набързо и аз ползвам ПъХъПъ. Ма стигне ли се до сериозни обекти и нужда от темплейти си ползвам правилните езици...

П.П. Е, ми ти като фен на ГИМП-ата, погледни как е написано ГТК-то. Стойни като войници функции, подредени по име на структурата дето манипулират, с първи параметър въпросната структура (чиста проба селф/дис/ми или както искаш го кажи) и последващи параметри. Да ти е кеф да му туриш един обектен рапър и да си го  ползваш с удоволствие (те различните скриптинг байндинги - Питон, ПХП, Перл - това и правят де)

Ами то за нишките е така - има и железа дето нямат възможност. Но исках да кажа че една суперминималистична RTOS почти няма овърхед. Писал съм за процесор дето кода трябваше да е 16к и компилатора нямаше никаква смислена оптимизация. Баси нареждахме циклите наобратно и сменяхме умноженията примерно а*3 със а << 1 + a... за мъничко скорост и мъничко свободно място.

А за C++ ще ти дам конкретен реален пример - андроид. нивото под Жабата е на C++ който е абсолютно извратен. Няма ексепшъни, примерно new ти връща null кат няма памет. И има куриози като C код да вика C++ код, който вика C код. Обаче гугълци са решили, че все пак имат файда от обектното... (ама пример - чудо... )

Куриози и извращения много... Важното е младежа да си извади поука. Да чете. Да мисли. Да ползва правилните инструменти. От мен стига толкова.

Успех!

Благодаря на всички за отговорите