Вот кто нить может сказать что он очень интенсивно использует STL под виндами? Да, не спорю библиотека не плоха, но все же ее идею отчасти устарели. Ну например взять тот же стринг, его использование под виндовсом настолько затруднительно, что я думаю его вообще мало кто использует. Идем дальше, на кой чер там вообще аллокаторы, причем они есть почти в каждом классе. Опять пережиток прошлого(или я всетаки заблуждаюсь в отношении оных). А вот класс auto_ptr вообще загадочная вещица, которую совсем лучше не трогать, обычно все берут бустовскую реализацию. И это все навскидку, думаю если подумать то много чего можно написать. Вот собственно и вопрос: зачем же нужна STL?

ЗЫ: Я конечно не спорю что контейнеры там ооочень даже неплохи, но STL это же не просто библиотека контейнеров.

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

D>Вот кто нить может сказать что он очень интенсивно использует STL под виндами? Да, не спорю библиотека не плоха, но все же ее идею отчасти устарели. Ну например взять тот же стринг, его использование под виндовсом настолько затруднительно, что я думаю его вообще мало кто использует. Идем дальше, на кой чер там вообще аллокаторы, причем они есть почти в каждом классе. Опять пережиток прошлого(или я всетаки заблуждаюсь в отношении оных). А вот класс auto_ptr вообще загадочная вещица, которую совсем лучше не трогать, обычно все берут бустовскую реализацию. И это все навскидку, думаю если подумать то много чего можно написать. Вот собственно и вопрос: зачем же нужна STL?

D>ЗЫ: Я конечно не спорю что контейнеры там ооочень даже неплохи, но STL это же не просто библиотека контейнеров.
Все написанное Вами — святая истина. Однако гораздо лучше иметь такую, чем никакой. А boost — это поле экспериментов, некоторые из которых со временем окажутся в стандартной библиотеке.

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

D>Вот кто нить может сказать что он очень интенсивно использует STL под виндами? Да, не спорю библиотека не плоха, но все же ее идею отчасти устарели. Ну например взять тот же стринг, его использование под виндовсом настолько затруднительно, что я думаю его вообще мало кто использует.

А что мешает использовать другие String-и например MFC?

D>Идем дальше, на кой чер там вообще аллокаторы, причем они есть почти в каждом классе. Опять пережиток прошлого(или я всетаки заблуждаюсь в отношении оных). А вот класс auto_ptr вообще загадочная вещица, которую совсем лучше не трогать, обычно все берут бустовскую реализацию. И это все навскидку, думаю если подумать то много чего можно написать.

Полностью согласен. Я например еще не видел для себя ситуации где auto_ptr был необходим.
Может быть я заблуждаюсь, конечно. Но тогда пусть меня знаюшие люди поправят. Он наверное для Java-программеров.

D>ЗЫ: Я конечно не спорю что контейнеры там ооочень даже неплохи, но STL это же не просто библиотека контейнеров.

Нет конечно, не только библиотека контейнеров, но даже если так, то оно того стоит.

Z>А что мешает использовать другие String-и например MFC?

Программирование под Виндовс != программирование с использованием MFC.

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

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

D>>Вот кто нить может сказать что он очень интенсивно использует STL под виндами? Да, не спорю библиотека не плоха, но все же ее идею отчасти устарели. Ну например взять тот же стринг, его использование под виндовсом настолько затруднительно, что я думаю его вообще мало кто использует.

Z>А что мешает использовать другие String-и например MFC?

Ага, и идеей переносимости кода под другую ОС можно подтереться. И к тому же можно еще добавить: А что мешает использовать контейнеры от ATL например, я имею в виду с 7 студией. Они очень даже не плохи. К тому же очень вписываются в технолигию СОМ, там даже есть контейнер интерфейсов.

D>>Идем дальше, на кой чер там вообще аллокаторы, причем они есть почти в каждом классе. Опять пережиток прошлого(или я всетаки заблуждаюсь в отношении оных). А вот класс auto_ptr вообще загадочная вещица, которую совсем лучше не трогать, обычно все берут бустовскую реализацию. И это все навскидку, думаю если подумать то много чего можно написать.

Z>Полностью согласен. Я например еще не видел для себя ситуации где auto_ptr был необходим.
Z>Может быть я заблуждаюсь, конечно. Но тогда пусть меня знаюшие люди поправят. Он наверное для Java-программеров.

D>>ЗЫ: Я конечно не спорю что контейнеры там ооочень даже неплохи, но STL это же не просто библиотека контейнеров.

