Re[9]: Корректен ли код
От: Alex Alexandrov США  
Дата: 26.11.05 10:50
Оценка: 5 (1) +2 -1
Здравствуйте, Анатолий Широков, Вы писали:

АШ>Я не могу понять, почему Вы настолько убеждены, что компилятор для структуры вида:



АШ>
АШ>struct point
АШ>{
АШ>    double x;
АШ>    double y;
АШ>    double z;
АШ>};
АШ>


АШ>не может сделать что-то подобное:


АШ>| x |XXXX| y |XXXX| z |XXXX


АШ>Именно в этом состоял первоначалный вопрос. И компилятор волен вполне так поступить, поскольку стандарт ему это не запрещает. Поэтому код



АШ>
АШ>double operator[](size_t i) {return (&x + i);}
АШ>


АШ>является хаком в том, смысле, что безосновательно полагается на то, что между x, y и z нет "дыр".


Вмешаюсь в беседу, извините. Почему-то все говорят про Стандарт, забывая о том, что это лишь один из документов, регулирующих поведение компилятора. Когда мы говорим о C-структурах, т.е. о типах, поля которых используются напрямую, то большее значение имеет другой документ: ABI (Application Binary Interface) спецификация. Именно она регулирует подобные вещи в большей степени, стремясь к гарантии, что вы можете использовать библиотеки и заголовочные файлы, полученные с помощью другого компилятора.

В частности, именно Intel 386 ABI запрещает компилятору сделать "что-то подобное", приведенное выше, поскольку

1. An entire structure or union object is aligned on the same boundary as its
most strictly aligned member.
2. Each member is assigned to the lowest available offset with the appropriate
alignment. This may require internal padding, depending on the previous
member.

Т.е. начало структуры обязано быть выравнено на границу выравнивания для double. Первый элемент double должен начинаться с минимально подходящего для него адреса, т.е. сразу. Второй элемент — то же самое, т.е. немедленно после первого элемента.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
It's kind of fun to do the impossible (Walt Disney)
Re[13]: Корректен ли код
От: jazzer Россия Skype: enerjazzer
Дата: 30.11.05 10:56
Оценка: 4 (1) +1
Здравствуйте, srggal, Вы писали:

S>Здравствуйте, Alex Alexandrov, Вы писали:


AA>>Разработчики ПО обязаны знать об ABI. Когда ты пишешь библиотеку под Unix, тебе надо понимать это хотя бы для того, чтобы понять, является ли новая версия твоей библиотеки ABI-совместимой с предыдущей, и какую цифру в версии таки надо менять (major/minor/patch). Когда начинаются глюки с С++ рантаймом также надо знать, что такое ABI и когда у GCC он поменялся. И т.д.


S>Насколько сильно я ошибусь предположив что руководствуясь стандартом языка С/С++ я могу абстрагироваться от АБИ?


S>Если Вас не затруднит — приведите пример когда с точки зрения стандарта код будет well-formed, но при этом Он не будет удовлетворять AАБИ.


S>Стандарт ИМХО для того и писан, чтобы абстрагироваться от платформы


Да легко: собери одну часть своего well-formed кода одинм компилятором, а другую — другим, а потом попробуй их заставить работать вместе.

Причем это имеет место даже для одного и того же компилятора, но разных его версий, или разных ключей компиляции.
Например, Sun поменял ABI своего компилятора при переходе с версии 4.2 на 5.x.
Для нашей системы это означало то, что теперь мы должны достать новые версии всех сторонних библиотек, собранные пятеркой.
Некоторые библиотеки их получить не удалось (по разным причинам — в одном случае фирма просто перестала существовать, в другом — запросила дополнительное бабло, в третьем — вообще переписала библиотеку на java и них теперь вообще нет интерфейса для С++), и в результате у нас один и тот же код компилируется дважды разными компиляторами — для сборки со старыми библиотеками и для сборки с новыми.

И из-за недоступности версий старых библиотек, поддерживающих ABI нового компилятора, у нас нет никакой надежды перевести приложения, которые с этими библиотеками линкуются, на нормальный С++ от версии 5.x.

Вот таков горький вкус ABI.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[12]: Корректен ли код
От: srggal Украина  
Дата: 30.11.05 08:29
Оценка: 1 (1) +1
Здравствуйте, Alex Alexandrov, Вы писали:

AA>Разработчики ПО обязаны знать об ABI. Когда ты пишешь библиотеку под Unix, тебе надо понимать это хотя бы для того, чтобы понять, является ли новая версия твоей библиотеки ABI-совместимой с предыдущей, и какую цифру в версии таки надо менять (major/minor/patch). Когда начинаются глюки с С++ рантаймом также надо знать, что такое ABI и когда у GCC он поменялся. И т.д.


Насколько сильно я ошибусь предположив что руководствуясь стандартом языка С/С++ я могу абстрагироваться от АБИ?

Если Вас не затруднит — приведите пример когда с точки зрения стандарта код будет well-formed, но при этом Он не будет удовлетворять AАБИ.

Стандарт ИМХО для того и писан, чтобы абстрагироваться от платформы
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[7]: Корректен ли код
От: Sergey Россия  
Дата: 11.08.04 13:50
Оценка: 1 (1)
Hello, dupamid!
You wrote on Wed, 11 Aug 2004 13:29:28 GMT:

d> Использовать это для оптимизации выравнивания нельзя, так как размер

d> типа в массиве и самомого по себе должен быть одинаковым. Т.е.
d> реализация, на которой sizeof типа long double 10 байт, а в масиве их
d> кладут через 16 — для выравнивания, не соответсвует Стнадарту. Теперь,
d> если вернуться у структурам, то получается что sizeof типов уже и так
d> выровнены для нормального последовательного размещения, так что
d> вставлять дыры смысла не имеет никакого.

Не так. Есть у нас10-байтный long double, в массив его приходится класть
подряд — чтоб по стандарту, а в структуру имеем право класть с дырками — и
так и делаем, для оптимизации. Где противоречие?

With best regards, Sergey.
Posted via RSDN NNTP Server 1.9 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[2]: Корректен ли код
От: Кирпа В.А. Украина  
Дата: 11.08.04 11:41
Оценка: :)
Здравствуйте, ssm, Вы писали:

ssm>Здравствуйте, Евгений Коробко, Вы писали:




ssm>раньше я так делал очень часто, но видимо могут возникнуть проблемы с выравниванием, может так получше будет?



