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

C>Ну недаделность — это факт, да и устарела STL сильно. Ей уже больше 10 лет, как-никак. Я воспринимаю STL скорее как "руководство к действию" для создания коллекций.

Ну вот комитет сейчас изо всех сил руководствуется. В следующем году узнаем, до чего доруководствуется.

И будет нам еще одна версия STL еще на 10 лет :-)

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


L>Зы вот кстать ещё вопрос — Кто как думает надо ли стараться уменьшать использование STL в win32 проектах?
Я обычно наоборот, стараюсь свести все к C++/STL. Я ленивый, мне лень переписывать много раз одно и тоже, хочется один раз написать и использовать где ни попадя. А STL худо-бедно стандарт, если на платформе есть современный компилятор C++, то мое барахло скомпилируется и будет работать.

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

Я как можно большую часть кода стараюсь писать независимо от платформы. Мало ли на подо что завтра писать придется.

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

PS На эксперта ни в коем разе не претендую

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

kan>Так а чем тогда "неициализированный" итератор не устраивает?
kan>

kan>std::vector<Type>::iterator nullIterator;
kan>

Очевидно тем же чем и неинициализированный указатель...
Итераторы ведь абстракция указателей? Ну так в pointer-based коде часто бывает нужен "указетль в никуда" AKA 0 или NULL, если в чистом C...

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

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

Мы же общий типичный случай обсуждаем, а не какой-то только "гроссмейстеру" доступный.
Опять же в программировании, в отличии от шахмат, "гроссмейстерский" код -- это почти всегда недостаток. Так как хороший код обычно доступен не только "гроссмейстерам"...

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

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

Ты вот для чего деки используеш? Без них же жили люди как-то?

Erop wrote:

> kan>Так а чем тогда "неициализированный" итератор не устраивает?
> kan>
> kan>std::vector<Type>::iterator nullIterator;
> kan>
> Очевидно тем же чем и неинициализированный указатель...
Он неинициализированный в кавычках. Вполне законное значение, соответсвующее null.
А на кой ты некрофилией занялся?

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

.>Erop wrote:

>> kan>Так а чем тогда "неициализированный" итератор не устраивает?
>> kan>
>> kan>std::vector<Type>::iterator nullIterator;
>> kan>
>> Очевидно тем же чем и неинициализированный указатель...
.>Он неинициализированный в кавычках. Вполне законное значение, соответсвующее null.
Нет, он именно неинициализированный.
Разница такая же, как между int*p; и int*p=0;, c той разницей только, что для итератора стандартного вектора второй записи не существует.

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

You will always get what you always got
  If you always do  what you always did

jazzer wrote:

> Нет, он именно неинициализированный.
> Разница такая же, как между int*p; и int*p=0;, c той разницей только,
> что для итератора стандартного вектора второй записи не существует.
Что за бред? iterator — не POD-тип. Там выполняется конструктор без параметров. Посмотри в исходиках, что-ли:

    _Vector_const_iterator()
        {    // construct with null pointer
        _Myptr = 0;
        }

> Есть кое-какие итераторы, для которых такое сингулярное значение может
> использоваться для чего-то помимо присваивания несингулярного значения
> (например, дял потоков ввода), но в общем случае ты с ними ничего
> сделать не можешь, кроме как присвоить нормальное значение.
Абсолютно то же самое, что и с NULL: разыменовывать нельзя, можно сравнивать с другими.

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

.>Что за бред? iterator — не POD-тип. Там выполняется конструктор без параметров.
какое отношение имеет ПОД к сингулярности итератора?

.>Посмотри в исходиках, что-ли:
Это особенности реализации.

>> Есть кое-какие итераторы, для которых такое сингулярное значение может
>> использоваться для чего-то помимо присваивания несингулярного значения
>> (например, дял потоков ввода), но в общем случае ты с ними ничего
>> сделать не можешь, кроме как присвоить нормальное значение.
.>Абсолютно то же самое, что и с NULL: разыменовывать нельзя, можно сравнивать с другими.
нет, сравнивать тоже нельзя, как и в случае с неинициализированным указателем.
сравнивать можно только если это специально оговорено (а для вектора это не оговорено).

You will always get what you always got
  If you always do  what you always did

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

_>Hi All

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

Основной минус STL, что все (string, vector, map) хранится в памяти. Можно написать хитрый allocator, но не сможет использовать логическую структуру данных, а просто аллокирует кусок пямяти. К примеру, в вас есть массив данных в файле из 500000 элементов и индеск как map для этих элементов. Одновременно вы работаете с каким-то фрагментом, скажем из 200 элементов. Очевидно, что весь массив одновременно нельзя загружать в память, а нужно элементы подгружать по мере надобности с диска. Как такие данные содержать в стандартном контейнере?

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

S>Основной минус STL, что все (string, vector, map) хранится в памяти. Можно написать хитрый allocator, но не сможет использовать логическую структуру данных, а просто аллокирует кусок пямяти. К примеру, в вас есть массив данных в файле из 500000 элементов и индеск как map для этих элементов. Одновременно вы работаете с каким-то фрагментом, скажем из 200 элементов. Очевидно, что весь массив одновременно нельзя загружать в память, а нужно элементы подгружать по мере надобности с диска. Как такие данные содержать в стандартном контейнере?

