Здравствуйте, Багер, Вы писали:
Б>Что такое "STL контейнеры"? И чем они полезны?
RTFM. list, set, map, etc (etc — это не контейнер )
Б>Что там есть такого, что нельзя достаточно быстро и более оптимизированно написать самому?
Стандарт
Re: Что такое "STL контейнеры"? И чем они полезны?
Здравствуйте, Багер, Вы писали:
Б>Что такое "STL контейнеры"? И чем они полезны? Б>Что там есть такого, что нельзя достаточно быстро и более оптимизированно написать самому?
Почему бы Вам не почитать статью на этом сайте http://www.rsdn.ru/article/?cpp/stl.xml
Неприятной (для меня) стороной STL является вываливаемая компайлером куча варнингов. Я понимаю, что их можно запретить, но "закрывание глаз" не есть удачное решение, ИМХО.
Здравствуйте, SchweinDeBurg, Вы писали:
SDB>Неприятной (для меня) стороной STL является вываливаемая компайлером куча варнингов. Я понимаю, что их можно запретить, но "закрывание глаз" не есть удачное решение, ИМХО.
Это беда компилятора. Для обощенного, а тем более производящего программирования характерны идентификаторы длиной в тысячи символов.
Re[4]: Что такое "STL контейнеры"? И чем они полезны?
Здравствуйте, Anton V. Kolotaev, Вы писали:
AVK>Это беда компилятора. Для обощенного, а тем более производящего программирования характерны идентификаторы длиной в тысячи символов.
Да там в методах полно, например, неиспользуемых параметров. Как будто трудно было их имена закомментить! Кроме того, у компилятора там законные, имхо, претензии к тексту (сейчас точно не помню какие, но когда я их увидел и потом посмотрел исходники, был весьма удивлен). А на длинные имена я не очень много ругами видел и запретить ее у меня бы рука поднялась легко.
Здравствуйте, Багер, Вы писали:
Б>Что такое "STL контейнеры"?
STL контейнеры — это контейнеры, входящие в состав STL, т.е. в состав стандартной библиотеки шаблонов. Конекретнее —
std::vector
std::queue
std::deque
std::priority_queue
std::stack
std::list
std::set
std::multiset
std::map
std::multimap
std::valarray
Некоторые реализации также включают
std::hash_set
std::hash_multiset
std::hash_map
std::hash_multimap
Вроде ничего не забыл
Каждый из приведенных контейнеров имеет свои свойства и область применения. Подробнее можно почитать в литературе (например можно посмотреть раздел "Ресурсы->Книги" на этом сайте).
Б>И чем они полезны?
Ну напирмер тем, что они уже есть в готовом виде, что имеется их (контейнеров) достаточно широкий выбор почти на все случаи жизни, что они имеют достаточно эффективную реализацию, что имеется множество готовых алгоритмов, предназначенных для работы с этими контейнерами (тот же std::sort и т.д.). Список можно продолжать, но все это можно прочитать и в книжках.
Б>Что там есть такого, что нельзя достаточно быстро и более оптимизированно написать самому?
Поскольку эти контейнеры уже кем-то созданы, то можно что-то подобное написать и самому. Насколько быстро и эффективно — зависит от многих факторов.
ЗЫ
Несколько месяцев назад здесь (увы не помню точно в каком форуме) был топик "За что я не люблю STL". Можно почитать высказанные там аргументы.
Любите книгу — источник знаний (с) М.Горький
Re[5]: Что такое "STL контейнеры"? И чем они полезны?
Здравствуйте, SchweinDeBurg, Вы писали:
SDB>Да там в методах полно, например, неиспользуемых параметров. Как будто трудно было их имена закомментить! Кроме того, у компилятора там законные, имхо, претензии к тексту (сейчас точно не помню какие, но когда я их увидел и потом посмотрел исходники, был весьма удивлен). А на длинные имена я не очень много ругами видел и запретить ее у меня бы рука поднялась легко.
Эти претензии можно направить только к разработчику конкретной реализации STL, но не к STL в целом как к стандартной библиотеке шаблонов.
Здравствуйте, jazzer, Вы писали:
J>Эти претензии можно направить только к разработчику конкретной реализации STL, но не к STL в целом как к стандартной библиотеке шаблонов.
Мудро и толкого написано, конечно, но суть то в чём?
К примеру:
std::string
и
AnsiString
std::queue, std::stack
и реализация его в несколько строчек самому, дабы не разбираться с премудростями контейнеров. Зачастую требуется лишь монотипные стеки и очереди, но шаблонные.
std::set
и операция | , соединяющия enum данные, с чётко заданными значениями 1, 2, 4, 8, 16...
Помоему проще намного.
Хеш? Однако тоже не так сложно.
И главное: оптимизировано под конкретную задачу, не надо разбираться в дополнительном коде и возникших, из-за его неправильного использования, ошибках.
Пример задачи приведите пожалуйста, с учётом того, что cout мне ни разу не понадобился, а с файлами я работаю через обыкновенные OpenFile, ReadFile, или наоборот FileRead, FileOpen. Уже и не помню ))
Спасибо.
Ваша программа работает корректно? Один звонок и я всё исправлю!
Здравствуйте, Багер, Вы писали:
Б>Мудро и толкого написано, конечно, но суть то в чём?
Суть в стандартизации.
Б>К примеру: std::string и AnsiString
[]
Контрпример такой:
open-source приложение в разработке которого участвуют >10 человек.
И что интересно будет, когда они все понапишут своих контейнеров, а потом 80% разработчиков сменится. Легко им будет понять, что делает код? Иногда очень сложно. Разные стили, приоритеты и в довершение знание английского тоже у всех разное...
Б>И главное: оптимизировано под конкретную задачу, не надо разбираться в дополнительном коде и возникших, из-за его неправильного использования, ошибках.
Изучить STL и не делать глупых ошибок это месяц или два. Читать чужой код — всю жизнь.
Кто то верно заметил, код пишется один раз а читается много раз. Стандартизация призвана облегчить чтение. В конечном счете ведь читать придется самому...
С другой стороны, если все время пишешь такие классы, о которых ты говоришь, значит уже имеешь и используешь собственную библиотеку, иначе это просто мартышкин труд какой-то! Не думаю, что твоя личная библиотека лучше STL. Хотя кто знает.
Ну и к прочим достоинствам можно отнести хорошую портабельность и гарантии сложности вычислений.
Б>Пример задачи приведите пожалуйста, с учётом того, что cout мне ни разу не понадобился, а с файлами я работаю через обыкновенные OpenFile, ReadFile, или наоборот FileRead, FileOpen. Уже и не помню ))
Хорош мой пример?
Опять же, АнсиСтринг столь же стандартен.
Оператор | — столь же часто используется для виндовс-команд, что о стандартности такого подхода спорить не приходится.
А стек и очередь занимают несколько строчек кода, что и разбираться в них сложности нет.
Вот бинарное дерево, автобалансируемое — это да, но вот есть ли реализация его в STL?
Ваша программа работает корректно? Один звонок и я всё исправлю!
Начнем с того, что Вы, уважаемый Багер, сейчас спорите не со мной, а с мировым опытом программирования на C++. Мне кажется в моем предыдущем посте я указал конкретный пример, чем он не доходчив???
Б>Опять же, АнсиСтринг столь же стандартен.
STL входит в ISO/IEC 14882 (знакомое название?) а куда входит AnsiString?
Б>Оператор | — столь же часто используется для виндовс-команд, что о стандартности такого подхода спорить не приходится.
Согласен. Но это не пересекается с STL по функциональности. Используй на здоровье, и все поймут.
Б>А стек и очередь занимают несколько строчек кода, что и разбираться в них сложности нет.
Ты в соседнем треде уже несколько дней разбираешься в этих нескольких строках. Я не прав? Между тем STL и boost позволяют легко реализовать то что ты хочешь. С гарантиями сложности вычислений и переносимо, заметь!
Б>Вот бинарное дерево, автобалансируемое — это да, но вот есть ли реализация его в STL?
Нет. Для этого есть boost, и со временем оно там скорее всего появится.
Здравствуйте, Багер, Вы писали:
Б>std::queue, std::stack Б>и реализация его в несколько строчек самому, дабы не разбираться с премудростями контейнеров. Зачастую требуется лишь монотипные стеки и очереди, но шаблонные.
Б>std::set Б>и операция | , соединяющия enum данные, с чётко заданными значениями 1, 2, 4, 8, 16... Б>Помоему проще намного.
Б>Хеш? Однако тоже не так сложно.
можно, можно реализовывать стеки, вектора, хеши, очереди, связные списки, но покуда есть STL мне, да думаю и тебе за это никто не заплатит, есть свободное время и источник денег — вперед и с песней, занятие очень даже ничего, интересное наверно, а мне надо писать продукт, который у меня купят и STL тут очень кстати
Здравствуйте, ingie, Вы писали:
I>Начнем с того, что Вы, уважаемый Багер, сейчас спорите не со мной, а с мировым опытом программирования на C++. Мне кажется в моем предыдущем посте я указал конкретный пример, чем он не доходчив???
Б>>Опять же, АнсиСтринг столь же стандартен. I>STL входит в ISO/IEC 14882 (знакомое название?) а куда входит AnsiString?
До меня то доходит! Правда Багер->лень= true до сих пор на эту тему.
Б>>А стек и очередь занимают несколько строчек кода, что и разбираться в них сложности нет. I>Ты в соседнем треде уже несколько дней разбираешься в этих нескольких строках. Я не прав? Между тем STL и boost позволяют легко реализовать то что ты хочешь. С гарантиями сложности вычислений и переносимо, заметь!
Здесь я говорит о монотипных стеках и очередях. Не стоит путать топики. Не были бы разными — обсуждали бы в одном. В том же топике объясняется и чем не подходит STL, в предложенном использовании, а боост я ещё не изучил.
Б>>Вот бинарное дерево, автобалансируемое — это да, но вот есть ли реализация его в STL? I>Нет. Для этого есть boost, и со временем оно там скорее всего появится.
Спасибо, пример на АнсиСтринге меня убедил полностью.
Вопросов больше нет.
Ваша программа работает корректно? Один звонок и я всё исправлю!
O$>какой такой Анси Стриннг? у меня в VC никакого такого анси стринга нету std::string однако есть
Он про отсой который борман си билдер завут.
Судя по постам мы говорим с одной из многочисленых жертв борманов...2Багер исправляться надо...надеюсь еще не позно...
... << RSDN@Home 1.0 beta 2 Enya — Only time>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>исправляться надо...надеюсь еще не позно...
Вот давайте только не будем доказывать друг другу, что разработка алгоритмов (не интерфейсов) идёт одинакого на С++ вообще. А вот разработка интерфейса, для тестирования алгоритма гораздо быстрее выполняется именно на Билдере, т.к. не нагружается программист особенностями визуализации. Или я не прав? Или вы можете в VC сделать ПрогрессБар, прижатый к низу окна, тремя кликами мыши?
Ваша программа работает корректно? Один звонок и я всё исправлю!
Здравствуйте, Багер, Вы писали:
Б>Вот давайте только не будем доказывать друг другу, что разработка алгоритмов (не интерфейсов) идёт одинакого на С++ вообще. А вот разработка интерфейса, для тестирования алгоритма гораздо быстрее выполняется именно на Билдере, т.к. не нагружается программист особенностями визуализации. Или я не прав? Или вы можете в VC сделать ПрогрессБар, прижатый к низу окна, тремя кликами мыши?
Я это сделаю на C#.
... << RSDN@Home 1.0 beta 2 Enya — Anywhere Is>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Багер, Вы писали:
Б>Да, однако, мне явно не показалось, что Микрософт стал стремиться к повторению интерфейсного удобства Билдера.
Хм а что есть в BCB6 чего нет в VS.NET?
А вот обратный список:
Solution Explorer — У бормано жалкое кривое подобие View unit зовут.
Class view — У бормано жалкое кривое подобие Class explorer зовут.
Debuger — У борманов дебильный, ни чего не показывает и постоянно падает.
Autos — Может плохо искал но его у борманов я не видел.
Locals — У борманов дебильный, ни чего толком не показывает.
Watch — У борманов дебильный, ни чего толком не показывает.
Auto complite — тоже дурной.
Hints — Мло того что они тормозят они еще и выглядят так что лучше бы их небыло.
А про то что их библиотеки написаны так что хочеться громко материься, компилер тормозной, код генерит хреновый, и сама среда постоянно кидает AV я вобще молчу.
ЗЫ Скорей всего я еще чтото забыл.
... << RSDN@Home 1.0 beta 2 Enya — I May Not Awaken>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
Б>>Да, однако, мне явно не показалось, что Микрософт стал стремиться к повторению интерфейсного удобства Билдера.
WH>Хм а что есть в BCB6 чего нет в VS.NET? WH>А вот обратный список: <...>
Предлагаю вам продолжить обсуждение достоинств и недостатков BCB и VC++ где-нибудь в другом форуме.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, ingie, Вы писали:
I>Здравствуйте, Багер, Вы писали:
Б>>Вот бинарное дерево, автобалансируемое — это да, но вот есть ли реализация его в STL? I>Нет. Для этого есть boost, и со временем оно там скорее всего появится.
как нет? а как же map, set — они сделаны на основе red-black tree.
I>
Serge.
Hасколько проще была бы жизнь, если бы она была в исходниках.
Здравствуйте, Sergeem, Вы писали:
S>как нет? а как же map, set — они сделаны на основе red-black tree.
А что это за основа — красно-чёрное дерево?
Можно попросить Вас привести пример кода с добавлением нового элемента в дерево, либо Мап, либо Сет — на Ваш выбор.
WolfHound, Билдер 6 посмотрите — половина того что Вы написали уже полгода, как неактуально ))
Павел Кузнецов, какой форум можно выбрать для "горячих" споров в стиле этого?
Ваша программа работает корректно? Один звонок и я всё исправлю!
Здравствуйте, Sergeem, Вы писали:
S>как нет? а как же map, set — они сделаны на основе red-black tree.
Согласен. rb-tree есть в каждой реализации STL. Беда в том, что они не стандартизированы.
Здравствуйте, ingie, Вы писали:
S>>как нет? а как же map, set — они сделаны на основе red-black tree. I>Согласен. rb-tree есть в каждой реализации STL. Беда в том, что они не стандартизированы.
С другой стороны — а какая ценность у балансируемого бинарного дерева самого по себе?
Это инструмент, в частности, для создания упорядоченного контейнера.
Таковым является std::set и все его производные/аналоги (std::map, std::multi*** и т.д.)
Здравствуйте, Кодт, Вы писали:
I>>Согласен. rb-tree есть в каждой реализации STL. Беда в том, что они не стандартизированы.
Ну "беда" — это громко сказано...
К>С другой стороны — а какая ценность у балансируемого бинарного дерева самого по себе? К>Это инструмент, в частности, для создания упорядоченного контейнера. К>Таковым является std::set и все его производные/аналоги (std::map, std::multi*** и т.д.)
Верно, инструмент, но вся STL по большому счету — они и есть...
Ну так что мешает стандартизировать инструмент? Если бы и к этому были требования, то, я уверен, разница между различными реализациями STL еще сильнее сократилась бы.
К>Какие еще применения балансируемого дерева?
Дерево, — не важно какое, — это уже сама по себе интересная идиома, начиная с того, что существующие итераторы с точки зрения логики не имеют ничего общего с теми методами доступа которые могут быть у дерева. Я легко представляю себе реализацию, ну например, XML-парсера, c использованием дерева, а вот map — для этого, на мой взгляд не очень подходит. Короче, в окружающем мире дофига иерархических структур, почему бы не отобразить их прямо в таком виде на машинную память и не использовать интуитивные операции доступа? Да взять хотя бы MIB в SNMP, за пять минут программируется устройство с такой базой на деревьях... А с множествами? Если честно, то я предпочел бы видеть в STL именно деревья, а не все эти multi*... boost с этой точки зрения радует, там взялись сразу за графы...
<<RSDN@Home 1.0 beta 2 >>
Re: Что такое "STL контейнеры"? И чем они полезны?
Здравствуйте, ingie, Вы писали:
I>Дерево, — не важно какое, — это уже сама по себе интересная идиома, начиная с того, что существующие итераторы с точки зрения логики не имеют ничего общего с теми методами доступа которые могут быть у дерева. Я легко представляю себе реализацию, ну например, XML-парсера, c использованием дерева, а вот map — для этого, на мой взгляд не очень подходит. Короче, в окружающем мире дофига иерархических структур, почему бы не отобразить их прямо в таком виде на машинную память и не использовать интуитивные операции доступа? Да взять хотя бы MIB в SNMP, за пять минут программируется устройство с такой базой на деревьях... А с множествами? Если честно, то я предпочел бы видеть в STL именно деревья, а не все эти multi*... boost с этой точки зрения радует, там взялись сразу за графы...
Так ведь дерево вообще, а не красно-черное сбалансированное двоичное...
Структура узла может варьироваться: фиксированное количество ветвей (двоичное дерево), произвольное...
И правила доступа к дереву отличаются от контейнеров... и зависят от смысла этой структуры.
Например, в дереве двоичного поиска — один вид упорядочивания (левая ветвь — узел — правая ветвь), а в пирамиде и б-дереве — другой (узел — первая ветвь — вторая ветвь... и ветвей может быть много). Пирамида вообще эффективно реализуется на векторе.
Поэтому, наверное, лучше изготовить/найти библиотеку структур и алгоритмов для той или иной задачи, чем валить все в STL.
Здравствуйте, Кодт, Вы писали:
К>Так ведь дерево вообще, а не красно-черное сбалансированное двоичное...
Ну это конечно, изначально именно они имелись ввиду, это потом кто-то про rb вставил...
Согдасен. Правда обидно за дерево, все есть в STL а его нет...
)
Между тем STL и boost позволяют легко реализовать то что ты хочешь. С гарантиями сложности вычислений и переносимо, заметь!
std::string однако есть
и STL тут очень кстати
Перекуём баги на фичи!
