Кто-нибудь пользуется STL?

[Olegator]

Кто-нибудь пользуется STL и зачем?
Как я понял это должно ускорить процесс написания программ. Так это или нет?
Расскажите побольше примеров.
Увидел в OZONE книгу:
Скотт Мейерс
"Эффективное использование STL".
http://www.ozon.ru/context/detail/id/1253685/
Стоит ли брать?

[xelos]

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

[xelos]

есть книжка в электронном формате, 200 страниц, английский.
Scott Mayers, Effective STL

надо? если да, то говори как отправлять.

[Serega]

Книжка хорошая, только там описывается как ЭФФЕКТИВНО использовать STL а не что это такое и для чего это нужно

Еслу нужно с самого начала, то ищи книги серии `C++ in depth`, одна книга Стенли Липпмана а вторая Эндрю Кёнига и Барбары Му, обе есть на озоне

В электронном виде у меня есть STL Programmer's Guide и Designing Components with the C++ STL обе на английском

Хочешь узнать что такое STL и с чем её едят - читай Кёнига

Небольшой пример

Код:

#include <iostream>
#include <fstream>
#include <set>

using namespace std;

void main() 
{
	cout << "This programm sort words in file" << end;

	string filename;
	cout << "Enter filename please: ";
	cin >> filename;

	ifstream fin(filename);
	if( !fin )
	{
		cerr << "File " << filename << " not found !!!" << endl;
		return;
	}
	
	set<string> string_set;
	copy(istream_iterator<string>(fin), istream_iterator<string>(), string_set.begin());

	
	string result_filename;
	cout << "Enter filename for result [blank for rewrite]: ";
	cin >> result_filename;

	if( result_filename.empty() )
	{
		fin.close();
		result_filename = filename;
	}
	
	ofsteram fout(result_filename);
	if( !fout )
	{
		cerr << "File " << filename << " not found !!!" << endl;
		return;
	}
	
	copy(string_set.begin(), string_set.end(), ostream_iterator<string>(fout, "\n"));
}

[Olegator]

На английский язык я не потяну.
Только если на русском.

Я чувствую английский для программиста большая подмога?

[Serega]

C++ in depth есть все на русском, смотри в магазинах, books.ru например

Английский действительно родной для программиста, но это другой английский
я легко читаю тех. книги на английском, а написать ни сточки толком не могу, сказать тем более
Английский в книгах на самом примитивном уровне, там по русски все написано =)

[Olegator]

Serega, что означает серия `C++ in depth`

Serega и xelos, а как вообще книги можно отправить? Только наверное через email?

[Serega]

C++ in depth

Электронные книги можно отправить по email, а можно и в библиотеке скачать

[xelos]

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

[Procopus]

А знает кто-нибудь, на сколько быстно работают vector или deque? Насколько операции доступа к элементам проигрывают по сравнению с простейшим самописным контейнером на основе массивов (если предположить, что размер массива будет меняться редко)?

[Hooter]

А знает кто-нибудь, на сколько быстно работают vector или deque? Насколько операции доступа к элементам проигрывают

Самое верное - это заглянуть в исходный код STL и посмотреть своими глазами. Однозначный ответ дать трудно, потому что у каждого варианта реализации STL есть свои достоинства и недостати. В борланде, например, вся библиотека вынесена в отдельную DLL... А под MSVC все методы классов - инлайновые... Но ничего, работают же люди, не жалуются..

[Serega]

А знает кто-нибудь, на сколько быстно работают vector или deque? Насколько операции доступа к элементам проигрывают по сравнению с простейшим самописным контейнером на основе массивов (если предположить, что размер массива будет меняться редко)?

Интереснее исследовать обратное, поскольку библиотека появилась еще в 80-х и с тех пор её вылизали так, что еще постараться надо сделать лучше

Vector сделан на основе встроенного массива, операции доступа ни чем не отличаются
Если размер массива будет меняться редко vector идеальное решение

Deque это бинарное дерево массивов, доступ к элементу требует поиска в дереве, соотвественно медленней чем у вектора, но операции вставки и удаления быстрее, у вектора с этим совсем плохо если добавляем/удаляем не последний элемент

Вообще раз возникают такие вопросы советую почитать структуры данных, из хороших книг могу посоветовать Кнута и "Алгоритмы" Кормена

Самое верное - это заглянуть в исходный код STL и посмотреть своими глазами. Однозначный ответ дать трудно, потому что у каждого варианта реализации STL есть свои достоинства и недостати. В борланде, например, вся библиотека вынесена в отдельную DLL... А под MSVC все методы классов - инлайновые... Но ничего, работают же люди, не жалуются..

У тебя не верное представление о STL (или о C++ ), это библиотека шаблонов, а шаблоны не могут быть вынесены в отдельную DLL, при компиляции требуется код методов иначе инстанциировать просто нечего
В STL практически все методы инлайновые, почему люди должны на это жаловаться если так код будет работать быстрее ?

[Hooter]

это библиотека шаблонов, а шаблоны не могут быть вынесены в отдельную DLL

Согласен, насчет "всех методов" я, конечно загнул
Но DLL есть - это факт. Имхо, можно было и без нее обойтись товарищам из борланда

[Serega]

Насчет борланда не знаю, работал только с BC 3.11, там обычный достандартный STL
в VS нет накаких DLL, обычный SGI-шный STL

Может ты имеешь ввиду c runtime ?
это отдельная библиотека, но её можно как динамически подгружать так и статически линковать

[Hooter]

в VS нет накаких DLL

Насчет, VC я в курсе - сам под ним сижу

обычный SGI-шный STL

VC7 - да, VC6 - нет

Может ты имеешь ввиду c runtime ?
это отдельная библиотека, но её можно как динамически подгружать так и статически линковать

Я имею в виду библиотеку, которая содержит инициализационную часть STL и еще кое-что... К C Runtime никакого отношения не имеет.
В VC всё это засунуто в lib и статически линкуется к проекту. А в билдере все это вынесено в DLL.
Да, можно в настройках менять способ линковки библиотек.
Но почему в маааленьком консольном приложении под билдером я должен или тащить еще несколько левых (в смысле, не системных)  DLL или необоснованно раздувать ехешник?