ssm>
ssm>class Vect
ssm>{
ssm>public:
ssm>  double operator [] (int i) const { ASSERT(i >= 0 && i < 3);  return arr[i];}
ssm>private:
ssm>  double arr[3];
ssm>  double &x(){return arr[0];}
ssm>  double &y(){return arr[1];}
ssm>  double &z(){return arr[2];}
ssm>};
ssm>



маленький штришок
!0xDEAD
Re[3]: Корректен ли код
От: WolfHound  
Дата: 11.08.04 12:50
Оценка: +1
Здравствуйте, Евгений Коробко, Вы писали:

struct vector
{
    double& x(){return items[0]);
    double& y(){return items[1]);
    double& z(){return items[2]);
    double const& x()const{return items[0]);
    double const& y()const{return items[1]);
    double const& z()const{return items[2]);
private:
    double items[3];
};

Ы?
... << RSDN@Home 1.1.4 rev. 142 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: Корректен ли код
От: Анатолий Широков СССР  
Дата: 11.08.04 14:42
Оценка: +1
АШ>Провал:

АШ>
АШ>const Vect v;

АШ>v.x = 10;
АШ>v.y = 20;
АШ>v.y = 30;
АШ>


АШ>Надо дополнительно шаблон reference дописать, чтобы член данных вел себя как подобает.


Выходит что-то вроде этого:

template<typename T>
struct reference_member
{
    typedef T value_type;

    value_type *value;

    explicit reference_member(value_type &ref) : value(&ref) {}

    template<typename T1>
    reference_member& operator = (const T1 &other) 
    {
        *value = other;
        return (*this);
    }

    reference_member& operator = (const reference_member &other)
    {
        value = other.value;
        return (*this);
    }

    operator value_type const &() const {return (*value);}
};

struct point
{
    point() : x(c[0]), y(c[1]), z(c[2]) 
    {
    }

    point(double tx, double ty, double tz) : x(c[0]), y(c[1]), z(c[2]) 
    {
        x = tx;
        y = ty;
        z = tz;
    }

    double& operator[](size_t i) 
    {
        return c[i];
    }

    double const& operator[](size_t i) const 
    {
        return c[i];
    }

    double c[3];
    reference_member<double> x;
    reference_member<double> y;
    reference_member<double> z;
};

int main()
{
    point p(10, 290, 200);

    p.x = 10;
    int d = p.x;
    p[0] = 10;
    p.y = p.y;
    p.z = d;

    const point p1;

    p1.x = p1.x; // error
    p1.x = 10; // error

    int d1 = p1.x; // ok

    return 0;
}


С другой стороны, выпендреж все это — неоправданный расход sizeof(reference_member<double>)*3 + const байт памяти ради сомнительно "высокого" искусства. Поэтому надо оставить:


struct point1 
{
   double x;
   double y;
   double z;
   ...
};


и горя не знать, имхо.
Re[10]: Корректен ли код
От: dupamid Россия  
Дата: 11.08.04 14:56
Оценка: :)
Здравствуйте, Sergey, Вы писали:

d>> Можещь посмотреть на gcc под Windows — 12, на Intel C++ (/Qlong_double) — 16.


S>И что с того? Под Win 16 у кучи компиляторов long double 80-bit был.


Так и у Win32 это все тот же 80-битный long double (в этом смысле размеры типов у FPU не изменились), его размер увеличен для выравнивания.

Кстати сказать, нашелся компилятор, "нетрадиционной ориентации" — BCC 5.5.1:
sizeof(long double) == 10
sizeof(S) == 32
Re: А я бы при нужде рискнул...
От: Erop Россия  
Дата: 25.11.05 10:36
Оценка: +1
Здравствуйте, Евгений Коробко, Вы писали:

ЕК>Собственно, вопрос вызывает то, можно ли быть уверенным, что x,y,z будут расположены в памяти подряд?


Конечно нельзя, но, как мне кажется, если очень нужно, то можно. Особенно для POD. (При этом можно хакнуть хитро -- завести структуру, где только поля, а уж её сделать полем этого хитрого класса)

Я прочитал всю ветку, и удивился, что никто не предложил пользоваться таким "почти стандартным" поведением, но при этом проверять его CT-assert'ом, например C_ASSERT

В конце концов это довольно надёжно. Если кто-то будет переносить этот код на какую-то дргугую платформу, где таки хак не работает, то там можно это дело подправить, например при помощи прагм.

Кроме того, я хочу немного уточнить ситуацию с бинарной совместимостью.
Конечно реализаций C++ очень много, среди них есть очень причудливые.
Но при этом, платформ на свете гараздо меньше. И на каждой есть API. Так что по крайней мере надо быть совместиммы с ним по раскладке структур.

Я не знаю платформ, где описываемое поведение нарушалось бы. Так что у компилятора, который хочет быть "не как все" есть два пути.
1) Быть не как все на каких-то экзотических типах, которых нет в API, например на long double, который больше 8 байт.
2) Иметь какие-то прагмы, которые для некоторых структур это "особое" поведение выключают.

Так что мне кажется, что такой подход вполне можно использовать, но только в случае, если есть веские основания (они, кстати, могут оказаться ещё более неперносимыми)

Правда если доступ к полям завернуть в методы, то на проблемной платформе всегда будет маза перейти к решению с методами возвращающими ссылки на элементы массива

Ну а резон, описанный в этом топике мне кажется не таким уж и весомым
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Корректен ли код
От: Евгений Коробко  
Дата: 11.08.04 11:02
Оценка:
class Vect
{
...
public:
double operator [] (int i) const {return *(&x+i);};
private:
double x,y,z;
};

Собственно, вопрос вызывает то, можно ли быть уверенным, что x,y,z будут расположены в памяти подряд?
Евгений Коробко
Re: Корректен ли код
От: achp  
Дата: 11.08.04 11:07
Оценка:
Здравствуйте, Евгений Коробко, Вы писали:

ЕК>Собственно, вопрос вызывает то, можно ли быть уверенным, что x,y,z будут расположены в памяти подряд?


Нет.
Re: Корректен ли код
От: Анатолий Широков СССР  
Дата: 11.08.04 11:08
Оценка:
ЕК>Собственно, вопрос вызывает то, можно ли быть уверенным, что x,y,z будут расположены в памяти подряд?

Нет, такой гарантии нет. Для гарантии необходимо использовать массив.
Re: Корректен ли код
От: dupamid Россия  
Дата: 11.08.04 11:12
Оценка:
Здравствуйте, Евгений Коробко, Вы писали:

ЕК>class Vect

ЕК>{
ЕК>...
ЕК>public:
ЕК> double operator [] (int i) const {return *(&x+i);};
ЕК>private:
ЕК> double x,y,z;
ЕК>};

