Erop wrote:

>> > Для хранения строк обычно используют всё-таки хеш таблицы, а не деревья.
> .>Просто hash_map нестандарна...
> Конечно это это плюс STL. Что же ещё?
> Людям, как обычно нужно, не чтобы стандартно, а чтобы работалось и
> дёшево переносилось
> Можно хоть свой собственный hash_map с собой таскать всегда
Если надо, то можно использовать. Просто Шахтёр так уж очень категорично заявил — что ваще map фтопку.
Вообще странное заявление. Ведь это разные структуры данных, с разными вариантами использования, нельзя сказать, что
одно правильно, другое нет.

>> > Кроме того, string может иметь дорогой оператор копирования. Именно
>> > поэтому его нельзя использовать для работы с большим массивом строк.
>> > Плюс фрагментация памяти.
> .>Тут же string в качестве ключа используется, копирование при помещении
> в map всё равно будет. Какая разница?
> Ну так в std::map<std::string> обычно есть где-то в недрах аналог
> std::vector<std::string>. а std::vector любит время от времени
Кто тебе сказал? Там обычное дерево, по устройству скорее всего ближе к std::list.

> копировать свои потроха, при этом std::string обычно копируется
> задорого, да ещё и кучу фрагментирует как подорванное
Думаю, там всё сводится к memcpy. А насчёт кучи... Трудно что-то определённое сказать, всё очень implementation defined.

> .>Со строками до нескольких килобайт думаю большой разницы не будет.
> memcmp работает очень быстро.
> Ну попробуй, например, родить hash_map и map для словника английского
> языка например.
> Узнаешь много интересного
Для словаря всё равно разумнее map использовать, т.к. частенько требуется иметь список слов отсортированный в
лексикографическом формате, а не как попало в хеше.

ЗЫЖ Хватит смайлики сообщениям в rsdn.cpp расставлять, нашел повод для веселья.

Здравствуйте, ., Вы писали:

.>Кто тебе сказал? Там обычное дерево, по устройству скорее всего ближе к std::list.
Да всё равно вроде сортируют
Да и аллокаций вагон, кстати.

.>Думаю, там всё сводится к memcpy. А насчёт кучи... Трудно что-то определённое сказать, всё очень implementation defined.
Ну да. Это ещё больше портит картину, если требуется переносимость. Конечно то, что у тебя типа всё соответсвует стандарту и типа работает, но на одной платформе нормально работает, а на другой куча фрагментируется в каку и получается просто один своп, вместо работы программы, то что делать дальше -- . А то, что теоретики C++ при этом с умным видом говорят "ну это у вас реализация STL такая" конечно же помогает офигительно

.>Для словаря всё равно разумнее map использовать, т.к. частенько требуется иметь список слов отсортированный в
.>лексикографическом формате, а не как попало в хеше.

Да? И зачем тебе отсортированный словник ангилйского языка "частенько"?
Читать на пенсии?

.>ЗЫЖ Хватит смайлики сообщениям в rsdn.cpp расставлять, нашел повод для веселья.
Так ведь смешно же

Erop wrote:

> .>Кто тебе сказал? Там обычное дерево, по устройству скорее всего ближе
> к std::list.
> Да всё равно вроде сортируют
Ну почитай исходники что-ли, да разберись как оно работает.
Обычно сделано это: http://en.wikipedia.org/wiki/Red_Black_Tree

> Да и аллокаций вагон, кстати.
У тебя какой-то аллокатор особенный? При каждом вызове аллокации тебя бьёт током?

> .>Думаю, там всё сводится к memcpy. А насчёт кучи... Трудно что-то
> определённое сказать, всё очень implementation defined.
> Ну да. Это ещё больше портит картину, если требуется переносимость.
> Конечно то, что у тебя типа всё соответсвует стандарту и типа работает,
> но на одной платформе нормально работает, а на другой куча
> фрагментируется в каку и получается просто один своп, вместо работы
> программы, то что делать дальше -- . А то, что теоретики C++ при этом с
> умным видом говорят "ну это у вас реализация STL такая" конечно же
> помогает офигительно
Профайлер. Только профайлер.
Premature optimization is the root of all evil! (c)
А при реализации надо пользоваться только сложностными характеристиками алгоритмов.

