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

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

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

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

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#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++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
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

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

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

Code
1
2
<a>
<b>

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

Code
1
2
<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

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

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

Новые блоги и статьи Все статьи Все блоги /
Ритм жизни kumehtar 27.02.2026 Иногда приходится жить в ритме, где дел становится всё больше, а вовлечения в происходящее — всё меньше. Плотный график не даёт вниманию закрепиться ни на одном событии. Утро начинается с быстрых,. . .	SDL3 для Web (WebAssembly): Сборка SDL3 и Box2D из исходников с помощью CMake и Emscripten 8Observer8 27.02.2026 Недавно вышла версия 3. 4. 2 библиотеки SDL3. На странице официальной релиза доступны исходники, готовые DLL (для x86, x64, arm64), а также библиотеки для разработки под Android, MinGW и Visual Studio. . . .	SDL3 для Web (WebAssembly): Реализация движения на Box2D v3 - трение и коллизии с повёрнутыми стенами 8Observer8 20.02.2026 Содержание блога Box2D позволяет легко создать главного героя, который не проходит сквозь стены и перемещается с заданным трением о препятствия, которые можно располагать под углом, как верхнее. . .	Конвертировать закладки radiotray-ng в m3u-плейлист damix 19.02.2026 Это можно сделать скриптом для PowerShell. Использование . \СonvertRadiotrayToM3U. ps1 <path_to_bookmarks. json> Рядом с файлом bookmarks. json появится файл bookmarks. m3u с результатом. # Check if. . .
Семь CDC на одном интерфейсе: 5 U[S]ARTов, 1 CAN и 1 SSI Eddy_Em 18.02.2026 Постепенно допиливаю свою "многоинтерфейсную плату". Выглядит вот так: https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11617&stc=1&d=1771445347 Основана на STM32F303RBT6. На борту пять. . .	Камера Toupcam IUA500KMA Eddy_Em 12.02.2026 Т. к. у всяких "хикроботов" слишком уж мелкий пиксель, для подсмотра в ESPriF они вообще плохо годятся: уже 14 величину можно рассмотреть еле-еле лишь на экспозициях под 3 секунды (а то и больше),. . .	И ясному Солнцу zbw 12.02.2026 И ясному Солнцу, и светлой Луне. В мире покоя нет и люди не могут жить в тишине. А жить им немного лет.	«Знание-Сила» zbw 12.02.2026 «Знание-Сила» «Время-Деньги» «Деньги -Пуля»

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

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

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

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