Сообщение Re[3]: Тест по базовому C++ -- интересно ваше мнение от 20.10.2015 20:57
Изменено 20.10.2015 20:58 Abyx
Здравствуйте, Tilir, Вы писали:
A>>1) правильный ответ — "разыменование d — это UB".
A>>Можно сделать каст к [unsigned] char* и разыменовать, но не к short*.
T>С чего бы это было UB? Приведение адреса к адресу, типы целочисленные, "An object pointer can be explicitly converted to an object pointer of a different type" (5.2.10-7) и так далее. Мне правда интересно. Я переформулирую вопрос на массивы если это и впрямь так.
потому что это нарушает правила aliasing'а.
В стандарте С++ это есть в [basic.lval] p10
> If a program attempts to access the stored value of an object through a glvalue of other than one of the following types the behavior is undefined:
> — the dynamic type of the object,
> ...
> a char or unsigned char type.
И внизу сноска
> *) The intent of this list is to specify those circumstances in which an object may or may not be aliased.
То есть конечно кастовать можно в любой тип. Но обращаться к члену нельзя (в вычисляемом контексте).
Ну и это не снимает проблему с implementation-defined представлением int.
A>>1) правильный ответ — "разыменование d — это UB".
A>>Можно сделать каст к [unsigned] char* и разыменовать, но не к short*.
T>С чего бы это было UB? Приведение адреса к адресу, типы целочисленные, "An object pointer can be explicitly converted to an object pointer of a different type" (5.2.10-7) и так далее. Мне правда интересно. Я переформулирую вопрос на массивы если это и впрямь так.
потому что это нарушает правила aliasing'а.
В стандарте С++ это есть в [basic.lval] p10
> If a program attempts to access the stored value of an object through a glvalue of other than one of the following types the behavior is undefined:
> — the dynamic type of the object,
> ...
> a char or unsigned char type.
И внизу сноска
> *) The intent of this list is to specify those circumstances in which an object may or may not be aliased.
То есть конечно кастовать можно в любой тип. Но обращаться к члену нельзя (в вычисляемом контексте).
Ну и это не снимает проблему с implementation-defined представлением int.
Re[3]: Тест по базовому C++ -- интересно ваше мнение
Здравствуйте, Tilir, Вы писали:
A>>1) правильный ответ — "разыменование d — это UB".
A>>Можно сделать каст к [unsigned] char* и разыменовать, но не к short*.
T>С чего бы это было UB? Приведение адреса к адресу, типы целочисленные, "An object pointer can be explicitly converted to an object pointer of a different type" (5.2.10-7) и так далее. Мне правда интересно. Я переформулирую вопрос на массивы если это и впрямь так.
потому что это нарушает правила aliasing'а.
В стандарте С++ это есть в [basic.lval] p10
> If a program attempts to access the stored value of an object through a glvalue of other than one of the following types the behavior is undefined:
> — the dynamic type of the object,
> ...
> — a char or unsigned char type.
И внизу сноска
> *) The intent of this list is to specify those circumstances in which an object may or may not be aliased.
То есть конечно кастовать можно в любой тип. Но обращаться к члену нельзя (в вычисляемом контексте).
Ну и это не снимает проблему с implementation-defined представлением int.
A>>1) правильный ответ — "разыменование d — это UB".
A>>Можно сделать каст к [unsigned] char* и разыменовать, но не к short*.
T>С чего бы это было UB? Приведение адреса к адресу, типы целочисленные, "An object pointer can be explicitly converted to an object pointer of a different type" (5.2.10-7) и так далее. Мне правда интересно. Я переформулирую вопрос на массивы если это и впрямь так.
потому что это нарушает правила aliasing'а.
В стандарте С++ это есть в [basic.lval] p10
> If a program attempts to access the stored value of an object through a glvalue of other than one of the following types the behavior is undefined:
> — the dynamic type of the object,
> ...
> — a char or unsigned char type.
И внизу сноска
> *) The intent of this list is to specify those circumstances in which an object may or may not be aliased.
То есть конечно кастовать можно в любой тип. Но обращаться к члену нельзя (в вычисляемом контексте).
Ну и это не снимает проблему с implementation-defined представлением int.