Супер
От: Драгомир
На: 7-08-2005@11:44 GMT+2
Оценка: 1/НеутраленМного добра, статия. Малко е на висок стил.
Не разбрах защо обектите се създават с копиращ конструктор, а не с инициализиращ.
Защо има my_class *point(new my_class(ds,ds,ds));??? Каде е указателя за този new обект. Това не е ли временен leak, до края на текущия sсope. Ще я прочета още няколко пъти докато я разбера напълно:)
[Отговори на този коментар]
Да
От: Драгомир
На: 7-08-2005@11:47 GMT+2
Оценка: 1/НеутраленМай го разбрах защо. За да може да се получи правилно името, "копие на ....". Така ли е?
[Отговори на този коментар]
към: Супер
От: vesso <vesok< at >yahoo__dot__com>
На: 8-08-2005@11:41 GMT+2
Оценка: 1/НеутраленМерси за оценката!
>...защо обектите се създават с копиращ конструктор, а не с инициализиращ
За кой ред става дума? Ред като:
my_class object("auto object");
ползва именно инициализиращ конструктор. Аз лично предпочитам този вариант пред
my_class object = my_class("auto object");
защото се твърди че при втория вариант някои компилатори първо създавали временно копие на my_class, после го копирали в променливата object и накрая разрушавали временното копие, което е неефективно.
Програмата ползва копиращ конструктор единствено в auto_example(), като част от vector_of_objects.push_back(... - както показва и резултата.
> Защо има my_class *point(new my_class(ds,ds,ds));???
Ами няма такъв ред ;-) Подобен ред е:
my_class * pointer(new my_class("dynamically allocated"));
Което е равносилно на:
my_class * pointer = new my_class("dynamically allocated");
Просто предпочитам винаги да ползвам инициализация на обект (int i(0);) вместо задаване на първоначална стойност (int i=0;) - въпрос на личен стил, донякъде породен от отговора на по-горния въпрос.
>Къде е указателя за този new обект
в променливата с име pointer
>Това не е ли временен leak, до края на текущия sсope.
Не е "временен leak" - просто си заделяме памет, ползваме я и накрая я освобождаваме.
>Ще я прочета още няколко пъти докато я разбера напълно
По-добре я изпълни постъпково в дебъгер, става по-ясно.
[Отговори на този коментар]
Относо копиращият конструктор
От: Андрей
На: 8-08-2005@11:55 GMT+2
Оценка: 1/НеутраленВиждал съм техника, пък и си мисля, че в "Ефективен С++" се споменаваше, че ако наистина не се налага да има такъв конструктор е добре той да се декларира като частен (private) и може да не се имплементира. По такъв начин случайни грешки от типа на създаване на временни обекти се откриват на фаза компилация.
Още един ресурс по отношение на съвременен метод за работа с паметта с използване на С++ е описан тук: http://www.scs.cs.nyu.edu/~dm/c++-new.h...
Аз лично много се накефих на обяснението - много добро, пространствено. Този университетски преподавател си разбира от работата и от свирене на електрическа китара явно разбира :)
[Отговори на този коментар]
Ima i drugi...
От: pingu
На: 12-08-2005@13:33 GMT+2
Оценка: 1/НеутраленIma i drugi methodi (makar i podobni):
1.http://www.cantrip.org/wave12.html
2.http://www.hpl.hp.com/personal/Hans_Boe...
Inache e dobre!
[Отговори на този коментар]
C/C++ управление на паметта
От: 0xff
На: 30-08-2005@9:51 GMT+2
Оценка: 1/НеутраленУправлението на паметта в С / С++ наистина може да се превърне в кошмар, грешките са трудни за проследяване и откриване, а едно условие за край на цикъл е абсолютно достатъчно за да предизвика SIGSERV и Segmentation Fault. На заитересуваните горещо препоръчвам незаменимия memory debugger: valgrind (http://valgrind.org/).
Що се отнася до описаната библиотека RefPtr на glib не е ли нещо от сорта?
[Отговори на този коментар]
към: 0xff
От: vesso
На: 30-08-2005@14:07 GMT+2
Оценка: 1/Неутрален Съгласен съм за valgrind - полезен е, но стигнеш ли до него вече си закъсал. Целта на boost::shared_ptr е да избегне нуждата от дебъгер на паметта и мога да кажа че тази цел е постигната. Нещо повече, shared_ptr е предложен за стандартизиране в С++ (http://www.open-std.org/jtc1/sc22/wg21/...) и сигурно ще го има в следващата версия на стандартната библиотека.
Нямам опит с Glib::RefPtr но една бърза справка показва че той изисква защитаваният клас да има два метода: reference() и unreference(), т.е. защитаваният обект сам си извършва броенето на референциите. boost::shared_ptr от друга страна няма такова изискване защото самият указател съдържа брояч на референциите. Иначе крайният резултат е един и същ - обектът се саморазрушава когато вече не е необходим.
Редактиран на: 30-08-2005@14:10
[Отговори на този коментар]