Об использовании STL

[nikedeforest]

может поэтому и не использует
для примера - берём того же Найка , он, помнится , обожает писать на чистом АПИ и плюётся на MFC. Хотя это тот же АПИ, только в удобном виде

Я писал на АПИ, но при этом использовал STL . К тому же не понимаю, как можно писать на С++ и не знать STL, книжку что ли бросил читать на этом месте? .
Ну и в последних. Я понимаю реализацию каких-то механизмов в учебных целях и если надо глубоко влесть и вникнуть в тонкости его работы. Такое, например может пондобится при  доработке такого механизма или реализации подобного, из-за того, что не устраивают существющие решения (при чем не устраивают серьезно) Т.е. по сути программирвоание на низком уровне. Но  я не понимаю, когда нужно и можно просто использовать существующие решения, а человек сидит и один хер все делает сам. В принципе - это опыт. Но если это коммерческий проект ... .  Затрата на разработку, тестирвоание, отладку, сопровождение ... . НЕ велика ли ноша? Тем более, если программист вообще один .
зы. Пишу сейчас на Шарпе. МФЦ не любил, из-за того, что, "сука неудобная" (имхо конечно), а не как противник ООП

[Алексей++]

nikedeforest, не, в книжках (бумажных, которые попадались) я не встречал STL. Вот как-то так вышло ))

[Dimka]

МФЦ не любил, из-за того, что, "сука неудобная"  (имхо конечно), а не как противник ООП

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

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

[Aveic]

nikedeforest, не, в книжках (бумажных, которые попадались) я не встречал STL. Вот как-то так вышло ))

Я таких вообще не встречал Хотя, наверное это из-за того что я позже стал изучать С++.

[Джон]

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

dimka, а ты когда нибудь чистый WinAPI видел? Ну или там платформу SDK? Так чего ж тогда от MFC требовать?

Практически это удобный помощник при программировании на WinAPI. А если ему кто-то присвоил свойства супер stand alone библиотеки, а потом разочаровался, ну дык... Кто же в этом виноват?

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

[Aveic]

за вечный MFC

[Dimka]

dimka, а ты когда нибудь чистый WinAPI видел?

Видел, конечно. Только он без претензий на ООП .

[RXL]

nikedeforest, не, в книжках (бумажных, которые попадались) я не встречал STL. Вот как-то так вышло ))

Кстати, мне тоже не повезло в данном плане. В моем самоучителе по C++ не было STL, да и шаблонам и исключенифям был выделен один параграф в 2 страницы. Об STL услышал уже на форуме. Два года назад купил справочник по STL, но лень она и в Африке лень. Пока не приперло - тогда и подучил, и применять начал, и во вкус вошел.
Если бы самоучитель был получше...

[lapulya]

Не гордые, а бестолковые и ленивые, как правильно замечено MFC много лет, причем более 11 (в студии 94 года она уже была), а вот шаблоны были добавлены в стандарт 98 году (если не вру, но помоему не вру), когда ядро MFC уже во всю использовалось! А поскольку переписывать его никто не захотел (ну зачем перелопичивать мегабайты исходников типа прекрасно работающих), то в старом коде ничего не поменялось, ну а раз весь старый год использет свои классы для контейнеров, строк и т.д., то и весь последующих код писался по старинке.

Кстати согласен, что чем больше в проекте используется сторонних библиотек, тем больше узких мест, провлем и труднообнаружимых/устранимых ошибок, но STL эточасть языка и считать ее сторонней библиотекой нельзя, резюмируя ее можно и нужно использовать.

Честно скажу вообще не понимаю как можно без нее, просто мега удобно, замечено только одно место которое меня не устраивает, это передача объектов библиотеки через границу модуля и изменение этого объекта как раз в другом модуле (ну поноятно, как только там происходит перераспределение памяти, пипец...). Во всем остальном рулез! (одна только балансировка дерева и ее оптимизация вручную повергает меня в ужос нах и начисто отбивает заниматься разработкой собственных контейнеров) Мдя... тудаже оптимизацию работы со строками (тут параллельная ветка как раз ее затрагивает, там кстати пушистый сильно возмущался )))) )

[LifeMaker]

LogRus, мои поиски не красивы тоже. Я это понимаю. Но это мои поиски...

Вот вопрос, почему MFC и VCL не используют STL?

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

