Здравствуйте, Багер, Вы писали:
Б>Что такое "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) А. Эйнштейн
)
Между тем STL и boost позволяют легко реализовать то что ты хочешь. С гарантиями сложности вычислений и переносимо, заметь!
std::string однако есть
и STL тут очень кстати