Z>Нет конечно, не только библиотека контейнеров, но даже если так, то оно того стоит.
Но действительных плюсов я признаться не вижу.

ЗЫ: Я бы был вооще против включения STL в стандарт. Это разумеется не означает вообще отсутствие этой библиотеки. Этоже было нужно только для написания переносимых программ, но программы это же не набор контейнеров, а как насчет ГУЙя? Он то занимает не малую часть.

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

D>Вот кто нить может сказать что он очень интенсивно использует STL под виндами?

Пишу на Delphi Смертельных неудобств не возникает. Я вообще против использования препроцессора и шаблонов, но это совсем другая песня...

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

Z>>А что мешает использовать другие String-и например MFC?

VB>Программирование под Виндовс != программирование с использованием MFC.

Я имел ввиду std::string против CString и CAtlString.

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

Z>>А что мешает использовать другие String-и например MFC?

D>Ага, и идеей переносимости кода под другую ОС можно подтереться. И к тому же можно еще добавить: А что мешает использовать контейнеры от ATL например, я имею в виду с 7 студией. Они очень даже не плохи. К тому же очень вписываются в технолигию СОМ, там даже есть контейнер интерфейсов.

Ну речь ведь шла про Win.

D>>>ЗЫ: Я конечно не спорю что контейнеры там ооочень даже неплохи, но STL это же не просто библиотека контейнеров.

Z>>Нет конечно, не только библиотека контейнеров, но даже если так, то оно того стоит.
D>Но действительных плюсов я признаться не вижу.

D>ЗЫ: Я бы был вооще против включения STL в стандарт. Это разумеется не означает вообще отсутствие этой библиотеки. Этоже было нужно только для написания переносимых программ, но программы это же не набор контейнеров, а как насчет ГУЙя? Он то занимает не малую часть.

Тогда надо определиться, что вообще ты хочешь видеть в этой библиотеке?
Хочешь сделать из нее монстра аля MFC?

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

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

ИМХО:

Шаблоны — это реализация какого либо полностью абстрактного алгоритма с вынесенными from something dependent parameters.

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

Аллокаторы — распределители памяти под хранение внутренних user dependent types при инстанцировании.

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

Вот кто нить может сказать что он очень интенсивно использует STL под виндами?

Часто пишут platform independent programs? или скажем более правильно — абстрактные алгоритмы.

Да, не спорю библиотека не плоха, но все же ее идею отчасти устарели.

Для этого и существуют альтернативные библиотеки, которые как уже говорилось и есть поле испытательной деятельности.

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

насколько? это char реализация шаблона basic_string. использовал, но мне так трудно не было. Главное представлять с какими типами ты работаешь и что имеешь на выходе.

А вот класс auto_ptr вообще загадочная вещица, которую совсем лучше не трогать, обычно все берут бустовскую реализацию.

в чем загадочная? в деструкторе? это уже давно не загадка и кто мешает использовать одиночные типы под auto_ptr. насчет бустовской согласен, но ведь создавался он не на пустом месте и кто знает где бы он был, если бы не на лицо были скрытые недочеты auto_ptr.

И это все навскидку, думаю если подумать то много чего можно написать. Вот собственно и вопрос: зачем же нужна STL?

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

ЗЫ: Я конечно не спорю что контейнеры там ооочень даже неплохи, но STL это же не просто библиотека контейнеров.

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

Было тут как-то голосование (вернее опрос) на эту тему.
Из тех кто проголосовал, очень многие используют STL в реальных проектах.
Я не исключение.
Если хочешь, поройся в архивах голосований. Может оно еще не удалено.

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

Основное преимущество STL, кроме того, что она удобна, — это ее стандартность
и хорошая документированность.

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

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

A>что то в последнее время очень часто стал замечать такие революционные вопросы, но все же высказать свое мнение по этому поводу считаю нужным.
A>Думаю, что столь броское предложение всего лишь очередной крик душы, потому что попытаюсь, возможно и неправильно, но все же высказать свое мнение по поводу шаблонов.

A>ИМХО:

A>Шаблоны — это реализация какого либо полностью абстрактного алгоритма с вынесенными from something dependent parameters.

А я разве сказал что то про шаблоны? Разумеется шаблоны это если так можно сказать революционный прыжок С++, я бы даже сказал более "высокий" чем технология NET(это ИМХО).

A>

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

A>Аллокаторы — распределители памяти под хранение внутренних user dependent types при инстанцировании.

А мне казалось(да и не только мне, Маерсу тоже) что аллокаторы нужны только при far & near указателях, которые канули в небытие.

