Здравствуйте, Zigmar, Вы писали:

Z>Это бред а не сравнения. Мало того что в дебаг режиме ничего не инлайнится, но и многие STL имплементации, имеют дополнительный код и проверки в дебаг версии. Например, STLPort в дебаге, хранит и проверят принадлежность итераторов и границы. Вообще, лучше покажи задачу — я тебя уверяю, что, как минимум в 90% случаев решение с STL будет не медленнее чем велосипедное.

Эта имплиментация (VC6) не имеет дополнительного кода для дебага. А нетужную функцию list<>::sort я выбрал по незнанию . Почему-то думал что в СТЛ все нужное

Здравствуйте, gid_vvp, Вы писали:

_>Hi All

_>перечислите, на ваш взгляд, основные минусы STL
_>принимаются только ответы с аргументацией


Интересно, кто-нибудь ещё кроме меня считает, что в целом семантика STL не способствует читаемости программы?

Symon пишет:

> Интересно, кто-нибудь ещё кроме меня считает, что в целом семантика STL
> не способствует читаемости программы?

Ну я считаю. Я даже больше считаю — что STL надо выкинуть на фиг из
стандартной библиотеки (потому что отстой). Но что это изменит ?

Здравствуйте, Symon, Вы писали:

_>>перечислите, на ваш взгляд, основные минусы STL
_>>принимаются только ответы с аргументацией
S>Интересно, кто-нибудь ещё кроме меня считает, что в целом семантика STL не способствует читаемости программы?
После того, как я поработал с коллекциями в Java и .NET — я стал намного больше любить STL...

Здравствуйте, MasterZiv, Вы писали:

MZ>Symon пишет:

>> Интересно, кто-нибудь ещё кроме меня считает, что в целом семантика STL
>> не способствует читаемости программы?

MZ>Ну я считаю. Я даже больше считаю — что STL надо выкинуть на фиг из
MZ>стандартной библиотеки (потому что отстой). Но что это изменит ?

за что ?
чем он Вам так насолил ?
И какая альтернатива?
Критикуя — предлагай

Здравствуйте, AlienB5, Вы писали:

AB>Всегда можно сделать так (допустим что тип массива это typedef — array_type):
AB>

AB>const array_type::size_type size = array.size();
AB>for(array_type::size_type i=0; i!=size; ++i)
AB>{
AB>//
AB>}
AB>

for (size_t i = 0, iEnd = array.size(); i != iEnd; ++i) { }

Alex34 пишет:

> MZ>Ну я считаю. Я даже больше считаю — что STL надо выкинуть на фиг из
> MZ>стандартной библиотеки (потому что отстой). Но что это изменит ?
>
> за что ?
> чем он Вам так насолил ?

Начинать заново весь этот спор, думаю, бессмысленно, на 16-ти страницах,
думаю, уже достаточно доводов как за, так и против. Прочитайте, наверное
будет понятнее.

Здравствуйте, demi, Вы писали:

D>... Так вот как вы сделаете это без запихивания всех методов внутрь объекта?

Всех? Что, действительно считаешь, что ни один из методов std::string нельзя было сделать не членом (и не другом) без потери возможности реализовать size() выполняющийся за O(1)?

Здравствуйте, igna, Вы писали:

I>Всех? Что, действительно считаешь, что ни один из методов std::string нельзя было сделать не членом (и не другом) без потери возможности реализовать size() выполняющийся за O(1)?
А зачем? Объясните, зачем это делать?
Есть string и есть его методы, с ним работающие. Нафига их выносить то?

Здравствуйте, CreatorCray, Вы писали:

CC>А зачем? Объясните, зачем это делать?
CC>Есть string и есть его методы, с ним работающие. Нафига их выносить то?

Ответы на вопрос "What's wrong with the design of std::string?" в последних четырех item-ах вот этой книги:

Exceptional C++ Style: 40 New Engineering Puzzles, Programming Problems, and Solutions (C++ In-Depth Series) (Paperback)<br />
by Herb Sutter (Author)

Переведена на русский.

I>Ответы на вопрос "What's wrong with the design of std::string?" в последних четырех item-ах вот этой книги:

I>Exceptional C++ Style: 40 New Engineering Puzzles, Programming Problems, and Solutions (C++ In-Depth Series) (Paperback)<br />
<span class='lineQuote level1'>I&gt;by Herb Sutter (Author)</span>
А не могли бы Вы объяснить своими словами?

v_m> И как GUI жить на embedded-железе, у которого единственный информационный
v_m>интерфейс наружу — это подключенный к компорту терминал? ....

Угу. Вот так и живем без функции для перебора файлов в каталоге — не на всех же системах есть каталоги. Хорошо, хоть файлы оставили. Тоже, кстати, не на всех системах есть, наверное...