> .>Для словаря всё равно разумнее map использовать, т.к. частенько
> требуется иметь список слов отсортированный в
> .>лексикографическом формате, а не как попало в хеше.
> Да? И зачем тебе отсортированный словник ангилйского языка "частенько"?
> Читать на пенсии?
Погляди как показывается список слов в той же Lingvo — отсортированный список с поиском as you type.

> .>ЗЫЖ Хватит смайлики сообщениям в rsdn.cpp расставлять, нашел повод для
> веселья.
> Так ведь смешно же
Может в rsdn.humor обсуждения перенести?

Здравствуйте, ., Вы писали:

>> но на одной платформе нормально работает, а на другой куча
>> фрагментируется в каку и получается просто один своп, вместо работы
>> программы, то что делать дальше -- . А то, что теоретики C++ при этом с
>> умным видом говорят "ну это у вас реализация STL такая" конечно же
>> помогает офигительно
.>Профайлер. Только профайлер.
.>Premature optimization is the root of all evil! (c)
.>А при реализации надо пользоваться только сложностными характеристиками алгоритмов.
Очень хорошо. Вызванный фрагментацией своп и без профайлера прекрасно заметен обычно
А вот как профайлер помогает в борьбе с ним --
Я был бы рад узнать методы

А вообще-то я ведь заранее написал конспект твоего ответа Он там сверху выделен...

.>Погляди как показывается список слов в той же Lingvo — отсортированный список с поиском as you type.
Хе-хе-хе. Я как-то читал исходники лингво. Там про STL ни слова и про структуры подобные std::map -- тоже
Там всё совсем-совсем иначе... Кроме того, там ещё и объединённый словник нескольких словарей...

Можешь, кстати, поинтересовать как там скролл работает... В смысле попробовать поскролировать разными способами...

---

.>Может в rsdn.humor обсуждения перенести?
Ну можешь попробовать

Здравствуйте, Erop, Вы писали:

RO>>Предлагаю реализовать аналог std::deque без итераторов.
E>А в чём проблема?

std::deque<X> xs;

for(std::deque<X>::const_iterator i = xs.begin(), i_e_ = xs.end(); i != i_e_; ++i)
{
    . . .
}

---

your::deque<X> xs;

for . . . ?

Здравствуйте, Roman Odaisky, Вы писали:

RO>Здравствуйте, Erop, Вы писали:

RO>>>Предлагаю реализовать аналог std::deque без итераторов.
E>>А в чём проблема?

RO>

RO>std::deque<X> xs;

RO>for(std::deque<X>::const_iterator i = xs.begin(), i_e_ = xs.end(); i != i_e_; ++i)
RO>{
RO>    . . .
RO>}
RO>

RO>

---

RO>

RO>your::deque<X> xs;

RO>for . . . ?
RO>

Зависит от того, что тебе надо
Например так:

namespace my {
    template<class T>
    class deque {
    public:
        ...
        void PushFront( const T& t )
        {
            if( firstelemntIndex <= 0 )
                allocSpaceInFront( size() );
            assert( firstelemntIndex > 0 );
            allocSpaceInFront--;
            data[allocSpaceInFront] = t;
        }
        void PushBask( const T& t ) { data.push_back( t ); }
        void PopFront() { assert( size() > 0 ); firstelemntIndex++; } 
        void PopBack() { assert( size() > 0 ); data.pop_back; }
        
        const T& operaotr[]( int i ) const { assert( i >= 0 && i < size() ); return data[i + firstelemntIndex] }
        int size() const { assert(firstelemntIndex);  return elems.size() - firstelemntIndex; }
        ...
    private:
        std::vector<T> elems;
        int firstelemntIndex;
        ...

    };
}

Здравствуйте, Erop, Вы писали:
АТ>>Это опасность "по невнимательности". Таких опасностей в С++ много и недостаками они в рамках идеологии С++ считаются не должны.
АТ>>Ошибки при использовании беззнаковых типов (в т.ч. в примерах ниже) обусловлены обычно 1) невнимательностью и 2) неоправданным смешением знаковых и беззнаковых типов. По этой причине, аргументами их считать сложно.
АТ>>Реальный способ тут только один — учиться пользоваться беззнаковыми типами как можно раньше.
АТ>>"Страховочное" использование знаковых типов допустимо для начинающего программиста, но не более.
E>Это первая группа комментов. Если коротко, то так: "Увольте всех невнимательных программистов и напишите, наконец, прекрасную программу "Hellow World!" в одинчку. Внимательно, правильно и без этих всех глупых и труднообнаружимых ошибок!
E>Так?
Если посмотреть на контрпримеры, то мне кажеться, что знаковость осмысленно используется только в значении -1 как признак того, что поиск неудачен.
Чем это лучше чем string::npos или vector::end()
Писать меньше? Но чем -1 лучше чем -10? Как отличить признак неудачи поиска от честной константы? Что делать в случае передачи отрицательного индекса в массив?
И таки исходный вопрос: многие ли операции в ваших программах действительно требуют работы со знаковыми типами и итераций по ним?