A>Отсюда возникает мое предположение — какая разница под чем их использовать и что значит зачем аллокаторы, когда стандартным образом это делает при помощи оператора new, а я хочу свои внутренние типы хранить не в сырой памяти, а скажем в каком нибудь значительно более эффективном распределителе.

A>

Вот кто нить может сказать что он очень интенсивно использует STL под виндами?

A>Часто пишут platform independent programs? или скажем более правильно — абстрактные алгоритмы.

Согласен когда пишешь алгоритмы, то тут спора нет. Только вот это оочень маленькая доля ПО, в основном же пишутся готовые программы, которые еще как правило имеют ГУЙ. И какая тут platform independent?

A>

Да, не спорю библиотека не плоха, но все же ее идею отчасти устарели.

A>Для этого и существуют альтернативные библиотеки, которые как уже говорилось и есть поле испытательной деятельности.

A>

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

A>насколько? это char реализация шаблона basic_string. использовал, но мне так трудно не было. Главное представлять с какими типами ты работаешь и что имеешь на выходе.

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

A>

А вот класс auto_ptr вообще загадочная вещица, которую совсем лучше не трогать, обычно все берут бустовскую реализацию.

A>в чем загадочная? в деструкторе? это уже давно не загадка и кто мешает использовать одиночные типы под auto_ptr. насчет бустовской согласен, но ведь создавался он не на пустом месте и кто знает где бы он был, если бы не на лицо были скрытые недочеты auto_ptr.

А в том что самый главный недостаток, в том что нельзя использовать в контейнерах?

A>

И это все навскидку, думаю если подумать то много чего можно написать. Вот собственно и вопрос: зачем же нужна STL?

A>много чего можна уточнить в следующих версиях. Как стандартная библиотека базовых алгоритмов.

Каждый раз уточняя, опять получиться монстр. Поэтому все же нечего ее было пихать в стандарт(ИМХО).

A>

ЗЫ: Я конечно не спорю что контейнеры там ооочень даже неплохи, но STL это же не просто библиотека контейнеров.

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

У нас программа и с GUI и с кучей языков и STL нисколько не мешает.
При этом основная часть системы (кроме GUI) прекрасно переноситься на другие платформы.

Те проблемы, которые ты описал — это скорее проблемы проектирования системы в целом
и STL тут ни причем. Используешь ты STL или нет, все равно полезно
явно отделять GUI от логики и все платформенно зависимые части выносить в отдельные
модули, которые имеют платформенно независимый интерфейсы.

А что ещё, кроме std::string и std::auto_ptr тебе не нравится в STL ?

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

А мне казалось(да и не только мне, Маерсу тоже) что аллокаторы нужны только при far & near указателях, которые канули в небытие.

С удовольствием возьму Мейерса и еще раз уточню для себя этот вопрос. Не спорю. Могу и не очень хорошо помнить.

Согласен когда пишешь алгоритмы, то тут спора нет. Только вот это оочень маленькая доля ПО, в основном же пишутся готовые программы, которые еще как правило имеют ГУЙ. И какая тут platform independent?

А где ты встречал GUI platform independent или как ты себе это представляешь? Вот это в стандартных библиотеках точно не стоит абстрагировать, потому что монстр вот он.

А в том что самый главный недостаток, в том что нельзя использовать в контейнерах?

не буду пока спорить. Сейчас еще раз пересмотрю инфу и сходники и подумаю почему.

Каждый раз уточняя, опять получиться монстр. Поэтому все же нечего ее было пихать в стандарт(ИМХО).

есть чего. уточнять алгоритм и исправлять недочеты, это не монстр а "работа над собой"

у меня тут тоже возник вопросик
если ты решил, что STL не нужна, то пытаюсь предположить, что у тебя есть предложения по поводу замены. Чего предлагаешь?
Если предложений нет, то по моему вопрос неактуален, ПО МОЕМУ.

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

D>Вот кто нить может сказать что он очень интенсивно использует STL под виндами? Да, не спорю библиотека не плоха, но все же ее идею отчасти устарели. Ну например взять тот же стринг, его использование под виндовсом настолько затруднительно, что я думаю его вообще мало кто использует. Идем дальше, на кой чер там вообще аллокаторы, причем они есть почти в каждом классе. Опять пережиток прошлого(или я всетаки заблуждаюсь в отношении оных). А вот класс auto_ptr вообще загадочная вещица, которую совсем лучше не трогать, обычно все берут бустовскую реализацию. И это все навскидку, думаю если подумать то много чего можно написать. Вот собственно и вопрос: зачем же нужна STL?

