Так в чем же преимущества C #?

Инкапсуляция для одного. Если вы не установите последовательность итераций вручную, будет сложнее нарушить ограничения на количество итераций.

Пример C ++:

std::vector<int> a;
std::vector<int> b;
std::vector<int>::iterator ba = a.begin();
std::vector<int>::iterator ea = a.end();
std::vector<int>::iterator bb = b.begin();
std::vector<int>::iterator eb = b.end();
// lots of code here
for(auto itr = ba; itr != eb; itr++) // iterator tries to "cross" vectors
                                     // you get undefined behavior, depending 
                                     // on what you do with itr

Какой подход более эффективен (какой приводит к более элегантным функциям, основанным на на итераторах).

Это зависит от того, что вы подразумеваете под самым могущественным.

Подход C ++ более гибкий.

С C # труднее злоупотреблять.

Я думаю, что пока вы говорите только об итераторах forward , мне нравится способ C # - последовательность знает свой собственный предел, вы можете легко преобразовать ее через LINQ и так далее. Нет никакой пользы в том, чтобы ограничение было выражено отдельно, потому что нет никакого способа добраться до , кроме как пройти по одному элементу за раз.

Однако итераторы C ++ намного мощнее - вы можете иметь двунаправленные итераторы или итераторы с произвольным доступом, которые позволяют делать то, что невозможно с односторонним последовательным итератором. Последовательный итератор в некотором смысле является обобщением связанного списка , а итератор произвольного доступа является обобщением массива . Вот почему вы можете эффективно выражать алгоритмы, такие как быстрая сортировка, в терминах итераторов C ++, в то время как это было бы невозможно с IEnumerable .

Мне кажется, что дизайн C# более инкапсулирован: последовательность заканчивается или выполняется, не завися ни от чего другого. Где имеет смысл сравнивать одно ограничение с другим?

Если вы хотите взять только несколько элементов, то LINQ предоставляет любое количество способов построения одной последовательности из другой, например,

foo.Take(10)
foo.Skip(10)
foo.Where(x => x.StartsWith("y"))

etc

Я думаю, что яснее - и более композиционно - преобразовать одну последовательность в другую, чем указывать это с помощью ограничений. Если вы хотите передать итератор другой функции, но хотите ограничить его первыми несколькими элементами, почему вы должны также передавать ограничение? Почему бы просто не передать преобразованную последовательность, которая сама себя ограничивает?

EDIT: Чтобы ответить на ваш вопрос, отредактируйте его: в C# (по крайней мере, в LINQ) вы не будете изменять существующую коллекцию. Вы создадите новую последовательность из старой. Это делается лениво; не создается новая копия или что-то в этом роде. Для LINQ to Objects это выполняется с помощью методов расширения IEnumerable, поэтому любая последовательность получает те же возможности.

Обратите внимание, что это не ограничивается традиционными коллекциями - это может быть последовательность строк, считанных из файла журнала (опять же, лениво). Вам не нужно знать саму коллекцию, только то, что это последовательность, из которой можно брать элементы. Есть также разница между IEnumerable и IEnumerator, где первый представляет последовательность, а второй - итератор по последовательности; IEnumerator редко используется явно в C#, или передается по кругу.

Теперь, ваш пример "все элементы, кроме последних 10" является сложным, потому что для общей последовательности вы не можете сказать, что вы находитесь в 10 элементах от конца, пока не достигнете конца. В LINQ to Objects нет ничего, чтобы сделать это в явном виде. Для чего-либо, реализующего ICollection или ICollection, можно использовать

Bar(list.Take(list.Count - 10))

но это не очень общее решение. Более общее решение должно поддерживать круговой буфер из 10 элементов, эффективно читая на 10 впереди того места, куда он выходит. Честно говоря, я редко встречал такое требование.