E>

---

АТ>>Слабый и странный "минус".
АТ>>Неочевидно. Если и минус, то очень слабый.
АТ>>По-моему это вопрос качества реализации. Нет?
АТ>>Нет. Не вижу в этом минуса. А придумать ситуацию, когда это неудобно можно всегда.
АТ>>В общес случае — нельзя. Но это ограничение имеет свои оправдания, свои плюсы и минусы. Странно видеть его в качестве "минуса".
E>Вторая большая группа "возражений". В переводе на русский: "Я не понял или не знаю что сказать"
По моему, всю эту группу вообше нельзя к минусам относить...
Чем has_elems лучше empty (кроме привычки к MFC)?
Зачем понадобиться конст-кастить итераторы (кроме плохого дизайна)?
Зачем нужен дополнительный '\0' в строке, которая может содержать любое количество этих '\0' (дополнить самому, если это так надо, религия не позволяет)?

E>

---

E>Выводы:
E>А выводы-то всё те же. Что мы видим с вами?
Что не надо пытаться применять подходы pure-C в STL.
Что в С-with-classes без шаблонов и исключений STL не только не нужен а даже, наверное, вреден.

P.S. Может я ошибаюсь, но если говорить про кадры, по моему проще выставить знание STL в требовании к вакансии и задать пару вопросов на собеседовании, чем приняв человека несколько месяцев обучать его работе с аналогом STL собственного изготовления.

Здравствуйте, strcpy, Вы писали:
IID>>Вы серъезно так думаете о С++ программистах ?
S>У нас в мухоср... Новосибирске ситуация именно такая.
А у нас в "мухоср... Новосибирске" ровно наоборот.

Здравствуйте, strcpy, Вы писали:
S>Мало квалифицированнах программистов, которые владеют STL.
S>Поэтому код на STL рискует стать трудносопровождаемым.
Как-то не представляется квалифицированный программист на С++ не владеющий STL.
Либо квалификация не очень, либо STL знает.

Здравствуйте, Tonal-, Вы писали:

T>Если посмотреть на контрпримеры, то мне кажеться, что знаковость осмысленно используется только в значении -1 как признак того, что поиск неудачен.
Странно. А вычисления с участием вычитания они типа редскость астрашенная?

T>И таки исходный вопрос: многие ли операции в ваших программах действительно требуют работы со знаковыми типами и итераций по ним?
Практически любое целое число в моих программах может оказаться отрицательным.
Пример такого числа: качество чего-нибудь. Если что-то получилось совсем плохо и качество отрицательное -- это повод для assert'а, а не для того, чтобы радоваться тому, что качество получилось где-то рядом с UINT_MAX
Ещё пример такого числа -- координаты точки (например на экране): x и y. И опять, хотя пикселей с отрицательными значениями коорлдинат не существует, тем не менее разность координат я хочу видеть знаковую, да и координаты углов окна, например, тоже
Вдруг я кусок окна задвину за границу экрана?
Ну и так дадее. Совершенно повсеместно. Специально для случая с индексом я приведу тебе один пример. А вообще-то был тут где-то недалеко здоровычй флейм про беззнаковые числа. Пиши туда?

for( int i = myArr.Size() - 5; i >= 0; i -= step )
    sum += myArr[i];

E>>

---

