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


M>Согласен. Только почему-то не я один такой. Наверное потому,что для того что бы сказать что функция next_permutation есть в STL это нужно просто ЗНАТЬ. Ты не можешь об этом догадаться, как например ты можешь не знать, чтоо в boost::filesystem есть функция извлечени пути из полного имени файла, но при этом логично предположить, что она там есть. И в 1-ю очередь я загляну в хелп, ибо вероятность найти там желаеме высока. А в случае с STL ДОГАДАТЬСЯ о наличии там какой-то фичи — проблематично. Если я не уверен что там есть нужный мне алгоритм,то не буду тратить время на штудирование хелпа — я напишу свой, ибо мои поиски могут не увенчаться успехом и я в пустую потрачу драгоценное время. Если конечно передо мной не стоит задача "по максимуму использовать STL".

Не пробывал посмотреть в документации?

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

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

_>>Hi All

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

G>1) Контейнеры STL не транзакционны. Т.е. если во время операции с контейнером не удалось выделить память, то после этого контейнер находится в неопределнном состоянии — уже не исходное, но еще не конечное. Соответственно типы, которые хранят данные в STL контейнерах тоже не будут транзакционными, если не прилагать специальных усилий и терять при этом эффективность.
G>2) В случае невозможности выделения памяти контейнеры STL кидают исключение. Стало быть, вызывающий код обязан его обрабатывать. Если вы используете STL в программе, это не так страшно, а вот если пишете библиотеку ф-ций с использованием STL, то тем самым навязываете пользователю то, что он тоже должен обрабатывать исключения. Если Вы используете контейнеры только внутренне и аккуратно обрабатываете все исключения, то тогда еще не все потеряно. А вот если используете типы STL в параметрах ф-ций, тогда плохо дело.

G>Насколько я знаю, STL, который поставляется с Visual Studio эти недостатки имеет. Было бы интересно узнать, как обстоит дело в остальных реализациях.

G>А вообще очень красивая библиотека. Лично мне нравится, только из-за вышеперечисленного пользоваться ей нужно очень осторожно.

Можно кстати пример библиотеки контейнеры которой поддерживают транзакционность ?

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

G>Можно кстати пример библиотеки контейнеры которой поддерживают транзакционность ?
Видимо таких мало
Правда меня это не удивляет, так как нужда в транзакционности надуманная

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

E>>2) Бывает таки так, что индексы участвуют в вычислениях. Например часто хочется узнать какой из индексов больше и на сколько . Или храниить какие-то диапазоны индексов, которые легко могут выходить за область индексов массива.
T>random access iterator решают эти проблему, не так ли?
И как они решают ту проблему, что иногда удобно получать и невалидные значения индексов?

T>Я, я как то работал с окошкаим и пикселями!
T>И получалось, что координаты внутри окна, всегда только положительные.
T>А когда выводим окно на экран, то снача вычисляем то, что выводить будем (клипирование называется).
T>Опять же итерирования по отричательным координатам нет.

Э-э-э? А при чём тут итерирование?
Вот у тебя окошко, которое задвинуто в позицию (-10, -20 ), а само окошко 100 Х 200 пикселей.
Конечно после клипирования у тебя останется прямоугольник (0 — 90 х 0 — 180), весь из себя положительный. А в оконных координатах получится прямоуголдьник (10 — 100 х 20 — 200). Но как ты собираешься хранить сам прямоугольник окна (или его позицию)?


T>Хотя, если подобных вычислений много, то может быть вам нужна библиотека работы с векторами и матрицами? Boost.uBLAS, например?
И давно его приспособили к деревьям?

T>В том, что массив всегда имеет конечный положительный размер, и начинается с 0го элемента?
И именно поэтому его естественно представлять как неотрицательное целое взятое по модулю какой-то степени двойки?

E>>тут уже была больискошая дискуссия на эту тему

Автор:
Дата: 12.11.06

лучше флеймить там
T>Ок.
+1

---

T>К сожалению отношение простоты и понятности мне оценивать трудно — по причине авторства.
T>Но оба успешно работают до сих пор в промыщленных системах.
+1
Конечно динамический полиморфизм обычно медленнее. Но часто это не важно. Обычно если надо действительно быстро, то надо менять архитектуру

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

P>Не так давно я узнал, когда именно г-ну Степанову пришла идея библиотеки STL — когда он находился в отделении интенсивной терапии (после отравления рыбой) в, как он сам написал, "delirium state", по-просту — в состоянии БРЕДА.

P>Этот малеьнкий фактик очень удачно вписался в мои собственные представления об STL и самом языка С++. В предельно короткой форме: STL — это просто болезненный бред.

