Вместо того чтобы вводить в язык дополнительно три операции образования интервалов ..<, <.. и <..<, можно ввести постфиксные и префиксные унарные операции < и > (последнюю — для симметрии, как впрочем и в случае операций образования интервалов для симметрии следовало бы добавить также ..>, >.. и >..>).
Выражения <n и n> были бы сокращением для n-1, а >n и n< — для n+1.
Может быть тогда наши foreach-и логичнее было бы записать с пробелом между .. и <:
Здравствуйте, Sinclair, Вы писали:
S> В тех редких случаях, когда мне все же нужен именно индекс, я бы предпочел вообще отказаться от манипуляций с Length. Оптимально было бы так: S>
S>int[] a = new int[] {1, 2, 3, 4};
S>int weightedSum = 0;
S>foreach(int i in a.Indexes)
S> weightedSum += i*a[i];
S>
#как-то так, да
weightedSum = 0
a.each_with_index {|obj, i| weightedSum += i * obj}
Здравствуйте, eao197, Вы писали:
E>Так что я не пытаюсь увести разговор в сторону. а исправляю фактические ошибки. Относись к ним как опечаткам, которые заметил читатель.
Нда. Исправляй дальше. Общаться с тобой по существу невозможно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Хочется услышать мнение народа о том как бы он хотел видеть паттерн перебора значений из некоторого диапазона.
А зачем тебе это?
Я вот нетак давно заморачивался вопросом что некоторые куски кода приходится повторять заново.
куски небольшие — как правило пару строк или что твой паттерн перебора.
Кто-то думает что решить эту проблему можно препроцессором (R#) или шаблонами (boost).
А мне кажется, что тут помогут Code-snippetы, жаль что для с++ их ещё не сделали.
Плюсы от их применения огромны.
1) стандартизация кода через шаблонные решения.
2) скорость чтения кода от применения узнаваемых решений.
3) автоматическая переконвертация кода под другой стиль.
Короче через 5 лет программер будет писать в своём коде паттерн в полюбившемся ему виде,
а при сдаче проекта другому программеру или заказчику маленькая программка переправит всё в соответствии со вкусами заказчика.
Здравствуйте, Sinclair, Вы писали:
S> В тех редких случаях, когда мне все же нужен именно индекс, я бы предпочел вообще отказаться от манипуляций с Length. Оптимально было бы так: S>
S>int[] a = new int[] {1, 2, 3, 4};
S>int weightedSum = 0;
S>foreach(int i in a.Indexes)
S> weightedSum += i*a[i];
S>
+1 за общую мысль, но мне не нравится реализация.
Один из частых случаев, когда нас интеерсует именно индекс — это заполнение значениями value-type массива.
Например:
struct SomeStruct {
public double a, b, c, d, e, f;
}
...
SomeStruct[] s = new SomeStruct[100];
for(int i = 0; i<s.Length; i++)
Fill(s[i]);
...
public void Fill(ref SomeStruct item) {}
Так вот, избавление от явного указания границ могло бы выглядеть так:
foreach(ref item in s)
Fill(item);
Красота!
S>Мне кажется, сама проблема использования диапазонов в значительной мере надумана. Во-первых, диапазон настолько часто приделан к коллекции, что проще сделать нарошные операции извлечения диапазона напрямую, чем давать человеку возможность ошибиться при "двухстадийной" схеме — сначала вытаскиваем границы, а потом формируем из них диапазон.
Угу, но все же лучше обойтись вообще без явных вытаскиваний диапазонов.
S>Во-вторых, все эти скобочки экономят буквально одиночные символы, в ущерб понятности и безошибочности. По мне, так гораздо лучше ввести необходимые функции-конструкторы диапазонов: S>Range(low, high) // для (1, 4) переберет 1, 2, 3, 4 S>ExclusiveRange(beforeLow, afterHigh) // для (1, 4) переберет (2, 3) S>Since(low) // для (1) будет перебирать 1, 2, 3, ... до бесконечности
Похоже в Nemerle можно будет всякого такого прикрутить
[]
_>Резюме. В перле приняли правильное решение — перебор элементов массива (без итераторов) foreach и универсальный сишный for.
из Programming Perl:
Ключевое слово foreach служит просто синонимом ключевого слова for, поэтому for и foreach можно использовать взаимозаменяемо и в зависимости от того, которое из них выглядит более удобочитаемым в конкретной ситуации.
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
i@len // for (int i = 0; i < len; i++)
i@len@2 // for (int i = 0; i < len; i+=2)
i@@len // for (int i = 0; i <= len; i++)
i@(len+1) // for (int i = 0; i <= len; i++)
gear nuke wrote:
> _>Резюме. В перле приняли правильное решение — перебор элементов массива > (без итераторов) foreach и универсальный сишный for. > > из Programming Perl: > Ключевое слово foreach служит просто *синонимом* ключевого слова for, > поэтому for и foreach можно использовать взаимозаменяемо и в зависимости > от того, которое из них выглядит более удобочитаемым в конкретной ситуации.
Я знаю, но какая лексема применяется — дело второе. Главное — две различные семантические конструкции:
Просто в этом треде обсуждали как лучше перебирать числа от нуля до n — ну не требуется это в большинстве практических
задач, максимум в учебных целях, когда человек ещё не понимает абстракцию "итератор".
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
я не сомневался
_>но какая лексема применяется — дело второе.
Со вторым не соглашусь. В Perl чего только не понапихали, с этим There is more than one way to do it. Казалось бы, что мешает наделать ещё пару десятков этих вариантов for, не пожалели же лишнюю лексему-синоним. А сделали всего 2. Должен же быть в этом всём какой-то смысл (учитывая, что P — это practical)
_>Просто в этом треде обсуждали как лучше перебирать числа от нуля до n — ну не требуется это в большинстве практических _>задач, максимум в учебных целях, когда человек ещё не понимает абстракцию "итератор".
Дык это как раз перебор всех элементов множества.
foreach(@a)
А точнее, вопрос был такой:
как должен выглядить идеальный синтаксис перебора значений из диапазона
А что такое диапазон множества, как не другое множество (срез от первого) ?
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