boost::alignment_of не работает с абстрактными типами:

#include <stdio.h>
#include "boost/type_traits/alignment_of.hpp"

#ifdef __GNUC__
#define DECLARE_ALIGN(x) __attribute__(aligned((x)))
#else
#define DECLARE_ALIGN(x) __declspec(align(x))
#endif

struct DECLARE_ALIGN(32) A {
  virtual void foo() = 0;
  double a;
};

struct B : A {
  virtual void foo() {}
};

int main() {
  printf("%d\n",boost::alignment_of<A>::value); //error C2259: 'A' : cannot instantiate abstract class
  printf("%d\n",boost::alignment_of<B>::value);

  return 0;
}

Это можно исправить вот так:

#include <stdio.h>
#include "boost/type_traits/alignment_of.hpp"
#include "boost/type_traits/is_abstract.hpp"

#ifdef __GNUC__
#define DECLARE_ALIGN(x) __attribute__(aligned((x)))
#else
#define DECLARE_ALIGN(x) __declspec(align(x))
#endif

struct DECLARE_ALIGN(32) A {
  virtual void foo() = 0;
  double a;
};

struct B : A {
  virtual void foo() {}
};

template<class T>
struct declared_alignment_of {
  template<bool F_,class T_> struct is_abstract {
    static T_& t;
    enum { value = __alignof(t) };
  };
  template<class T_> struct is_abstract<false,T_> {
    enum { value = boost::alignment_of<T_>::value };
  };

  enum { value = is_abstract<boost::is_abstract<T>::value,T>::value };
};

int main() {
  printf("%d\n",declared_alignment_of<A>::value); //OK
  printf("%d\n",declared_alignment_of<B>::value);

  return 0;
}

Компиляторы: msvc80,gcc4.1.2,comeau4.3.9b

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

V>Компиляторы: msvc80,gcc4.1.2,comeau4.3.9b

А зачем так сложно?
Почему просто ссылку на тип-параметр не объявлять? А для ссылок сделать частичную специализацию...

Правда лично мне не ясна цель выяснение смещения абстрактного типа...

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

E>А зачем так сложно?
E>Почему просто ссылку на тип-параметр не объявлять? А для ссылок сделать частичную специализацию...
Это как?

E>Правда лично мне не ясна цель выяснение смещения абстрактного типа...
Выравнивание и абстрактность типа это ортогональные вещи. На забывай что alignment как и sizeof — "наследуем".

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

E>>Правда лично мне не ясна цель выяснение смещения абстрактного типа...
V>Выравнивание и абстрактность типа это ортогональные вещи. На забывай что alignment как и sizeof — "наследуем".

Ну и что? Нужда-то какая?

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

E>>>Правда лично мне не ясна цель выяснение смещения абстрактного типа...
V>>Выравнивание и абстрактность типа это ортогональные вещи. На забывай что alignment как и sizeof — "наследуем".
E>Ну и что? Нужда-то какая?
Мне в одном месте пригодилось. Проще было написать это, чем проверять тип на абстрактность и убирать код делающий alignment_of.

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

V>Мне в одном месте пригодилось. Проще было написать это, чем проверять тип на абстрактность и убирать код делающий alignment_of.

Странно это как-то. Казалось бы зачем тебе выравнивание, если ты не собираешься размещать объекты в памяти? А если таки собираешься, то как ты собираешься это делать с объектами абстрактного класса?

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

V>>Мне в одном месте пригодилось. Проще было написать это, чем проверять тип на абстрактность и убирать код делающий alignment_of.
E>Странно это как-то. Казалось бы зачем тебе выравнивание, если ты не собираешься размещать объекты в памяти? А если таки собираешься, то как ты собираешься это делать с объектами абстрактного класса?
Выравнивание просто читается с типа, а абстрактный он или неабстрактный, мне не интересно. Если он абстрактный, то и код не будет заюзан, но вот ошибку непользованный код будет генерить, чего не хотелось...

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

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