D>ЗЫ: Я конечно не спорю что контейнеры там ооочень даже неплохи, но STL это же не просто библиотека контейнеров.

Ну я использую, и что?
GUI на MFC, а вся бизнеслогика — на STL + Loki + boost + ATL.
Смесь, конечно, весёлая, но действенная.
Единственный напряг — это следить за конверсией TCHAR <-> wchar_t (прога собирается и с юникодом, и с мультибайтом).

Аллокаторы STL — это вещь в себе. Тут я не поспорю.
Вообще, аллокатор — это разновидность политики (policy).
См. Александреску и его Loki — там с аллокаторами более человечно обошлись. Да и другие политики в ассортименте представлены...

Нужно учесть, что STL начинался в эпоху слабых компиляторов, поэтому многие очевидные сейчас вещи там отсутствуют (просто не скомпилировались бы). Пример — boost::bind.

std::auto_ptr и boost::shared_ptr — разные сущности.
auto_ptr задуман для реализации техники "move constructor". Если знаешь его ограничения — то вполне можешь использовать.
Его основные роли:
* возвращать указатель на свежесозданный объект (если объект не схватили — то пристрелить)
* приватный член класса (требует специального конструктора копирования у класса-хозяина)

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

A>>Аллокаторы — распределители памяти под хранение внутренних user dependent types при инстанцировании.

D>А мне казалось(да и не только мне, Маерсу тоже) что аллокаторы нужны только при far & near указателях, которые канули в небытие.
--
Не совсем.
Например, при использовании STL в kernel-mode драйверах без своих аллокаторов трудно обойтись.

C уважением,
Геннадий Майко.

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

D>Вот кто нить может сказать что он очень интенсивно использует STL под виндами? Да, не спорю библиотека не плоха, но все же ее идею отчасти устарели. Ну например взять тот же стринг, его использование под виндовсом настолько затруднительно, что я думаю его вообще мало кто использует.

Критикуешь? Предлагай!
Что вместо std::string? Тормозящий CString из монстрообразной MFC? Или сишный char*?

К тому же, приведи аналог с использованием CString:

std::ostream& operator<<(std::ostream &os, const DisplayList &list)
{
        std::ostringstream oss;
        oss << std::endl << "stroke" << std::endl;
        std::copy(list.begin(),
                list.end(),
                std::ostream_iterator<DisplayList::value_type>(os, oss.str().c_str()));
        os << "showpage" << std::endl;
        return os;
}

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

Во-первых, переопределять дефолтные аллокаторы тебя никто не заставляет. Устраивают --- используй.
Во-вторых, это дополнительная гибкость. Когда упрёшься в производительность стандартного аллокатора на базе operator new и будешь делать свой, то вот тут-то и увидишь всю красоту STL.

D>А вот класс auto_ptr вообще загадочная вещица, которую совсем лучше не трогать, обычно все берут бустовскую реализацию. И это все навскидку, думаю если подумать то много чего можно написать. Вот собственно и вопрос: зачем же нужна STL?

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

D>ЗЫ: Я конечно не спорю что контейнеры там ооочень даже неплохи, но STL это же не просто библиотека контейнеров.

STL --- это не только (и не столько) контейнеры.

Проблема STL — в излишней универсальности, что плохо сказывается на производительности. Хотя штука, конечно, удобная. А в большинстве случаев используется в некритичных по быстродействию участках.
Про аллокаторы. Я как-то писал класс для BSTR на базе STL. Взял base_string<wchar_t> и перегрузил аллокатор, в котором вместо new сделал SysAllocString. Это была самая компактная реализация класса bstr их тех, что я видел.
Хотя, если честно, хотелось бы иметь класс — что-то среднее между list и vector. Т.е. с динамикой list и с индексаций как в vector. И чтобы указатель объекта можно было получить по итератору:

void FillValue(int* val)
{
val=0;
}
...
for(list<int>::iterator i=mylist.begin();i!=mylist.end();i++)
FillValue(i); // Болт!!! это не скомпилится!

А какие проблемы?

void FillValue(int* val)
{
    val=0;
}
...
for(list<int>::iterator i=mylist.begin();i!=mylist.end();i++)
    FillValue( &(*i) );  // это уже скомпилится!

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

LVV>А boost — это поле экспериментов, некоторые из которых со временем окажутся в стандартной библиотеке.

А исходники boost, кроме всего прочего, — пример стиля, как надо писать свои библиотеки шаблонов.