Вот у Липпмана в книжке есть такой пример с описанием:



"Если возвращенный указатель равен адресу &ia[6] (который расположен за последним элементом массива), то поиск оказался безрезультатным, в противном случае значение найдено".

Но у меня как-то в памяти закрепилось, что обращение к памяти  "за последним элементом массива" не влечёт за собой ничего хорошего..

Или данный приём является нормальной практикой и не грозит неопределённым поведением?

Беглый поиск по интернетам и форуму мне не помог.

Ничего страшного не произойдёт, т. к. по этому индексу ничего не пишется и не читается.

То же самое и при использовании итераторов STL контейнеров:

Итератор v.begin() ведёт себя как правильный указатель, и по нему можно прочитать значение, а вот чтение или запись с помощью итератора v.end() приведёт к ошибке.

Это сообщение отредактировал(а) 586 - 25.9.2012, 01:18

Это было бы тогда так:

Вот разименовывание указателя *finishPtr и есть обращение к памяти. До разименовывания указатель представляет собой просто переменную, с целочисленным значением (по сути, номер байта в памяти процесса), 32-битную или 64-битную. Поэтому указателям можно присваивать произвольные значения (например, NULL), можно их сравнивать друг с другом и т.д.

В Вашем примере

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

Вы можете представить себе код функции find в таком виде:

Функция find при этом упрощена до предела. Обращения за пределы массива нет, хотя в случае неудачи возвращается указатель, не указывающий внутрь массива.

Впрочем, здесь есть подводные камни. При вызове find значение аргумента finishPtr может не быть выровненной по границе четырёх (или восьми) байт, то есть ((unsigned int) finishPtr) % 4 != 0 (при этом полагаю, что startPtr - выровнена):
В этом коде уже заложена ошибка, связанная с тем, что число прочитанных из сокета (а это может быть и файл, и устройство, и всё что угодно) байт не соответствует целому числу ожидаемых интегеров, например, когда bytes равно 10. Тогда мало того, что find в случае неуспеха вернёт не тот указатель (&buf[12] вместо нами проверяемых &buf[10]), так ещё и может найти наше искомое значение в &buf[8], хотя значения buf[10] и buf[11] представляют собой мусор.

Это сообщение отредактировал(а) feodorv - 25.9.2012, 01:45

> Почему в случае неудачи не возвращается NULL - это надо спросить Липпмана.
      

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

Вот что касается того, что речь идёт именно об индексе, который в действительности никак не влияет на память, этого я не увидел, почему-то сразу подумалось (сам додумал, чего в коде не написано  ), что читаются данные по этому адресу, хотя, конечно, форма представления адресов массива сразу показалась мне странной, оказывается в этом и было всё дело, она использована именно для наглядности.

Спасибо.

Добавлено @ 08:19
feodorv,  спасибо за объяснения.

Это сообщение отредактировал(а) NoviceF - 25.9.2012, 08:22

На самом деле find (впрочем, как и другие алгоритмы STL) работает не с итераторами, а с шаблонными параметрами, которые поддерживают операцию разыменования (*it), операцию ++ и сравнения друг с другом. Под эти требования замечательно подходят указатели, а итераторы просто имитируют поведение указателей.

и ещё. рекомендую делать не так

а так

if ( presult != ia + ia_count ) { OK } else { BAD }
думаю, понятно почему.

Если бы для меня всё было так очевидно  Это защита от того, что размер инта может быть разным на разных платформах, чтобы не обратиться к не существующему элементу массива по индексу?

нет. это защита от того, что завтра ты изменишь размер массива

Стандарт С++, глава 5.7 Additive operators:
Т.е. указатель, смотрящий сразу за границу массива вполне валиден, но не далее.

Чешу репу. Что значит "валидный указатель" в данном контексте?
Я понял отрывок так, что если вычислить указатель Q, равный P плюс несколько элементов массива, то получим указатель, значение которого больше значения P, даже если Q станет смотреть сразу за границу массива. Если же переборщить, то может произойти переполнение значения Q, и Q может стать меньше P.
Возможно, такое понимание является игрой моего воображения, поправьте, если чо...

Насколько я понимаю, имелось в виду следующее. Если у нас есть массив типа int a[10];, то мы можем свободно использовать в адресной арифметике указателями от &a[0] до &a[10] включительно. При этом будут получаться указатели с вполне ожидаемым поведением (в том числе и ожидаемыми результатами их сравнения). Если же мы попытаемся вычислить &a[11] - то это уже UB

Добавлено через 1 минуту и 17 секунд

Более того, он вполне может стать чем угодно, NULL например   

Проще говоря, на 16-ти битных платформах можно создать массив из 65535 чаров. При этом индекс 65535 валиден, но выходит за границу массива. Следующий же индекс должен быть 65536, но будет 0. А это уже валидный индекс внутри массива. В итоге, программа его использующая, будет работать не так, как ожидалось.

в новом стандарте можно даже так:

xvr, bsa, спасибо!
Именно так я и понял))) Речь идёт именно о неожиданном переполнении значения указателя. Пока значение указателя не переполнилось, мы можем спокойно его сравнивать с другим указателем. Иначе - сюрприз.



Вот. Сочетание "валидный указатель", всё же, соотносится с понятием "разименовывание указателя", не?



Гм. В плоской модели памяти поведение указателя при сдвиге предсказуемо, совсем "чем угодно" он стать не может))) И в этом смысле (void *) 4 ничуть не лучше или хуже чем просто NULL)))

Не. Например NULL - вполне себе валидный указатель, но разименовывать его явно нельзя