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

[StressedintheUS]

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

Интересует опыт подобных решений - удалось ли применить STL в больших проектах без особой натуги, переключились ли на собственные классы - менеджеры памяти - или использовали что-либо другое?

[Palych]

Можно добавить чайниковский вопрос? (начальство заставляет на C++ писать )
Где можно почитать про управлению памятью в больших проектах?
Наши аксакалы отрицают необходимость централизованного memory management mechanism

[lx_uk]

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

Это дело привычки/опыта скорее.

Интересует опыт подобных решений - удалось ли применить STL в больших проектах без особой натуги, переключились ли на собственные классы - менеджеры памяти - или использовали что-либо другое?

Использование STL контейнеров обычно дает неплохой результат в плане упорядочивания кода. Впрочем обычно всё контейнерами и ограничивается. Ну плюc еще string, auto_ptr. А вот управление памятью, алгоритмы и всякие другие сложности как правило (IMHO) остаются невостребованными. Используется то что есть по-умолчанию.

[AndreyT]

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

В STL нет специализированных средств, предназначенных для решения таких задач. Поэтому мне не совсем понятно, в чем суть вопроса. Кстати, что имеется в виду, под "выгружением из памяти"?

Интересует опыт подобных решений - удалось ли применить STL в больших проектах без особой натуги, переключились ли на собственные классы - менеджеры памяти - или использовали что-либо другое?

[Вася Пупкин]

Кстати, что имеется в виду, под "выгружением из памяти"?

Сборщика мусора как в жабе человек хочет

[AndreyT]

Кстати, что имеется в виду, под "выгружением из памяти"?

Сборщика мусора как в жабе человек хочет

В том то и дело, что первое, что приходит в голову, когда говорят о "выгружении из памяти" - это своппинг, а не сборка мусора. Хотя и сборка мусора тоже кандидат. Потому и непонятно.

[Вася Пупкин]

Кстати, что имеется в виду, под "выгружением из памяти"?

Сборщика мусора как в жабе человек хочет

В том то и дело, что первое, что приходит в голову, когда говорят о "выгружении из памяти" - это своппинг, а не сборка мусора. Хотя и сборка мусора тоже кандидат. Потому и непонятно.

Своппингом обычно ОС занимается.

[Vovka]

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

А в чём конкретно проблема? Я вот если честно даже представить не могу, где там "страшный геморрой" может возникнуть при работе с памятью.
Единственно, вам ещё для нормального использования скорее всего понадобятся смарт-поинтеры кроме auto_ptr (его ни в коем случае нельзя хранить в коллекциях!). Например, посмотрите сюда: http://boost.org/libs/smart_ptr/smart_ptr.htm. В коллекции обычно хорошо запихивать shared_ptr из этой библиотеки.

Один совет по поводу STL и её изучения.
Эта библиотека не сложная, она просто неочевидная. Т.е., есть какие-нить библиотеки - вроде коллекций в MFC - посмотрел на нитерфейс класса, вроде как ясно, что он делает. Худо-будно начал использовать.
Другое дело STL. Лучше сначала выделить какое-то время на то, чтобы почитать про неё. Немного, не больше одного или даже половины дня. В онлайне вроде где-то есть статья самого Степанова. Если книжка - то есть книжка "The C++ Standard Library", by Nicolai M. Josuttis. Но её даже всю читать не надо, она толстая. MSDN насчёт STL лучше не смотреть, там написано очень плохо, лучше вот это: http://www.sgi.com/tech/stl/table_of_contents.html. Там, правда, несколько нестандартных расширений описано, но есть соотв. пометки. Ну и неплохо почитать Meyers, "Effective STL".

Интересует опыт подобных решений - удалось ли применить STL в больших проектах без особой натуги, переключились ли на собственные классы - менеджеры памяти - или использовали что-либо другое?

Удавалось и удаётся. И в больших, и в маленьких тоже.
Мне вот наоборот, после STL любая библиотека контейнеров неуклюжей кажется.

[Vovka]

Кстати, что имеется в виду, под "выгружением из памяти"?

Сборщика мусора как в жабе человек хочет

Кстати, зачем? Т.е. это не риторический вопрос, действительно интересно.
В жабе как я понимаю детерминированных деструкторов нету, соответственно и смартпоинтеров. Поэтому им пришлось исхитряться и изобретать GC. А в каких случаях он для C++ нужен, я пока не могу представить.

[A. Fig Lee]

Кстати, что имеется в виду, под "выгружением из памяти"?

Сборщика мусора как в жабе человек хочет

Кстати, зачем? Т.е. это не риторический вопрос, действительно интересно.
В жабе как я понимаю детерминированных деструкторов нету, соответственно и смартпоинтеров. Поэтому им пришлось исхитряться и изобретать GC. А в каких случаях он для C++ нужен, я пока не могу представить.

Ну если хочется реиспользовать обьекты - какой смысл их создавать и уничтожать?
Можно иметь пул обьектов с автосайзом и удалять в конце.

[AndreyT]

Кстати, что имеется в виду, под "выгружением из памяти"?

Сборщика мусора как в жабе человек хочет

В том то и дело, что первое, что приходит в голову, когда говорят о "выгружении из памяти" - это своппинг, а не сборка мусора. Хотя и сборка мусора тоже кандидат. Потому и непонятно.

Своппингом обычно ОС занимается.

Обычно - ОС. Необычно - не ОС. Кто ж знает, что человеку нужно.

Своппинг в Win32, например, никак не помогает в ситуациях, когда задаче недостаточно адресного простанства процесса. Т.е. мало 2Гб и все тут. В такой ситуации спасает только самописный своппинг.

[potapych]

Своппинг в Win32, например, никак не помогает в ситуациях, когда задаче недостаточно адресного простанства процесса. Т.е. мало 2Гб и все тут. В такой ситуации спасает только самописный своппинг.

( стало интересно ) А что за задачи такие, где 2ГБ памяти может не хватить?

[Dmitry67]

Или AWE. Или переход на 64bit.
А базам данных памяти всегда мало

[Vovka]

Ну если хочется реиспользовать обьекты - какой смысл их создавать и уничтожать?
Можно иметь пул обьектов с автосайзом и удалять в конце.

Ну а при чём тут GC? Сами явно программируйте время жизни, и всё тут.

[A. Fig Lee]

Ну если хочется реиспользовать обьекты - какой смысл их создавать и уничтожать?
Можно иметь пул обьектов с автосайзом и удалять в конце.

Ну а при чём тут GC? Сами явно программируйте время жизни, и всё тут.

1. Как программировать время хизни?
2. А какая разница с GC?
3. Дык вроде вопрос был зачем кастом менеджмент меморы, предположили - нужен гарбейдж коллектор. Зачем он должен быть точной копией жавовского?

[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(); }
};

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