Инкрементация указателя по членам класса

notAll · Регистрация: 27.05.2016

Студворк — интернет-сервис помощи студентам

Вот такая задачка у меня попалась на тестировании: "Корректен ли данный код? Если да, то что будет выведено на экран? Аргументируйте свой ответ. "

C++

#include <iostream>
 
struct C
{
    char a, b;
};
 
int main()
{
    C c;
    c.a = 'x';
    c.b = 'y';
    char* pc = &c.a;
    pc++;
    std::cout << *pc;
}

Я ответил, что результат не определен из за выравнивания в классе и инкрементация указателя может указывать на не корректную память. Следовательно, может вывести как 'y' так и мусор.
Но, вот уже дома проверил - выводит всегда 'y'. Это такое поведение по стандарту? Или тут что другое.

@ящюр · 22.12.2016, 21:07

Нашел вот такую инфу в интернете

Выравниваются в памяти поля по границе кратной своему же размеру. То есть 1-байтовые поля не выравниваются, 2-байтовые — выравниваются на чётные позиции, 4-байтовые — на позиции кратные четырём и т.д.

notAll · 23.12.2016, 00:31 **[ТС]**

Из всего этого делаем вывод что если одинаковые типы в классе идут один за другим, то по ним можно спокойно пробегаться указателем.

Добавлено через 4 минуты
Даже в private получается залесть:

C++

struct C
{
    short a;
private:
    short b = 20;
};
 
int main()
{
    C c;
    c.a = 2;
    short* p = &c.a;
    p++;
    std::cout << "p = " << *p << "\n"; // 20
}

@DrOffset · 23.12.2016, 01:29

Сообщение от notAll

Даже в private получается залесть

Для разных секций нет гарантии порядка. Так что этот код потенциально может породить выход за пределы объекта.

@rikimaru2013 · 23.12.2016, 01:33

DrOffset, а откуда такое утверждение? после компиляции нету секций и разделения на права доступа. Инициализация полей будет сверху вниз с объявления класса в любом случаи

@DrOffset · 23.12.2016, 01:38

Сообщение от rikimaru2013

а откуда такое утверждение? после компиляции нету секций и разделения на права доступа

При чем тут "после компиляции нет секций"?
Еще раз: нет гарантии порядка для переменных в разных секциях. Это значит, что в результате (в зависимости от реализации компилятора) может получиться как объект с лэяутом

Код

<a>
<b>

так и с лэяутом

Код

<b>
<a>

так вот, во втором случае, получая адрес а, а затем инкрементируя его, мы вылетаем за границы объекта.

@rikimaru2013 · 23.12.2016, 01:42

DrOffset, так я и интересуюсь откуда у вас эта информация? Почему компиляторы могут изменить порядок класс-членом не "сверху-вниз" ?

@DrOffset · 23.12.2016, 01:50

rikimaru2013,

Сообщение от 9.2/12

Nonstatic data members of a (non-union) class declared without an intervening access-specifier are allocated so that later members have higher addresses within a class object. The order of allocation of nonstatic data members separated by an access-specifier is unspecified (11.1). Implementation alignment requirements might cause two adjacent members not to be allocated immediately after each other; so might requirements for space for managing virtual functions (10.3) and virtual base classes (10.1).

Добавлено через 2 минуты

Сообщение от rikimaru2013

так я и интересуюсь откуда у вас эта информация?

Ты не интересуешься, а споришь, причем безосновательно.

Сообщение от rikimaru2013

Инициализация полей будет сверху вниз с объявления класса в любом случаи

Порядок инициализации полей к рассматриваемому вопросу отношения не имеет.

Добавлено через 4 минуты
В новых черновиках эта цитата в 13м пункте, а не в 12. На всякий случай говорю.

@Nosey · 23.12.2016, 01:51

DrOffset, А зачем такое поведение в стандарт ввели, это дает какую-то возможность компиляторам?

@rikimaru2013 · 23.12.2016, 01:54

Не по теме:

Nosey, я тоже самое спрашивал - но меня оклеветали, что я спорю) :cry:

@DrOffset · 23.12.2016, 02:06

Сообщение от Nosey

А зачем такое поведение в стандарт ввели, это дает какую-то возможность компиляторам?

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

@hoggy · 23.12.2016, 12:05

Сообщение от ящюр

Нашел вот такую инфу в интернете

ложь.

@TheCalligrapher · 23.12.2016, 12:16

Сообщение от notAll

Я ответил, что результат не определен из за выравнивания в классе и инкрементация указателя может указывать на не корректную память. Следовательно, может вывести как 'y' так и мусор.

Совершенно правильный ответ. Поведение такого кода будет не определено.

Сообщение от notAll