ЕК>Собственно, вопрос вызывает то, можно ли быть уверенным, что x,y,z будут расположены в памяти подряд?


Так как пример написан — нет (есть private члены). Для того чтобы была гарантия последовательного размещения класс должен быть POD. На практике обычно будет работать.
Re[2]: Корректен ли код
От: Анатолий Широков СССР  
Дата: 11.08.04 11:14
Оценка:
D>Так как пример написан — нет (есть private члены). Для того чтобы была гарантия последовательного размещения класс должен быть POD.

Причем здесь POD?
Re: Корректен ли код
От: Glоbus Украина  
Дата: 11.08.04 11:14
Оценка:
Здравствуйте, Евгений Коробко, Вы писали:

ЕК>class Vect

ЕК>{
ЕК>...
ЕК>public:
ЕК> double operator [] (int i) const {return *(&x+i);};
ЕК>private:
ЕК> double x,y,z;
ЕК>};

ЕК>Собственно, вопрос вызывает то, можно ли быть уверенным, что x,y,z будут расположены в памяти подряд?


Нет
Удачи тебе, браток!
Re: Корректен ли код
От: Sergey Россия  
Дата: 11.08.04 11:18
Оценка:
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 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[3]: Корректен ли код
От: dupamid Россия  
Дата: 11.08.04 11:23
Оценка:
Здравствуйте, Анатолий Широков, Вы писали:

D>>Так как пример написан — нет (есть private члены). Для того чтобы была гарантия последовательного размещения класс должен быть POD.


АШ>Причем здесь POD?


Так как для POD есть требование совместимости по раскладке (layout-compatible), то для POD-struct члены должны лежать последовательно. Если говорить упрощенно то две структуры с одинаковым началом должны содержать одинаковые члены на одинаковых местах. Так что можно построить последовательность структур, в каждой на один член больше чем в предыдущей и их начала должны быть разложены одинаково, для того чтобы это соблюсти придется разложить члены последовательно.
Re[2]: Корректен ли код
От: Евгений Коробко  
Дата: 11.08.04 11:24
Оценка:
Спасибо!
Реально дырок для выравнивания, вероятно, не будет, потому как для double вряд ли будет выравнивание по 16 байт. В крайнем случае, можно управлять выравниваем директивами компиляторы
Евгений Коробко
Re[2]: Корректен ли код
От: Евгений Коробко  
Дата: 11.08.04 11:26
Оценка:
Такой код не работает:
class Vect
{
...
private:
double items[3];
double& x=items[0];
double& y=items[1];
double& z=items[2];
};

А через индексы уж больно некрасиво выглядит.
Евгений Коробко
Re[3]: Корректен ли код
От: maq Россия http://www.maqdev.com
Дата: 11.08.04 11:32
Оценка:
Здравствуйте, Евгений Коробко, Вы писали:

ЕК>Такой код не работает:

ЕК>class Vect
ЕК>{
ЕК>...
ЕК>private:
ЕК> double items[3];
ЕК> double& x=items[0];
ЕК> double& y=items[1]; 
ЕК> double& z=items[2];
ЕК>};

Все верно — инициализация ссылок должна быть в конструкторе.
Еще можно предложить такой вариант:
    class Vect
    {
            ...
    private:
        double items[3];
        enum {x,y,z};
        ...
        // юзаем как items[x], items[y] ...
    };


ЕК>А через индексы уж больно некрасиво выглядит.
... << RSDN@Home 1.1.4 beta 2 >>
Re[4]: Корректен ли код
От: achp  
Дата: 11.08.04 11:32
Оценка:
Здравствуйте, dupamid, Вы писали:

D>Так как для POD есть требование совместимости по раскладке (layout-compatible), то для POD-struct члены должны лежать последовательно.


По возрастанию адресов — да, но вряд ли последовательно.
Re: Корректен ли код
От: ssm Россия  
Дата: 11.08.04 11:33
Оценка:
Здравствуйте, Евгений Коробко, Вы писали:



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


class Vect
{
public:
  double operator [] (int i) const {return arr[i];}
private:
  double arr[3];
  double &x(){return arr[0];}
  double &y(){return arr[1];}
  double &z(){return arr[2];}
};
Re[3]: Корректен ли код
От: rus blood Россия  
Дата: 11.08.04 11:33
Оценка:
Здравствуйте, Евгений Коробко, Вы писали:

ЕК>Такой код не работает:

ЕК>class Vect
ЕК>{
ЕК>...
ЕК>private:
ЕК> double items[3];
ЕК> double& x=items[0];
ЕК> double& y=items[1];
ЕК> double& z=items[2];
ЕК>};


class Vect
{
public:
    Vect() : x(items[0]), y(items[1]), z(items[2]) {}

private:
    double items[3];
    double& x;
    double& y;
    double& z;
};
Имею скафандр — готов путешествовать!
Re[2]: Корректен ли код
От: Bell Россия  
Дата: 11.08.04 11:39
Оценка:
Здравствуйте, dupamid, Вы писали:


D>Так как пример написан — нет (есть private члены). Для того чтобы была гарантия последовательного размещения класс должен быть POD. На практике обычно будет работать.


А что насчет выравнивания?
Любите книгу — источник знаний (с) М.Горький
Re[4]: Корректен ли код
От: Анатолий Широков СССР  
Дата: 11.08.04 11:39
Оценка:
RB>
RB>class Vect
RB>{
RB>public:
RB>    Vect() : x(items[0]), y(items[1]), z(items[2]) {}

RB>private:
RB>    double items[3];
RB>    double& x;
RB>    double& y;
RB>    double& z;
RB>};
RB>



Провал:

const Vect v;

v.x = 10;
v.y = 20;
v.y = 30;


Надо дополнительно шаблон reference дописать, чтобы член данных вел себя как подобает.
Re: Корректен ли код
От: ilnar Россия  
Дата: 11.08.04 11:40
Оценка:
Здравствуйте, Евгений Коробко, Вы писали:

ЕК>class Vect

ЕК>{
ЕК>...
ЕК>public:
ЕК> double operator [] (int i) const {return *(&x+i);};
ЕК>private:
ЕК> double x,y,z;
ЕК>};

ЕК>Собственно, вопрос вызывает то, можно ли быть уверенным, что x,y,z будут расположены в памяти подряд?


