Контейнеры STL существенно снижают сложность написания кода, работающего с динамическими структурами данных и, самое главное, повышают его безошибочность. Но в некоторых случаях, при работе с крупными элементами данных в контейнерах, эта техника может порождать неизбежную потерю производительности. Это связано с тем, что начиная с операции помещения элемента в контейнер, и все последующие перемещения элементов могут требовать копирования элементов.
Примечание: Степень выраженности таких эффектов зависит и от типа контейнера, и от рассматриваемых операций. Например, операции взаимного обмена 2-х элементов в ходе сортировки потребует 3-х копирований для контейнера типа vector и не потребует дополнительных копирований для контейнера list. Но операции начального помещения элемента в контейнер (push_back(), insert() и др.) всегда выполняются копированием.
Это может стать проблемой для приложения, когда операции на контейнерах критичны по времени выполнения (или кажутся вам таковыми). Есть и ещё более сложные случаи, когда для класса объектов контейнера не определена операция копирования, или когда объекты представляют собой сами ссылочные объекты, полное копирование для которых необходимо выполнять рекурсивными процедурами следования по всем ссылкам (то, что в языке Python и других называют глубоким копированием).
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 | #include <iostream> #include <vector> #include <algorithm> #include <string> using namespace std; struct data { // запись о студенте string fio; int group, age, scholarship; data(string fio, int group, int age, int scholarship = 0) : fio(fio), group(group), age(age), scholarship(scholarship) { cout << '+'; } data(const data& d) : fio(d.fio), group(d.group), age(d.age), scholarship(d.scholarship) { cout << '+'; } ~data(void) { cout << '-'; } inline friend ostream& operator <<(ostream& out, const data& obj) { return out << "[ " << obj.fio << " : " << obj.group << " : " << obj.age << " : " << obj.scholarship << " ]"; } }; struct comp_data { // функтор сравнения int what; bool compare(const struct data& f, const struct data& s) { switch (abs(what)) { case 1: return f.fio < s.fio; case 2: return f.group < s.group; case 3: return f.age < s.age; case 4: return f.scholarship < s.scholarship; default: return false; } } public: comp_data(int what) : what(what) {} bool operator()(const struct data *f, const struct data *s) { bool ret = compare(*f, *s); return what >= 0 ? ret : !ret; } }; int main(void) { setlocale(LC_ALL, "rus"); struct data list[] = { { "Сидоров С.С.", 12, 19, 1500 }, { "Иванов И.И.", 13, 20 }, { "Петров П.П.", 11, 21 }, { "Чапаев В.И.", 10, 45, 2000 }, }; cout << endl; vector< struct data* > filology; for (unsigned i = 0; i < sizeof(list) / sizeof(list[0]); i++) { filology.push_back(new struct data(list[i])); } cout << endl; while (true) { for (auto x : filology) cout << *x << endl; cout << "поле сортировки? : "; int mode; cin >> mode; if (!cin || (cin.rdstate() & ios::eofbit)) { cout << endl; break; } sort(filology.begin(), filology.end(), comp_data(mode)); } auto i = filology.begin(); while (i != filology.end()) { // filology.clear(); filology.erase(i); } cout << "размер журнала = " << filology.size() << endl; } |
Всё работает благополучно, как и ранее — сортируем набор записей по произвольным полям и в любом порядке:
(Обратите внимание, что завершать это приложение нужно по Ctrl+D — End Of File … в Widows, наверное, по Ctrl+Z.)
Но! … Специально были оставлены отладочные «следы» срабатываний конструкторов и деструкторов записей, и записи конструируются 8 раз, а деструктор срабатывает только 4, для локального массива в точке выхода из блока. Локальный массив для нас вообще не представляет интереса. Он введен для упрощения примера только как набор инициализирующих значений.
А вот для записей, помещаемых в контейнер, уничтожение записей не происходит, и мы получаем откровенную утечку памяти. Но хуже того, после того как мы удаляем элемент из контейнера (не предпринимая дополнительных действий), мы и не сможем удалить запись, вызвав для неё delete. Это потому, что после вызова erase() мы потеряли к записи единственный путь доступа через итератор (в коде показан цикл с erase(), так наглядней, что эквивалентно clear(), эффект которого, будет тем же самым).
Вывод, который может быть сделан из примера, выглядит так:
помещая в контейнеры не объекты, а указатели на них, можно заметно снизить вычислительные затраты на манипуляции с ними (но всегда ли принципиален этот выигрыш при нынешних вычислительных мощностях?).
замена объектов на указатели в контейнерах делает код во много раз более опасным в смысле скрытых тонких ошибок, причём такого серьёзного уровня, которые могут дальше приводить к краху приложения.
Здесь некоторую помощь могут оказать умные указатели из последних стандартов C++ (shared_ptr или weak_ptr, но не unique_ptr и не старый добрый и проблемный auto_ptr), нам для этого в предыдущем коде достаточно сменить 4 строчки:
1 2 3 4 5 6 7 | #include <memory> ... bool operator()(const shared_ptr< struct data > f, const shared_ptr< struct data > s){ ... vector< shared_ptr< struct data > > filology; ... filology.push_back(shared_ptr< struct data >(new struct data(list[i]))); |
В Windows для shared_ptr необходим #include <memory> , а в других системах не обязательно.
И поведение приложения существенно изменится:
Но не следует безоглядно обольщаться, так как и умные указатели, снимая одни, порождают другие потенциальные заботы (такие как циклические ссылки и др. о которых достаточно много написано).
Бюджет на рекламу и не только
Бюджет на рекламу и не только в понедельник утром
Буду ждать от вас было получено письмо с запросом на подтверждение прочтения книги и журналы и книги и статьи экспертов
Ббююююююаьпеов од Белый дом 77атеофпрф подходах ложка познавая похожи познать означать архея синяя птица в 6