АТ>>>Слабый и странный "минус".
АТ>>>Неочевидно. Если и минус, то очень слабый.
АТ>>>По-моему это вопрос качества реализации. Нет?
АТ>>>Нет. Не вижу в этом минуса. А придумать ситуацию, когда это неудобно можно всегда.
АТ>>>В общес случае — нельзя. Но это ограничение имеет свои оправдания, свои плюсы и минусы. Странно видеть его в качестве "минуса".
E>>Вторая большая группа "возражений". В переводе на русский: "Я не понял или не знаю что сказать"
T>По моему, всю эту группу вообше нельзя к минусам относить...
T>Чем has_elems лучше empty (кроме привычки к MFC)?
T>Зачем понадобиться конст-кастить итераторы (кроме плохого дизайна)?
T>Зачем нужен дополнительный '\0' в строке, которая может содержать любое количество этих '\0' (дополнить самому, если это так надо, религия не позволяет)?

ИМХО пример плохого дизайна -- это весь шаблон basic_string. Он позволяет создать некую, довольно безумную абстракцию, но совсем не позволяет создать строку в традиционном понимании этого слова
В принципе мне религия позволяет пойти ещё дальше и не то чтобы нолики куда-то добавлять, а вообще пользоваться другой C++ строкой
Вообще-то мне хочется, чтобы в строчке хранились символы. Ну на крайняк хитрые символы. Но таки символы.
Кроме того, мне хотелось бы, чтобы нули были толкьо в конце и т. д.

E>>

---

E>>Выводы:
E>>А выводы-то всё те же. Что мы видим с вами?
T>Что не надо пытаться применять подходы pure-C в STL.
T>Что в С-with-classes без шаблонов и исключений STL не только не нужен а даже, наверное, вреден.
Проблема в том, что то, что ты называешь С-with-classes не такой уж плохой язык. А шаблоны -- страшная всё-таки хреновина. Ну вот STL всё равно с нами. И всегда сложный. Даже если ты с шаблорнами пишешь, то всё равно он сожный

T>P.S. Может я ошибаюсь, но если говорить про кадры, по моему проще выставить знание STL в требовании к вакансии и задать пару вопросов на собеседовании, чем приняв человека несколько месяцев обучать его работе с аналогом STL собственного изготовления.
К сожалению так сделать нельзя. Просто потому что STL код реально плохо предсказуемо взрывается. А ещё потому, что для программирования всяких роеальных задач STL хронически мало. Так что всё равно прийдётся искать/учить ещё какую-нибудь хреновину
Ну а буст, ИМХО, совсем неприемлемо сложен и непредсказуем. Увы

Здравствуйте, Tonal-, Вы писали:

T>Как-то не представляется квалифицированный программист на С++ не владеющий STL.
T>Либо квалификация не очень, либо STL знает.

Я бы осмелился сказать, что навык "квалифицированный программист" он внеязыковой.
То есть я с бОльшей радостью возьму себе сотрудника, который вообще не занет C++, но зато квалифицированный программист

А знание STL подразумевается у квалифицированного кодера на C++. При этом наш опыт кажет, что эти "квалифицированные кодеры" нихрена не "квалифицированные программисты". Мало того, второй навык похоже мешает вырабатываться первому Мне кажется, что это так из-за неправильной системы ценностей

Здравствуйте, gid_vvp, Вы писали:

_>перечислите, на ваш взгляд, основные минусы STL
_>принимаются только ответы с аргументацией

Не бывает просто абстрактных "минусов". Бывают положительные и отрицательные свойства технологии применительно к конкретно заданной области применения. Я считаю, что STL и так создан на пределе возможностей C++, так что там, где он не достаточно хорош, там вина C++ а не собственно STL.

Здравствуйте, CrazyClown, Вы писали:

CC> Не бывает просто абстрактных "минусов". Бывают положительные и отрицательные свойства технологии применительно к конкретно заданной области применения. Я считаю, что STL и так создан на пределе возможностей C++, так что там, где он не достаточно хорош, там вина C++ а не собственно STL.

В целом я согласен с выделенным тезисом, но не согласен с выводами.
ИМХО STL наоборот в большинстве случаев он слишком хорош
Типа обычно можно и проще. Занчит лучше делать таки проще

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Tonal-, Вы писали:

T>>Если посмотреть на контрпримеры, то мне кажеться, что знаковость осмысленно используется только в значении -1 как признак того, что поиск неудачен.
E>Странно. А вычисления с участием вычитания они типа редскость астрашенная?
Мы же не про вычисления вообще, а про итерации по контейнерам и адресацию в них, правильно?
А в этом разрезе, отрицательные величины как-то странненько смотряться.
Чем поведение контейнера при адресации [-10] должно отличаться от [4294967286]?