Но можно написать свой контейнер который юудет работать со стандартными алгоритмами.

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

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

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

Стоп, какие мапы с хешами, когда ты хочешь массив массивов?
Или мы уже сменили тему?

E>Ты вот для чего деки используеш? Без них же жили люди как-то?
для того, чтоб не приходилось копировать вектор целиком, когда он вышел за свой capacity.

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

You will always get what you always got
  If you always do  what you always did

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

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

S>>Основной минус STL, что все (string, vector, map) хранится в памяти. Можно написать хитрый allocator, но не сможет использовать логическую структуру данных, а просто аллокирует кусок пямяти. К примеру, в вас есть массив данных в файле из 500000 элементов и индеск как map для этих элементов. Одновременно вы работаете с каким-то фрагментом, скажем из 200 элементов. Очевидно, что весь массив одновременно нельзя загружать в память, а нужно элементы подгружать по мере надобности с диска. Как такие данные содержать в стандартном контейнере?

M>Но можно написать свой контейнер который юудет работать со стандартными алгоритмами.

+1.

Такое чувство, что люди воспринимают STL так: "есть штук пять реализованных контейнеров и штук двадцать реализованных алгоритмов, и штук десять реализованных функторов, и не моги этот список расширять!"

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

Так нет же...

You will always get what you always got
  If you always do  what you always did

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

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

_>>Hi All

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

S>Основной минус STL, что все (string, vector, map) хранится в памяти. Можно написать хитрый allocator, но не сможет использовать логическую структуру данных, а просто аллокирует кусок пямяти. К примеру, в вас есть массив данных в файле из 500000 элементов и индеск как map для этих элементов. Одновременно вы работаете с каким-то фрагментом, скажем из 200 элементов. Очевидно, что весь массив одновременно нельзя загружать в память, а нужно элементы подгружать по мере надобности с диска. Как такие данные содержать в стандартном контейнере?
А зачем их держать в контейнере? Все равно ссылки/указатели на них нельзя будет сохранять, если они в любой момент могут уехать и на их место загрузится что-то еще.
Если тебе нужно просто пройтись по этому фрагменту — ну так загрузи его и предоставь просто пару указателей на начало-конец — все, все алгоритмы заработают автоматом, с обычными указателями.

Либо напиши свой свой контейнер.

You will always get what you always got
  If you always do  what you always did

S>>>Основной минус STL...

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

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

S>>>>Основной минус STL...

V>Основной минус STL — наличие гнусного алгоритма for_each. В отсутствии лямбда-выражений и вложенных функций наличие for_each выглядело бы просто тонким издевательством над языком и поводом для остроумия, но рекомендации к его использованию поступаюшие от гуру заставляют бедных девелоперов кусать себя за хвост и таки всовывать его в свой код. У тех, кому приходится этот код поддерживать, возникает желание укусить девелопера...

Если у тебя функтор тривиальный — сойдет и boost::lambda/boost::bind (до определенного предела, конечно)
А если нетривиальный — то я бы закусал девелопера, который пишет лямбду на страницу — нетривиальная дурища должна идти в отдельную функцию.

Посмотри на Python, например — там совершенно драконовские ограничения на то, что можно делать внутри лямбды, а что нельзя.
Именно чтоб народ с ума не сходил.

Ну и, само собой, если семантика работы с контейнером не подходит под for_each — надо просто писать цикл и не сходить с ума, благо, цикл точно так же не будет зависеть от контейнера, а только от пары итераторов на что угодно, так что все в рамках концепции, даже если ты к for_each и ближко не подойдешь.

You will always get what you always got
  If you always do  what you always did

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

.>Что за бред? iterator — не POD-тип. Там выполняется конструктор без параметров. Посмотри в исходиках, что-ли:

Что за бред? std::vector<X>::iterator вполне может быть X*. PODее не бывает.

J>Если у тебя функтор тривиальный — сойдет и boost::lambda/boost::bind (до определенного предела, конечно)
Это не СТЛ

J>Ну и, само собой, если семантика работы с контейнером не подходит под for_each — надо просто писать цикл и не сходить с ума,

Да. Но народ, начитавшись Саттера, уверен, что for_each — это обязательно, и цикл вместо for_each не допустим ни в коем случае.

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

foreach Vector::Iterator element in vector  {
   element.Display(CurrentMonitor);
}

смотрится безусловно лучше, чем

for (Vector::Iterator b = vector.begin(), e = vector.end(); b!=e; ++b) 
    b->Display(CurrentMonitor);

Но цикл смотрится в миллион раз лучше, чем

std::foreach(vector.begin(), vector.end(), std::bind2nd(CurrentMonitor, std:mem_fun_ref(&ElementType::display))); 
/*А здесь еще изволь указать тип элемента!*/

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

M>Но можно написать свой контейнер который будет работать со стандартными алгоритмами.
Очень сильно сомневаюсь что это возможно по стандарту. Во всяком случае по факту не получится совместимо. Возьмите STLport и поглядите сколько там директорий для различных компиляторов