Положительный/Отрицательный опыт использования STL

[A. Fig Lee]

Vovka,
кроме того, иногда хочется ветвистые обьекты одним куском аллокировать - чтоб потом пхнуть их другой программе через шеред мемори или еще как.
Аллокировать например сразу на шеред меморы..
You know...

[Vovka]

1. Как программировать время хизни?
2. А какая разница с GC?

Да как угодно программировать - как хочется. Напрямую программировать - уничтожать, когда надо уничтожать.
Разница в том, что о состоянии каждого объекта в любой момент времени можно со 100% вероятностью сказать - жив он или мёртв. И ниакаого дурацкого реиспользования. Либо жив, либо мёртв.
Пока что так и не понял, зачем GC - жабовский, нежабовский - в любом виде.

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

Ну, написать кастомную сереализацию - десеарелизацию. Да даже в MFC это было, миллион лет назад. Опять не понятно, при чём тут GC.

You know...

No, still don't...

[A. Fig Lee]

Да как угодно программировать - как хочется. Напрямую программировать - уничтожать, когда надо уничтожать.
Разница в том, что о состоянии каждого объекта в любой момент времени можно со 100% вероятностью сказать - жив он или мёртв. И ниакаого дурацкого реиспользования. Либо жив, либо мёртв.
Пока что так и не понял, зачем GC - жабовский, нежабовский - в любом виде.

Да я не утверждаю что ето 100% GC. Ну как Вы будете знать что обьект уже был использован и освободился? Надо иметь глобальный обьект, который имел бы референс к етим обьектам, знал бы их состояние и выделял уже освободившиеся.
Как без глобального обьекта? Точка входа какайто должна быть в любом случае.
Расскажите как Вы узнаете где ети выделеные обьекты и каково их состояние?

Ну, написать кастомную сереализацию - десеарелизацию. Да даже в MFC это было, миллион лет назад. Опять не понятно, при чём тут GC.

1. Да дался Вам етот GC. ИМХО, человек высказал предположение о GC. Вопрос то был о мемори менеджмент? Или я чегото не понимаю?
Сериализацию - не еффективно - только создали обьект и сериализировать его?
Смысл? Почему сразу не аллокировать в одном флаконе?

[Palych]

Разница в том, что о состоянии каждого объекта в любой момент времени можно со 100% вероятностью сказать - жив он или мёртв. И никаого дурацкого реиспользования. Либо жив, либо мёртв.
Пока что так и не понял, зачем GC - жабовский, нежабовский - в любом виде.

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

[Strannik223]

Пытаюсь применить STL библиотеки в С++ для автоматизации работы с памятью (чтобы объекты выгружались из памяти автоматом). Пока - страшный геморрой,

Ну если STL пихать куда оно не предназначено природой, тогда дейтствительно, геморрой можно заработать

[Vovka]

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

Какой такой "синхронизированный код". Вообще не понял, о чём вы. Пожете поконкретнее, с примером? Если ктор-дторы такие дорогие, то зачем их вообще часто вызывать, тогда нужно объект постоянно в памяти держать.

[Strannik223]

Интересно, хоть кто то первоначальный постинг прочитал?
Человек STL пользоватся не умеет, а вы начали про GC, сериалиалазацию с синхронизацией и еще черт знает что.

[roadman]

Интересно, хоть кто то первоначальный постинг прочитал?
Человек STL пользоватся не умеет, а вы начали про GC, сериалиалазацию с синхронизацией и еще черт знает что.

I worked and still working with STL. The final result, the main containers I overrided (map, vector, list, stack, hash), but algorithms are all STL original. And the main purpose to do this - memory management. When I don't need a super performance I simply use original STL containers.
Disadvantages of STL containers are:
1. STL makes a copy of provided allocator (I would like to send only reference).
Solution: create wrapper around your allocator, which keeps only reference on your class and let STL to make a copy of your object - it's only copy of reference.
2. Some internal objects of containers (map, list - MS implementation) are created on provided allocator and will be alive until destruction of object, even if container is empty, so you can't clear container and reset allocator at the same time.
Solution: rewrite container or override specific methods.
3. Some objects (allocated on reisable memory) are simple (no additional dynamic memory allocated on heap) and can be safely destroyed without calling destructor.
However the implementation of clear function will waste of a lot time to go through a huge set of objects.
Solution - overide container for a simple objects or only clear method.
The improvments I made is not STL lack (nobody can write a 100% perfect code for ALL purposes). It was just a business requirement.

[Strannik223]

2. Some internal objects of containers (map, list - MS implementation) are created on provided allocator and will be alive until destruction of object, even if container is empty, so you can't clear container and reset allocator at the same time.

А что про StlPort можете сказать, я когда несколько раз натыкался на грабли в МС реализации, и каждый раз StlPort работал как положено.

[roadman]

А что про StlPort можете сказать, я когда несколько раз натыкался на грабли в МС реализации, и каждый раз StlPort работал как положено.

Стыдно признаться , но я не смотрел реализацию STLPort, мне было легче переписать контейнеры самому, чем интегрировать в С++ third party STL код для программ, написанных под Microsoft. Более того, мне нужен был контейнер который бы в методе clear - ничего почти не делал, в случае создания объектов на внешнем allocator.
Типа

template < class T, class A = byte_allocator >
class _list : public base_list< T >
{
public:
....................
inline _list< T, A >::iterator insert(A& allocator_, _list< T, A >::iterator it, const T& x = T());
..............................
// no memory deallocation
// remove the specified element of list
// must be defined compare operator for stored object
inline void remove(const T& x);
................................
inline void clear() {_head._prev = _head._next = head(); }
};

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