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

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

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

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

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

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

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

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

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

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

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

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;
}

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

unit ExtendedList;
interface
uses Classes, Math;

type
  _Param = Extended;
const
  _nil: Extended = INFINITY;
{$include 'GenericList.intf'}
  TExtendedList = TGenericList;
implementation
{$Include 'GenericList.impl'}
end.

А>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;
А>}
А>

 CStrign s;
 s.LoadString(ID);

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

Хорошая совместимость с WinAPI

A>>[q]Что я собственно хотел бы увидеть: иметь библиотеку с концепцией конечно СТЛ, но что бы она была заточена для виндов, ну не надо мне этой независимости. Отсюда вытекает что она не должна входить в стандарт.

A>>[q]Хорошая совместимость с WinAPI

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

D>Я тоже повторю свои слова, а именно что я хочу: ХОЧУ ИМЕТЬ ЗАТОЧЕННУЮ ЛИБУ ПОД ВИНДОВС В СТИЛЕ СТЛ
D>И не надо ее ни в какой стандарт пихать.

D> CStrign s;
D> s.LoadString(ID);
D>

// ==========================================================================
//!                  ЗАГРУЗИТЬ СТРОКУ ИЗ РЕСУРСОВ
inline std::tstring LoadString(uint id, HINSTANCE hRes = NULL)
{
   if (!hRes)  hRes = ::GetModuleHandle(NULL);

   std::vector<TCHAR> buff(256); // Начальный размер буфера - 256 символов
   int len = 0;
   while ( (len = ::LoadString(hRes, id, &buff[0], buff.size() )) == 
           static_cast<int>(buff.size() - 1) )
   {
      buff.resize( buff.size() * 2 );                    // Увеличить буфер
   }

   return std::tstring( &buff[0] );
}

// Пример использования:
std::tstring s = LoadString( ID );