Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, vitz, Вы писали:
V>>Вот и я ща свое БЕ выскажу...
V>>Да ничем foreach пренципиально не лучше, но только если уважеемые госпада вспомнат чем массив от списка отличается? V>>и если для перебора списка использовать перегруженый индексатор и произвольный доступ через for... V>>А для массивов использовать итераторы и foreach... V>>Вот тогда и получится извращение, и дело не в простоте синтаксиса конструкций или еще чего-то там это и есть особенности внутренней организации
L>Что-то никак не пойму чего ты хотел своим сообщением сказать? Можешь расшифровать (для тех, кто в танке)?
Тем кто в танке посвящается:
Хотел сказать, что использовать инструмент нужно по назначению
foreach не гибок, само то что для различных перечислений требуются различные итераторы уже ставит крест на этом. Я уже не говорю о много поточности, достук к одному итератору в разных потоках сделает бобо. Другое дело индексатор, поддерживает любые фантазии с перечислениями, потоко безопасен и т.д. Поэтому когда я вижу в чьемто сорце итераторы меня сразу тошнит и я дальше без всяких объективных причин не могу смокойно смотреть на этот сорц, и в итоге я этот сорц посылаю фтопку %). Я понимаю, что можно юзать foreach там где без ниго никак, скажем в МС сделали мега класс у которого есть только итератор, но зачем бяку делать в своих сорцах?
представим мега Grid Control от мега компании за мега цену. Вот я решил в этом гриде сделать цикл чтоб каждый второй элемент стал зеленым, но почемуто разработчики не догадались сделать такой итератор, а индексатора у них и в помине нету, что можно будет тогда сказать о разработчикак этого грида? я бы сказал что они мега бараны.
Здравствуйте, Nimnul, Вы писали:
N>Вот я решил в этом гриде сделать цикл чтоб каждый второй элемент стал зеленым, но почемуто разработчики не догадались сделать такой итератор,
Хочешь сказать, ты такой итератор сам написать не в состоянии?
Re[5]: Как получить обратный for each?
От:
Аноним
Дата:
12.09.06 04:44
Оценка:
каким же образом ты добавишь итератор в скомпилированную сборку?
Более того существуют задачи которые с помощью итераторов впринципе решить нельзя. Пример: существует некий класс который предоставляет доступ к объектам с помощью итератора, но в силу решаемой задачи доступ к элементам тебе нужен не последовательный а Random, и как же ты будешь корячиться с помощью foreach в данном случае?
Здравствуйте, Nimnul, Вы писали:
N>каким же образом ты добавишь итератор в скомпилированную сборку?
Зачем мы бы это понадобилось делать. Я вполне обошелся бы статическим методом в классе-утилите.
N>Более того существуют задачи которые с помощью итераторов впринципе решить нельзя.
Ну во-первых, про "нельзя решить в принципе" -- это перебор, т.к. random access iterator через unidirectional iterator эмулируется, правда за линейное число вызовов next.
Во-вторых, -- да, не может корова летать Если у меня будет необходимость в random access-е, то я не буду "корячиться", а возьму подходящую для этого структуру данных.
В общем, ты скажи прямо: все тобой написанное -- это какие-то религиозные соображения или что? Если да, то дальше говорить просто бессмысленно (у меня нет цели кого-то переубеждать).
Если нет, то казалось бы чтение GoF (паттерн итератор), а также общеалгоритмическая эрудиция все без проблем расставляют на место.
Есть как структуры данных с дорогим random access-ом, и быстрым next-ом, так и наоборот. Два крайних представителя: связный список и обычный массив.
Есть и кое что посередине. Скажем, структура данных, которая поддерживает последовательность ключей и позволяет
1) по номеру в последовательности узнать ключ
2) удалить ключ в заданной итератором позиции
3) добавить ключ после заданной итератором позиции
Стандартное решение освновано на применении сбалансированного дерева, тогда сложность первой операции O(log n), а последних двух -- O(1). Тем самым, у нее достаточно эффективный random access. Однако линейный просмотр через random access будет требовать времени порядка n log n, а просмотр через iterator (реализованный через inorder обход дерева) -- всего n. Причем множитель log n на больших коллекциях (скажем, n = 1000000) очень даже ощутим (порядка 20).
Вот такие дела. Нормальному человеку языковые инструменты не должны мешать, если он правильно их применяет.
Здравствуйте, Nimnul, Вы писали:
N>представим мега Grid Control от мега компании за мега цену. Вот я решил в этом гриде сделать цикл чтоб каждый второй элемент стал зеленым, но почемуто разработчики не догадались сделать такой итератор, а индексатора у них и в помине нету, что можно будет тогда сказать о разработчикак этого грида? я бы сказал что они мега бараны.
Нифига подобного. Грид — это не Excell, где можно как угодно красить ячейки. В DataGridView можно вручную менять некоторые параметры ячейки, но всё это несерьёзно. Вот, скажем, для увеличения юзабилити нужно в гриде каждую вторую строку делать немного темнее. Что же, придётся подписываться на события добавления, удаления, сортировки и прочие, ради того чтобы заново перекрасить грид? Поэтому удобнее иметь событие, которое вызывается каждый раз, как гриду нужно узнать стиль ячейки и обработчик которого должен самый стиль сообщать.
Ещё одним аргументом против явного указания цветов ячеек служит то, что грид может показывать 1000_000 строк. Поэтому модификация всего этого дела будет занимать немалое время, а хранение цветов — немао памяти.
Кстати, в DataGridView средства для динамического указания стилей неудобны. По мне так проще вот как. Во-первых, зря MS убрали TableStyle'ы. Во-вторых, в TableStyle'е должна быть коллекция StyleSheet некоторых StyleSelector'ов; окончательный стиль формируется таким образом: стиль грида -> стиль таблицы -> стиль столбца -> последовательно стили из StyleSheet. Здесь стрелкой я обозначил последовательное применение стилей к некоторому стилю по-умолчанию. Сами StyleSelector'ы — это пары, где есть предикат и стиль; стиль применяется только если предикат для заданной ячейки возвращает true. Стили должны быть в состоянии явно указать, какие из свойств должны быть унаследованы. Например, свойства шрифта вроде Bold, Italic, Underline — должны быть не bool, а некоторый enum со значениями True/False/Inherit.
Для Excel-подобных контролов уместнее всего было бы сделать итерацию по интервалу ячеек, буквально:
IEnumerable<Cell> GetCells(CellRange range)
А у каждой Cell есть координаты, так что нет проблем всё это покрасить так как нужно.
Не знал, что итерация не потокобезобасна. Вроде как при ней ничего в принципе меняться не может в пределах коллекции, а сами итераторы создаются различные для каждого foreach'а. Так что, если возникают проблемы синхронизации при итерации foreach'ем, то они же возникнут и при for'е. Дело в неправильной архитектуре.
Здравствуйте, Nimnul, Вы писали:
N>представим мега Grid Control от мега компании за мега цену. Вот я решил в этом гриде сделать цикл чтоб каждый второй элемент стал зеленым, но почемуто разработчики не догадались сделать такой итератор, а индексатора у них и в помине нету, что можно будет тогда сказать о разработчикак этого грида? я бы сказал что они мега бараны.
Ну ты и тупой .... пример привел.
bool skip = true;
foreach (GridRow row in grid.Rows)
{
if (!skip)
row.Color = Colors.Green;
skip = !skip;
}
Re[5]: Как получить обратный for each?
От:
Аноним
Дата:
12.09.06 05:40
Оценка:
Lloyd
А каков будет замыслел если нужно выделять разными цветами по четыре строки?
--------------
Любое удобство идет за счет мегагерцеф! : {<b>1</b>, <b>2</b>}
Здравствуйте, Nimnul, Вы писали:
N>А каков будет замыслел если нужно выделять разными цветами по четыре строки?
А самому никак подумать не получается?
Re[6]: Как получить обратный for each?
От:
Аноним
Дата:
12.09.06 05:49
Оценка:
Mab
>Зачем мы бы это понадобилось делать. Я вполне обошелся бы статическим методом в классе-утилите.
Это в ответ на вопрос почему я не могу добавить свой итератор.
>Ну во-первых, про "нельзя решить в принципе" -- это перебор, т.к. random access iterator через unidirectional iterator эмулируется, правда за линейное число вызовов next.
Как то ты быстро проскачил этот момент, а ведь какой ценой будет эта самая эмуляция! Причем цена растет при увеличении количества элементов в коллекции, и при обращении к "дальним" элементам.
>Есть как структуры данных с дорогим random access-ом, и быстрым next-ом, так и наоборот. Два крайних представителя: связный список и обычный массив.
Как правило итераторы удобны в деревьях. А связанный список, я вобще не разу не видел, использованным в дотнете.
--------------
Любое удобство идет за счет мегагерцеф! : {<b>1</b>, <b>2</b>}
Не могу не согласится, что касается грида ты прав, разрисовывать лучше на событиях, но суть не в этом, я показал лишь пример где может возникнуть данная проблема.
--------------
Любое удобство идет за счет мегагерцеф! : {<b>1</b>, <b>2</b>}
Здравствуйте, Nimnul, Вы писали:
N>Это в ответ на вопрос почему я не могу добавить свой итератор.
Не можешь потому, что C# 2.0 (в отличие от C# 3.0) этого не позволяет.
N>>Ну во-первых, про "нельзя решить в принципе" -- это перебор, т.к. random access iterator через unidirectional iterator эмулируется, правда за линейное число вызовов next. N>Как то ты быстро проскачил этот момент, а ведь какой ценой будет эта самая эмуляция! Причем цена растет при увеличении количества элементов в коллекции, и при обращении к "дальним" элементам.
Я это отлично понимаю. Тем не менее, это не делает задуманное "не разрешимым в принципе". Неразрешимость -- более сильная категория.
N>Как правило итераторы удобны в деревьях. А связанный список, я вобще не разу не видел, использованным в дотнете.
Не понял, к чему этот аругмент. Ну не видел ты его использованным, и что?
Re[6]: Как получить обратный for each?
От:
Аноним
Дата:
12.09.06 06:01
Оценка:
Mab
еще хотел добавить... Вот смотри сам, сколько нужно знать заморочек использую итераторы, что бы не "прогодать", а ведь намного проще использовать просто индексатор и все вопросы отпадают сами собой в том числе и вопросы производительности.
--------------
Любое удобство идет за счет мегагерцеф! : {<b>1</b>, <b>2</b>}
Вообще мне всегда казалось, что когда человек не знает этих (вполне элементарных, кстати) "заморочек", то код у него получается... эм... не очень качественный. Но это вопрос вкуса, конечно. Низкооплачиваемые кодеры тоже вполне пользуются спросом.
Re[7]: Как получить обратный for each?
От:
Аноним
Дата:
12.09.06 06:19
Оценка:
Речь не о том, ты сам можешь забыть коечто в позапарке, что в итоге привет либо к багу в твоей программе либо к большим потерям производительности, когда начнется производственная обкатка твоей проги.
--------------
Любое удобство идет за счет мегагерцеф! : {<b>1</b>, <b>2</b>}
Здравствуйте, Nimnul, Вы писали:
>>>А самому никак подумать не получается?
N>Я сам уже подумал, но хочу все же увидеть твой вариант и обсудить его в дальнейшем.
Мой вариант по поводу твоего примера вообще не должен требовать перебора, т.к. во всех известных мне гридах имеется событие типа CellFormatting-а, в котором и надо производит изменение внешнего вида грида.