P>Бред относится к авторам библиотеки, а болезненный — это состояние ее пользователей.

P>Уже с самого начала STL производит впечатление чего-то монстроидального и совершенно непонятного. Это нагромождение template'd классов (яязык не поворачивается называть их объектами, это просто АТД-переростки) с огромным количество параметров и морем методов с весьма непонятными названиями.
P> .................................
P>[/q]

Да хоть в наркотическом опьянении он её писал. Какая мне разница. Библиотека прекрасно отлажена, и есть хоть какой-то стандарт. Лучше работать с одним корявым (?) вектором, чем с десятью супер-векторами, запоминая разницу между ними, тратя время на отладку,поддержку, документацию и т.п.

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

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

Опять подняли?

Есдинственный минус — буква S.

Из-за нее я не могу быть уверен в том, что std::sort работает за n log n, не знаю, насколько эффективна list::splice. Из-за нее я должен ориентироваться на самую слабую реализацию — я не могу сказать: «библиотека требует Super Template Library 1.6.8+».

И т. п.

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

A>Здравствуйте, Programador, Вы писали:
Вообщето это писал другой человек, Там приведена ссылка http://steps3d.narod.ru/tutorials/c-minus-minus.html

A>Да хоть в наркотическом опьянении он её писал. Какая мне разница.
Тексты не читабельны. Смена конттекста для тривиальных действий раздражает

A>Библиотека прекрасно отлажена, и есть хоть какой-то стандарт.
Какая именно баблиотека отлажена? Какой стандарт?

A> Лучше работать с одним корявым (?) вектором, чем с десятью супер-векторами, запоминая разницу между ними, тратя время на отладку,поддержку, документацию и т.п.
Корявый — CFile не засунеш. ну и т.д. Да все уже обсуждалось

E>А вообще идея продумать и написать небольшую юиюлиотеку, в которой будут
E>массивы, списки, деревья и простые умные указатели
E>Хэши и хэшмэпы (а не то прекрасное изделие, которое есть в stl под названием map)
E>стредства управления памятью
E>средства доступа к бинарным файлам
E>средства сериализации в текст (хотя против потоков я как раз ничего не имею, просто хочется, чтобы всё совместимо осталось)
E>средства сереализации в бинарный архив
E>система исключений
E>строчки.

E>И типа более или менее всё -- она позитивная весьма.

Классная идея Осталась спроектировать и реализовать эту библиотеку так чтобы она удовлетворяла потребностям ну хотя бы 90% программистов Потому что одному хочется в контейнеры пихать вот такие вот классы, другому — эдакие, но обоим хочется чтобы всё это было просто для понимания и лаконично выглядело в использовании. Ну и заодно сделать чтобы эта библиотека компилировалась и работала безбажно и желательно — эффективно на всём зоопарке компиляторов, среди которых есть довольно древние и довольно экзотичные. Да, и ещё не забыть пропихнуть эту библиотеку в массы, так чтобы её грабли и грабельки, которые будут в дизайне и/или имплементации (а они будут обязательно) — были описаны и известны широкому кругу пользователей библиотеки. Не то что бы задача неразрешимая — но ИМХО очень и очень непростая.

STL хоть как-то эту задачу решает. Реальной альтернативы ему не видно Буде такая появится на горизонте — я ей с удовольствием воспользуюсь.

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

E>>А вообще идея продумать и написать небольшую юиюлиотеку, в которой будут
E>>массивы, списки, деревья и простые умные указатели
E>>Хэши и хэшмэпы (а не то прекрасное изделие, которое есть в stl под названием map)
E>>стредства управления памятью
E>>средства доступа к бинарным файлам
E>>средства сериализации в текст (хотя против потоков я как раз ничего не имею, просто хочется, чтобы всё совместимо осталось)
E>>средства сереализации в бинарный архив
E>>система исключений
E>>строчки.

E>>И типа более или менее всё -- она позитивная весьма.

L>желательно — эффективно на всём зоопарке компиляторов, среди которых есть довольно древние и довольно экзотичные.
Насчет эффективности — СТЛ насилие над компиляторами. И они не очень давно научились ее эффективно компилить

L> Да, и ещё не забыть пропихнуть эту библиотеку в массы, так чтобы её грабли и грабельки, которые будут в дизайне и/или имплементации (а они будут обязательно) — были описаны и известны широкому кругу пользователей библиотеки. Не то что бы задача неразрешимая — но ИМХО очень и очень непростая.
STLport насколько я понимаю одним человеком сделан. Вопрос собственно не в релизации, а в несколько кривом дизайне ( http://rsdn.ru/Forum/Message.aspx?mid=2095037&only=1

Автор:
Дата: 06.09.06

)