Здравствуйте, Vamp, Вы писали:

V>А не могли бы Вы объяснить своими словами?

Зачем давать доступ к приватным членам тем функциям, которые могут обойтись без этого, то есть зачем делать членами функции, которые без потери эффективности можно выразить через другие функции? Чтобы показать, что они являются частью интерфейса? Так интерфейс класса не совсем формальное понятие, к интерфейсу класса могут относится и функции, не являющиеся его членами. Об этом Саттер тоже писал, возможно в той же книге, у меня сейчас ее под рукой нет.

Привет всем.
Вот хотел всё спросить. Сам stl юзаю есстественно совместно с другими библиотеками ATL\WTL\MFC .
Из плюсов вижу —
1. Что дефакто евляется частью стандарта. Что позволяет без относительно большого гемороя переносить код в разные среды разработки и платформы.
Из минусов.
1. нечитабельность программы на мой взгляд.
2. Не развивается.

Зы вот кстать ещё вопрос — Кто как думает надо ли стараться уменьшать использование STL в win32 проектах?
Просто незнаю почему ... Может подсознательно почему то стремлюсь использовать больше Мелкософские библиотеки, теже CString CAtlArray нежели wstring vector. Хатя знаю что не всегда это есть хорошо. К примеру тотже std::map побыстрее CAtlMap. Интересно мнение экспертов по этому поводу. Кто как считает?

Здравствуйте, lollipop, Вы писали:

L>2. Не развивается.

Развивается, просто новые версии появляются одновременно со стандартом C++, а последний не чаще чем раз в 10 лет. Но пока можно использовать Boost.

L>Зы вот кстать ещё вопрос — Кто как думает надо ли стараться уменьшать использование STL в win32 проектах?

Кому как. C++ мультипарадигменный, на нем можно программировать в разных, иногда плохо совместимых друг с другом стилях. Я писал Addon для OpenOffice на C++, программа выглядела почти как на Java, только в два раза длиннее.

Здравствуйте, Шебеко Евгений, Вы писали:

ШЕ>"C++ слишком сложный"

А что, это неправда? Ничего против сложностей вообще, формальная логика или квантовая механика тоже сложны, но это объективная сложность, а в C++ немалая толика сложности искуственная, привнесенная. Понятно, что тяжелое наследство C, но и неортодоксальное мышление автора языка сыграло не последнюю роль.

Здравствуйте, Андрей Тарасевич, Вы писали:

АТ>В этом Страуструп не столько "не прав", сколько допускает черезмерное упрощение, ориентируясь на начинающего программиста (его книга изобилует такими упрощениями).

Да? А можно ссылку, где Страуструп в этом признался? И может где-нибудь есть список "таких упрощений" Страуструпа?

Здравствуйте, igna, Вы писали:

I>Зачем давать доступ к приватным членам тем функциям, которые могут обойтись без этого, то есть зачем делать членами функции, которые без потери эффективности можно выразить через другие функции? Чтобы показать, что они являются частью интерфейса? Так интерфейс класса не совсем формальное понятие, к интерфейсу класса могут относится и функции, не являющиеся его членами. Об этом Саттер тоже писал, возможно в той же книге, у меня сейчас ее под рукой нет.

1) Методы находятся в интерфейсе класса не ради удобства их написания, а ради удобства использования класса, IMHO,
Хотя, возможно, стоит уметь объявлять свой метод"врагом"

2) Во многих случаях было бы, IMHO, последовательно, для всяких действий использовать внешине функции.
Скажем для округления float мы же используем внешние функции, а не методы?
Для выяснения длины const char* тоже. И т. д.

Здравствуйте, Vamp, Вы писали:

V>Угу. Вот так и живем без функции для перебора файлов в каталоге — не на всех же системах есть каталоги. Хорошо, хоть файлы оставили. Тоже, кстати, не на всех системах есть, наверное...

На "всех системах" каталоги устроены немного по-разному.
Хотя как-то обобщить конечно могли бы...

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

Здравствуйте, Cyberax, Вы писали:

C>После того, как я поработал с коллекциями в Java и .NET — я стал намного больше любить STL...
STL лучше чем ничего, конечно. И лучше безумных коллекций со встреонными в них иетраторами.
Но, если воспринимать STL, именно как библиотеку колелкций, то он явно очень слабый и недоделанный (смотрите буст тот же, в конце концов). И сделан как-то так, "грубой силой оптимизирующего компилятора".
Есть намного более разумно обустроенные библиотеки контйнеров, вообще-то. Ориентированные на реальные сценарии, а не так как в std::basic_string. Они, INHO лучше чем STL...

Всё таки в сравнении познаётся...