M> Плюс в 1-м варианте у меня нет счётчика,а здесь есть. В общем так спокойнее — без канатоходства.
Насколько хорошо вы комментируте код? Такое ощущение, что перед данным циклом у вас одна запись типа: "делаем то-то и то-то".
У цикла есть собственная семантика, а у вас какая-то "вещь в себе" получается.
24 августа 2006 11:36 gid_vvp wrote:
> на мой взгляд вырисовалось ещё два минуса...
Взгляд у вас костный. Привязан, видимо, к логотипу сломанного окна...
> 2. Это то что stl не охватывает все области... например нет сокетов, > threads, GUI, баз данных
И как GUI жить на embedded-железе, у которого единственный информационный
интерфейс наружу — это подключенный к компорту терминал? А база данных
должна иметь триггеры, ХП, репликацию? )
v_m> Взгляд у вас костный. Привязан, видимо, к логотипу сломанного окна...
Уважаемый давайте не будем обсуждять у кого какой взгляд?
>> 2. Это то что stl не охватывает все области... например нет сокетов, >> threads, GUI, баз данных v_m> И как GUI жить на embedded-железе, у которого единственный информационный v_m>интерфейс наружу — это подключенный к компорту терминал?
ничего не мешает этому GUI быть в библиотеке в общем случае и для поддерживающих систем и не быть для неподдерживающих систем.
хотя обощённое гуи это не простая задача, но есть множество примеров
v_m> А база данных v_m>должна иметь триггеры, ХП, репликацию? )
Шебеко Евгений wrote:
> Проблема не в том как вы обходите контейнер, а в том что писать > функциональный объект (или отдельную функцию) фактически для тела for() > оказывается непрактично > За всё время я наверное раза 2 использовал for_each()
Ты вроде сравнивал:
for(vector<int>::iterator it = array.begin();it!=array.end();++it)
и
for(int i=0;i<N;++i)
... причём тут for_each? Просто я предпочитаю первый вариант в большинстве случаев, ибо более универсален.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, gid_vvp, Вы писали:
_>Hi All
_>перечислите, на ваш взгляд, основные минусы STL _>принимаются только ответы с аргументацией
ИМХО, самый большой недостаток — плохо продуманная структура...
Если последовательные контейнеры еще ничего (хотя почему вектор назвали вектором, а не array — никак не пойму),
то ассоциативные — оставляют желать лучшего...
Подчеркивание того, что множество — ассоциативный контейнер — только с толку сбивает начинающего...
Множество — это множество, как бы оно ни было реализовано...
Подчеркивать специфику реализации не стоило и для map — можно было б и как хеш реализовать...
А набор алгоритмов — это вообще напорминает свалку...
А уж про string все написал Саттер в последней книжке — интерфейс перегружен до предела...
Битовый вектор можно было сделать и динамическим...
И похоже на то, что новой редакции STL мы не скоро дождемся... Тока вместе со стандартом...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LaptevVV wrote:
> _>перечислите, на ваш взгляд, основные минусы STL > _>принимаются только ответы с аргументацией > ИМХО, самый большой недостаток — плохо продуманная структура...
В голове у начинающих программистов?
> Если последовательные контейнеры еще ничего (хотя почему вектор назвали > вектором, а не array — никак не пойму),
Потому что одномерный array называется vector, двухмерный array называется matrix. Трёх и более специальных названий не
имеют (насколько я знаю).
> то ассоциативные — оставляют желать лучшего... > Подчеркивание того, что множество — ассоциативный контейнер — только с > толку сбивает начинающего...
It is a simple associative container because its element values are its key values.
Просто это так. Что не устраивает?
К тому же, можно множества одних и тех же элементов строить, но с разным operator<, что в итоге может давать разные
множества.
> Множество — это множество, как бы оно ни было реализовано... > Подчеркивать специфику реализации не стоило и для map — можно было б и
А если для объекта хаш считать очень неудобно или получится неэффективно?
> как хеш реализовать...
std::hash_map?
> А набор алгоритмов — это вообще напорминает свалку... > А уж про string все написал Саттер в последней книжке — интерфейс > перегружен до предела...
С этим согласен.
> Битовый вектор можно было сделать и динамическим...
Не понял? std::vector<bool>? А он какой?
> И похоже на то, что новой редакции STL мы не скоро дождемся... Тока > вместе со стандартом...
Юзаем boost, и хватит плакаться.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, kan_izh, Вы писали:
_>LaptevVV wrote:
>> _>перечислите, на ваш взгляд, основные минусы STL >> _>принимаются только ответы с аргументацией >> ИМХО, самый большой недостаток — плохо продуманная структура... _>В голове у начинающих программистов?
>> Если последовательные контейнеры еще ничего (хотя почему вектор назвали >> вектором, а не array — никак не пойму), _>Потому что одномерный array называется vector, двухмерный array называется matrix. Трёх и более специальных названий не _>имеют (насколько я знаю).
Здравствуйте, gid_vvp, Вы писали:
E>>А где гарантии? E>>Например, где гарантии, что нигде не заложлись на особенность реализации? E>>Например на производительность какого-нибудь метода?
_>все гарантии в стандарте...
При чём тут стандарт?
Вот ты разрабатываешь большую коммерческую библиотеку. Вот тебе как-то надо обеспечить качество разработки. Ты для этого проводишь ревизию кода и тестирование.
Ну и где гарантии? Ревизия кода дело долгое, высококвалифицированное и не осчень надёжное
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
LaptevVV,
> Подчеркивание того, что множество — ассоциативный контейнер — только с толку сбивает начинающего...
Или, с другой стороны, дает ему в руки более общую "модельку", которая позволит легко запомнить общие моменты set, multiset, bitset, map и multimap без запоминания всех их деталей как было бы, будь они несвязанными компонентами.
> Подчеркивать специфику реализации не стоило и для map — можно было б и как хеш реализовать...
Гм... В чем, интересно, состояло подчеркивание специфики реализации? А при реализации в виде hash изменилась бы семантика, т.к. порядок перестал бы быть определенным.
> Битовый вектор можно было сделать и динамическим...
Можно. vector<bool> и так динамический.
> И похоже на то, что новой редакции STL мы не скоро дождемся... Тока вместе со стандартом...
Это неизбежное следствие её стандартизации.
Posted via RSDN NNTP Server 2.0
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Шахтер, Вы писали:
Ш>главный минус (из которого вытекают и все остальные) один -- эта библиотека перестала развиваться. По политическим соображениям STL включили в стандарт. Это привело к замораживанию интерфейса библиотеки (который далек от идеального).
Верно, (но) это вынужденная мера. Либо иметь 68 велосипедов, либо какой-никакой, но стандарт. Да, из-за этого ценность снижена, но и цена использования тоже. Промышленный накладывает свои отпечатки.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
25 августа 2006 10:57 gid_vvp wrote:
> информационный v_m>интерфейс наружу — это подключенный к компорту > терминал? > ничего не мешает этому GUI быть в библиотеке в общем случае и для > поддерживающих систем и не быть для неподдерживающих систем. хотя > обощённое гуи это не простая задача, но есть множество примеров
Зачем в стандартной обвязке какая-то библиотека для частного случая? Тем
более, библиотек для gui вагон с тележкой, какую же конкретно надо
использовать, чтобы всех удовлетворить?
> v_m> А база данных > v_m>должна иметь триггеры, ХП, репликацию? ) > почему нет?
Тот же самый вопрос, что и с gui.
v_m> Зачем в стандартной обвязке какая-то библиотека для частного случая? Тем v_m>более, библиотек для gui вагон с тележкой, какую же конкретно надо v_m>использовать, чтобы всех удовлетворить?
E>При чём тут стандарт? E>Вот ты разрабатываешь большую коммерческую библиотеку. Вот тебе как-то надо обеспечить качество разработки. Ты для этого проводишь ревизию кода и тестирование. E>Ну и где гарантии? Ревизия кода дело долгое, высококвалифицированное и не осчень надёжное
Обычно пишу много-много тестов и прогоняю их в том числе на разных версиях библиотек (это относится не только к STL)
26 августа 2006 14:53 gid_vvp wrote:
> v_m> Зачем в стандартной обвязке какая-то библиотека для частного случая? > Тем v_m>более, библиотек для gui вагон с тележкой, какую же конкретно надо > v_m>использовать, чтобы всех удовлетворить? > Что за вопросы? > Несомненно лучшую
Например?
Здравствуйте, gid_vvp, Вы писали:
E>>Ну и где гарантии? Ревизия кода дело долгое, высококвалифицированное и не осчень надёжное
_>Обычно пишу много-много тестов и прогоняю их в том числе на разных версиях библиотек (это относится не только к STL)
Имеются в виду автоматические тесты готового изделия? И при этом ещё подразумевается воссоздание всех разнообразных условий компиляции и версий STL ?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
E>Имеются в виду автоматические тесты готового изделия? И при этом ещё подразумевается воссоздание всех разнообразных условий компиляции и версий STL ?
27 августа 2006 15:40 gid_vvp wrote:
>>> Несомненно лучшую > v_m> Например? > незнаю я гуйню не пишу... > например qt... когда станет свободной
билл гейтс будет против
Здравствуйте, gid_vvp, Вы писали:
E>>Имеются в виду автоматические тесты готового изделия? И при этом ещё подразумевается воссоздание всех разнообразных условий компиляции и версий STL ? _>всех это уже маразм _>обычно ищетсяя компромис
всех -- это всех встречающихся у пользователей
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
если удаётся сделать это (за что надо поставить отдельный памятник тому кто может предусмотреть всех встречающихся у пользователей), то количество тестов не на много возрастает в связи с использованием разных stl
А база данных