Здравствуйте, Аноним, Вы писали:
А>STLport насколько я понимаю одним человеком сделан.
STLport основана на SGI STL (здесь):

STLport Story
by Boris Fomitchev

First Step

I started STLport project in Jan'97, shortly after first release of SGI STL. Back then, I was working for Moscow Center for SPARC Technology. I made a quick-and-dirty port of SGI STL for gcc-2.7.2 and SUN CC 4.2 for internal use. Very proud of myself, I submitted my changes back to SGI team. Matt Austern (still leading library developer) was kind enough to respond to me. However, I realized SGI team were not interested at all in extra portability. So I built my own Web page and started distributing my humble port from there. I named it "Adapted SGI STL" (weird, huh ?). Reasonable name appeared only a few months later.

Здравствуйте, Пётр Седов, Вы писали:

ПС>Здравствуйте, Аноним, Вы писали:
А>>STLport насколько я понимаю одним человеком сделан.
ПС>STLport основана на SGI STL (здесь):

Бесхозный он какойто СТЛ. Я думаю MS в VC на него забила, поскольку это продукт SGI, а SGI вообще на него забила

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

A>>Здравствуйте, Programador, Вы писали:
А>Вообщето это писал другой человек, Там приведена ссылка http://steps3d.narod.ru/tutorials/c-minus-minus.html
Извиняюсь. Надеюсь я Вас не сильно оскорбил .


A>>Библиотека прекрасно отлажена, и есть хоть какой-то стандарт.
А>Какая именно баблиотека отлажена? Какой стандарт?
stl. Стандарт C++. Например, увидев:

//list<int> l;
l.push_back(10);

Я могу быть уверенным, что:
1) В списке есть хотя бы один элемент.
2) Этот элемент находится в конце, указатель на следующий элемент пуст (т.е равер end()).
3) Все предыдущие ссылки, которые я использовал (итератора) остались валидны.
4) Размер списка увеличился на один элемент.
Уже достаточно много. Многие свои разрабатываемые контейнеры могут не поддерживать по какой-либо причине эти условия (в целях оптимизации).

A>> Лучше работать с одним корявым (?) вектором, чем с десятью супер-векторами, запоминая разницу между ними, тратя время на отладку,поддержку, документацию и т.п.
А>Корявый — CFile не засунеш. ну и т.д. Да все уже обсуждалось
Не думаю, что Вам станет удобнее, если у Вас будет множество векторов на все случаи жизни.
Согласен, всё уже обсуждалось. Мои посты были в тему "разработчику C++ stl знать не обязательно".
Ещё поясню, чтобы меня не поняли неправильно: наверное, можно найти серьёзный проект, где stl не нужен. Но это не значит, что программисту С++ не надо знать stl, это скорее означает, что ему можно забыть stl на время текущего проекта.

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

A>Ещё поясню, чтобы меня не поняли неправильно: наверное, можно найти серьёзный проект, где stl не нужен. Но это не значит, что программисту С++ не надо знать stl, это скорее означает, что ему можно забыть stl на время текущего проекта.

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

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

A>Ещё поясню, чтобы меня не поняли неправильно: наверное, можно найти серьёзный проект, где stl не нужен. Но это не значит, что программисту С++ не надо знать stl, это скорее означает, что ему можно забыть stl на время текущего проекта.

Знать конечно нужно. И остородно использовать, особенно в серьезных проектах

А решил я производительность померять СТЛ. Правда асм в релизе не посмотрел толком. В дебаге СТЛ вообще кошмар. В дебаге велосипед в 20 раз быстрее в релизе в 3

Чет функцию сравнения не могу в параметры шаблона засунуть. Как можно?

#include <stdio.h>
#include <list>

__declspec(naked) __int64 rdtsc()
{   __asm rdtsc;
    __asm ret;
}

typedef std::list<int> Ilist;

//  список и ноде от Ilist
struct kak_int
{  kak_int *next,*prev;
   int value;
};
struct kak_il
{  kak_int *xz,*head;
   int size;
};
inline bool operator<(kak_int const& a,kak_int const& b)
{  return a.value<b.value;
}