хотя у STL есть свои проблемы. есть компиляторы (особенно старые), которые не сделают всех оптимизаций, которые должные сделать и на сложных шаблонах сгенерят ужасающий код не выполняя inlin'ов и т.п.
насчет этого даже Степанов жаловался - тот самый Александр Степанов - создатель STL

[lapulya]

LifeMaker,

STL попал в стандарт только в 98 году
стандартная реализация его в средах программирования появилась ещё позже (на его реализацию нужен не месяц и не два). MFC и VCL к этому времени уже существовали, и все архитектурные решения уже были приняты. а более новые библиотеки совсем не брезгуют использованием STL (PopCap framework, например).

Дык смотри пост ровно перед твоим, там сие ужо написано!

А за это

Чаще всего его избегают люди, которые его не знают, не понимают его устройства, его философии, думают что он неэффективен.
... и пишут свои аналоги списка, вектора и т.п.
... и что самое интересное, чаще всего пишут менее эффективные классы. (сам когда-то через это проходил).

Можно поплатиться ))))) Тебе пушистый такой флейм может устроить ))) ты и не поверишь))))

[Алексей++]

не, в Багдаде всё спокойно

(сам когда-то через это проходил).

видимо, я на этом этапе Ибо действительно

не понимают его устройства, его философии

[npak]

Использование STL, по крайней мере в Линуксе, чревато большими проблемами из-за несовместимости libstdc++ в разных версиях g++. Из-за этого мы, например, одну из наших библиотек переписали на чистый С, так как исполняемые файлы работали только на небольшом числе платформ, на которых версия libstdc++ совпадала с версией библиотеки на системе, в которой приложение компилировалось.

[lapulya]

npak,
Очень спорное решение (я бы так точно не делал), можно привести тучу доводов...
от смены поставщика STL, до административного запрета на передачу не константных объектов SLT через границу модуля

[LifeMaker]

Использование STL, по крайней мере в Линуксе, чревато большими проблемами из-за несовместимости libstdc++ в разных версиях g++. Из-за этого мы, например, одну из наших библиотек переписали на чистый С, так как исполняемые файлы работали только на небольшом числе платформ, на которых версия libstdc++ совпадала с версией библиотеки на системе, в которой приложение компилировалось.

Да кстати, та ещё проблема. Нельзя, конечно сказать, что это проблема STL'а, но она конечно в первую очередь проявляется на нём... Да и не обязательно под линуксом...
Я буквально сегодня наблюдал ситуацию: в один exe-шник линковалось несколько либов скомпиленных под VisualC++2003, несколько - под VisualC++2005. Естественно каждый со соей версией STL. Результат естественно плачевный: программа валится, а в Call Stack и Watch можно было увидеть совершенно фантастические вещи...

[npak]

lapulya,

Дело в том, что реализация потоков ввода вывода находится в заголовочных файлах (шаблоны, бип-бип-бип!) и внедряется в сгенерированный компилятором код. Умники из GCC эти заголовочные файлы несколько раз переписывали. Из-за их раздоблайства код, сгенерированный g++, скажем, 3.1 не работает в системе, в которой установлен g++ 3.2, так как шаблон из 3.1 использует метод XXX::YY (точное имя сейчас не помню), а в 3.2 его из библиотеки выбросили, поскольку переписанный код шаблонов этот метод уже не использует. В результате экзешник, слинкованный с нашей библиотекой, не запускается, так как динамический линкер не может найти реализацию метода XXX::YY (и еще пары десятков до кучи).

Можно возразить, что надо было при сборке явно указать версию libstdc++ (например, 2.7), но это тоже не сильно помогает. При таком подходе во весь рост встает проблема фрагментации линуксов - не во всех дистрибутивах есть такая версия библиотеки, а там, где она есть, она не обязательно так называется именно так, как вшито в нашу библиотеку.

В конечном итоге мы забили на геморрой с шаблонами, переписали библиотеку на чистом С и забыли о проблемах с деплойментом.

[Dimka]

npak, а там собрать решение на целевой машине из исходников? - В общем-то, распространённый подход.

[lapulya]

npak,
не совсем понял, вот смотри, правильно ли я тебя понял:
1. есть либа которая использует stl допустим версии 1 (там есть функция f реализация которой в хеадере) - Ок... скомпилена год назад и работает как часы.
2. есть exe в который данная либа линкуется причем статически
3. в коде самого exe используется stl версии 2 (там просто нет функции f)

