Я програміст на С, який намагається зрозуміти C ++. Багато навчальних посібників демонструють ідентифікацію об'єкта за допомогою фрагмента, наприклад:
Dog* sparky = new Dog();що означає, що згодом ви зробите:
delete sparky;що має сенс. Тепер, у випадку, коли динамічне розподілення пам’яті непотрібне, чи є причина використовувати вищезазначене замість
Dog sparky;і нехай викличе деструктор, як тільки іскри вийде за межі?
Дякую!
Відповіді:
Навпаки, завжди слід віддавати перевагу розподілу стеків, якщо ви, як правило, ніколи не повинні мати нові / видаляти у своєму коді користувача.
Як ви кажете, коли змінна оголошена в стеку, її деструктор автоматично викликається, коли вона виходить за рамки, що є вашим головним інструментом для відстеження терміну служби ресурсу та уникнення витоків.
Тож загалом, кожного разу, коли потрібно виділяти ресурс, будь то пам'ять (виклик нового), ручки файлів, сокети або щось інше, загортайте його в клас, де конструктор отримує ресурс, а деструктор випускає його. Тоді ви можете створити об’єкт цього типу на стеці, і ви гарантуєтеся, що ваш ресурс буде звільнений, коли він вийде за межі області. Таким чином, вам не доведеться скрізь відслідковувати ваші нові / видаляти пари, щоб уникнути витоку пам'яті.
Найпоширеніша назва цієї ідіоми - RAII
Також розгляньте класи класів розумних покажчиків, які використовуються для обгортання отриманих покажчиків на рідкісні випадки, коли вам потрібно виділити щось нове поза виділеним об’єктом RAII. Ви натомість передаєте вказівник розумному вказівнику, який потім відстежує його термін служби, наприклад, шляхом підрахунку посилань, і викликає деструктора, коли остання посилання виходить за межі області. Стандартна бібліотека має std::unique_ptrпросте управління, засноване на масштабах, і std::shared_ptrщо робить підрахунок посилань для реалізації спільної власності.
Багато навчальних посібників демонструють інстанціювання об'єкта за допомогою фрагмента, наприклад ...
Отже, ви виявили, що більшість навчальних посібників смоктають. ;) Більшість навчальних посібників навчають вас манірних практик C ++, включаючи виклик нових / видалення для створення змінних, коли це не потрібно, та важко відстежуючи термін експлуатації ваших виділень.
Хоча наявність у стеку речей може бути перевагою з точки зору розподілу та автоматичного звільнення, це має деякі недоліки.
Можливо, ви не хочете виділяти величезні об'єкти на стеку.
Динамічна відправка! Розглянемо цей код:
#include <iostream>
class A {
public:
virtual void f();
virtual ~A() {}
};
class B : public A {
public:
virtual void f();
};
void A::f() {cout << "A";}
void B::f() {cout << "B";}
int main(void) {
A *a = new B();
a->f();
delete a;
return 0;
}Це надрукує "B". Тепер давайте подивимося, що відбувається під час використання Stack:
int main(void) {
A a = B();
a.f();
return 0;
}Це надрукує "A", що може бути не інтуїтивно зрозумілим для тих, хто знайомий з Java або іншими об'єктно-орієнтованими мовами. Причина полягає в тому, що ви більше не маєте вказівника на екземпляр B. Натомість створюється екземпляр Bі копіюється в aзмінну типу A.
Деякі речі можуть трапитися ненавмисно, особливо коли ви не знайомі зі C ++. У C у вас є вказівники, і все. Ви знаєте, як їх використовувати, і вони ВЖЕ завжди те ж саме. У C ++ це не так. Тільки уявіть , що відбувається, коли ви використовуєте в цьому прикладі в якості аргументу для методу - все стає більш складним , і це робить величезну різницю , якщо aмає тип Aабо A*навіть A&(виклик за посиланням). Можливо багато комбінацій, і всі вони поводяться по-різному.
Ну, причина використання вказівника була б точно такою ж, як причина використання покажчиків на C, виділених malloc: якщо ви хочете, щоб ваш об'єкт жив довше, ніж ваша змінна!
Навіть дуже рекомендується НЕ використовувати нового оператора, якщо ви зможете цього уникнути. Особливо, якщо ви використовуєте винятки. Взагалі набагато безпечніше дозволити компілятору звільнити ваші об’єкти.
Я бачив цю антидіаграму від людей, які не зовсім отримують & адресу оператора. Якщо їм потрібно викликати функцію за допомогою вказівника, вони завжди будуть виділяти на купі, щоб вони отримали вказівник.
void FeedTheDog(Dog* hungryDog);
Dog* badDog = new Dog;
FeedTheDog(badDog);
delete badDog;
Dog goodDog;
FeedTheDog(&goodDog);Ставтеся до купи як до дуже важливої нерухомості та використовуйте її дуже розумно. Основне правило великого пальця - використовувати стек, коли це можливо, і використовувати купу, коли немає іншого способу. Виділяючи об'єкти в стеці, ви можете отримати багато переваг, таких як:
(1). Вам не потрібно турбуватися про розмотування стека у випадку винятків
(2). Вам не потрібно турбуватися про фрагментацію пам’яті, спричинену виділенням більше місця, ніж потрібно вашому менеджеру купи.
Єдине, чому я хвилююся, - це те, що Собака зараз виділяється на стек, а не на купу. Отже, якщо собака має мегабайти в розмірі, у вас можуть виникнути проблеми,
Якщо вам потрібно пройти новий / видалити маршрут, будьте обережні до винятків. І через це вам слід використовувати auto_ptr або один із типів інтелектуального вказівника для підвищення рівня життя об'єкта.
Немає підстав для нового (на купі), коли ви можете виділити його на стек (якщо з якоїсь причини у вас є невеликий стек і ви хочете використовувати купу.
Ви можете розглянути можливість використання shared_ptr (або одного з його варіантів) зі стандартної бібліотеки, якщо ви хочете виділити їх на купі. Це допоможе зробити видалення для вас, коли всі посилання на shared_ptr вже не існують.
Є додаткова причина, яку ніхто більше не згадував, чому ви можете вирішити створити свій об’єкт динамічно. Динамічні об’єкти на основі купи дозволяють використовувати поліморфізм .
У мене була така ж проблема у Visual Studio. Ви повинні використовувати:
yourClass-> classMethod ();
а не:
yourClass.classMethod ();