McSeem2 wrote:

> Хорошо, раскрываю карты. Дело даже не в производительности. Как мне
> при поможи std::copy() корректно "вытащить" данные из памяти,
> находящиеся по невыровненному адресу? По-моему никак.

Данный конкретный случай в std::copy как раз работать будет.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

C>//Fast memmove-backed mover
C>template<class T> struct memmove_traits
C>{
C>    enum{bitwise_moveable=1};

C>    static void destroy_range(T* _first, T* _last)
C>    {
C>        for (T* f=_first; f!=_last; f++)
            f->~T();
C>    }
C>    . . .

C>В этом коде можно многое улучшить, но идея должна быть понятна.

Идея понятна, спасибо. Но чисто в качестве придирки — это уже полное безобразие (я не хочу наглеть до такой степени): Если объект является bitwise_moveable, то он по определению не может иметь нетривиальный деструктор (который что-то там реально уничтожает). Если же деструктор действительно что-то делает, сразу ставим жирный крест на побитовом копировании. Такое ограничение представляется мне вполне разумным, ибо опасно.

Здравствуйте, Анатолий Широков, Вы писали:

АШ>struct point
АШ>{
АШ>   int x, y;
АШ>};

АШ>...
АШ>point pt = {0, 0};
АШ>

АШ>И наглядно и эффективно.

Хочу конструктор! Ыыыыыыаааааа!!! (размазывая слезы и сопли)

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

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

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

C>Данный конкретный случай в std::copy как раз работать будет.

        // TEMPLATE FUNCTION copy
template<class _II, class _OI> inline
    _OI copy(_II _F, _II _L, _OI _X)
    {for (; _F != _L; ++_X, ++_F)
        *_X = *_F;
    return (_X); }

Как? Здесь будет мгновенная автобусная ошибка. Можно, конечно написать специализации для всех типов объектов, но это опять же много лишней работы.

MS>Хочу конструктор! Ыыыыыыаааааа!!! (размазывая слезы и сопли)

Если хочется именно конструирование, то отдай его на откуп врапперам. Например:

...
template<typename T, typename P1, typename P2>
T pod_initializer(P1 p1, P2 p2)
{
     T tmp = {p1, p2};
     return tmp; 
}

struct point 
{
    int x, y;
};

class cpoint
{
    point pt;
public:
    cpoint(int x, int y) : pt(pod_initializer<point>(x, y))
    {
    }
    operator point& ()
    {
        return pt;
    }
    operator point const & () const
    {
        return pt;
    }
    point* operator &()
    {
        return &pt;
    }
    point const * operator &() const
    {
        return &pt;
    }
};

void foo(point const &pt)
{
    std::cout << pt.x << ", " << pt.y << std::endl;
}

void foo(point const *ptr)
{
    std::cout << ptr->x << ", " << ptr->y << std::endl;
}

int main()
{
    std::cout << sizeof(point) << sizeof(cpoint);
    cpoint pt1(100, 200);
    cpoint pt2(300, 200);
    foo(&pt1);
    foo(&pt2);
}

McSeem2 wrote:

> C>В этом коде можно многое улучшить, но идея должна быть понятна.
> Идея понятна, спасибо. Но чисто в качестве придирки — это уже полное
> безобразие (я не хочу наглеть до такой степени): Если объект является
> bitwise_moveable, то он по определению не может иметь нетривиальный
> деструктор (который что-то там реально уничтожает).

Не обязательно, у меня используются бит-копируемые объекты, в которых в
деструкторе делаются assert'ы и некоторые другие проверки. Так что пусть
живет.

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

У меня по умолчанию побитовое копирование будет работать только для
простых типов. Для более сложных нужно ставить флажок
ENABLE_BITWISE_MOVEABLE — если его явно поставить, то уж сам виноват....

--
С уважением,
Alex Besogonov (alexy@izh.com)

McSeem2 wrote:

> C>Данный конкретный случай в std::copy как раз работать будет.
>
> // TEMPLATE FUNCTION copy
>template<class _II, class _OI> inline
> _OI copy(_II _F, _II _L, _OI _X)
> {for (; _F != _L; ++_X, ++_F)
> *_X = *_F;
> return (_X); }
>
> Как? Здесь будет мгновенная автобусная ошибка.

Компилятор обнаружит, что размер структуры не позволяет срабатывать
выравниванию, и сгенерирует byte-by-byte копирование. А байты везде
читаются без выравнивания.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

C>Компилятор обнаружит, что размер структуры не позволяет срабатывать
C>выравниванию, и сгенерирует byte-by-byte копирование. А байты везде
C>читаются без выравнивания.

Не верю!

    struct point { int x,y; };
    char array[100];
    point p[4];
    std::copy((point*)(array+1), (point*)(array+1+sizeof(p)), p);

И что, на SGI не возникнет автобусной ошибки? Я ведь проверю! И очень скоро проверю!

#include <algorithm>

struct point { int x,y; };

void main()
{
    char array[100];
    point p[4];
    std::copy((point*)(array+1), (point*)(array+1+sizeof(p)), p);
}

rndusexwally:~>CC buserror.cpp
cc-3563 CC: WARNING File = buserror.cpp, Line = 5
  return type of function "main" must be "int"

  void main()
       ^

rndusexwally:~>./a.out
Bus error (core dumped)
rndusexwally:~>

Как и ожидалось... Интересно, откуда компилятор может заранее знать, что указатель не выровнен? Это возможно только в run-time, что есть накладно весьма.

а что такое:

MS>Как? Здесь будет мгновенная автобусная ошибка.

?

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


dad>а что такое:
MS>>Как? Здесь будет мгновенная автобусная ошибка.

Bus Error (core dumped). Обращение по невыровненному адресу, например:

char a[5] = {0}; 
int i = *(int*)(a + 1);

Такая операция в общем случае является криминалом. Но на Intel — работает.

dad>>а что такое:
MS>>>Как? Здесь будет мгновенная автобусная ошибка.

MS>Bus Error (core dumped). Обращение по невыровненному адресу, например:
MS>

MS>char a[5] = {0}; 
MS>int i = *(int*)(a + 1);
MS>

MS>Такая операция в общем случае является криминалом. Но на Intel — работает.

"автобусная" ошибка регламентируется стандартом?
Внешне криминала не видно, получаешь 4 байта [1-4]

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

dad>"автобусная" ошибка регламентируется стандартом?
dad>Внешне криминала не видно, получаешь 4 байта [1-4]

Это регламентируется не стандартом C++, а архитектурой процессоров. Если процессор не позволяет так копировать, а некий (абстрактный) язык позволяет, то bus error в run-time будет в любом языке. А стандарт не имеет права запрещать подобный криминал (да и не может по жизни). То есть, это все — на совести программиста.

dad>>"автобусная" ошибка регламентируется стандартом?
dad>>Внешне криминала не видно, получаешь 4 байта [1-4]

MS>Это регламентируется не стандартом C++, а архитектурой процессоров. Если процессор не позволяет так копировать, а некий (абстрактный) язык позволяет, то bus error в run-time будет в любом языке. А стандарт не имеет права запрещать подобный криминал (да и не может по жизни). То есть, это все — на совести программиста.

А на какой платформе такое у тебя? С чем это связано чисто технически.

dad,

MS>> Bus Error (core dumped). Обращение по невыровненному адресу, например:
MS>>

 MS>> char a[5] = {0};
 MS>> int i = *(int*)(a + 1);
 MS>>

MS>> Такая операция в общем случае является криминалом. Но на Intel -
MS>> работает.

d> "автобусная" ошибка регламентируется стандартом?

Да. Ищи alignment requirements.

d> Внешне криминала не видно, получаешь 4 байта [1-4]

Данные не выравнены надлежащим для этого типа образом.

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

dad>А на какой платформе такое у тебя? С чем это связано чисто технически.

На SGI, на Sun Ultra Sparc, на HP, на DEC Alpha и многих других. Ну не культурно это обращаться к памяти как к int, если адрес не выровнен на int. На Intel, кстати тоже. Это хоть и работает технически, но значительно медленнее, чем в случае выровненных данных. Именно поэтому в структурах появляюся "дыры" от выравнивания. И sizeof(struct) != sum(sizeof(data_members)) в общем случае.

McSeem2 wrote:

> На SGI, на Sun Ultra Sparc, на HP, на DEC Alpha и многих других. Ну не культурно это обращаться к памяти как к int, если адрес не выровнен на int. На Intel, кстати тоже. Это хоть и работает технически, но значительно медленнее, чем в случае выровненных данных.

Я читал, что когда данные в кэш линейке, выранивание на скорость доступа на ia32 не оказывает никакого влияния. Сам не проверял.

> Именно поэтому в структурах появляюся "дыры" от выравнивания. И sizeof(struct) != sum(sizeof(data_members)) в общем случае.

В-общем случае размер структуры кратен ее выравниванию. Это связано с тем, что в массивах между элементами не может быть "дыр", поэтому если размер структуры не был бы кратен выравниванию, массив из этих структур создать не было бы возможно.

--
Maxim Yegorushkin

Я и сложные типы типа std::vector, std::string двигаю по памяти при помощи memcpy... а это совсем не POD-типы. Говорят, возможно в будущем С++ стандарте будет какая-то специальная move-семантика. Но зачем усложнять язык, если это и сейчас возможно при помощи memcpy.

McSeem2 wrote:

> Не верю!
>
> struct point { int x,y; };
> char array[100];
> point p[4];
> std::copy((point*)(array+1), (point*)(array+1+sizeof(p)), p);
>
> И что, на SGI не возникнет автобусной ошибки? Я ведь проверю! И очень
> скоро проверю!

Так вот будет:

    struct point { int x,y; };
    char *array=(char*)malloc(100)
    point p[4];
    std::copy(&p[0], &p[0]+4, array);

--
С уважением,
Alex Besogonov (alexy@izh.com)