Но, вот уже дома проверил - выводит всегда 'y'. Это такое поведение по стандарту? Или тут что другое.

Так в вы чего ожидали? Что на мониторе загорятся большие красные буквы "поведение не определено"? Неопределенное поведение можно проявлять себя в том числе и как "работающий" код. Понятно, что на практике поля класса могу быть расположены в памяти компактно и вести себя фактически как элементы одного массива. Но это не меняет того факта, что язык формально не поддерживает такой адресной арифметики и поведение не определено.

Сообщение от notAll

Из всего этого делаем вывод что если одинаковые типы в классе идут один за другим, то по ним можно спокойно пробегаться указателем.

"Можно" в смысле "у меня все работало и у Васи Косого из второго подъезда, говорят, тоже работало".

С точки зрения языка ничего подобного делать не разрешается.

@hoggy · 23.12.2016, 12:20

Сообщение от TheCalligrapher

Совершенно правильный ответ. Поведение такого кода будет не определено.

с фигали? оба чара в рамках одной секции будут идти друг за другом вплотную.
возможное выравнивание будет по границе однородных членов.

Сообщение от TheCalligrapher

С точки зрения языка ничего подобного делать не разрешается.

язык никому ничего не запрещает.

MrGluck · 23.12.2016, 12:30

Сообщение от notAll

Вот такая задачка у меня попалась на тестировании:

Надо было сразу на подобный глупый вопрос спросить:
А в скольких местах подобная конструкция используется в вашем production коде?
Ответ "много где" - нахрена мне нужно поддерживать ваш быдлокод?
Ответ "нигде" - нахрена мне нужно это тогда знать наизусть?

@TheCalligrapher · 23.12.2016, 12:53

Сообщение от hoggy

с фигали? оба чара в рамках одной секции будут идти друг за другом вплотную.

В С++ "друг за другом вплотную" идут только элементы одного массива. Все остальные "будут идти друг за другом вплотную" - не более чем особенности/совпадения/случайности конкретной реализации, к языку С++ никакого отношения не имеющие.

В язык С++ адресная арифметика определена только среди элементов одного массива. Никакой другой адресной арифметики в С++ нет.

Сообщение от hoggy

возможное выравнивание будет по границе однородных членов.

Язык С++ не дает никаких гарантий на тему того, где и как будут располагаться padding bytes в классе. Выравнивание в данном случае (и в любом другом случае) возможно где угодно и в неограниченных количествах.

Сообщение от hoggy

язык никому ничего не запрещает.

Речь идет о легальности конструкции и определенности поведения.

@hoggy · 23.12.2016, 13:21

Сообщение от TheCalligrapher

В С++ "друг за другом вплотную" идут только элементы одного массива. Все остальные "будут идти друг за другом вплотную" - не более чем особенности/совпадения/случайности конкретной реализации, к языку С++ никакого отношения не имеющие.

такое поведение вполне объясняется банальным здравым смыслом.
не знаю ни один компилятор, который втыкал бы дырки между однородными членами.
тем паче, что стандарт позволяет доступ к чару по неровному адресу.
вставлять между ними дырки - это какой то бред.

@TheCalligrapher · 23.12.2016, 13:32

Сообщение от hoggy

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

Дело тут не в том, чтобы вставлять или не вставлять между ними дырки, а в том, что такой фичи, как итерирование/адресная арифметика по независимым полям класса в языке С++ просто нет.

@hoggy · 23.12.2016, 13:37

Сообщение от TheCalligrapher

Дело тут не в том, чтобы вставлять или не вставлять между ними дырки, а в том, что такой фичи, как итерирование/адресная арифметика по независимым полям класса в языке С++ просто нет.

зато есть доступ к памяти, и возможность заинкрементить обычный указатель на данные.
стандарт не объявляет подобную ситуацию UB.
насколько мне известно, он просто её не описывает.
но по косвенным признакам, которые стандарт описывает,
можно допустить, что подобный хак - не есть ill formed,
а значит не есть UB

@Renji · 23.12.2016, 14:42

Сообщение от MrGluck

Ответ "много где" - нахрена мне нужно поддерживать ваш быдлокод?

Дык это любимый сишниками каламбур типизации. Вероятно, достался в нагрузку к библиотекам на "самом лучшем" языке.

MrGluck Форумчанин 8194 / 5044 / 1437 Регистрация: 29.11.2010 Сообщений: 13,453
	23.12.2016, 12:30	15
	Сообщение от notAll Вот такая задачка у меня попалась на тестировании: Надо было сразу на подобный глупый вопрос спросить: А в скольких местах подобная конструкция используется в вашем production коде? Ответ "много где" - нахрена мне нужно поддерживать ваш быдлокод? Ответ "нигде" - нахрена мне нужно это тогда знать наизусть? 2

