Я с ней работала не так много,но
1. STL - это библиотека содеражащая набор фукнций, шаблонов функций, шаблонов классов на многие случаи жизни. За частую, чем изобретать велосипед удобнее пользоваться ей.
Лично мне от туда нравится вектор и строка. Вектро тот вообще намнгого удобнее MFC-шного CArray`я. ИХМО.
2. Из книг для самых маленких мне нравится учебник по C++ для росийских вузов ПАвловской. Там и основы самого С++ и краткое введение в STL.

В общем, есть следующие соображения. Если MFC-контейнеры делались на основе STL (а так оно и есть, судя по исходникам), то быстродействие должно быть примерно одинаковым у большинства аналогичных ф-ций и методов обеих библиотек. Что я и попробовал проверить на простых примерах для списков, строк и карт:

Example 1

Код

CList <int, int> lstM; list <int> lstS; const int MAX_CNT = 100000; DWORD Before = GetTickCount(); for(int i=0; i<MAX_CNT; i++) {  lstM.AddTail(i); } DWORD PeriodMFC = GetTickCount()-Before; Before = GetTickCount(); for(i=0; i<MAX_CNT; i++) {  lstS.push_back(i); } DWORD PeriodSTL = GetTickCount()-Before; cout<<"Period STL: "<<PeriodSTL<<"\n"; cout<<"Period MFC: "<<PeriodMFC<<"\n";

Странно, но MFC примерно в 2-3 раза быстрее.

Example 2

Код

CList <int, int> lstM; list <int> lstS; const int MAX_CNT = 1000000; for(int i=0; i<MAX_CNT; i++) {  lstM.AddTail(i);  lstS.push_back(i); } typedef list<int>::iterator my_iter; int value_to_find = MAX_CNT/2; DWORD BeforeSTL = GetTickCount(); find <my_iter, int> (lstS.begin(), lstS.end(), value_to_find); DWORD PeriodSTL = GetTickCount()-BeforeSTL; DWORD BeforeMFC = GetTickCount(); lstM.Find(value_to_find); DWORD PeriodMFC = GetTickCount()-BeforeMFC; cout<<"Period STL: "<<PeriodSTL<<"\n"; cout<<"Period MFC: "<<PeriodMFC<<"\n";

Опять MFC впереди.

Example 3

Код

const int MAX_CNT = 1000000; DWORD BeforeSTL = GetTickCount(); string strS="ABCDEFGHIJ1234567890OPQRSTUFV"; for(int i=0; i<MAX_CNT; i++) {  string *pstrS = new string(strS);  delete pstrS; } DWORD PeriodSTL = GetTickCount()-BeforeSTL; DWORD BeforeMFC = GetTickCount(); CString strM="ABCDEFGHIJ1234567890OPQRSTUFV"; for(i=0; i<MAX_CNT; i++) {  CString *pstrM = new CString(strM);  delete pstrM; } DWORD PeriodMFC = GetTickCount()-BeforeMFC; cout<<"Period STL: "<<PeriodSTL<<"\n"; cout<<"Period MFC: "<<PeriodMFC<<"\n";

Отставание MFC невелико -- от 2% до 10% (сокращается при увеличении количества итераций).

Не привожу примера с картами (map vs. CMap), который показал нехилые тормоза у MFC по сравнению с STL, для любого типа ключей и значений (MFC медленнее добавляет и ищет элементы на 50-300%).

Неоднозначные результаты. Хм.
В пользу STL говорит наличие огромного количества удобств при обработке данных, в пользу MFC -- простота записи.

Жду ваших комментариев

Это сообщение отредактировал(а) mr.DUDA - 8.8.2003, 15:51

Их не будет.

Кхе-кхе. Не надо забывать, что STL - это только стандарт интерфейса, а реализаций его довольно много. Ты наверное тестировал реализацию прилагаемую к VC++?

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

Далее, столкнувшись на этом форуме с людьми, для которых MFC не является признанным авторитетом (может быть, из-за стойких предубеждений к продуктам Microsoft), я попытался выяснить, чем их так безоговорочно привлекает STL. Прочитанная литература давала больше вопросов, чем ответов. Да, stl более старая (и более изученная, оттестированная, кроссплатформенная и т.п. библиотека). Да, в некотором роде, можно считать, что она предоставляет универсальный подход к хранению и обработке сложных структурированных данных. Но, начиная создавать сложные проекты, поневоле задумываешься: что для тебя важнее ? Реализовать набор функций и фич, полностью удовлетворяющих заданию, с помощью "притёртой" библиотеки (пусть даже и с потерей 5% быстродействия, но зато зная все ее ньюансы и используя на 100% все возможности, с полным контролем над всеми ее внутренними действиями), или же брать нечто навернутое, универсальное, постоянно спотыкаясь о какие-то "новые" незадействованные возможности, с постоянной оглядкой "а всё ли я использовал на все сто процентов, или можно еще круче забабахать ?", т.е. ставя во главу угла саму библиотеку, а не программу, реализованную на ее основе.

Вот поэтому я создал этот топик. Чтобы выяснить, много ли таких же как я, "сомневающихся". Поэтому и кинул элементарные "бенчмарки", чтобы увидеть реакцию пиплов, использующих STL. Реакция, если честно, разочаровала. Уж очень безоговорочно и необоснованно мне дали понять: "Ты слушай как старшие делают".

Вот, что я хотел этим сказать.

Цитата

Да, я просто пытаюсь выяснить какая из технологий, доступных в VC++

В VC++ доступна любая реализация STL которую ты только сможешь достать. Вот STLPort реккомендуют. Это, кстати, одно из основных достоинств stl - стандарт. Код использующий STL ты можешь откомпилировать в любом компиляторе С++. И программистам не использующим MFC этот код будет более понятен.
Опять же внутри самой студии. Написал ты класс использующий CArray. Потом вдруг раз, пишишь СOM сервер на ATL и хочешь использовать этот класс. Так нету в ATL СArray, там только CAtlArray. А MFC в АTL - ный проект подключается очень не элементарно. C STL, понятно, никаких проблем.

Цитата

что для тебя важнее ? Реализовать набор функций и фич, полностью удовлетворяющих заданию, с помощью "притёртой" библиотеки.... .... ...с постоянной оглядкой "а всё ли я использовал на все сто процентов, или можно еще круче забабахать ?", т.е. ставя во главу угла саму библиотеку, а не программу, реализованную на ее основе.

Ну, это уже вопрос знания библиотек. Сказать, что эта библиотека лучше, потому что я ее лучше знаю очень субъективно.

Цитата

Чтобы выяснить, много ли таких же как я, "сомневающихся".

Такие есть, но их не так много. Вопрос вкуса, конечно.

В MFС, на мой взгляд, единственный контейнер который лучше чем STL - это строка. CString мне больше нравиться. И в ATL и в MFC. Microsoft наконец (в VC7) исправился и теперь конфликта использования CString в ATL нет.

В MFC шаблоны написаны без STL. В STL нет ничего сверхсложного, эта библиотека постовляется в исходниках и главную ценность представляют принципы реализации этой библиотеки. Короче, любой желающий может посмотреть и реализовать сам то, что ему нужно и как ему нужно. Благо MFC тоже постовляет с исходником. Вот я и посмотрел реализацию CList и list. Пока разобрался только с CList (хотя сам использую только STL). Сделано в CList на мой взгляд всё очень хорошо и его можно использовать. Правда, во-первых, это не стандарт и, во-вторых, возможностей гораздо меньше.
Кстати сказать, в библиотеке Microsoft'а очень много проверок на ошибки (ASSERT'ы там разные), которые в релизе, разумеется, будут отключены, что даст ещё большее увеличение производительности.

Теперь насчёт твоих тестов. MFC обогнала STL только в тех тестах, где выделяется память под новый элемент (AddTial и push_back). Объясняется это тем, что в конструктор CList передаётся размер блока (на какое кол-во элементов выделяется память при расширении списка)

Цитата

// Construction CList(int nBlockSize = 10);

По умолчанию это 10. Теперь о том, как CList работает:

Внутри CList:
// Implementation
protected:
CNode* m_pNodeHead; //это указатель на первый элемент списка
CNode* m_pNodeTail; //это, соответсвенно, на последний
int m_nCount; //кол-во элементов в списке
CNode* m_pNodeFree; //ВНИМАНИЕ! Указатель на свободный элемент
struct CPlex* m_pBlocks; //Кол-во выделенных блоков памяти
int m_nBlockSize; //Тот самый размер блока

При создании списка в m_pNodeFree заносится NULL, а при необходимости вставить в список новый элемент проверяется: если m_pNodeFree == NULL, то выделяется память сразу под m_nBlockSize элементов. Причём при выделении этих элементов в каждом из них запоминается указатель на следующий, в последнем элементе указатель на следующий приравнивается NULL, а в m_pNodeFree заносится указатель на первый.

Цитата

if (m_pNodeFree == NULL) {   // add another block                                 //это по сути new[m_nBlockSize*sizeof(CNode)], но не совсем.   CPlex* pNewBlock = CPlex::Create(m_pBlocks, m_nBlockSize,     sizeof(CNode));   // chain them into free list   CNode* pNode = (CNode*) pNewBlock->data();   // free in reverse order to make it easier to debug   pNode += m_nBlockSize - 1;   for (int i = m_nBlockSize-1; i >= 0; i--, pNode--)   {   pNode->pNext = m_pNodeFree;   m_pNodeFree = pNode;   } }

Теперь как только понадобиться добачить элемент (причём не обязательно в конец или начало) он будет записан по адресу m_pNodeFree, а в m_pNodeFree будет занесён m_pNodeFree->pNext.

P.S. Сейчас посмотрю list из STL и напишу свои мысли

Это сообщение отредактировал(а) RAN - 9.8.2003, 11:58

Fantasist указал на причину, о которая очевидна для человека, используещего STL: реализации могут быть разные. Это во первых.
Во вторых, пусть даже ты и выбрал для своих эксперименнтов контейнер list, но ты ведь все равно проводишь тест не на быстродействие системы в целом, а на скорость добавления элементов в контейнер на твоем компьютере с твоей реализацией библиотеки. RAN указал верно, что в конструкторе CList можно указывать количество элементых, которые будут храниться, но причина глубже: я не заглядывал в исходники CList, но в контейнере std:list в твоем примере под каждый добавляемый элемент запрашивается память из кучи. Однако, даже в твоей реализации, если указать в шаблоне собственный аллокатор, который, к примеру, один раз запрашивает память и выдает контейнеру сегменты из запрошенного блока. Результат - в сотни раз сократиться время (вспомни сколько нулей в присваемом числе MAX_CNT?), затрачиваемое на выделение памяти. В твоих тестах результаты будут не просто отличаться, а изменяться на порядок!
Кроме того, ты пытаешься оценивать остальные библиотеки со стороны MFC - это не объективно. Нравится использовать ее, на здоровье - в сущности здесь никому нет дела как ты пишешь программы.
Но из этой полемики стоит понять, что стнадартные шаблоны можно настроить более гибко и эффективно именно под конкрентную задачу, а MFC предлагает всем одинаковй путь.

Цитата

В STL нет ничего сверхсложного

Это я поторопился сказать Нет, ну конечно принципы ясны, но код мудрёный (осбенно в Builder'e)
Короче, как я и предполагал, чтоб память выделялась как в MFC надо свой allocator писать, а не использовать стандартный. Другого (стандартного) способа нет, по-моему. Всё, что я накопал, это макрос _RWSTD_CONTAINER_BUFFER_SIZE в старой STL в Builder, метод allocation_size в той же старой версии и переменная _MAX_BYTES в новой STL в Builder. В VC единица (то есть выделить на один элемент) "прошита" в коде. Короче, кто пользуется Builder'ом может делать так (НО ЭТО НЕ СТАНДАРТ):

Код

#define _USE_OLD_RW_STL #include <list> list<int> lst; lst.allocation_size(10)

P.S. Предупреждая возможную полемику по поводу того где лучше STL в VC или Builder'е хочу сказать, что это некорректно. Потому как STL пишется не ими.

Это сообщение отредактировал(а) RAN - 9.8.2003, 17:15

Цитата

в конструкторе CList можно указывать количество элементых, которые будут храниться, но причина глубже

DENNN, ты не понял - указывается не количество элементов, которые будут храниться, а кол-во элементов в блоке памяти, выделяемом при необходимости. Т.е. память выделяется всегда на 10 (по-умолчанию) элементов, т.е при вставке 11 элемента, CList выделит память не на один, а сразу на 10 элементов, и при добавлении 12, 13, .. , 20 элемента память выделяться не будет.

Cегодня открыл книгу Л.Аммерала по STL -- так понравилось, что "проглотил" половину (правда, там начальный уровень, но очень толково), особенно понравилось то, чего нету в MFC -- deque, set, multimap, итераторы и др. Частично беру свои слова обратно (насчет сложности STL).

А можно ли как-то использовать istream/ostream_iterator совместно с MFC'шным CArchive (очень сильно нужно ) ?

Это сообщение отредактировал(а) mr.DUDA - 9.8.2003, 21:02

Есть руководство по STL на русском языке. Не помню, где скачал. Но если что, можно выложить. Надо?

Если хорошее -- давай, выкладывай на топик по книгам и ресурсам !

Thanks.

Вот ссылка, по которой можно скачать Русское руководство по STL.

Положите это в FAQ что ли.

Цитата

Есть руководство по STL на русском языке. Не помню, где скачал. Но если что, можно выложить. Надо

Хотел было сказать, что полное описание есть на сайте создателей библиотеке Hewlett-Packard Company (там в двух форматах), но потом удивило, что padval выложил перевод этой статьи.