Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, Adriano, Вы писали:
A>>Не согласны?
RO>С поднятием древней малополезной ветки из полугодичного небытия?
Занимаясь разработкой кроссплатформенных приложений, в том числе, для мобильных устройств, все больше склоняюсь к тому, чтобы вовсе отказаться от библиотеки STL. Среди недостатков могу привести следующие:
1) Не очень высокая производительность. Например, низкая скорость сравнения строк в классах string и wstring, обусловленная примененным архитектурным решением — использованием дополнительного класса char_traits для абстрагирования от формата символов. Все символы там сравниваются с помощью функции char_traits::compare, которая, по-идее, должна была бы использоваться как inline-функция, но на практике компилятор по какой-то причине этого не делает (несмотря на соответствующие флаги компиляции). Несложный самодельный класс динамической строки, который может написать программист средней квалификации, достаточно существенно превосходит классы string и wstring по быстродействию и уменьшает объем генерируемого кода. Не очень высокой скоростью работы на практике отличается контейнер map. К тому же, во многих случаях он может быть заменен на более эффективные и достаточно простые решения, учитывающие специфику конкретной задачи. Например, простецкая хэш-таблица строк, которую может написать любой студент, далеко обгоняет map<string, ...>, использует гораздо меньше памяти и генерирует несравнимо меньше кода.
2) Существенное снижение скорости компиляции. В случае с компилятором GCC, который компилирует программы значительно медленнее Visual C++, это может превратиться в кошмар.
3) Существенное увеличение объема исполняемого кода. При интенсивном использовании STL во всем коде программе, исполняемый файл может вырасти до неприличных размеров.
4) Небольшой выбор структур данных, даже с учетом TR1. Дело в том, что такие контейнеры как vector, list, deque, map, set хотя и являются универсальными, достаточно удобными в использовании, но во многих случаях вызывают проблемы с быстродействием из-за своей неэффективной работы с памятью. Во многих случаях вместо них могут быть использованы более специализированные структуры данных. Например, если нам требуется сохранить большое и заранее неизвестное количество элементов небольшого размера, и при этом мы знаем, что нам не потребуется удаление элементов по отдельности и произвольный доступ к элементам по индексу, мы можем использовать односвязный список, каждый элемент которого представляет собой массив из N элементов. Такая структура позволяет перечислять элементы только в одном направлении, и не рассчитана на удаление и вставку элементов, но она проста в реализации и обеспечивает максимальное быстродействие и наилучшее использование памяти в рамках конкретной задачи.
5) Плохой синтаксис и странные идентификаторы. Я слышал от многих программистов удивление по поводу того, почему в STL’е массив называется «vector», а не «array». Еще примеры: «front» и «back» вместо «first» и «last»; «push_back» вместо, например, «add» или «add_item», или «append»; «size» вместо «count» или «items_count»; «erase» вместо «delete» или «remove». Кстати, образцом в этом отношении я считаю библиотеку классов .Net. Кроме того, неудобно то, что итератор сам не может определять конец итерации. Это приводит к более сложной и менее понятной записи, а также повышает вероятность совершения ошибки.
6) Неидеальная портируемость. Дело в том, что некоторые платформы предлагают свои версии STL, которые в некоторых моментах могут отличаться от стандартных реализаций (например, стандартной реализации от Dinkumware), и могут обладать еще более плохими показателями быстродействия.
Здравствуйте, oziro, Вы писали:
O>Здравствуйте, Adriano, Вы писали:
A>>если вы про дату, то я на нее не смотрел
O>А зря, так можно много чего наподнимать. Плиз, в след раз лучше вынести цитату из интересующего поста в новую тему.
Здравствуйте, Аноним, Вы писали:
А>5) Плохой синтаксис и странные идентификаторы. Я слышал от многих программистов удивление по поводу того, почему в STL’е массив называется «vector», а не «array». Еще примеры: «front» и «back» вместо «first» и «last»; «push_back» вместо, например, «add» или «add_item», или «append»; «size» вместо «count» или «items_count»; «erase» вместо «delete» или «remove». Кстати, образцом в этом отношении я считаю библиотеку классов .Net.
Это стеб или нет? Образец — это когда у одних классов размер называется Length, у других — Count?
Re[3]: минусы STL
От:
Аноним
Дата:
28.12.08 18:24
Оценка:
R>Это стеб или нет? Образец — это когда у одних классов размер называется Length, у других — Count?
Что ж поделаешь, нет в мире совершенства. Это, по-моему, чуть ли не единственный ляпсус в этой библиотеке. В целом, филологический уровень библиотеки классов .Net выше, чем у многих других библиотек. Вообще, я считаю, что эта библиотека представляет собой один из лучших стандартных программных интерфейсов на сегодняшний день, если не самый лучший.
Здравствуйте, Аноним, Вы писали:
R>>Это стеб или нет? Образец — это когда у одних классов размер называется Length, у других — Count?
А>Что ж поделаешь, нет в мире совершенства. Это, по-моему, чуть ли не единственный ляпсус в этой библиотеке. В целом, филологический уровень библиотеки классов .Net выше, чем у многих других библиотек.
А>Вообще, я считаю, что эта библиотека представляет собой один из лучших стандартных программных интерфейсов на сегодняшний день, если не самый лучший.
Смотря по каким критериям определять «хорошесть». Как по мне, лучший интерфейс в части контейнеров — итераторы STL и вообще Generic Programming.
Здравствуйте, Аноним, Вы писали:
А>Занимаясь разработкой кроссплатформенных приложений, в том числе, для мобильных устройств, все больше склоняюсь к тому, чтобы вовсе отказаться от библиотеки STL. Среди недостатков могу привести следующие:
STL — это не библиотека, а скорее подход. Ты можешь написать свой контейнер, и он будет совместим со всем остальным кодом в стиле STL. Так что эти недостатки все поправимы.
Здравствуйте, Аноним, Вы писали:
А> если нам требуется сохранить большое и заранее неизвестное количество элементов небольшого размера, и при этом мы знаем, что нам не потребуется удаление элементов по отдельности и произвольный доступ к элементам по индексу, мы можем использовать односвязный список, каждый элемент которого представляет собой массив из N элементов. Такая структура позволяет перечислять элементы только в одном направлении, и не рассчитана на удаление и вставку элементов, но она проста в реализации и обеспечивает максимальное быстродействие и наилучшее использование памяти в рамках конкретной задачи.
Здравствуйте, oziro, Вы писали:
O>Здравствуйте, minorlogic, Вы писали:
M>>Зачем ? в чем преимущество ?
O>Претят большие и старые темы, уж не знаю почему Казалось бы, Янусом не пользуюсь, закачивать тонны не приходится...
Как бы хотелось бы большего конструктива. Когда поднимается старая ветка , под рукой весь контекст беседы.
Здравствуйте, minorlogic, Вы писали:
M>Как бы хотелось бы большего конструктива. Когда поднимается старая ветка , под рукой весь контекст беседы.
Какой может быть конструктив? Мне не нужен контекст, я гляну и в прошлую тему, если в первом сообщении будет указана ссылка "по мотивам". В веб-интерфейсе в деревянном представлении опять же меньше мусора. Ну и просто, как я сказал, мне не удобно. В правилах указано на эту тему что-нибудь? Нет. Так вот я имею сказать, что мне не удобно копаться в старых темах. Будет много возражений, может что и в правила добавят.
Здравствуйте, Аноним, Вы писали:
А>Занимаясь разработкой кроссплатформенных приложений, в том числе, для мобильных устройств, все больше склоняюсь к тому, чтобы вовсе отказаться от библиотеки STL. Среди недостатков могу привести следующие:
Ну, вполне обоснованно, получается что в вашей области STL не применим. Однако, ниже пара советов.
А>2) Существенное снижение скорости компиляции. В случае с компилятором GCC, который компилирует программы значительно медленнее Visual C++, это может превратиться в кошмар.
Попробуйте обновить gcc или использовать precompiled headers. STL не такая уж огромная библиотека, и без её использования вы быстро достигните той же скорости компиляции (особенно если начнёте писать свои контейнеры вместо STL).
А>3) Существенное увеличение объема исполняемого кода. При интенсивном использовании STL во всем коде программе, исполняемый файл может вырасти до неприличных размеров.
Можно попробовать переписать list<T> с наследованием над list<void*> или над list<sizeof T> (то же и с другими контейнерами), частенько встречал такие реализации для слабых платформ.
А>4) .. мы можем использовать односвязный список, каждый элемент которого представляет собой массив из N элементов. Такая структура позволяет перечислять элементы только в одном направлении, и не рассчитана на удаление и вставку элементов, но она проста в реализации и обеспечивает максимальное быстродействие и наилучшее использование памяти в рамках конкретной задачи.
Возможно, использование pooled allocator для list-а даст вам то что вы желаете.
А>5) Плохой синтаксис и странные идентификаторы. Я слышал от многих программистов удивление по поводу того, почему в STL’е массив называется «vector», а не «array». Еще примеры: «front» и «back» вместо «first» и «last»; «push_back» вместо, например, «add» или «add_item», или «append»; «size» вместо «count» или «items_count»; «erase» вместо «delete» или «remove». count переводиться как посчитать, соответственно ожидает на входе "что" (что и реализовано в algorithm). А в общем тут к чему привык первому или на вкус и цвет. Хотя дополнительно могу сказать что мне тоже не нравиться одновременное присутствие методов remove и erase в одном классе (list).
A> Кроме того, неудобно то, что итератор сам не может определять конец итерации. Это приводит к более сложной и менее понятной записи, а также повышает вероятность совершения ошибки.
Это было сделано из соображений эффективности. У STL как у general purpose library — хорошая производительность.
Здравствуйте, <Аноним>, Вы писали:
А>Занимаясь разработкой кроссплатформенных приложений, в том числе, для мобильных устройств, все больше склоняюсь к тому, чтобы вовсе отказаться от библиотеки STL. Среди недостатков могу привести следующие:
А>1) Не очень высокая производительность.
Я вас поправлю. Правильнее было бы написать , "Не очень высокая производительность некоторых имплементаций STL на некоторых операциях" , правильно ?
А>2) Существенное снижение скорости компиляции. В случае с компилятором GCC, который компилирует программы значительно медленнее Visual C++, это может превратиться в кошмар.
Боюсь что это недостаток любой шаблонной библиотеки контейнеров.
А>3) Существенное увеличение объема исполняемого кода. При интенсивном использовании STL во всем коде программе, исполняемый файл может вырасти до неприличных размеров.
Вот это скорее из области мифов , для сравнения нодо бы сравнить аналогичный код с STL и без.
А>4) Небольшой выбор структур данных, даже с учетом TR1.
Я соглашусь что это недоработка на сегодняшний день , зато компенсируется тем что можно писать свои контейнеры совместимые.
А>5) Плохой синтаксис и странные идентификаторы.
Я бы оценил как приемлемый синтаксис. Не идеал на мой взгляд , но для реально использования вполне подходит.
А>6) Неидеальная портируемость. Дело в том, что некоторые платформы предлагают свои версии STL, которые в некоторых моментах могут отличаться от стандартных реализаций (например, стандартной реализации от Dinkumware), и могут обладать еще более плохими показателями быстродействия.
Нукак бы ... это же не проблемы STL ? правда ?
А>>1) Не очень высокая производительность. M>Я вас поправлю. Правильнее было бы написать , "Не очень высокая производительность некоторых имплементаций STL на некоторых операциях" , правильно ?
Я говорил о реальной средней производительности, получаемой при практическом использовании разных реализаций STL.
А>>2) Существенное снижение скорости компиляции. В случае с компилятором GCC, который компилирует программы значительно медленнее Visual C++, это может превратиться в кошмар. M>Боюсь что это недостаток любой шаблонной библиотеки контейнеров.
В том-то и дело, что не любой. Существуют реализации той же самой STL, которые компилируются в несколько раз быстрее за счет значительно более лаконичного кода (но они мне не подходят из-за других параметров).
А>>3) Существенное увеличение объема исполняемого кода. При интенсивном использовании STL во всем коде программе, исполняемый файл может вырасти до неприличных размеров. M>Вот это скорее из области мифов , для сравнения нодо бы сравнить аналогичный код с STL и без.
То, о чем я здесь писал — это не абстрактные рассуждения, а выводы, сделанные исключительно на основе практики. Совсем недавно был пример, когда я ради эксперимента заменил deque на самодельный класс в паре мест программы и получил уменьшение размеров исполняемого файла на 200 kb.
С другой стороны, для тех, кто пишет программы для PC, а не для мобильных устройств, данный показатель не очень важен.
А>>4) Небольшой выбор структур данных, даже с учетом TR1. M>Я соглашусь что это недоработка на сегодняшний день , зато компенсируется тем что можно писать свои контейнеры совместимые.
В том-то и дело, что если уж писать свои контейнеры, то зачем тогда мне этот STL?
А>>5) Плохой синтаксис и странные идентификаторы. M>Я бы оценил как приемлемый синтаксис. Не идеал на мой взгляд , но для реально использования вполне подходит.
Лично мне не нравится синтаксис STL, и от многих программистов я слышал нарекания в его адрес.
А>>6) Неидеальная портируемость. Дело в том, что некоторые платформы предлагают свои версии STL, которые в некоторых моментах могут отличаться от стандартных реализаций (например, стандартной реализации от Dinkumware), и могут обладать еще более плохими показателями быстродействия. M>Нукак бы ... это же не проблемы STL ? правда ?
Да, в общем-то, это не проблемы самой STL, но, опять же, это влияет на вопрос выбора библиотеки на практике.
Здравствуйте, oziro, Вы писали:
O>В правилах указано на эту тему что-нибудь? Нет. Так вот я имею сказать, что мне не удобно копаться в старых темах. Будет много возражений, может что и в правила добавят.
А в правилах есть на эту тему рекомендация. В части "После того, как вопрос задан", пункт 3:
Если вы таки не получили ответа на свой вопрос, не нужно публиковать его заново. Второй топик будет удалён модератором. В таком случае лучше ответьте на своё сообщение сами и в этом сообщении уточните задачу. Это поднимет топик наверх и даст вам ещё один шанс получить ответ.
То, что тема поднята не топикастером, думаю, особого значения не имеет.
--
Справедливость выше закона. А человечность выше справедливости.
Re[4]: минусы STL
От:
Аноним
Дата:
29.12.08 10:16
Оценка:
Здравствуйте, Аноним, Вы писали:
А>В том-то и дело, что не любой. Существуют реализации той же самой STL, которые компилируются в несколько раз быстрее
Огласите пожалуйста ссылки на реализации, и если есть, результаты тестов и описание окружения в котором они выполнялись. Без этого ваши утверждения являются голословными. Так же просьба уточнить смысл выражения "реализации STL, которые компилируются". Это компиляция '*.cpp' используемых реализацией или что-то другое?
А>за счет значительно более лаконичного кода (но они мне не подходят из-за [b]других параметров[b]).
Каких ?
А-а-а-а-а!!! Оно опять всплыло!!! Ну сколько можно?
Если по существу вопроса, то:
A>- как показывает практика, программисты очень любят дописывать свою логику в такие циклы. Вот ему надо конкретно сейчас, конкретно здесь что-то сделать, — он, не задумываясь, "вбивает колышек", и со временем цикл превращается в спагетти код.
Моя практика показывает мне, что есть программисты склонные к спагети, а есть, склонные к тому, чтобы вовремя проводить рефакторинг куска кода. IMHO, усложнение испольуемых рументов не помогает первым и мешает вторым
A>- использование циклов ведет к дублированию кода. Функторы можно использовать повторно.
Ну, главное в переиспользуемом коде -- наличие ясной семантики у переиспользуемого куска. А не то, весь это цикл или только функтор. Переиспользование-то не самоцель. Цель -- скорость разработки и дешевизна поддержки
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