@hoggy 8725 / 4305 / 958 Регистрация: 15.11.2014 Сообщений: 9,752
	23.12.2016, 13:21	17
	Сообщение от TheCalligrapher В С++ "друг за другом вплотную" идут только элементы одного массива. Все остальные "будут идти друг за другом вплотную" - не более чем особенности/совпадения/случайности конкретной реализации, к языку С++ никакого отношения не имеющие. такое поведение вполне объясняется банальным здравым смыслом. не знаю ни один компилятор, который втыкал бы дырки между однородными членами. тем паче, что стандарт позволяет доступ к чару по неровному адресу. вставлять между ними дырки - это какой то бред. 0

@TheCalligrapher Вездепух 10907 / 5904 / 1613 Регистрация: 18.10.2014 Сообщений: 14,832
	23.12.2016, 13:32	18
	Сообщение от hoggy тем паче, что стандарт позволяет доступ к чару по неровному адресу. вставлять между ними дырки - это какой то бред. Дело тут не в том, чтобы вставлять или не вставлять между ними дырки, а в том, что такой фичи, как итерирование/адресная арифметика по независимым полям класса в языке С++ просто нет. 0

@hoggy 8725 / 4305 / 958 Регистрация: 15.11.2014 Сообщений: 9,752
	23.12.2016, 13:37	19
	Сообщение от TheCalligrapher Дело тут не в том, чтобы вставлять или не вставлять между ними дырки, а в том, что такой фичи, как итерирование/адресная арифметика по независимым полям класса в языке С++ просто нет. зато есть доступ к памяти, и возможность заинкрементить обычный указатель на данные. стандарт не объявляет подобную ситуацию UB. насколько мне известно, он просто её не описывает. но по косвенным признакам, которые стандарт описывает, можно допустить, что подобный хак - не есть ill formed, а значит не есть UB 0

@ящюр 114 / 112 / 62 Регистрация: 15.03.2013 Сообщений: 561 Записей в блоге: 5
	22.12.2016, 21:07	2
	Нашел вот такую инфу в интернете Выравниваются в памяти поля по границе кратной своему же размеру. То есть 1-байтовые поля не выравниваются, 2-байтовые — выравниваются на чётные позиции, 4-байтовые — на позиции кратные четырём и т.д. 1

@DrOffset 17411 / 9247 / 2260 Регистрация: 30.01.2014 Сообщений: 16,184
	23.12.2016, 01:29	4
	Сообщение от notAll Даже в private получается залесть Для разных секций нет гарантии порядка. Так что этот код потенциально может породить выход за пределы объекта. 1

@rikimaru2013 2549 / 1208 / 358 Регистрация: 30.11.2013 Сообщений: 3,826
	23.12.2016, 01:33	5
	DrOffset, а откуда такое утверждение? после компиляции нету секций и разделения на права доступа. Инициализация полей будет сверху вниз с объявления класса в любом случаи 0

@DrOffset 17411 / 9247 / 2260 Регистрация: 30.01.2014 Сообщений: 16,184
	23.12.2016, 01:38	6
	Сообщение от rikimaru2013 а откуда такое утверждение? после компиляции нету секций и разделения на права доступа При чем тут "после компиляции нет секций"? Еще раз: нет гарантии порядка для переменных в разных секциях. Это значит, что в результате (в зависимости от реализации компилятора) может получиться как объект с лэяутом Код <a> <b> так и с лэяутом Код <b> <a> так вот, во втором случае, получая адрес `а`, а затем инкрементируя его, мы вылетаем за границы объекта. 1

@rikimaru2013 2549 / 1208 / 358 Регистрация: 30.11.2013 Сообщений: 3,826
	23.12.2016, 01:42	7
	DrOffset, так я и интересуюсь откуда у вас эта информация? Почему компиляторы могут изменить порядок класс-членом не "сверху-вниз" ? 0

@DrOffset 17411 / 9247 / 2260 Регистрация: 30.01.2014 Сообщений: 16,184
	23.12.2016, 01:50	8
	rikimaru2013, Сообщение от 9.2/12 Nonstatic data members of a (non-union) class declared without an intervening access-specifier are allocated so that later members have higher addresses within a class object. The order of allocation of nonstatic data members separated by an access-specifier is unspecified (11.1). Implementation alignment requirements might cause two adjacent members not to be allocated immediately after each other; so might requirements for space for managing virtual functions (10.3) and virtual base classes (10.1). Добавлено через 2 минуты Сообщение от rikimaru2013 так я и интересуюсь откуда у вас эта информация? Ты не интересуешься, а споришь, причем безосновательно. Сообщение от rikimaru2013 Инициализация полей будет сверху вниз с объявления класса в любом случаи Порядок инициализации полей к рассматриваемому вопросу отношения не имеет. Добавлено через 4 минуты В новых черновиках эта цитата в 13м пункте, а не в 12. На всякий случай говорю. 7