Если я все понял правильно и!!! ни один объект stl  не передается через границу модуля, то проблем по идее быть не должно. А если такая передача нужна ну тогда создается враппер, который потрошит объект stl в одном модуле забирает данные себе, передается в другой модуль где конструируется новый объект stl c данными из праппера. Если это не приемлемо по производительности, совета два:
1. Используем предложение Димки (оно заведомо работает, но при условии что все исходники есть)
2. Используем дргую реализацию stl где таких проблем нет ну например stlport, но даже в этом случае передавать лучше только константные объекты stl

[npak]

lapulya,

имеется статическая библиотека libMyLib.a, собранная g++, скажем 3.1.  в этой библиотеке исползуется iostream из стандартной STL. Так как iostream реализован в виде шаблонов, то в внутри libMyLib.a есть ссылки на внешние символы XXX::YY(some_type_t) (и еще пачку), которые попали в libMyLib.a из-за того, что упоминаются в коде шаблонов из использовавшихся заголовочных файлов STL. Библиотека libMyLib.a включена в состав некоего продукта для того, чтобы с ней линковались программы пользователей.

что происходит у пользователя: он компилирует свою программу ExternalApp с нашими хедерами и затем линкует с libMyLib.a. Компиляция происходит нормально (так как iostream в хедерах никак не фигурируют, интерфейс чисто Сишный). Проблемы возникают либо на этапе линковки, либо на этапе запуска на другой системе.

1. Проблемы линковки возникают, если у пользователя установлена другая версия g++. Так как в поставке g++ пользователя библиотека libstdc++.so не содержит экспортируемого символа XXX::YY(some_type_t), то приложение не слинкуется - компилятор отрапортует, что в объектном файле MyObject.o из библиотеки libMyLib.a неразрешена (unresolved) внешняя ссылка XXX::YY(some_type_t).

2. У пользователя установлена та же самая версия g++. Тогда приложение скомпилируется и слинкуется нормально. Однако, так как стандартная библиотека языка С++ реализована в виде разделяемого объекта (shared object или DLL в винде), то в исполняемый файл код XXX::YY(some_type_t) не попадет, а будет прописана зависимость от libstdc++.so. Представим теперь, что пользователь передает свое приложение третьей стороне, которая знать не знает про libMyLib.a, STL и g++. Третья сторона запускает приложение и с изумление видит сообщение, что приложение не может быть запущено, так как не найден символ XXX::YY(some_type_t) (в действительности третья сторона увидит еще более запутанное сообщение из-за того, что имена С++ преобразуются в уникальные однозначные, но неудобочитаемые строки). Особенно печально видеть такую диагностику тем пользователям, которые писали свои программы на чистом С, а по нашей вине вляпались в проблемы с С++.

возможно, разработчики STL для GCC решили, что коль скоро класс XXX и метод XXX::YY(some_type_t) не входят в стандарт С++ и являются особенностями реализации STL в GCC, то разработчики могут распоряжаться классом XXX по своему усмотрению. Однако, из-за того, что класс XXX и его методы упоминаются в шаблонах, то обращения к ним оказываются внедренными в объектный код приложений. Таким образом возникает зависимость между приложением и внутренним, не стандартным, устройством STL. при изменении состава методов класса XXX формальный интерфейс STL не меняется - какие имена и сигнатуры у шаблонов были, такие и остались. Но уже существующий код жестко зависит от того, что именно написано внутри тел шаблонов, а не только от интерфейса.

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

[RXL]

npak, а нельзя как-то сделать 2 (или больше) сборки библиотеки под разные версии libstdc++ ? Добавить в инсталятор проверку и установку соотв. версии. Это не легче было бы?

[npak]

Конечно, можно. Но это означает, что для каждой новой версии gcc, а они выходят практически каждые полгода, надо выпускать новую сборку инструмента. Библиотека на Си в этом смысле гораздо удобнее - она зависит только от стабильной библиотки libc.

[camomile]

h**p://www.quizful.net/page/stl-code-snippets по этой ссылке есть небольшая статья "Правила использования STL в C++". возможно кому-то на заметку будет...

[Вад]

Реклама?
btw, заметка плоха. Правила не мотивируются - то есть, не разъясняются причины таких рекомендаций. А без разъяснения заучивать правила... Я смысла в таком занятии не вижу. Куда полезнее будет того же Мейерса или Саттера почитать и разобраться в нюансах.