САБЖ. Нужно для привязывания переменных и геттеров/сеттеров к их строковому эквиваленту времени исполнения.

Пример:

class A
{
  int member0;
  int member1;
  int member2;
  SOMETHING_COOL(member0)
  SOMETHING_COOL(member1)
  SOMETHING_COOL(member2)
};

Решение пока через класс с конструктором по умолчанию.

#define SOMETHING_COOL(...) \
struct UNIQ_NAME  \
{  \
    UNIQ_NAME() \
    { \
         тут делаем что нужно; \
    } \
} uniq_member_name;

Всё бы ничего, но на каждый пустой тип выделяется 1 байт. Штука активно используется для связывания статики и динамики в большом проекте с глубокой иерархией классов и на эти однобайтовые красивости куча памяти уходит. Нахожусь в поисках решения чтобы сильно не пришлось портить устоявшийся интерфейс.

П.С.
C++0x11 не доступен.

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

G>Всё бы ничего, но на каждый пустой тип выделяется 1 байт. Штука активно используется для связывания статики и динамики в большом проекте с глубокой иерархией классов и на эти однобайтовые красивости куча памяти уходит. Нахожусь в поисках решения чтобы сильно не пришлось портить устоявшийся интерфейс.
Так непонятно почему бы просто вызов SOMETHING_COOL не перенести в конструктор класса A? Или тебе всё же нужно и в деструкторе вспомогательного класса какие-то действия совершать? Ну тогда можно сделать чтобы один класс от другого наследовался. В идеале сделать класс A наследником такой иерархии — любой современный компилятор позаботится чтобы пустые базовые классы в этом случае никакой памяти не занимали.

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

G>САБЖ. Нужно для привязывания переменных и геттеров/сеттеров к их строковому эквиваленту времени исполнения.

G>

G>class A
//...
G>#define SOMETHING_COOL(...) \
G>struct UNIQ_NAME  \
G>{  \
G>    UNIQ_NAME() \
G>    { \
G>         тут делаем что нужно; \
G>    } \
G>} uniq_member_name; 
G>

А делать "что нужно" надо для каждого класса А или для каждого экземпляра каждого класса А?

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

G>САБЖ. Нужно для привязывания переменных и геттеров/сеттеров к их строковому эквиваленту времени исполнения.

Такой дизайн устроит?

class A
{
  int member0;
  int member1;
  int member2;

  SOMETHING_COOL_BEGIN(A)      // A() {
    SOMETHING_COOL(member0)    //   .....
    SOMETHING_COOL(member1)    //   .....
    SOMETHING_COOL(member2)    //   .....
  SOMETHING_COOL_END()         // }
};

Максимум, 1 байт на член-хелпер, а минимум — 0 байт на инлайн-определение функции (например, конструктора).

Это близко к тому к чему я склоняюсь. Правда придётся как-то так:

SOMETHING_COOL_SCOPE(      
    SOMETHING_COOL(member0),   
    SOMETHING_COOL(member1),   
    SOMETHING_COOL(member2)   
 )

Один SOMETHING_COOL не только код инициализации наращивает, но и одну-две функции-помощника создаёт в A.

В целом не плохо. Жаль, что похоже нет варианта вообще не менять интерфейс классов...

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


E>А делать "что нужно" надо для каждого класса А или для каждого экземпляра каждого класса А?

Для каждого класса А. В конструкторе UNIQ_NAME есть проверка было ли это действие уже произведено.

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

К>

К>class A
К>{
К>  int member0;
К>  int member1;
К>  int member2;

К>  SOMETHING_COOL_BEGIN(A)      // A() {
К>    SOMETHING_COOL(member0)    //   .....
К>    SOMETHING_COOL(member1)    //   .....
К>    SOMETHING_COOL(member2)    //   .....
К>  SOMETHING_COOL_END()         // }
К>};
К>

Ну и конечно конструктор класса нельзя занимать.

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

G>Для каждого класса А. В конструкторе UNIQ_NAME есть проверка было ли это действие уже произведено.

тогда можно пойти по такому пути:

template<void (*It)()> class CallItOnce {
    static struct Caller {
        Caller() { It(); }
    } callIt;
    const char dummy;
public:
    CallItOnce() : dummy( (char)&callIt ) {}  // хак, что бы гарантировать инстанциацию соответствующего шаблона.
};