@Nosey 1379 / 406 / 144 Регистрация: 22.10.2014 Сообщений: 872
	23.12.2016, 01:51	9
	DrOffset, А зачем такое поведение в стандарт ввели, это дает какую-то возможность компиляторам? 0

@rikimaru2013
	23.12.2016, 01:54 #10
	Не по теме: Nosey, я тоже самое спрашивал - но меня оклеветали, что я спорю) :cry: 0

@DrOffset 17411 / 9247 / 2260 Регистрация: 30.01.2014 Сообщений: 16,184
	23.12.2016, 02:06	11
	Сообщение от Nosey А зачем такое поведение в стандарт ввели, это дает какую-то возможность компиляторам? Насколько я знаю, в стандарте оно всегда было. Про "зачем ввели" - свечку не держал (это значит, что далее идет мое личное мнение, которое может не соответствовать истине), но, возможно, это сделано чтобы дать возможность оптимизировать размер классов. В пределах одной секции порядок будет неизменен, но разные секции теоретически можно переставить местами в памяти, чтобы получить более компактный размер. Но, честно говоря, я не назову сейчас ни одного компилятора, который бы это делал на практике. 2

@hoggy 8725 / 4305 / 958 Регистрация: 15.11.2014 Сообщений: 9,752
	23.12.2016, 12:05	12
	Сообщение от ящюр Нашел вот такую инфу в интернете ложь. 0

Опции темы

@TheCalligrapher Вездепух 10907 / 5904 / 1613 Регистрация: 18.10.2014 Сообщений: 14,832
	23.12.2016, 12:16	13
	Сообщение от notAll Я ответил, что результат не определен из за выравнивания в классе и инкрементация указателя может указывать на не корректную память. Следовательно, может вывести как 'y' так и мусор. Совершенно правильный ответ. Поведение такого кода будет не определено. Сообщение от notAll Но, вот уже дома проверил - выводит всегда 'y'. Это такое поведение по стандарту? Или тут что другое. Так в вы чего ожидали? Что на мониторе загорятся большие красные буквы "поведение не определено"? Неопределенное поведение можно проявлять себя в том числе и как "работающий" код. Понятно, что на практике поля класса могу быть расположены в памяти компактно и вести себя фактически как элементы одного массива. Но это не меняет того факта, что язык формально не поддерживает такой адресной арифметики и поведение не определено. Сообщение от notAll Из всего этого делаем вывод что если одинаковые типы в классе идут один за другим, то по ним можно спокойно пробегаться указателем. "Можно" в смысле "у меня все работало и у Васи Косого из второго подъезда, говорят, тоже работало". С точки зрения языка ничего подобного делать не разрешается. 1

@hoggy 8725 / 4305 / 958 Регистрация: 15.11.2014 Сообщений: 9,752
	23.12.2016, 12:20	14
	Сообщение от TheCalligrapher Совершенно правильный ответ. Поведение такого кода будет не определено. с фигали? оба чара в рамках одной секции будут идти друг за другом вплотную. возможное выравнивание будет по границе однородных членов. Сообщение от TheCalligrapher С точки зрения языка ничего подобного делать не разрешается. язык никому ничего не запрещает. 0

@TheCalligrapher Вездепух 10907 / 5904 / 1613 Регистрация: 18.10.2014 Сообщений: 14,832
	23.12.2016, 12:53	16
	Сообщение от hoggy с фигали? оба чара в рамках одной секции будут идти друг за другом вплотную. В С++ "друг за другом вплотную" идут только элементы одного массива. Все остальные "будут идти друг за другом вплотную" - не более чем особенности/совпадения/случайности конкретной реализации, к языку С++ никакого отношения не имеющие. В язык С++ адресная арифметика определена только среди элементов одного массива. Никакой другой адресной арифметики в С++ нет. Сообщение от hoggy возможное выравнивание будет по границе однородных членов. Язык С++ не дает никаких гарантий на тему того, где и как будут располагаться padding bytes в классе. Выравнивание в данном случае (и в любом другом случае) возможно где угодно и в неограниченных количествах. Сообщение от hoggy язык никому ничего не запрещает. Речь идет о легальности конструкции и определенности поведения. 0

@Renji 2761 / 1915 / 569 Регистрация: 05.06.2014 Сообщений: 5,571
	23.12.2016, 14:42	20
	Сообщение от MrGluck Ответ "много где" - нахрена мне нужно поддерживать ваш быдлокод? Дык это любимый сишниками каламбур типизации. Вероятно, достался в нагрузку к библиотекам на "самом лучшем" языке. 0