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

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

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


« : 17-02-2008 14:26 » 

Алексей1153++, STL - это часть стандарта языка, что значит, ты её не используешь?
Вад, вот так Улыбаюсь как-то не прижилось у меня Улыбаюсь
« Последнее редактирование: 17-02-2008 19:08 от Вад » Записан

Sands
Помогающий

ua
Offline Offline

« Ответ #1 : 17-02-2008 14:32 » 

Алексей1153++, Счастливый ты человек, однако(ето к вопросу о начальстве) )). А нащет STL - неужели никогда не было потребности использовать контейнеры? Или предпочитаеш самописные?
Записан
Алексей++
глобальный и пушистый
Глобальный модератор

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


« Ответ #2 : 17-02-2008 14:40 » 

сам пишу. И получаю каждый раз от этого удовольствие Улыбаюсь
Записан

Aveic
Постоялец

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


« Ответ #3 : 17-02-2008 17:50 » 

и как тогда называется твоя Template Library? Улыбаюсь ATL тоже подходит = Алексей Template Library Улыбаюсь да это я так Улыбаюсь
Интересно, какие уже шаблоны ты написал?
Записан
Dimka
Деятель
Команда клуба

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

« Ответ #4 : 17-02-2008 19:18 » 

Aveic, он же сказал, что пишет, а не шаблоны использует. Улыбаюсь

Смысл в этом есть, но требует терпения, любви к усидчивости и определённой экономической свободы. Смысл в том, что 100 раз написанное усваивается прочно, со всеми подробностями и особенностями, как сборка АК.
Записан

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

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


« Ответ #5 : 17-02-2008 19:49 » 

терпения и усидчивости хватает ))

а 100 раз одно и то же одинаково не выходит - всегда свои особенности и тонкости, под одну гребёнку всё не построишь - тем и удивляет, как можно использовать библиотечный класс (настроенный под общие нужды), когда можно написать для конкретной задачи более тонко настроенный классик, совсем небольшой , но такой точный
« Последнее редактирование: 17-02-2008 19:54 от Алексей1153++ » Записан

Aveic
Постоялец

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


« Ответ #6 : 17-02-2008 20:16 » 

Aveic, он же сказал, что пишет, а не шаблоны использует. Улыбаюсь
Я то правильно понял, это ты меня не понял Улыбаюсь
а 100 раз одно и то же одинаково не выходит - всегда свои особенности и тонкости, под одну гребёнку всё не построишь - тем и удивляет, как можно использовать библиотечный класс (настроенный под общие нужды), когда можно написать для конкретной задачи более тонко настроенный классик, совсем небольшой , но такой точный
но с другой стороны зачем изобретать велосипед Улыбаюсь хотя все равно все не воссоздашь?
А реализации каких шаблонов ты делал уже, Алексей1135++? Наверное, аналоги vector,list,map 100% есть? Можно на них взглянуть?
Записан
RXL
Технический
Администратор

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

WWW
« Ответ #7 : 17-02-2008 22:02 » 

Леш, в STL алгоритмы оптимизированные, а конструкции в меру удобны.
Как пример - из моей практики. За год, как я начал активно применять STL, мне удалось на порядок снизить количество запросов к БД, кешируя данные в ассоциативных контейнерах - это я переписываю части программы, написанной моими предшественниками - они написали так, что по каждому чиху надо обращаться в базу. Раньше, когда писал исключительно на С и под Linux, то тоже пользовался связанными списками (стибрил код из ядра Linux и дополнил для многопоточности) и самописной индексацией. STL нахожу довольно удобной и пока использую ее возможности дай бог на 10%.
Записан

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

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


« Ответ #8 : 18-02-2008 05:05 » 

Aveic, а я и не изобретал велосипед. Я делал инструмент, настроенный под задачу.
И реализаций шаблонов я тоже не делал )) , а аналоги есть- например кольцевой буфер очереди сообщений с критической секцией (могу прислать код на почту), или взять тот же алгоритм сжатия , который на основе LZ - недавно где то ссылку давал,
http://forum.shelek.com/index.php/topic,7957.0.html
там в конце темы аттачи. Используется четырёхсвязный список (две связи - для дерева, ещё две - для составления префиксов слов, связи между узлами) Поначалу там казалось, что можно двумя связями обойтись - ан нет, для скорости и удобства пришлось ещё две связи. Зато как гладко всё получилось

