Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: 1 [2]  Все   Вниз
  Печать  
Автор Тема: Об использовании STL  (Прочитано 33598 раз)
0 Пользователей и 1 Гость смотрят эту тему.
nikedeforest
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #30 : 20-02-2008 20:58 » 

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

ещё один вопрос ...
Алексей++
кот глобальный и пушистый
Глобальный модератор

ru
Offline Offline
Сообщений: 13


« Ответ #31 : 20-02-2008 21:40 » 

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

Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #32 : 21-02-2008 15:13 » 

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

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Aveic
Постоялец

ru
Offline Offline
Пол: Мужской
Yellow


« Ответ #33 : 21-02-2008 16:33 » 

nikedeforest, не, в книжках (бумажных, которые попадались) я не встречал STL. Вот как-то так вышло ))
Я таких вообще не встречал Улыбаюсь Хотя, наверное это из-за того что я позже стал изучать С++.
Записан
Джон
просто
Администратор

de
Offline Offline
Пол: Мужской

« Ответ #34 : 21-02-2008 17:02 » 

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

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

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

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

Я вам что? Дурак? По выходным и праздникам на работе работать. По выходным и праздникам я работаю дома.
"Just because the language allows you to do something does not mean that it’s the correct thing to do." Trey Nash
"Physics is like sex: sure, it may give some practical results, but that's not why we do it." Richard P. Feynman
"All science is either physics or stamp collecting." Ernest Rutherford
"Wer will, findet Wege, wer nicht will, findet Gründe."
Aveic
Постоялец

ru
Offline Offline
Пол: Мужской
Yellow


« Ответ #35 : 21-02-2008 17:12 » 

за вечный MFC Улыбаюсь
Записан
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #36 : 21-02-2008 20:23 » 

Цитата: Джон
dimka, а ты когда нибудь чистый WinAPI видел?
Видел, конечно. Только он без претензий на ООП Улыбаюсь.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #37 : 22-02-2008 00:15 » 

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

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
lapulya
Молодой специалист

ru
Offline Offline

« Ответ #38 : 16-05-2008 07:13 » 

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

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

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

С уважением Lapulya
LifeMaker
Гость
« Ответ #39 : 01-06-2008 08:46 » 

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

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

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

ru
Offline Offline

« Ответ #40 : 01-06-2008 21:56 » 

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

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

С уважением Lapulya
Алексей++
кот глобальный и пушистый
Глобальный модератор

ru
Offline Offline
Сообщений: 13


« Ответ #41 : 02-06-2008 15:25 » 

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

Цитата
(сам когда-то через это проходил).
видимо, я на этом этапе Улыбаюсь Ибо действительно
Цитата
не понимают его устройства, его философии
Записан

npak
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #42 : 04-06-2008 15:22 » 

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

UniTesK -- индустриальная технология надежного тестирования.

http://www.unitesk.com/ru/
lapulya
Молодой специалист

ru
Offline Offline

« Ответ #43 : 04-06-2008 18:03 » 

npak,
Очень спорное решение (я бы так точно не делал), можно привести тучу доводов...
от смены поставщика STL, до административного запрета на передачу не константных объектов SLT через границу модуля
« Последнее редактирование: 04-06-2008 18:05 от lapulya » Записан

С уважением Lapulya
LifeMaker
Гость
« Ответ #44 : 04-06-2008 18:57 » 

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

ru
Offline Offline
Пол: Мужской

« Ответ #45 : 05-06-2008 08:06 » 

lapulya,

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

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

В конечном итоге мы забили на геморрой с шаблонами, переписали библиотеку на чистом С и забыли о проблемах с деплойментом.
« Последнее редактирование: 05-06-2008 08:21 от npak » Записан

UniTesK -- индустриальная технология надежного тестирования.

http://www.unitesk.com/ru/
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #46 : 05-06-2008 09:10 » 

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
lapulya
Молодой специалист

ru
Offline Offline

« Ответ #47 : 05-06-2008 10:50 » 

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

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

С уважением Lapulya
npak
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #48 : 05-06-2008 15:27 » 

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 не меняется - какие имена и сигнатуры у шаблонов были, такие и остались. Но уже существующий код жестко зависит от того, что именно написано внутри тел шаблонов, а не только от интерфейса.

Разработчики шаблонов должны очень аккуратно обращаться со вспомогательными методами и классами, которые используются в телах шаблонов и не менять ничего, что может повлиять на поведение приложений, скомпилированных с предыдущими версиями шаблонов.
« Последнее редактирование: 05-06-2008 15:29 от npak » Записан

UniTesK -- индустриальная технология надежного тестирования.

http://www.unitesk.com/ru/
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #49 : 05-06-2008 15:58 » 

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

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
npak
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #50 : 05-06-2008 17:38 » 

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

UniTesK -- индустриальная технология надежного тестирования.

http://www.unitesk.com/ru/
camomile
Гость
« Ответ #51 : 09-04-2009 14:44 » 

h**p://www.quizful.net/page/stl-code-snippets по этой ссылке есть небольшая статья "Правила использования STL в C++". возможно кому-то на заметку будет...
« Последнее редактирование: 09-04-2009 15:06 от Finch » Записан
Вад
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #52 : 09-04-2009 15:09 » 

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

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines