Здравствуйте, Cyberax, Вы писали:
C>Ну недаделность — это факт, да и устарела STL сильно. Ей уже больше 10 лет, как-никак. Я воспринимаю STL скорее как "руководство к действию" для создания коллекций.
Ну вот комитет сейчас изо всех сил руководствуется. В следующем году узнаем, до чего доруководствуется.
L>Зы вот кстать ещё вопрос — Кто как думает надо ли стараться уменьшать использование STL в win32 проектах?
Я обычно наоборот, стараюсь свести все к C++/STL. Я ленивый, мне лень переписывать много раз одно и тоже, хочется один раз написать и использовать где ни попадя. А STL худо-бедно стандарт, если на платформе есть современный компилятор C++, то мое барахло скомпилируется и будет работать.
L> Просто незнаю почему ... Может подсознательно почему то стремлюсь использовать больше Мелкософские библиотеки, теже CString CAtlArray нежели wstring vector. Хатя знаю что не всегда это есть хорошо. К примеру тотже std::map побыстрее CAtlMap. Интересно мнение экспертов по этому поводу. Кто как считает?
Я как можно большую часть кода стараюсь писать независимо от платформы. Мало ли на подо что завтра писать придется.
Очевидно тем же чем и неинициализированный указатель...
Итераторы ведь абстракция указателей? Ну так в pointer-based коде часто бывает нужен "указетль в никуда" AKA 0 или NULL, если в чистом C...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, LaptevVV, Вы писали:
LVV>А гроссмейстеры ж сплошь и рядом играют...
Ну дык всё равно плохо, и только в какой-то хитрой позиции почему-то хорошо. Типа какие-то преимущества пересиливают "общую плохость".
Мы же общий типичный случай обсуждаем, а не какой-то только "гроссмейстеру" доступный.
Опять же в программировании, в отличии от шахмат, "гроссмейстерский" код -- это почти всегда недостаток. Так как хороший код обычно доступен не только "гроссмейстерам"...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, jazzer, Вы писали:
J>Ну я вот не знаю, как иначе бороться с переаллокацией всего массива целиком.
Ну списки там всякие, мапы с хэшами...
Для FIFO очередей тоже есть варианты...
Ты вот для чего деки используеш? Без них же жили люди как-то?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Erop wrote:
> kan>Так а чем тогда "неициализированный" итератор не устраивает? > kan> > kan>std::vector<Type>::iterator nullIterator; > kan> > Очевидно тем же чем и неинициализированный указатель...
Он неинициализированный в кавычках. Вполне законное значение, соответсвующее null.
А на кой ты некрофилией занялся?
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
.>Erop wrote:
>> kan>Так а чем тогда "неициализированный" итератор не устраивает? >> kan> >> kan>std::vector<Type>::iterator nullIterator; >> kan> >> Очевидно тем же чем и неинициализированный указатель... .>Он неинициализированный в кавычках. Вполне законное значение, соответсвующее null.
Нет, он именно неинициализированный.
Разница такая же, как между int*p; и int*p=0;, c той разницей только, что для итератора стандартного вектора второй записи не существует.
Есть кое-какие итераторы, для которых такое сингулярное значение может использоваться для чего-то помимо присваивания несингулярного значения (например, дял потоков ввода), но в общем случае ты с ними ничего сделать не можешь, кроме как присвоить нормальное значение.
jazzer wrote:
> Нет, он именно неинициализированный. > Разница такая же, как между int*p; и int*p=0;, c той разницей только, > что для итератора стандартного вектора второй записи не существует.
Что за бред? iterator — не POD-тип. Там выполняется конструктор без параметров. Посмотри в исходиках, что-ли:
> Есть кое-какие итераторы, для которых такое сингулярное значение может > использоваться для чего-то помимо присваивания несингулярного значения > (например, дял потоков ввода), но в общем случае ты с ними ничего > сделать не можешь, кроме как присвоить нормальное значение.
Абсолютно то же самое, что и с NULL: разыменовывать нельзя, можно сравнивать с другими.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
.>Что за бред? iterator — не POD-тип. Там выполняется конструктор без параметров.
какое отношение имеет ПОД к сингулярности итератора?
.>Посмотри в исходиках, что-ли:
Это особенности реализации.
>> Есть кое-какие итераторы, для которых такое сингулярное значение может >> использоваться для чего-то помимо присваивания несингулярного значения >> (например, дял потоков ввода), но в общем случае ты с ними ничего >> сделать не можешь, кроме как присвоить нормальное значение. .>Абсолютно то же самое, что и с NULL: разыменовывать нельзя, можно сравнивать с другими.
нет, сравнивать тоже нельзя, как и в случае с неинициализированным указателем.
сравнивать можно только если это специально оговорено (а для вектора это не оговорено).
Здравствуйте, 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.
Вообще, в мире куча разнообразнх структур данных, кроме вектора, те же упомянутые тобой мапы с хешами
Так что твой вопрос про то, как жили, можно и им переадресовать
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, shrecher, Вы писали:
S>>Основной минус STL, что все (string, vector, map) хранится в памяти. Можно написать хитрый allocator, но не сможет использовать логическую структуру данных, а просто аллокирует кусок пямяти. К примеру, в вас есть массив данных в файле из 500000 элементов и индеск как map для этих элементов. Одновременно вы работаете с каким-то фрагментом, скажем из 200 элементов. Очевидно, что весь массив одновременно нельзя загружать в память, а нужно элементы подгружать по мере надобности с диска. Как такие данные содержать в стандартном контейнере?
M>Но можно написать свой контейнер который юудет работать со стандартными алгоритмами.
+1.
Такое чувство, что люди воспринимают STL так: "есть штук пять реализованных контейнеров и штук двадцать реализованных алгоритмов, и штук десять реализованных функторов, и не моги этот список расширять!"
Хотя все ровно наоборот: пиши сколько угодно новых алгоритмов, пусть они просто принимают пару итераторов, и все автоматически срастется с любым совместимым контейнером.
И ппиши сколько угодно новых контейнеров, только пусть они предоставляют пару итераторов, и тогда все написанные алгоритмы с ними автоматически заработают.
Здравствуйте, shrecher, Вы писали:
S>Здравствуйте, gid_vvp, Вы писали:
_>>Hi All
_>>перечислите, на ваш взгляд, основные минусы STL _>>принимаются только ответы с аргументацией
S>Основной минус STL, что все (string, vector, map) хранится в памяти. Можно написать хитрый allocator, но не сможет использовать логическую структуру данных, а просто аллокирует кусок пямяти. К примеру, в вас есть массив данных в файле из 500000 элементов и индеск как map для этих элементов. Одновременно вы работаете с каким-то фрагментом, скажем из 200 элементов. Очевидно, что весь массив одновременно нельзя загружать в память, а нужно элементы подгружать по мере надобности с диска. Как такие данные содержать в стандартном контейнере?
А зачем их держать в контейнере? Все равно ссылки/указатели на них нельзя будет сохранять, если они в любой момент могут уехать и на их место загрузится что-то еще.
Если тебе нужно просто пройтись по этому фрагменту — ну так загрузи его и предоставь просто пару указателей на начало-конец — все, все алгоритмы заработают автоматом, с обычными указателями.
Основной минус STL — наличие гнусного алгоритма for_each. В отсутствии лямбда-выражений и вложенных функций наличие for_each выглядело бы просто тонким издевательством над языком и поводом для остроумия, но рекомендации к его использованию поступаюшие от гуру заставляют бедных девелоперов кусать себя за хвост и таки всовывать его в свой код. У тех, кому приходится этот код поддерживать, возникает желание укусить девелопера...
Здравствуйте, Vamp, Вы писали:
S>>>>Основной минус STL...
V>Основной минус STL — наличие гнусного алгоритма for_each. В отсутствии лямбда-выражений и вложенных функций наличие for_each выглядело бы просто тонким издевательством над языком и поводом для остроумия, но рекомендации к его использованию поступаюшие от гуру заставляют бедных девелоперов кусать себя за хвост и таки всовывать его в свой код. У тех, кому приходится этот код поддерживать, возникает желание укусить девелопера...
Если у тебя функтор тривиальный — сойдет и boost::lambda/boost::bind (до определенного предела, конечно)
А если нетривиальный — то я бы закусал девелопера, который пишет лямбду на страницу — нетривиальная дурища должна идти в отдельную функцию.
Посмотри на Python, например — там совершенно драконовские ограничения на то, что можно делать внутри лямбды, а что нельзя.
Именно чтоб народ с ума не сходил.
Ну и, само собой, если семантика работы с контейнером не подходит под for_each — надо просто писать цикл и не сходить с ума, благо, цикл точно так же не будет зависеть от контейнера, а только от пары итераторов на что угодно, так что все в рамках концепции, даже если ты к for_each и ближко не подойдешь.
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 и поглядите сколько там директорий для различных компиляторов