// сортировка односвязного списка
template <class C,C* (C::* NEXT)>
struct Vel_lis1
{  
  inline static C* merge(C* a,C* b)
  { if(!a)
       return b;
    if(!b)
       return a;
    C *x,**xx=&x;
    for(;;)
    if(*b<*a)
    {  *xx=b;
        xx=&(b->*NEXT);
       if( !(b= *xx))
       { *xx=a; 
         break;
       }
    }
    else
    {  *xx=a;
        xx=&(a->*NEXT);
       if( !(a= *xx))
       { *xx=b; 
         break;
       }
    }
    return x;
  }

  inline static int sort(C  *&_l)
  {  C *l2n[32],*l=_l,*lpp;
     int j;
     for( j=32;j--;)
       l2n[j]=0;
     for(;l;l=lpp)     
     { lpp=l->*NEXT;
       l->*NEXT=0; 
       for(int j=0;;j++)
       if(l2n[j])
         l=merge(l2n[j],l),l2n[j]=0;
       else
       { l2n[j]=l;
          break;
       }
     }
     _l=0;
     int n=0,e=1;
     for( j=0;j<32;j++,e<<=1)
     if(l2n[j])
       _l=merge(l2n[j],_l),n+=e;
     return n;
  }
};



void main(int , char* [])
{  Ilist il, ila,ilb;
   kak_il &kila=(kak_il&)ila,&kilb=(kak_il&)ilb;
   int j;


   for( j=0;j<100;j++)
     { int r=rand(); ila.push_back(r),ilb.push_back(r);     }
   
   
   __int64 klk_stl, klk_velo;  // клики стл и вело

   klk_stl=rdtsc();
   ila.sort();
   klk_stl=rdtsc()-klk_stl;
   
     
     
   klk_velo=rdtsc();
   // прревращаем в односвязный
   kilb.head->prev->next=0; 
   // сортируем односвязный
   Vel_lis1<kak_int,&kak_int::next >::sort(kilb.head->next);
   // вертаем в зад в двухсвязный
   for(kak_int *node=kilb.head,*nodepp;;node=nodepp)
   { nodepp=node->next;
     if(!nodepp)
     { kilb.head->prev=node;
       node->next=kilb.head; 
       break;
     } 
     nodepp->prev=node; 
   }

   klk_velo=rdtsc()-klk_velo;
   
   
   // проверки
   if(ila==ilb)
   {   __asm nop
      j=__LINE__;
   }
   if(ilb==ila)
   {   __asm nop
      j=__LINE__;
   }
   ila.erase(ila.begin(),ila.end());
   ilb.erase(ilb.begin(),ilb.end());


   printf(" %.0f / %.0f = %.2f \n",double(klk_stl),double(klk_velo),double(klk_stl)/double(klk_velo));
   __asm nop

}

Здравствуйте, Programador, Вы писали:
P>А решил я производительность померять СТЛ.
P>…
P>// сортировка односвязного списка
Зачем сортировать список (std::list)? Может, лучше использовать std::set – в нём элементы всегда сортированы.

Здравствуйте, Пётр Седов, Вы писали:

ПС>Зачем сортировать список (std::list)? Может, лучше использовать std::set – в нём элементы всегда сортированы.

Вообще-то если тебе надо собрать 10 000 элементов, а потом отсортировать их, то сначаоа собрать, а потом отсортировать быстрее, вроде

Здравствуйте, Erop, Вы писали:
ПС>>Зачем сортировать список (std::list)? Может, лучше использовать std::set – в нём элементы всегда сортированы.
E>Вообще-то если тебе надо собрать 10 000 элементов, а потом отсортировать их, то сначаоа собрать, а потом отсортировать быстрее, вроде
Так вроде в обоих случаях время = O(N * log(N)) (насколько я знаю, стандарт гарантирует, что set::insert работает за время O(log(set::size))). Хотя если надо сортировать по целым числам из маленького диапазона, то это можно сделать за линейное время (распихать элементы по вёдрам, а потом собрать по порядку).

Здравствуйте, Пётр Седов, Вы писали:

ПС>Так вроде в обоих случаях время = O(N * log(N)) (насколько я знаю, стандарт гарантирует, что set::insert работает за время O(log(set::size))). Хотя если надо сортировать по целым числам из маленького диапазона, то это можно сделать за линейное время (распихать элементы по вёдрам, а потом собрать по порядку).
чесно слово не знаю деревья. Но если вставка за O(log(set::size))) я думаю что она может и быть за O(log(set::size))), но при этом можно придумать такие данные что прийдется перевешивать значительное число данных с одних веток на другие. Кроме того сортировка может понадобьтся внезапно, или потребуется несколько вариантов.

А разговор собственно не за O(N * log(N)) а за O(N * log(N)) Меня интересует насколько алокаторы тормозят код

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

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