да
Re[5]: Корректен ли код
От: dupamid Россия  
Дата: 11.08.04 11:45
Оценка:
Здравствуйте, 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, то доступ к полям должен осуществляться без проблем. Такие требования есть наследие С. Где было популярно в следующей версии добавлять поля в структуры, при этом раскладка ее начала должна быть одинаковой для бинарной совместимости со старыми программами.
Re[3]: Корректен ли код
От: dupamid Россия  
Дата: 11.08.04 11:49
Оценка:
Здравствуйте, Bell, Вы писали:

D>>Так как пример написан — нет (есть private члены). Для того чтобы была гарантия последовательного размещения класс должен быть POD. На практике обычно будет работать.


B>А что насчет выравнивания?


В данном случае это не проблема, так как все члены одного типа. Вот если они будут разных типов, пусть даже одного размера — тогда могут быть проблемы.
Re[3]: Корректен ли код
От: ilnar Россия  
Дата: 11.08.04 11:50
Оценка:
Здравствуйте, Bell, Вы писали:

B>Здравствуйте, dupamid, Вы писали:



D>>Так как пример написан — нет (есть private члены). Для того чтобы была гарантия последовательного размещения класс должен быть POD. На практике обычно будет работать.


B>А что насчет выравнивания?


объекты в структуре будут выравниваться так, как требуется для их типа, например, long — по 4 байтам, так же будет и в массиве.
Re[3]: Корректен ли код
От: ssm Россия  
Дата: 11.08.04 11:58
Оценка:
Здравствуйте, Кирпа В.А., Вы писали:


double operator [] (int i) const { assert(i >= 0 && i < 3); return arr[i];}

КВА>маленький штришок


еще один
Re[4]: Корректен ли код
От: Bell Россия  
Дата: 11.08.04 12:41
Оценка:
Здравствуйте, dupamid, Вы писали:

D>В данном случае это не проблема, так как все члены одного типа. Вот если они будут разных типов, пусть даже одного размера — тогда могут быть проблемы.


Все это — не более чем наблюдаемое поведение одного или нескольких компиляторов. Что же касается стандарта, то ни о чем подобном там нет и речи:

9.2/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).


или я плохо искал?
Любите книгу — источник знаний (с) М.Горький
Re[5]: Корректен ли код
От: dupamid Россия  
Дата: 11.08.04 13:20
Оценка:
Здравствуйте, Bell, Вы писали:

D>>В данном случае это не проблема, так как все члены одного типа. Вот если они будут разных типов, пусть даже одного размера — тогда могут быть проблемы.


B>Все это — не более чем наблюдаемое поведение одного или нескольких компиляторов. Что же касается стандарта, то ни о чем подобном там нет и речи:

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

B>или я плохо искал?

Что конкретно ты считаешь не соответствует Стандарту или не требуется им. Могут ли быть дырки между подряд идущими членами класса одного типа? Если компилятор так поступает АБСОЛЮТНО всегда (во всех струтурах, чтобы они были совместимы по раскладке) то теортически могут — прямого запрета на это нет. Но это просто не имеет никакого смысла, поэтому, наверное, не удастся найти ни один такой компилятор.
Re[6]: Корректен ли код
От: dupamid Россия  
Дата: 11.08.04 13:29
Оценка:
Использовать это для оптимизации выравнивания нельзя, так как размер типа в массиве и самомого по себе должен быть одинаковым. Т.е. реализация, на которой sizeof типа long double 10 байт, а в масиве их кладут через 16 — для выравнивания, не соответсвует Стнадарту. Теперь, если вернуться у структурам, то получается что sizeof типов уже и так выровнены для нормального последовательного размещения, так что вставлять дыры смысла не имеет никакого.
Re[6]: Корректен ли код
От: Bell Россия  
Дата: 11.08.04 13:32
Оценка:
Здравствуйте, dupamid, Вы писали:

D>Что конкретно ты считаешь не соответствует Стандарту или не требуется им. Могут ли быть дырки между подряд идущими членами класса одного типа? Если компилятор так поступает АБСОЛЮТНО всегда (во всех струтурах, чтобы они были совместимы по раскладке) то теортически могут — прямого запрета на это нет. Но это просто не имеет никакого смысла, поэтому, наверное, не удастся найти ни один такой компилятор.


Мое мнение таково: если стандарт чего-то не гарантирует, или тем паче прямо говорит о возможности несоблюдения неких свойств или поведения, то на такие свойства/поведение полагаться не стоит, даже если во всех доступных реализациях все "работает как надо". Тем более в ситуациях, когда есть простое "стандартное" решение.
Любите книгу — источник знаний (с) М.Горький
Re[7]: Корректен ли код
От: dupamid Россия  
Дата: 11.08.04 14:13
Оценка:
Здравствуйте, Bell, Вы писали:

D>>Что конкретно ты считаешь не соответствует Стандарту или не требуется им. Могут ли быть дырки между подряд идущими членами класса одного типа? Если компилятор так поступает АБСОЛЮТНО всегда (во всех структурах, чтобы они были совместимы по раскладке) то теоретически могут — прямого запрета на это нет. Но это просто не имеет никакого смысла, поэтому, наверное, не удастся найти ни один такой компилятор.


B>Мое мнение таково: если стандарт чего-то не гарантирует, или тем паче прямо говорит о возможности несоблюдения неких свойств или поведения, то на такие свойства/поведение полагаться не стоит, даже если во всех доступных реализациях все "работает как надо". Тем более в ситуациях, когда есть простое "стандартное" решение.


Де-факто, такое размещение членов структур важно для низкоуровневого программирования именно для этого в Стандарте присутствуют POD и бинарная совместимость структур. Не смотря на кажущуюся вольность в размещение членов структур и битовых полей, ей никто не пользуется, так как это нарушит возможность использования языка для низкоуровневого программирования, где нужно строго контролировать раскладку структур и на самом деле реализации позволяют это делать, и не просто некоторые — а все. Выравнивание, раскладка структур, размеры типов, возможность копирования POD побайтно – это все части этой бинарной совместимости.

Что касается гарантий Стандарта, то мы практически постоянно пишем код, который балансирует на грани (а часто и за гранью) Стандарта. Это неизбежно. Например, практически любая программа содержит преобразования типов, которые является по-сути reinterpret_cast (возможно записанные через преобразования типов в старом стиле), поведение, которого явно оговорено что не портируемо. В этом смысле мне нравиться подход комитета по стандартизации С, есть понятие "common existing practice" и Стандарт старается ее поддерживать и пояснять, даже когда можно было бы сделать лучше ее нарушив. В C99Rational про это хорошо написано.

Касательно вопроса о раскладке структур там написано следующее:

The layout of structures is determined only to a limited extent:
— no hole may occur at the beginning.
— consecutive members occupy increasing storage addresses.
— if necessary, a hole is placed on the end to make the structure big enough to pack tightly into arrays and maintain proper alignment.

Since some existing implementations, in the interest of enhanced access time, leave internal holes larger than absolutely necessary, it is not clear that a portable deterministic method can be given for traversing a structure member by member.


Возможно путешествия по членам структуры на практике вызывает сложности только для членов разных типов, а не подряд идущих одинаковых.
Re[8]: Корректен ли код
От: dupamid Россия  
Дата: 11.08.04 14:24
Оценка:
Здравствуйте, Sergey, Вы писали:

d>> Использовать это для оптимизации выравнивания нельзя, так как размер

d>> типа в массиве и самомого по себе должен быть одинаковым. Т.е.
d>> реализация, на которой sizeof типа long double 10 байт, а в масиве их
d>> кладут через 16 — для выравнивания, не соответсвует Стнадарту. Теперь,
d>> если вернуться у структурам, то получается что sizeof типов уже и так
d>> выровнены для нормального последовательного размещения, так что
d>> вставлять дыры смысла не имеет никакого.

S>Не так. Есть у нас10-байтный long double, в массив его приходится класть

S>подряд — чтоб по стандарту, а в структуру имеем право класть с дырками — и
S>так и делаем, для оптимизации. Где противоречие?

А почему это его sizeof будет равен 10???
Можещь посмотреть на gcc под Windows — 12, на Intel C++ (/Qlong_double) — 16.

#include <stdio.h>

struct S
{
    long double d1;
    long double d2;
};

int main()
{
    printf("sizeof(long double) == %d\n", sizeof(long double));
    printf("sizeof(S) == %d\n", sizeof(S));
}


GCC:
sizeof(long double) == 12
sizeof(S) == 24

ICL (/Qlong_double):
sizeof(long double) == 16
sizeof(S) == 32
Re[9]: Корректен ли код
От: Sergey Россия  
Дата: 11.08.04 14:47
Оценка:
Hello, dupamid!
You wrote on Wed, 11 Aug 2004 14:24:10 GMT:

S>> Не так. Есть у нас10-байтный long double, в массив его приходится

S>> класть подряд — чтоб по стандарту, а в структуру имеем право класть с
S>> дырками — и так и делаем, для оптимизации. Где противоречие?

d> А почему это его sizeof будет равен 10???


А почему бы и нет? Мы же рассматриваем гипотетическую ситуацию. Но если
нужна причина, пусть будет потому, что это для сопроцессора "родная" длина
слова.

d> Можещь посмотреть на gcc под Windows — 12, на Intel C++ (/Qlong_double)

d> — 16.

И что с того? Под Win 16 у кучи компиляторов long double 80-bit был.

With best regards, Sergey.
Posted via RSDN NNTP Server 1.9 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[8]: Корректен ли код
От: Анатолий Широков СССР  
Дата: 11.08.04 14:53
Оценка:
Я не могу понять, почему Вы настолько убеждены, что компилятор для структуры вида:


struct point
{
    double x;
    double y;
    double z;
};


не может сделать что-то подобное:

| x |XXXX| y |XXXX| z |XXXX

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


double operator[](size_t i) {return (&x + i);}


является хаком в том, смысле, что безосновательно полагается на то, что между x, y и z нет "дыр".
Re: Корректен ли код
От: MaximE Великобритания  
Дата: 12.08.04 06:47
Оценка:
Евгений Коробко wrote:

> class Vect

> {
> ...
> public:
> double operator [] (int i) const {return *(&x+i);};
> private:
> double x,y,z;
> };
>
> Собственно, вопрос вызывает то, можно ли быть уверенным, что x,y,z будут расположены в памяти подряд?

Вопрос достаточно тонкий и заставляет хмурить брови, когда смотришь на такой код.

Почему бы не написать простой и безопасный код?

struct vect
{
     double arr[3];
     enum { x, y, z };

     double operator[](size_t i) const { return arr[i]; }
     double f() const { return arr[x] * arr[z]; }
};


--
Maxim Yegorushkin
Posted via RSDN NNTP Server 1.9 beta
Re[2]: Корректен ли код
От: Евгений Коробко  
Дата: 12.08.04 07:14
Оценка:
ME>Почему бы не написать простой и безопасный код?
Потому что получается либо простой, либо безопасный. Потому как если обращаться к членам через m_Items[x], то формула, например, векторного умножения будет выглядеть просто страшно.

Сейчас так:
return Vect(v1.m_X*v2.m_Z-v1.m_Z*v2.m_Y, v1.m_Z*v2.m_X-v1.m_X*v2.m_Z,
v1.m_Y*v2.m_Z-v1.m_Z*v2.m_Y);

А будет так:

return Vect(v1.m_Items[x]*v2.m_Items[z]-v1.m_Items[z]*v2.m_Items[y], v1.m_Items[z]*v2.m_Items[x]-v1.m_Items[x]*v2.m_Items[z],
v1.m_Items[y]*v2.m_Items[z]-v1.m_Items[z]*v2.m_Items[y]);

Стало гораздо хуже. А что качается функций доступа, то просто нет уверенности, что компилятор оптимизирует это как надо, а кусок критичный
Евгений Коробко
Re[3]: Корректен ли код
От: MaximE Великобритания  
Дата: 12.08.04 07:48
Оценка:
Евгений Коробко wrote:

> Потому что получается либо простой, либо безопасный. Потому как если обращаться к членам через m_Items[x], то формула, например, векторного умножения будет выглядеть просто страшно.

>
> Сейчас так:
> return Vect(v1.m_X*v2.m_Z-v1.m_Z*v2.m_Y, v1.m_Z*v2.m_X-v1.m_X*v2.m_Z,
> v1.m_Y*v2.m_Z-v1.m_Z*v2.m_Y);
>
> А будет так:
>
> return Vect(v1.m_Items[x]*v2.m_Items[z]-v1.m_Items[z]*v2.m_Items[y], v1.m_Items[z]*v2.m_Items[x]-v1.m_Items[x]*v2.m_Items[z],
> v1.m_Items[y]*v2.m_Items[z]-v1.m_Items[z]*v2.m_Items[y]);

Лично я разницы не вижу — и тот и другой кусок страшен.

Я бы написал так:

double const(&a)[N] = v1.m_Items;
double const(&b)[N] = v2.m_Items;
return Vect(
       a[x] * b[z] - a[z] * b[y]
     , a[z] * b[x] - a[x] * b[z]
     , a[y] * b[z] - a[z] * b[y]
     );


