>Скажу больше. Стандарт не гарантирует корректность работы программы, содержащей неопределенное поведение. Вообще, всей программы, понимаешь? Даже i++ не гарантируется, если ты где-то разыменовываешь нулевой указатель.
С тем же успехом можно утверждать, что NULL указателей не существует, потому что разыменование такого указателя — есть пример неопределённого поведения.
собссно, это не имеет отношение к топику...
было сказало, что отличие ссылки от указателя в том, что ссылка не может быть NULL, на что был приведен пример, что это не так, только и всего.
Определённое это поведение или нет — в данном случае неважно.
Здравствуйте, Вумудщзук, Вы писали:
В>С тем же успехом можно утверждать, что NULL указателей не существует, потому что разыменование такого указателя — есть пример неопределённого поведения.
Это утверждение неверно. Запрет на разыменование нулевого указателя не запрещает существование такого указателя.
С нулевым указателем можно производить много других вещей, кроме разыменования, например, сравнение с другими указателями.
Объектов же по нулевому адресу не существует.
В>собссно, это не имеет отношение к топику... В>было сказало, что отличие ссылки от указателя в том, что ссылка не может быть NULL, на что был приведен пример, что это не так, только и всего.
В>Определённое это поведение или нет — в данном случае неважно.
Если ты не собираешься эту программу запускать — да, это не важно.
Но если ты ее все-таки запустишь — у тебя может отформатироваться винчестер, и об этом нужно помнить.
Здравствуйте, jazzer, Вы писали:
>>> K>Зато он опрокидывает утверждение-гарантию, что референсов >>> K>на NULL не бывает. Бывают, хотя и не гарантированно. >>> >>> В программе, содержащей только определенное поведение, таких ссылок не >>> бывает. А объектов не бывает никогда, по определению.
K>>The important thing about this plan is to remember K>>that nothing can go wrong. (c) Вузи, GTA:SA.
J>Именно так.
J>Стандарт специфицирует только поведение программы, не содержащей неопределенного поведения. J>Если неопределенное поведение есть — программа может вести себя как угодно. J>Как известно, обычно она просто форматирует винчестер.
Что-то у меня такое подозрение, что 100% моих программ имеют неопределенное поведение, если пройтись с ними по стандарту. Особенно если учесть, что на самом нижнем уровне они всё равно работают с C-style API, преобразуют всё в void* и обратно, когда передают callbacks etc.
>Если ты не собираешься эту программу запускать — да, это не важно.
Ты живёшь в выдуманном мире, где всё идеально, всё по стандарту, и никто не совершает ошибок.
Начнём с того, что компайлеры не в полной мере соответствуют стандарту. Так что с точки зрения стандарта 100% — Delta прог имеют неопределённое поведение.
Но это всё высокие материи... Пусть какая-нть third-party либа вызывает callback в твоём коде и один из параметров этого callback'а — надо ж такому случится — не указатель, а ссылка. Будь это указатель, ты б, конечно, проверил, NULL он или нет ("мало ли, кто писал этот код, проверить стоит на всякий случай..."). А со ссылкой что делать бум? Можешь ли ты быть уверен, что эта ссылка указывает именно на объект, а не на NULL?
>подними мне веки, плиз, — где там объект по адресу 0? Не вижу никакого объекта. Вижу только нулевой указатель.
Опять же — с точки зрения этого callback'a передана ссылка на объект, а то, что его адрес равен NULL, скажет винда в виде окошка с error'ом.
Здравствуйте, Кодёнок, Вы писали:
Кё>Особенно если учесть, что на самом нижнем уровне они всё равно работают с C-style API, преобразуют всё в void* и обратно, когда передают callbacks etc.
Каст к void * и обратно не вносит в программу неопределенного поведения.
Принцип работы с указателями и ссылками очень простой — они должны ссылаться на реальные существующие объекты, тогда никаких проблем первого порядка не возникнет.
Здравствуйте, Вумудщзук, Вы писали:
В>Но это всё высокие материи... Пусть какая-нть third-party либа вызывает callback в твоём коде и один из параметров этого callback'а — надо ж такому случится — не указатель, а ссылка. Будь это указатель, ты б, конечно, проверил, NULL он или нет ("мало ли, кто писал этот код, проверить стоит на всякий случай..."). А со ссылкой что делать бум? Можешь ли ты быть уверен, что эта ссылка указывает именно на объект, а не на NULL?
Herb Sutter, Jim Hyslop, Conversations 02 — Null References (кстати говоря, вся серия дико рулит и рекомендуется к прочтению).
“No,” the Guru’s quiet voice startled us both. Once again, she had appeared at the right moment, and now stood behind us, an open tome in hand. “There is no need of such an abomination. The Standard teaches that it is not possible to have null references.”
“But it is possible, dearie,” Bob insisted. “We’ve just shown that. That’s his problem.”
I wanted to smack him. The Guru merely favored him with a chill glare. “No. You should check for that. Never dereference a null pointer. Change your code: If the pointer is null, do not call helper(). Show me the working code this afternoon. Begone, you instrument of malformed programs,” she waved him away.
[…]
“Just as you must assume that a non-null pointer is valid, you must assume that a reference is valid. You must have faith in your fellow programmers.”
“Even Bob?” I asked.
She nodded with an air of sadness, then drifted quietly away down the corridor, reading her tome.
Здравствуйте, jazzer, Вы писали:
J>Принцип работы с указателями и ссылками очень простой — они должны ссылаться на реальные существующие объекты, тогда никаких проблем первого порядка не возникнет.
Разыменование нулевого указателя это понятное дело ошибка программиста и как следствие, неверная программа. Но чем нулевой отличается от прочего невалидного? Почему нулевому такое внимание?
Странно как-то это звучит. Цель указателя может быть уничтожена чужим кодом, даже по ошибке. Но тут стандарт молчит. Собственно, какая тогда ценность замечания про неопределенное поведение? Можно было просто сказать, разыменование указателя может привести к неопределенному поведению?
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, jazzer, Вы писали:
J>>Принцип работы с указателями и ссылками очень простой — они должны ссылаться на реальные существующие объекты, тогда никаких проблем первого порядка не возникнет.
Кё>Разыменование нулевого указателя это понятное дело ошибка программиста и как следствие, неверная программа. Но чем нулевой отличается от прочего невалидного? Почему нулевому такое внимание?
C невалидным указателем ты вообще ничего не можешь делать, даже сравнивать с ним не можешь. Ты можешь только присвоить ему какое-нть значение.
С нулевым же ты сравнивать можешь.
Кё>Странно как-то это звучит. Цель указателя может быть уничтожена чужим кодом, даже по ошибке. Но тут стандарт молчит.
Если стандарт по какому-то случаю молчит, значит, он никак не определяет поведение программы, значит, это — неопределенное поведение.
Кё>Собственно, какая тогда ценность замечания про неопределенное поведение? Можно было просто сказать, разыменование указателя может привести к неопределенному поведению? :)
Можно так сказать, но эти слова не несут никакого смысла.
Имеет смысл выражаться точнее: разыменование указателя не приводит к неопределенному поведению, если он указывает на объект в программе (или подобъект). А неопределенное поведение будет во всех остальных случаях, как то: разыменование нулевого или неинициализированного указателя, т.е. когда указатель содержит адрес, по которому никаких объектов нет, либо указатель на разрушенный объект, потому что после разрушения объект он, очевидно, не существует...
Здравствуйте, jazzer, Вы писали:
J>C невалидным указателем ты вообще ничего не можешь делать, даже сравнивать с ним не можешь. Ты можешь только присвоить ему какое-нть значение. J>С нулевым же ты сравнивать можешь.
Могу. Я например, передаю в STL-алгоритм указатель на первый элемент (в качестве итератора) и указатель на элемент после последнего. Что, я неверно использую STL? Если сравнение с невалидным указателем неопределенное поведение, тогда я точно уверен, что мои программы имеют неопределенное поведение А следовательно, ценность этого понятия становится нулевой — ведь они же работают, их используют.
Кё>>Странно как-то это звучит. Цель указателя может быть уничтожена чужим кодом, даже по ошибке. Но тут стандарт молчит. J>Если стандарт по какому-то случаю молчит, значит, он никак не определяет поведение программы, значит, это — неопределенное поведение.
Вот это и странно. Отличный код с известным, понятым и совершенно определенным поведением называют каким-то плохим словосочетанием Может все-таки надо по-другому говорить — зависит от реализации, например. Зависит от контекста.
Кё>>Собственно, какая тогда ценность замечания про неопределенное поведение? Можно было просто сказать, разыменование указателя может привести к неопределенному поведению?
J>Можно так сказать, но эти слова не несут никакого смысла. J>Имеет смысл выражаться точнее: разыменование указателя не приводит к неопределенному поведению, если он указывает на объект в программе (или подобъект). А неопределенное поведение будет во всех остальных случаях, как то: разыменование нулевого или неинициализированного указателя, т.е. когда указатель содержит адрес, по которому никаких объектов нет, либо указатель на разрушенный объект, потому что после разрушения объект он, очевидно, не существует...
Он может содержать указатель на объект, созданный в другом модуле, к коду которого компилятор и программист не имеют доступа. Модульность — обычное дело. Т.е. нельзя логически вывести валидность указателя из текста программы. В этом суть указателя. Что тогда, вся программа имеет неопреденное поведение? Какая ценность тогда этого определения, какую информацию оно несет?
stasan wrote:
> C> Herb Sutter, Jim Hyslop, Conversations 02 - > C> Null References <http://www.gotw.ca/conv/002.htm> (кстати > C> говоря, вся серия дико рулит и рекомендуется к прочтению). > Поддерживаю! Первое, что читаю в свежем номере CUJ. Особенно нравиться > момент, > когда в комнату заходит гуру и...
Кстати, а можно ли как-нибудь подписаться на CUJ через нашу Российскую
Почту?
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, jazzer, Вы писали:
J>>C невалидным указателем ты вообще ничего не можешь делать, даже сравнивать с ним не можешь. Ты можешь только присвоить ему какое-нть значение. J>>С нулевым же ты сравнивать можешь.
Кё>Могу. Я например, передаю в STL-алгоритм указатель на первый элемент (в качестве итератора) и указатель на элемент после последнего. Что, я неверно использую STL? :) Если сравнение с невалидным указателем неопределенное поведение, тогда я точно уверен, что мои программы имеют неопределенное поведение :) А следовательно, ценность этого понятия становится нулевой — ведь они же работают, их используют.
Я был неправ, увлекся. Конечно же, сравнение — это не неопределенное поведение, это максимум unspecified. Если хочешь более строго — можешь почитать 5.9.
Про указатели вообще — 3.9.2/3.
Кё>>>Странно как-то это звучит. Цель указателя может быть уничтожена чужим кодом, даже по ошибке. Но тут стандарт молчит. J>>Если стандарт по какому-то случаю молчит, значит, он никак не определяет поведение программы, значит, это — неопределенное поведение.
Кё>Вот это и странно. Отличный код с известным, понятым и совершенно определенным поведением называют каким-то плохим словосочетанием :)
Как можно называть код, который удаляет что-то по ошибке, "отличным кодом с <...>"? :)
Кё>Может все-таки надо по-другому говорить — зависит от реализации, например. Зависит от контекста.
Когда говорят, что что-то зависит от реализации — это означает зависиость от реализации компилятора, а не от реализации тобой твоей программы :)
Кё>>>Собственно, какая тогда ценность замечания про неопределенное поведение? Можно было просто сказать, разыменование указателя может привести к неопределенному поведению? :)
J>>Можно так сказать, но эти слова не несут никакого смысла. J>>Имеет смысл выражаться точнее: разыменование указателя не приводит к неопределенному поведению, если он указывает на объект в программе (или подобъект). А неопределенное поведение будет во всех остальных случаях, как то: разыменование нулевого или неинициализированного указателя, т.е. когда указатель содержит адрес, по которому никаких объектов нет, либо указатель на разрушенный объект, потому что после разрушения объект он, очевидно, не существует...
Кё>Он может содержать указатель на объект, созданный в другом модуле, к коду которого компилятор и программист не имеют доступа. Модульность — обычное дело. Т.е. нельзя логически вывести валидность указателя из текста программы. В этом суть указателя. Что тогда, вся программа имеет неопреденное поведение? Какая ценность тогда этого определения, какую информацию оно несет?
Нет, программа имеет неопределенное поведение не в случае, когда компилятор не может "логически вывести валидность указателя из текста программы". Неопределенное поведение возникает, когда ты совершаешь с указателем определенные действия, а указатель при этом не указывает на валидный объект.
Ценность этого определения в том, что стандарт гарантирует ту работу программы, которая описана в нем. Т.е. если ты написал программу, которая не содержит неопределенного поведения — она будет работать строго определенно в соответствии со Стандартом. Тяжесть же по избеганию ситуаций, приводящих к неопределенному поведению, целиком лежит на программисте.
P.S. Не стоит также забывать, что частный случай неопределенного поведения — это "правильное" поведение, т.е. такое поведение, которого ты ожидаешь. Но, как ты понимаешь, никаких гарантий, что оно так будет работать и дальше, нет, в отличие от определенного поведения.
"Кодёнок" wrote... > Могу. Я например, передаю в STL-алгоритм указатель на первый элемент (в > качестве итератора) и указатель на элемент после последнего. Что, я неверно > использую STL?
*v.end() всегда не правильно, но обычно так никто не делает... поэтому во всех
алгоритмах STL в циклах стоит условие curr != end, а end НИКОГДА не
разыменовывают, эт почти так же плохо как *nullptr .
Здравствуйте, Кодёнок, Вы писали:
J>>C невалидным указателем ты вообще ничего не можешь делать, даже сравнивать с ним не можешь. Ты можешь только присвоить ему какое-нть значение. J>>С нулевым же ты сравнивать можешь.
Кё>Могу. Я например, передаю в STL-алгоритм указатель на первый элемент (в качестве итератора) и указатель на элемент после последнего. Что, я неверно использую STL? Если сравнение с невалидным указателем неопределенное поведение, тогда я точно уверен, что мои программы имеют неопределенное поведение А следовательно, ценность этого понятия становится нулевой — ведь они же работают, их используют.
Один момент.
Указатели бывают:
— невалидные
— валидные неразыменовываемые
— — нуль
— — указатель за конец массива (в т.ч. за конец единственного объекта)
— валидные разыменовываемые (указывающие на объекты)
Так что я надеюсь, что твои программы не содержат UB.
Перекуём баги на фичи!
Re[15]: В оличие указателя от референса?
От:
Аноним
Дата:
10.08.05 20:49
Оценка:
Здравствуйте, Кодёнок, Вы писали:
Кё>Могу. Я например, передаю в STL-алгоритм указатель на первый элемент (в качестве итератора) и указатель на элемент после последнего. Что, я неверно использую STL? Если сравнение с невалидным указателем неопределенное поведение, тогда я точно уверен, что мои программы имеют неопределенное поведение А следовательно, ценность этого понятия становится нулевой — ведь они же работают, их используют.
Taking a pointer to the element one beyond the end of an array is guaranteed to work. This is
important for many algorithms (§2.7.2, §18.3). However, since such a pointer does not in fact point
to an element of the array, it may not be used for reading or writing.
Суть заключается в техниках программирования, в которых применяются указатели и ссылки. Например, при перегрузке оператора "+" для Вашего класса, Вы не сможете воспользоваться указателями не потеряв при этом простую семантику операции сложения. Выглядит это так:
1. используем ссылки:
//...class A;
A operator+ (const A& ra, const A& rb){/*...*/}
void f(A a, A b)
{
A c;
c=a+b; //верно, a и b передаются по ссылке в operator+
}
//...
2. используем указатели:
//...class A;
A operator+ (A* pa, A* pb){/*...*/}
void f(A a, A b)
{
A c;
c=a+b; //не верно, правильно будет с = operator+(&a, &b) или c = &a + &b
}
//...
Ясно, что в этих примерах аргументы не передаются по значению из соображений эффективности (копирование больших объектов).
Более того, если мы захотим написать что-то вроде a+b+c, то... в случае с указателями запись приобретает еще более "кривой" вид:
//...
&( &a + &b ) + &c;
//...
зато при использовании ссылок мы смело можем написать a+b+c.
p.s. к нижним веткам: ссылка в отличие от указателя всегда "валидна", все примеры "не валидных" ссылок являются элементарнейшим хаком (зачем в таком случае Вам вообще нужен С++ ??? Правильно, не нужен ).
p.p.s. а все что я написал есть в каждом "толковом" букваре С++, поэтому пинайте авторов .
Перекуём баги на фичи!
). 
.