T>>И таки исходный вопрос: многие ли операции в ваших программах действительно требуют работы со знаковыми типами и итераций по ним?
E>Практически любое целое число в моих программах может оказаться отрицательным.
Т.е. количество пользователей -5чел — вполне нормальная ситуация?

E>Пример такого числа: качество чего-нибудь. Если что-то получилось совсем плохо и качество отрицательное -- это повод для assert'а, а не для того, чтобы радоваться тому, что качество получилось где-то рядом с UINT_MAX
Этот ассерт будет не более информативен, чем сравнение с UINT_MAX/2 для беззнаковых.
А вот если в нём действительно будет проверяться допустимый ожидаемый диапазон...

E>Ещё пример такого числа -- координаты точки (например на экране): x и y. И опять, хотя пикселей с отрицательными значениями коорлдинат не существует, тем не менее разность координат я хочу видеть знаковую, да и координаты углов окна, например, тоже
E>Вдруг я кусок окна задвину за границу экрана?
Опять же, часто ли ты эти отрицательные координаты используються для индексации массива?

E>Ну и так дадее. Совершенно повсеместно. Специально для случая с индексом я приведу тебе один пример. А вообще-то был тут где-то недалеко здоровычй флейм про беззнаковые числа. Пиши туда?
E>

for( int i = myArr.Size() - 5; i >= 0; i -= step )
E>    sum += myArr[i];

Чуть длиннее:

if (myArr.Size() > 5)
  accumulate(advance(myArr.rbegin(), 5), myArr.rend(); sum);

По моему, проблема тут таки не в STL, а в некотором смешении понятий:
Целое число как абцисса и как индекс в массиве это совершенно разные типы.
В первом случае знак вполне осмыслен, во втором нет.
То что часто их представляют одинаковым типом в языке — можно отнести к недостаткам языка.
В STL ввели итераторы — это представление позиции в контейнере. Т.е. попытка исправить этот недостаток.
Код с итераторами действительно становиться более безопасный в плане выхода за граници, как только это понимаешь.

E>>>

---

T>>Зачем нужен дополнительный '\0' в строке, которая может содержать любое количество этих '\0' (дополнить самому, если это так надо, религия не позволяет)?
E>ИМХО пример плохого дизайна -- это весь шаблон basic_string. Он позволяет создать некую, довольно безумную абстракцию, но совсем не позволяет создать строку в традиционном понимании этого слова

E>>>

---

E>>>Выводы:
E>>>А выводы-то всё те же. Что мы видим с вами?
T>>Что не надо пытаться применять подходы pure-C в STL.
T>>Что в С-with-classes без шаблонов и исключений STL не только не нужен а даже, наверное, вреден.
E>Проблема в том, что то, что ты называешь С-with-classes не такой уж плохой язык. А шаблоны -- страшная всё-таки хреновина. Ну вот STL всё равно с нами. И всегда сложный. Даже если ты с шаблорнами пишешь, то всё равно он сожный
Я не утверждаю что он плохой.
Он несколько другой.
Ну и код, с применением шаблонов часто получается компактнее и быстрее.
Ну а понимание — дело наживное.

T>>P.S. Может я ошибаюсь, но если говорить про кадры, по моему проще выставить знание STL в требовании к вакансии и задать пару вопросов на собеседовании, чем приняв человека несколько месяцев обучать его работе с аналогом STL собственного изготовления.
E>К сожалению так сделать нельзя. Просто потому что STL код реально плохо предсказуемо взрывается. А ещё потому, что для программирования всяких роеальных задач STL хронически мало. Так что всё равно прийдётся искать/учить ещё какую-нибудь хреновину
E>Ну а буст, ИМХО, совсем неприемлемо сложен и непредсказуем. Увы
С предсказуемостью и переносимостью спорить не буду.
Но опять же — это не проблемы STLя и даже не стандарта, как такового...
Перенос сколько-нибудь сложного кода даже между разными компиляторами дело не лёгкое.
И если для поддерживаемой платформы нет вменяимого компилятора, то даже идеальная стандартная библиотека не поможет...
Другое дело, что собственный код в таком случае проще адаптируется.

Здравствуйте, Erop, Вы писали:

E>В целом я согласен с выделенным тезисом, но не согласен с выводами.
E>ИМХО STL наоборот в большинстве случаев он слишком хорош
E>Типа обычно можно и проще. Занчит лучше делать таки проще

Делать проще громоздкий синтаксис C++ не позволяет. Так что приходится делать так, как делает STL.

Конечно же, на каждый случай применения STL найдутся сотни частных случаев, когда можно сделать проще и тупее — ну так это беда любого слишком общего решения.

Здравствуйте, Tonal-, Вы писали:

T>Здравствуйте, strcpy, Вы писали:
S>>Мало квалифицированнах программистов, которые владеют STL.
S>>Поэтому код на STL рискует стать трудносопровождаемым.
T>Как-то не представляется квалифицированный программист на С++ не владеющий STL.
T>Либо квалификация не очень, либо STL знает.

А зачем "знать" STL если её не использовать?
Точно так же можно сказать, что то кто не знает MFC -- неквалифицированный программист.

Знать нужно не STL, а приёмы программирования , в том числе и те, которые в STL используются.
Ну и разумеется, знать алгоритмическую базу.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, Андрей Тарасевич, Вы писали:

АТ>Это неверно. В STL-контейнерах никак не используется 'size_t'. Используется же там контейнерно-зависимый беззнаковый тип 'size_type'. Использование беззнакого типа вполне оправдано, ибо соответствует он заведомо неотрицательному значению. В данном случае наблюдается следование правилу "всегда использовать в программе только беззнаковые типы, кроме тех мест, где необходим знаковый тип", что более чем похвально.

1 — Софистика — нельзя априори говорить о значении, мы отлаживаем программу и может быть все что угодно

2 На соседней ветке Вы говорили об том что беззнаковые вычисления более быстрые. Все с точностью наоборот. Для целых они попросту одинаковы. А преобразования из в плавающие могут быть выполнены одной командой для знаковых.

3 Сравнений беззнаковых не существует, уж не знаю что там в стандардарте. Я пишу всегда проверу для индексов 0<=I && I<N . По идее это можно заменить на одну проверку signed(I)<N.

НО

  unsigned U=-10,U0=1;
  if(U<100)
    U+=U0;
  else
    U-=U0;

дает else как и

  unsigned U=-10,U0=1;
  if(U<100u)
    U+=U0;
  else
    U-=U0;

В MSDN написано что если одно беззнаковое то все беззнаковые тем не менее.

Вот еще код из MS vecto

    void _Ufill(iterator _F, size_type _N, const _Ty &_X)
        {for (; 0 < _N; --_N, ++_F)
            allocator.construct(_F, _X); }

тоесть беззнаковых операций сравнения не существует, уж не знаю как там по стандару. Возможно они есть у МС по какомуту ключу компилятора. Но это уже не актуально

баг ...
P>3 Сравнений беззнаковых не существует, уж не знаю что там в стандардарте. Я пишу всегда проверу для индексов 0<=I && I<N . По идее это можно заменить на одну проверку UNsigned(I)<N.

Здравствуйте, Tonal-, Вы писали:

T>Опять же, часто ли ты эти отрицательные координаты используються для индексации массива?

E>>Ну и так дадее. Совершенно повсеместно. Специально для случая с индексом я приведу тебе один пример. А вообще-то был тут где-то недалеко здоровычй флейм про беззнаковые числа. Пиши туда?
E>>

for( int i = myArr.Size() - 5; i >= 0; i -= step )
E>>    sum += myArr[i];

T>Чуть длиннее:
T>

if (myArr.Size() > 5)
T>  accumulate(advance(myArr.rbegin(), 5), myArr.rend(); sum);

Что характерно, step !всегда= 1 и std::advance принимает ссылку. Понятно, что это не так уж и существенно, и что Boost решает обе проблемы, но не надо бежать впереди паровоза.

А с другой стороны, если вышеуказанное должным образом переделать в итераторы, то оно будет работать любыми итераторами, включая std::list-овые.

Здравствуйте, Андрей Тарасевич, Вы писали:
P>3 Сравнений беззнаковых не существует, уж не знаю что там в стандардарте. Я пишу всегда проверу для индексов 0<=I && I<N . По идее это можно заменить на одну проверку signed(I)<N.

Пардон все правильно действительно можно и быстрей беззнаково Ошибся — наверно плохо отдохнул