> Стало гораздо хуже. А что качается функций доступа, то просто нет уверенности, что компилятор оптимизирует это как надо, а кусок критичный


Тут ответ риторический — профайлинг и / или изучение ассемблерного кода.

--
Maxim Yegorushkin
Posted via RSDN NNTP Server 1.9 beta
Re[4]: Корректен ли код
От: Шахтер Интернет  
Дата: 12.08.04 09:33
Оценка:
Здравствуйте, MaximE, Вы писали: ...

Возвращаясь к недавней дискуссии. Вот здесь бы для упрощения кода помогли бы пропертя.
... << RSDN@Home 1.1.0 stable >>
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[11]: Корректен ли код
От: srggal Украина  
Дата: 25.11.05 10:49
Оценка:
Здравствуйте, dupamid, Вы писали:

D>Здравствуйте, Sergey, Вы писали:


d>>> Можещь посмотреть на gcc под Windows — 12, на Intel C++ (/Qlong_double) — 16.


S>>И что с того? Под Win 16 у кучи компиляторов long double 80-bit был.


D>Так и у Win32 это все тот же 80-битный long double (в этом смысле размеры типов у FPU не изменились), его размер увеличен для выравнивания.


Именно в этом и поинт.

Стандарт, вроде как, жестко(абсолютно) не привязывает ни размеры кардинальных типов ни выравнивания, все это отдано на откуп разработчикам компилятора.
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[8]: Корректен ли код
От: srggal Украина  
Дата: 25.11.05 10:55
Оценка:
Здравствуйте, dupamid, Вы писали:


D>Де-факто, такое размещение членов структур важно для низкоуровневого программирования именно для этого в Стандарте присутствуют POD и бинарная совместимость структур. Не смотря на кажущуюся вольность в размещение членов структур и битовых полей, ей никто не пользуется, так как это нарушит возможность использования языка для низкоуровневого программирования, где нужно строго контролировать раскладку структур и на самом деле реализации позволяют это делать, и не просто некоторые — а все. Выравнивание, раскладка структур, размеры типов, возможность копирования POD побайтно – это все части этой бинарной совместимости.


Пример из личной практики.

Несколько лет назад обратились ко мне коллеги из параллельной организации с вопросом: "А почему мы не можем получить из железяки данные", они использовали POD-struct ( точно не приведу его — не помню ) но в нем была, как здесь назвали "дырка", и получали они иногда мусор, а и ногда кору от ядра

Спасло коллег явное использования выравнивания 1.

К чему это ? Да к тому, что гарантия валидности копирования memcpy ничего не грит о выравнивании.
Да и проблема возникла на железном уровне
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[10]: Корректен ли код
От: dupamid Россия  
Дата: 26.11.05 13:15
Оценка:
Здравствуйте, Alex Alexandrov, Вы писали:

AA>Вмешаюсь в беседу, извините. Почему-то все говорят про Стандарт, забывая о том, что это лишь один из документов, регулирующих поведение компилятора. Когда мы говорим о C-структурах, т.е. о типах, поля которых используются напрямую, то большее значение имеет другой документ: ABI (Application Binary Interface) спецификация. Именно она регулирует подобные вещи в большей степени, стремясь к гарантии, что вы можете использовать библиотеки и заголовочные файлы, полученные с помощью другого компилятора.


AA>В частности, именно Intel 386 ABI запрещает компилятору сделать "что-то подобное", приведенное выше.


А можешь дать ссылочку на этот документ? А то google находит его только для System V, а мне бы хотелось для Windows/Linux или (лучше) не зависымый от опреационной системы. Для Itanium или EM64T/AMD64 это общедоступные документы.
Re[10]: Корректен ли код
От: srggal Украина  
Дата: 28.11.05 08:32
Оценка:
Здравствуйте, Alex Alexandrov, Вы писали:


AA>Вмешаюсь в беседу, извините. Почему-то все говорят про Стандарт, забывая о том, что это лишь один из документов, регулирующих поведение компилятора. Когда мы говорим о C-структурах, т.е. о типах, поля которых используются напрямую, то большее значение имеет другой документ: ABI (Application Binary Interface) спецификация. Именно она регулирует подобные вещи в большей степени, стремясь к гарантии, что вы можете использовать библиотеки и заголовочные файлы, полученные с помощью другого компилятора.


Цитата взята здесь

In computer software, an application binary interface (ABI) describes the low-level interface between an application program and the operating system, between an application and its libraries, or between component parts of the application. An ABI differs from an application programming interface (API) in that an API defines the interface between source code and libraries, so that the same source code will compile on any system supporting that API, whereas an ABI allows compiled object code to function without changes on any system using a compatible ABI.


И исходя из этого становится ясно почему все говорят о Стандарте:
Решение, которое отвечает стандарту, будет переносимым( на компиляторы поддерживающие стандарт ). В свою очередь решения затаченное под Intel Binary Compatibility Standard (iBCS) может быть н6еперносимо на другие платформы.

А об ABI будут думать разрабочики компилятора под конкретные программно-аппаратные платформы. ИМХО в большинстве задач только разработчики компиляторов и должны думать ABI. И очень редко должны задумываться рпзрпботчики ПО
... << RSDN@Home 1.1.4 stable rev. 510>>
Re: Корректен ли код
От: Аноним  
Дата: 28.11.05 10:28
Оценка:
Здравствуйте, Евгений Коробко, Вы писали:

ЕК>class Vect

ЕК>{
ЕК>...
ЕК>public:
ЕК> double operator [] (int i) const {return *(&x+i);};
ЕК>private:
ЕК> double x,y,z;
ЕК>};

ЕК>Собственно, вопрос вызывает то, можно ли быть уверенным, что x,y,z будут расположены в памяти подряд?


А почему бы (чтобы не возникали такие вопросы и не было зависимости от используемого компилятора) не написать просто

class Vect
{
...
public:
double operator [] (int i) const {return x[i];};
private:
double x[3];
};

Олег Р.
Re[2]: Корректен ли код
От: ekamaloff Великобритания  
Дата: 28.11.05 10:43
Оценка:
Здравствуйте, Аноним, Вы писали:

А>А почему бы (чтобы не возникали такие вопросы и не было зависимости от используемого компилятора) не написать просто


А>class Vect

А>{
А>...
А>public:
А> double operator [] (int i) const {return x[i];};
А>private:
А> double x[3];
А>};

читай внимательней предыдущие посты — человеку не нравится обращаться к значениям по индексу, хочется символьных обозначений %)