template<void (*It)()> CallItOnce<It> CallItOnce<It>::callIt;

// пример:
class AZZ {
    static int count;
    // Это собственно то, что будет генериться внутри твоего макроса
    static void initializer() {
        CallItOnce<&initializer> callIt; // продолжение того же хака.
        count++;
    }
public:
    static int Get(){ return count; }
};

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

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

G>>Для каждого класса А. В конструкторе UNIQ_NAME есть проверка было ли это действие уже произведено.

E>тогда можно пойти по такому пути: ...

Отлично! Спасибо.

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

E>>тогда можно пойти по такому пути: ...

G>Отлично! Спасибо.

Не за что, обращайся.
p. s.
Для "спасибо" тут есть кнопки

Интересно почему этот приём не работает с шаблонными классами для каждой инстанциации. MSVC.

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

G>>Для каждого класса А. В конструкторе UNIQ_NAME есть проверка было ли это действие уже произведено.
E>тогда можно пойти по такому пути: [c]template<void (*It)()> class CallItOnce {
E> static struct Caller {
E> Caller() { It(); }
E> } callIt;
E> const char dummy;
E>public:
E> CallItOnce() : dummy( (char)&callIt ) {} // хак, что бы гарантировать инстанциацию соответствующего шаблона.
E>};
Использование статических мемберов — плохой тон. Можно ненароком шмальнуть себе по ноге из конструктора такого же статического объекта.

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

G>П.С.
G>C++0x11 не доступен.
что если С++17 не доступен, то уж 14 или 11-то доступны? так там NSDMI есть

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


V>Использование статических мемберов — плохой тон. Можно ненароком шмальнуть себе по ноге из конструктора такого же статического объекта.

Вообще инициализации где-то кроме глобальной функции инициализации -- дурной тон.
Но конкретно тут, как планируется шмалять?

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

V>>Использование статических мемберов — плохой тон. Можно ненароком шмальнуть себе по ноге из конструктора такого же статического объекта.
E>Вообще инициализации где-то кроме глобальной функции инициализации -- дурной тон.
E>Но конкретно тут, как планируется шмалять?
Как обычно делают? Обычно деляют либо инициализацию по вызову функции со статической переменной, либо, ещё лучше, явную инициализацию всего одним явным вызовом по принципу "либо всё, либо ничего", чтобы можно было перенести/пересортировать вызовы различных инициализаций в нужном месте. Такое если выстрелет, то сразу в голову без всяких прилюдий.

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

E>>Но конкретно тут, как планируется шмалять?
V>Как обычно делают? Обычно деляют либо инициализацию по вызову функции со статической переменной, либо, ещё лучше, явную инициализацию всего одним явным вызовом по принципу "либо всё, либо ничего", чтобы можно было перенести/пересортировать вызовы различных инициализаций в нужном месте. Такое если выстрелет, то сразу в голову без всяких прилюдий.

Про то, что явной функцией приложение инициализировать лучше, я не спорю.
Но это вопрос архитектуры приложения, а не тот, который задал ТС...

И таки да, как в данном конкретном случае планируется шмалять?..

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

E>И таки да, как в данном конкретном случае планируется шмалять?..
Я ж ответил — явной инициализацией.

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

E>>И таки да, как в данном конкретном случае планируется шмалять?..
V>Я ж ответил — явной инициализацией.

Имелось в виду "шмалять в ногу".

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

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

V>>>Использование статических мемберов — плохой тон. Можно ненароком шмальнуть себе по ноге из конструктора такого же статического объекта.
E>>Вообще инициализации где-то кроме глобальной функции инициализации -- дурной тон.
E>>Но конкретно тут, как планируется шмалять?
V>Как обычно делают? Обычно деляют либо инициализацию по вызову функции со статической переменной, либо, ещё лучше, явную инициализацию всего одним явным вызовом по принципу "либо всё, либо ничего", чтобы можно было перенести/пересортировать вызовы различных инициализаций в нужном месте. Такое если выстрелет, то сразу в голову без всяких прилюдий.

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

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

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

G>>П.С.
G>>C++0x11 не доступен.
A>что если С++17 не доступен, то уж 14 или 11-то доступны? так там NSDMI есть

За что минус влепил? Ещё и бред какой-то написав в ответ.
Мне недоступен современный цпп. Тебе очень интересно причина или к чему это написано?