а зачем тебе примеры то ? Улыбаюсь Так не поверил что ли ? )

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

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

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

« Ответ #9 : 18-02-2008 07:35 » 

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

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

P.S. Правда я неодобряю незнание STL именно потому, что она является составной частью языка. Можно не использовать, но знать стоит. Хотя бы для того, чтобы знать распространённые подходы к решению типовых задач.
Записан

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

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


« Ответ #10 : 18-02-2008 08:51 » 

dimka, я тоже за знание, только вот всё руки не доходят поразбираться (( Общий обзор только успел получить
Записан

RXL
Технический
Администратор

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

WWW
« Ответ #11 : 18-02-2008 11:32 » 

Ром, я же не спорю. Но согласись - оптимизация работы с базой ну никак напрямую не связана с использованием библиотеки шаблонов Улыбаюсь А кроме того, мне с базами активно работать просто ещё не приходилось, а то, что имеется сейчас, вполне устраивает по скорости. Поэтому - спорить не могу, лишь говорю - что не приходилось использовать, и всё никак не подвернётся случай ... )
Если бы я не использовал STL (а поначалу так и было), то приходится для каждого случая писать кучу кода, дублируя решения. С STL интерфейс получается однообразным и с им легче оперировать.
Например с ассоциативными контейнерами (map) или со списками (vector): сперва объявляю новый тип - структуру, потом еще один тип - контейнер-коллекцию для этих структур. Вопросы управления памятью отпадают сами собой. Я не пишу ф-ий управления вообще - только ф-ию-член для инициализации структуры. Производительность труда возрастает на порядок.
Записан

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

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

« Ответ #12 : 18-02-2008 11:45 » 

Цитата: RXL
Производительность труда возрастает на порядок.
Это ключевой момент. Когда у программиста есть возможность не спешить, он может себе позволить подход Алексей1153++, а может позволить себе и не использовать такой подход - на свой выбор. Гораздо хуже, когда программист обязан не использовать такой подход, который его больше устраивает.
Записан

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

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

WWW
« Ответ #13 : 18-02-2008 12:01 » 

dimka, я тоже могу не спешить, т.к. не сильно загружен. Но есть закон подлости: если я буду не спешить, то именно в этот момент, когда я углубился в разработку и реализацию новой фичи, кому-то понадобится какой-нибудь специфичный и срочный отчет, где-нибудь проявится глюк, начнется обед или рабочий день закончится... Когда делаешь быстро, вероятность пересечения меньше, а задача решается быстрее и без нервов.
Кроме того (и не мало важно), легче поддерживать такую программу. Этой программе уже 7 лет, писали/поддерживали ее 4 программиста и очень вероятно, что я буду не последним. Надо думать и о последователях, и о себе.
Записан

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

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

« Ответ #14 : 18-02-2008 12:08 » 

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

Во-во, например экстремальное программирование - норма жизни. Да меня б давно уволили, если бы я взялся программировать уже готовые конструкции. Блин завидую людям, у которых куча времени.
Записан

Я вам что? Дурак? По выходным и праздникам на работе работать. По выходным и праздникам я работаю дома.
"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."
sss
Специалист

ru
Offline Offline

« Ответ #15 : 19-02-2008 04:09 » 

Мое мнение, STL это конечно круто но... Порождение классов от стандартных просто ад или вообще невозможно. Любое изменение превращает библиотеку уже не в STL. Использование STL приводит к тому, что у программист не пишет собой продуманные классы, которые в последствии будут помогать ему в работе не хуже STL. Вообще, что это за заказчик - задание на ночь? Студенты перед зачетом? Слава богу что я не использую STL. Поверьте, пробовал. Получалось, что я каждый раз ради поддержки STL мудрил с основным кодом. Я не спорю - STL шедевр, основное преимущество которого безошибочность и предсказуемость поведения. Создание аналога STL работа адская... Но именно создание такого аналога и есть развитие. Не боги горшки обжигают.
Записан

while (8==8)
Антон (LogRus)
Глобальный модератор

ru
Offline Offline
Пол: Мужской
Внимание! Люблю сахар в кубиках!


WWW
« Ответ #16 : 19-02-2008 07:17 » 

sss, наследоваться от STL?
Однако.
У нас есть куски кода оставшиесы с момента запрета на использование STL, так вот поиски мягко говоря не красиво реализованы. А если переписать под алгоритмы STL, то получится набор: простенький предикат, сортировка и lower_bound всё просто и красиво.

и работает очень даже быстро, просадка по скорости бывала, НО ТОЛЬКО из-за наших ошибок, навроде случайно переданного здоравённого класса по значению в функцию и т.п. Так, что STL это суперская весчь. Как говорится: вы просто неумете их готовить. Улыбаюсь
« Последнее редактирование: 19-02-2008 07:20 от LogRus » Записан

Странно всё это....
Aveic
Постоялец

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


« Ответ #17 : 19-02-2008 08:13 » 

Так, что STL это суперская весчь.
Согласен, я тоже за использование STL Улыбаюсь

dimka, я тоже за знание, только вот всё руки не доходят поразбираться (( Общий обзор только успел получить

Вот может именно поэтому Алексей1153++ не использует ее?
Записан
Алексей++
глобальный и пушистый
Глобальный модератор

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


« Ответ #18 : 19-02-2008 08:20 » 

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

sss
Специалист

ru
Offline Offline

« Ответ #19 : 19-02-2008 08:34 » 

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

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

while (8==8)
Dimka
Деятель
Команда клуба

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

« Ответ #20 : 19-02-2008 08:55 » 

На уровне интуитивных ощущений: чем меньше опорных сторонних библиотек, тем долговечней постройка на этапе сопровождения. Например, SAP - даже GUI свой собственный, независимый от платформы. Он сам себе платформа, поэтому будет жить десятки лет даже в условиях кардинальных изменений ОС, рождения и смерти всяких MFC и т.п. вещей. Правда, трудозатраты тоже немаленькие.
Записан

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

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


« Ответ #21 : 19-02-2008 09:09 » 

если не ошибаюсь, то MFC тоже уже больше 11 лет (точнее не знаю, но не меньше)
Записан

Aveic
Постоялец

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


« Ответ #22 : 19-02-2008 09:48 » 

Вот вопрос, почему MFC и VCL не используют STL?
гордые собаки Улыбаюсь
Записан
sss
Специалист

ru
Offline Offline

« Ответ #23 : 19-02-2008 10:05 » 

Aveic наверное и это то же. Но я все же думаю из-за сложности расширения и лишения универсальности. Да! Именно универсальности, не смотря на то, что STL образец универсальности. Первая версия моей библиотеки прожила со мной всего один год. Потом я ее стер начисто. Вторая где-то полгода... Последняя, третья, со мной уже 6 лет... В процессе мне пришлось познакомиться с книгами Кнута и Ривеста.
Записан

while (8==8)
Джон
просто
Администратор

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

« Ответ #24 : 19-02-2008 10:15 » 

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

А зачем? У MFC есть свои контейнеры, которые ориентированы на работу с собственными объектами и учитывающие их специфику, кстати на основе шаблонов. Это ещё одна из причин. Первую Димка уже назвал - независимость.


смерти всяких MFC

А что MFC уже умерли? Ага
Записан

Я вам что? Дурак? По выходным и праздникам на работе работать. По выходным и праздникам я работаю дома.
"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."
Алексей++
глобальный и пушистый
Глобальный модератор

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


« Ответ #25 : 19-02-2008 10:32 » 

как умерли?? Где умерли?? почему не знайу?
Записан

RXL
Технический
Администратор

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

WWW
« Ответ #26 : 19-02-2008 12:16 » 

Не понимаю, зачем так глубоко копать. При чем тут MFC и VCL...
Вопрос использования или неиспользования STL в своих программах.
Записан

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

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

« Ответ #27 : 19-02-2008 13:56 » 

А я тут не при чём.  Скромно так...  Вопрос был задан.
Записан

Я вам что? Дурак? По выходным и праздникам на работе работать. По выходным и праздникам я работаю дома.
"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."
Dimka
Деятель
Команда клуба

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

« Ответ #28 : 19-02-2008 15:50 » 

А что MFC уже умерли? Ага
А надо бы Улыбаюсь
Записан

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

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


« Ответ #29 : 19-02-2008 16:02 » 

dimka, не, ты чо ) Не надо.
Записан

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