А>Олег Р.
It is always bad to give advices, but you will be never forgiven for a good one.
Oscar Wilde
Re[11]: Корректен ли код
От: Alex Alexandrov США  
Дата: 29.11.05 18:59
Оценка:
Здравствуйте, srggal, Вы писали:

S>И исходя из этого становится ясно почему все говорят о Стандарте:

S> Решение, которое отвечает стандарту, будет переносимым( на компиляторы поддерживающие стандарт ). В свою очередь решения затаченное под Intel Binary Compatibility Standard (iBCS) может быть н6еперносимо на другие платформы.

S>А об ABI будут думать разрабочики компилятора под конкретные программно-аппаратные платформы. ИМХО в большинстве задач только разработчики компиляторов и должны думать ABI. И очень редко должны задумываться рпзрпботчики ПО


Разработчики ПО обязаны знать об ABI. Когда ты пишешь библиотеку под Unix, тебе надо понимать это хотя бы для того, чтобы понять, является ли новая версия твоей библиотеки ABI-совместимой с предыдущей, и какую цифру в версии таки надо менять (major/minor/patch). Когда начинаются глюки с С++ рантаймом также надо знать, что такое ABI и когда у GCC он поменялся. И т.д.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
It's kind of fun to do the impossible (Walt Disney)
Re[11]: Корректен ли код
От: Alex Alexandrov США  
Дата: 29.11.05 18:59
Оценка:
Здравствуйте, dupamid, Вы писали:

D>Здравствуйте, Alex Alexandrov, Вы писали:


AA>>Вмешаюсь в беседу, извините. Почему-то все говорят про Стандарт, забывая о том, что это лишь один из документов, регулирующих поведение компилятора. Когда мы говорим о C-структурах, т.е. о типах, поля которых используются напрямую, то большее значение имеет другой документ: ABI (Application Binary Interface) спецификация. Именно она регулирует подобные вещи в большей степени, стремясь к гарантии, что вы можете использовать библиотеки и заголовочные файлы, полученные с помощью другого компилятора.


AA>>В частности, именно Intel 386 ABI запрещает компилятору сделать "что-то подобное", приведенное выше.


D>А можешь дать ссылочку на этот документ? А то google находит его только для System V, а мне бы хотелось для Windows/Linux или (лучше) не зависымый от опреационной системы. Для Itanium или EM64T/AMD64 это общедоступные документы.


Честно сказать, я привел цитату из того же System V ABI. Что-то мне подсказывает, что GCC ABI корнями идет оттуда. Но не смог найти явной информации.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
It's kind of fun to do the impossible (Walt Disney)
Re: Корректен ли код
От: Аноним  
Дата: 30.11.05 08:40
Оценка:
ЕК>class Vect
ЕК>{
ЕК>...
ЕК>public:
ЕК> double operator [] (int i) const {return *(&x+i);};
ЕК>private:
ЕК> double x,y,z;
ЕК>};

ЕК>Собственно, вопрос вызывает то, можно ли быть уверенным, что x,y,z будут расположены в памяти подряд?


Если мне не изменяет память, такая гарантия есть, если это будет не class а struct
Re[2]: Корректен ли код
От: Bell Россия  
Дата: 30.11.05 09:17
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Если мне не изменяет память, такая гарантия есть, если это будет не class а struct

Можно привести ссылки на первоисточники?
Любите книгу — источник знаний (с) М.Горький
Re[14]: Корректен ли код
От: srggal Украина  
Дата: 30.11.05 11:02
Оценка:
Здравствуйте, jazzer, Вы писали:

[]

Немного оторвано от контекста дискуссии, но тем не менее

ГМ, в целом, я писал здесь
Автор: srggal
Дата: 28.11.05
так:

А об ABI будут думать разрабочики компилятора под конкретные программно-аппаратные платформы. ИМХО в большинстве задач только разработчики компиляторов и должны думать ABI. И очень редко должны задумываться рпзрпботчики ПО



Думаю Вы согласитесь, что "очень редко" как раз описываеи привеленную Вами ситуацию

... << RSDN@Home 1.1.4 stable rev. 510>>
Re[15]: Корректен ли код
От: jazzer Россия Skype: enerjazzer
Дата: 30.11.05 11:24
Оценка:
Здравствуйте, srggal, Вы писали:

S>Здравствуйте, jazzer, Вы писали:


S>[]


S>Немного оторвано от контекста дискуссии, но тем не менее


S>ГМ, в целом, я писал здесь
Автор: srggal
Дата: 28.11.05
так:


S>

S>А об ABI будут думать разрабочики компилятора под конкретные программно-аппаратные платформы. ИМХО в большинстве задач только разработчики компиляторов и должны думать ABI. И очень редко должны задумываться рпзрпботчики ПО



S>Думаю Вы согласитесь, что "очень редко" как раз описываеи привеленную Вами ситуацию


S>


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

И потом, ты ведь спорил конкретно с http://rsdn.ru/Forum/Message.aspx?mid=1512742&amp;only=1
Автор: Alex Alexandrov
Дата: 29.11.05
, а там как раз идет речь именно о смене ABI.

Еще пример — у тебя есть приложение, собранное из нескольких библиотек плюс то, что ты написал. Так вот, собирая все это дело вместе, имеет смысл помнить, что каждый компонент мог быть собран со своими ключами компиляции, а эти ключи, в принципе, могут конфликтовать (хотя это, конечно, было бы очень нехорошо со стороны разработчиков компилятора). По-моему, у VC++ или у Борланда была опция, при помощи которой которой можно было управлять бинарной реализацией множественного наследования, и предлагалось там варианта 4, по-моему. Насколько я понимаю, эти варианты были бинарно несовместимыми, а это означало, что если тебе захотелось изменить эту опцию, тебе в общем случае придется пересобрать все библиотеки, а не только парочку объектников, которые тебя интересуют. И хорошо, если все библиотеки у тебя есть в исходниках. А если нет? Ты проклянешь все в поисках причины глюков и путей их объезда.

P.S. Мы ведь на "ты" здесь, да?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[16]: Корректен ли код
От: srggal Украина  
Дата: 30.11.05 11:33
Оценка:
Здравствуйте, jazzer, Вы писали:

S>>Немного оторвано от контекста дискуссии, но тем не менее


S>>ГМ, в целом, я писал здесь
Автор: srggal
Дата: 28.11.05
так:


S>>

S>>А об ABI будут думать разрабочики компилятора под конкретные программно-аппаратные платформы. ИМХО в большинстве задач только разработчики компиляторов и должны думать ABI. И очень редко должны задумываться рпзрпботчики ПО



