Вопрос про адреса на разных системах

[220Volt]

Здравствуйте.

struct S
{
    char a;
    char b;
};

Верно ли утверждение что на всех системах &a < &b ?

Наверное нет, насколько известно в dos'е стек рос в другую сторону?

И более важный вопрос: если направление роста адресов может разниться, будут ли корректно работать (на разных системах) алгоритмы работающие с адресами напрямую (+, -, <, >)? Или операторы меняют поведение в зависимости от системы?

Думаю я нашел ответ.
В <iterator> в описании про std::advance() следующее:

template <class InputIterator, class Distance>
  void advance (InputIterator& it, Distance n);
Advance iterator

Advances the iterator it by n element positions.

 If it is a random-access iterator, the function uses just once operator+ or operator-. Otherwise, 
the function uses repeatedly the increase or decrease operator (operator++ or operator--) until n elements have been advanced.

Поэтому, прямой инкремент/декремент указателей видимо лучше избегать.
P.s.
std::advance не показатель (может сдвигать в обе стороны)

[MaTBeu]

Верно ли утверждение что на всех системах &a < &b ?

Все зависит от платформы, на которой компилируется данный код и компилятора. Может случиться ситуация, когда у вас есть следующий код

struct S
{
    char a;
    char b;
};

S obj;
obj.a = '1';
obj.b = '1';

При одинаковых значениях обоих полей (которые не меняются на протяжении всей программы), компилятор может оптимизировать код таким образом, что данные будут лежать по адресу, к примеру 0x0000FFCA, а обе ссылки будут указывать на этот адрес. Получится, что &a == &b

[Пепел Феникса]

куча бреда.

в ДОСе стек рос так же, рост стека вообще от ОС не зависит.

операторы не меняют значения, адрес есть число, их и сравнивает.

std::advance вообще к этому отношения не причем, да и вывод бред.

на интеловской платформе стек всегда растет в одну сторону.
а на иных вы врятли будете работать.
да и там стек растет так же, и объекты расположены линейно

Получится, что &a == &b

поидее только при битовых полях, не иначе.

[220Volt]

Сообщение от Пепел Феникса

куча бреда.

в ДОСе стек рос так же, рост стека вообще от ОС не зависит.

операторы не меняют значения, адрес есть число, их и сравнивает.

std::advance вообще к этому отношения не причем, да и вывод бред.

на интеловской платформе стек всегда растет в одну сторону.
а на иных вы врятли будете работать.
да и там стек растет так же, и объекты расположены линейно

поидее только при битовых полях, не иначе.

Я лично читал о том, как при переполнении стека в dos затирается область инструкций, не могу сейчас найти ссылку, тем более попробовать.

Прежде чем говорить что std::advance бред, попробуйте туда указатель передать (и смежные с ним функции prev, next).

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

Все зависит от платформы, на которой компилируется данный код и компилятора. Может случиться ситуация, когда у вас есть следующий код

struct S
{
    char a;
    char b;
};

S obj;
obj.a = '1';
obj.b = '1';

При одинаковых значениях обоих полей (которые не меняются на протяжении всей программы), компилятор может оптимизировать код таким образом, что данные будут лежать по адресу, к примеру 0x0000FFCA, а обе ссылки будут указывать на этот адрес. Получится, что &a == &b

Не согласен, думаю если бы компилятор делал такие оптимизации был бы ужас.

[MaTBeu]

Сообщение от 220Volt

Не согласен, думаю если бы компилятор делал такие оптимизации был бы ужас.

Никакого ужаса, зачем выделять память под 2 объекта, если значение одно и тоже (константное) на протяжении всей программы?

По поводу std::advance - мне кажется вы неправильно понимаете. Как вы проверяете, что итератор переместился?

[Пепел Феникса]

Я лично читал о том, как при переполнении стека в dos затирается область инструкций, не могу сейчас найти ссылку, тем более попробовать.

стек там растет так же, в сторону уменьшения адресов.

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

Никакого ужаса, зачем выделять память под 2 объекта, если значение одно и тоже (константное) на протяжении всей программы?

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

[Son Of Pain]

Смотрим в стандарт. Раздел 9.2, параграф 13:

Nonstatic data members of a (non-union) class with the same access control (Clause 11) are allocated so
that later members have higher addresses within a class object. The order of allocation of non-static data
members with different access control is unspecified (Clause 11). 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).

[220Volt]

Большое спасибо, это вносит ясность.

...The order of allocation of non-static data
members with different access control is unspecified ...

А вот это меня очень удивило, даже не подозревал.

[_Bers]

Сообщение от 220Volt

Здравствуйте.

struct S
{
    char a;
    char b;
};

Верно ли утверждение что на всех системах &a < &b ?

Да.

Сообщение от 220Volt

Наверное нет, насколько известно в dos'е стек рос в другую сторону?

Это не принципиально. Это трудности компилятора, как он будет разруливать адреса.

Вы имеете полное право рассчитывать на то, что:
адрес массива всегда совпадает с адресом первого элемента массива.
адрес второго массива - это адрес первого + смещение равное sizeof(a[0])

и тд.

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

Структуры: struct example { int a,b; };
Так же являются непрерывными блоками памяти, которые хранят элементы.

Структуры можно рассматривать как массивы, способные хранить элементы разных типов.

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

[waleri]

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

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

Не факт, есть еще выравнивание...