Здравствуйте, Евгений Коробко, Вы писали:
ЕК>class Vect ЕК>{ ЕК>... ЕК>public: ЕК> double operator [] (int i) const {return *(&x+i);}; ЕК>private: ЕК> double x,y,z; ЕК>};
ЕК>Собственно, вопрос вызывает то, можно ли быть уверенным, что x,y,z будут расположены в памяти подряд?
Так как пример написан — нет (есть private члены). Для того чтобы была гарантия последовательного размещения класс должен быть POD. На практике обычно будет работать.
Здравствуйте, Евгений Коробко, Вы писали:
ЕК>class Vect ЕК>{ ЕК>... ЕК>public: ЕК> double operator [] (int i) const {return *(&x+i);}; ЕК>private: ЕК> double x,y,z; ЕК>};
ЕК>Собственно, вопрос вызывает то, можно ли быть уверенным, что x,y,z будут расположены в памяти подряд?
Hello, Евгений!
You wrote on Wed, 11 Aug 2004 11:02:48 GMT:
ЕК> class Vect ЕК> { ЕК> ... ЕК> public: ЕК> double operator [] (int i) const {return *(&x+i);}; ЕК> private: ЕК> double x,y,z; ЕК> };
ЕК> Собственно, вопрос вызывает то, можно ли быть уверенным, что x,y,z ЕК> будут расположены в памяти подряд?
Можно. Только между ними могут быть дырки для выравнивания. Пункт стандарта
9.2.12:
12 Nonstatic data members of a (nonunion) class declared without an
intervening accessspecifier
are allocated so that later members have higher addresses within a class
object. The order of allocation of nonstatic
data members separated by an accessspecifier 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).
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Анатолий Широков, Вы писали:
D>>Так как пример написан — нет (есть private члены). Для того чтобы была гарантия последовательного размещения класс должен быть POD.
АШ>Причем здесь POD?
Так как для POD есть требование совместимости по раскладке (layout-compatible), то для POD-struct члены должны лежать последовательно. Если говорить упрощенно то две структуры с одинаковым началом должны содержать одинаковые члены на одинаковых местах. Так что можно построить последовательность структур, в каждой на один член больше чем в предыдущей и их начала должны быть разложены одинаково, для того чтобы это соблюсти придется разложить члены последовательно.
Спасибо!
Реально дырок для выравнивания, вероятно, не будет, потому как для double вряд ли будет выравнивание по 16 байт. В крайнем случае, можно управлять выравниваем директивами компиляторы
Здравствуйте, dupamid, Вы писали:
D>Так как для POD есть требование совместимости по раскладке (layout-compatible), то для POD-struct члены должны лежать последовательно.
По возрастанию адресов — да, но вряд ли последовательно.
D>Так как пример написан — нет (есть private члены). Для того чтобы была гарантия последовательного размещения класс должен быть POD. На практике обычно будет работать.
Здравствуйте, Евгений Коробко, Вы писали:
ЕК>class Vect ЕК>{ ЕК>... ЕК>public: ЕК> double operator [] (int i) const {return *(&x+i);}; ЕК>private: ЕК> double x,y,z; ЕК>};
ЕК>Собственно, вопрос вызывает то, можно ли быть уверенным, что x,y,z будут расположены в памяти подряд?
Здравствуйте, achp, Вы писали:
D>>Так как для POD есть требование совместимости по раскладке (layout-compatible), то для POD-struct члены должны лежать последовательно.
A>По возрастанию адресов — да, но вряд ли последовательно.
Последовательно, но с точностью до выравнивания. Так как у POD не может быть срытых полей, кроме как для вырвнивания. Пример:
struct A1
{
int a1;
};
struct A2
{
int a1;
float a2;
};
struct A3
{
int a1;
float a2;
double a3;
};
и т.д.
Так вот так как начала стуруктур должны быть совместимы, то получается что члены должны лежать последоватлеьно. Например, если указатьль на A3 преобразовать в указатель на A2, то доступ к полям должен осуществляться без проблем. Такие требования есть наследие С. Где было популярно в следующей версии добавлять поля в структуры, при этом раскладка ее начала должна быть одинаковой для бинарной совместимости со старыми программами.
Здравствуйте, Bell, Вы писали:
D>>Так как пример написан — нет (есть private члены). Для того чтобы была гарантия последовательного размещения класс должен быть POD. На практике обычно будет работать.
B>А что насчет выравнивания?
В данном случае это не проблема, так как все члены одного типа. Вот если они будут разных типов, пусть даже одного размера — тогда могут быть проблемы.