J>И потом, ты ведь спорил конкретно с http://rsdn.ru/Forum/Message.aspx?mid=1512742&amp;only=1
Автор: Alex Alexandrov
Дата: 29.11.05
, а там как раз идет речь именно о смене ABI.


Я вот о чем: этот спор в контексте темы топика


J>Еще пример — у тебя есть приложение, собранное из нескольких библиотек плюс то, что ты написал. Так вот, собирая все это дело вместе, имеет смысл помнить, что каждый компонент мог быть собран со своими ключами компиляции, а эти ключи, в принципе, могут конфликтовать (хотя это, конечно, было бы очень нехорошо со стороны разработчиков компилятора). По-моему, у VC++ или у Борланда была опция, при помощи которой которой можно было управлять бинарной реализацией множественного наследования, и предлагалось там варианта 4, по-моему. Насколько я понимаю, эти варианты были бинарно несовместимыми, а это означало, что если тебе захотелось изменить эту опцию, тебе в общем случае придется пересобрать все библиотеки, а не только парочку объектников, которые тебя интересуют. И хорошо, если все библиотеки у тебя есть в исходниках. А если нет? Ты проклянешь все в поисках причины глюков и путей их объезда.


Дык что да, то да

Но опять, в контексте темы отпика и первого сообщения того, с кем я спорил

ABI не при чем
Что я и озвучил здесь
Автор: srggal
Дата: 28.11.05


J>P.S. Мы ведь на "ты" здесь, да?

По правилам вроде на Вы

... << RSDN@Home 1.1.4 stable rev. 510>>
Re[17]: Корректен ли код
От: jazzer Россия Skype: enerjazzer
Дата: 30.11.05 11:41
Оценка:
Здравствуйте, srggal, Вы писали:

S>Здравствуйте, jazzer, Вы писали:


J>>И потом, ты ведь спорил конкретно с http://rsdn.ru/Forum/Message.aspx?mid=1512742&amp;only=1
Автор: Alex Alexandrov
Дата: 29.11.05
, а там как раз идет речь именно о смене ABI.


S>Я вот о чем: этот спор в контексте темы топика


в контексте темы топика нам от ABI достаточно sizeof

J>>P.S. Мы ведь на "ты" здесь, да?

S>По правилам вроде на Вы

S>


ОК, прошу прощения за тыканье!
Постараюсь запомнить, что с Вами надо на Вы Ну или на брудершафт
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[18]: Корректен ли код
От: srggal Украина  
Дата: 30.11.05 11:46
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Здравствуйте, srggal, Вы писали:


S>>Здравствуйте, jazzer, Вы писали:


J>>>И потом, ты ведь спорил конкретно с http://rsdn.ru/Forum/Message.aspx?mid=1512742&amp;only=1
Автор: Alex Alexandrov
Дата: 29.11.05
, а там как раз идет речь именно о смене ABI.


S>>Я вот о чем: этот спор в контексте темы топика


J>в контексте темы топика нам от ABI достаточно sizeof

И чем нам
здесь
Автор: Евгений Коробко
Дата: 11.08.04


достаточно sizeof

Для того что-бы забить на выравнивание и статически проверять при компялиции валидность утверждения ?
ИМХО — не выход.

J>>>P.S. Мы ведь на "ты" здесь, да?

S>>По правилам вроде на Вы

S>>


J>ОК, прошу прощения за тыканье!

J>Постараюсь запомнить, что с Вами надо на Вы Ну или на брудершафт
Ах, оставьте...

... << RSDN@Home 1.1.4 stable rev. 510>>
Re[19]: Корректен ли код
От: jazzer Россия Skype: enerjazzer
Дата: 30.11.05 12:21
Оценка:
Здравствуйте, srggal, Вы писали:

S>достаточно sizeof


S>Для того что-бы забить на выравнивание и статически проверять при компялиции валидность утверждения ?

S>ИМХО — не выход.

Ну почему же

если sizeof(массив) == sizeof(структура) — значит, нечему там больше быть, кроме этих несчастных членов в порядке их объявления в классе.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[20]: Корректен ли код
От: srggal Украина  
Дата: 30.11.05 12:26
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Здравствуйте, srggal, Вы писали:


S>>достаточно sizeof


S>>Для того что-бы забить на выравнивание и статически проверять при компялиции валидность утверждения ?

S>>ИМХО — не выход.

J>Ну почему же


J>если sizeof(массив) == sizeof(структура) — значит, нечему там больше быть, кроме этих несчастных членов в порядке их объявления в классе.


Я же написал ИМХО
Потому что нет гарантии что в следующей версии компилятора, или на другом компиляторе все будект ОК ( ABI прнимаешь )

ИМХО лучше, по возможности, придерживаться стандарта



ЗЫ
Можно не отвечать ибо еще немного и нас можно в философию отправлять
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[13]: Корректен ли код
От: Alex Alexandrov США  
Дата: 02.12.05 19:53
Оценка:
Здравствуйте, srggal, Вы писали:

S>Здравствуйте, Alex Alexandrov, Вы писали:


AA>>Разработчики ПО обязаны знать об ABI. Когда ты пишешь библиотеку под Unix, тебе надо понимать это хотя бы для того, чтобы понять, является ли новая версия твоей библиотеки ABI-совместимой с предыдущей, и какую цифру в версии таки надо менять (major/minor/patch). Когда начинаются глюки с С++ рантаймом также надо знать, что такое ABI и когда у GCC он поменялся. И т.д.


S>Насколько сильно я ошибусь предположив что руководствуясь стандартом языка С/С++ я могу абстрагироваться от АБИ?


S>Если Вас не затруднит — приведите пример когда с точки зрения стандарта код будет well-formed, но при этом Он не будет удовлетворять AАБИ.


S>Стандарт ИМХО для того и писан, чтобы абстрагироваться от платформы


Я смотрю, вы тут уже с Джаззером поговорили. В общем-то, все по делу. Если все происходит в пределах одного модуля, и не надо взаимодействовать ни с кем, кто потенциально может быть скомпилирован хотя бы с другими ключами компиляции, то Стандарта достаточно. В реальном мире ваше "Редко" приходится постоянно держать в голове при проектировании более или менее серьезного интерфейса.

Дядя Саттер тоже об этом пишет: http://www.cuj.com/documents/s=8188/cuj0412g/0412sutter.html (для прочтения необходимо иметь регистрацию на cuj.com. Вроде можно бесплатно на полгода зарегистрироваться.)
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
It's kind of fun to do the impossible (Walt Disney)
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.