А зачем?
Казалось бы выравнивание -- это значит какой-то контейнер. А зачем контейнер абстрактных объектов?

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

V>>Выравнивание просто читается с типа, а абстрактный он или неабстрактный, мне не интересно. Если он абстрактный, то и код не будет заюзан, но вот ошибку непользованный код будет генерить, чего не хотелось...
E>А зачем?
E>Казалось бы выравнивание -- это значит какой-то контейнер. А зачем контейнер абстрактных объектов?
Уф, ну есть шаблонный класс, который выравнивание проверяет:

template<class T>
struct BlaBla {
  void foo() { ... alignment_of<T>::value ... }
};

Нихочу я писать всякие лишние конструкции, на проверку T и т.д. Проще alignment_of подменить.

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

V>Уф, ну есть шаблонный класс, который выравнивание проверяет:
V>Нихочу я писать всякие лишние конструкции, на проверку T и т.д. Проще alignment_of подменить.

А всё равно не понятно. Зачем он его проверяет?
Ну типа, например, читаем файл какой, проверяем что нет проблем из-за выравнивая. Но всё равно выравниваени абстрактного объекта как бы смысла не имеет.

Я к тому, что вроде в C++ нету никакого смысла физического в выравнивании абстрактного типа. Оно ни на что не влияет в С++ программе. Соответственно не понятно на кой его проверять...

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

V>>Уф, ну есть шаблонный класс, который выравнивание проверяет:
V>>Нихочу я писать всякие лишние конструкции, на проверку T и т.д. Проще alignment_of подменить.
E>А всё равно не понятно. Зачем он его проверяет?
E>Ну типа, например, читаем файл какой, проверяем что нет проблем из-за выравнивая. Но всё равно выравниваени абстрактного объекта как бы смысла не имеет.
Я же говорю, что я не пытаюсь выравнивать абстрактный тип, просто T может быть абстрактным но при этом не хочу чтобы брасались ошибки в коде, который и не используется и не выкинуть его, т.к. он висит в шаблоне и проверяет выравнивание у типа.

E>Я к тому, что вроде в C++ нету никакого смысла физического в выравнивании абстрактного типа. Оно ни на что не влияет в С++ программе. Соответственно не понятно на кой его проверять...
Выравнивание наследуется, ты можешь смешать интерфейс и выравнивание, чтобы в каждом производном классе не писать каждый раз одно и тоже выравнивание.

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

V>Выравнивание наследуется, ты можешь смешать интерфейс и выравнивание, чтобы в каждом производном классе не писать каждый раз одно и тоже выравнивание.

А зачем искусственно увеличивать выравнивание чего-нибудь?

Опять же, если речь идёт о интерфейсах, то значит ты уже выравниваешься на 4.
То есть ты хочешь наследовать выравнивание на 8 или даже на 16. На кой такая экзотика нужна?

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

V>>Выравнивание наследуется, ты можешь смешать интерфейс и выравнивание, чтобы в каждом производном классе не писать каждый раз одно и тоже выравнивание.
E>А зачем искусственно увеличивать выравнивание чего-нибудь?
Кеш линия? Ещё мож для чего, не суть.

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

E>Опять же, если речь идёт о интерфейсах, то значит ты уже выравниваешься на 4.
E>То есть ты хочешь наследовать выравнивание на 8 или даже на 16. На кой такая экзотика нужна?
Ну... На всяких 64-битных PPC и ia64 неправильно выравненный указатель вызовет большой БУМ! А неправильно выровненный SSE-вектор вызовет такой же БУМ! и на x86.

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

C>Ну... На всяких 64-битных PPC и ia64 неправильно выравненный указатель вызовет большой БУМ! А неправильно выровненный SSE-вектор вызовет такой же БУМ! и на x86.

А выравнивая встроенного типа не хватит?
Зато наследовать от чего-то левого конечно дико повышает производительность...