есть задача обращаться к полям класса по их имени, т.е. зная строку. Это строка, приходит, парсится потом собственно идет само обращение.
Каждое поля класса это класс, интерфейс которого нам известен.
Придумал вот такую функцию, которую вызываю из констактора и заполняю мап со смещениями для всех полей:
bool ORMtableBase::FillFiledsMap(FieldsList& fields, const ORMtableBase* _this)
{
size_t Finish = _this->GetSize(); // size of main class
size_t Start = _this->GetFirstField(); // offset to first field
while(Start < Finish)
{
const IORMField* pField =
static_cast<const IORMField*> // common interface for each field
(
static_cast<const void*>
(
(
static_cast<const char*>
(
static_cast<const void*>(_this)
) + Start
)
)
);
fields.insert(std::pair<std::string, FieldInfo>(pField->GetName(), FieldInfo(pField->GetType(), Start))); // sometimes it crashes here
Start += pField->GetSize(); // sizeof(ClassFieldName)
}
return !fields.empty();
}
и все замечательно работает на 32-х машинах, но на 64-х битных возникает крэш, ровно для одного из типов, который возвращает размер 42, а реально смещение до следующего поля 46. Выравниваение во всех проектах стоит 8 байт. Это похоже на проблему выравнивания и можно было ббы написать функцию, которая бы подравнивала такие значения, вот только будет ли это гарантированно правильно во всех компиляторах?
P.S. Все эти извращения потому, что в месте использования нет информации о конечном типе, а есть только интерфейс.
Здравствуйте, dilmah, Вы писали:
D>я не понимаю, ты хочешь сказать что offsetof неправильно работает?
он работает правильно, но я не могу его использовать для всех членов класса. Могу только для первого.
Я же хотел сказать что offsetof != sizeof() для некоторых полей, sizeof() == 42, а оffsetof 46 из-за выравнивания.
S>это работает, но как-то это не по-казачьи. Может кто-то предложет что-то получше?
1. 'offsetof' корректно(гарантированно) работает для POD
2. почему не использовать указатели(враперы для указателей) на члены класса для обращения к таковым?
т.к. Ваша реализация(вычисления) вероятно сильно будет зависить от реализации/настроек компилятора,
и/или не учитывает #pragma pack's, а у Вас не видно использований 'alignof'(MSVC '__alignof'). И т.п.
Если считать( ) то более корректно с учетом ниже сказанного.
2.a) заменить "8" на что-то типо:
struct someStruct {};
int opt=alignof(someStruct); // get compiler option 'alignment'
2.b) учесть выравнивание самого класса(влияние #pragma pack's)
3.
Здравствуйте, szag, Вы писали:
S>P.S. Все эти извращения потому, что в месте использования нет информации о конечном типе, а есть только интерфейс.
Странная какая-то затея. Чем тебе offsetof() не нравится? Собственно, никто никому не обещает, что сумма размеров членов даст в результате правильное смещение следующего члена. Тут ещё куча вопросов по ходу дела, например, зачем обращаться по смещению (!), одновременно скрывая информацию о классе? Чтоб спрашивали, что ли? Давай, ты лучше про саму задачу расскажешь.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, szag, Вы писали:
S>это работает, но как-то это не по-казачьи. Может кто-то предложет что-то получше?
Не надо так делать, ты вносишь дополнительные зависимости, которые очень сложно отлавливать. Расскажи про саму задачу. Почти наверняка есть какой-то удобоваримый способ решения, без колдунства.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, szag, Вы писали:
[skipped]
S>P.S. Все эти извращения потому, что в месте использования нет информации о конечном типе, а есть только интерфейс.
Я думаю, — решение можно представить в виде регистратора(статического) объектов(рожденных от class Object)
Примерно так:
//------------------------------------------------------------------------------
class Object {
public:
Object();
virtual ~Object() = 0;
string getName();
static Object* findObjectByName(const string &name);
/*
* Здесь Ваш "известный" интерфейс, вероятно virtual some_result_type1(-N) some_fun1(-N)(arg_list1-(-N)) = 0;
*/
protected:
typedef map<string, Object*> c_objReg;
typedef c_objReg::iterator c_objRegI;
// регистр объектов
static c_objReg objReg;
// имя
string name;
// запрос на регистрацию объекта с конкретным именем
bool registerName(const string &in_name);
};
//------------------------------------------------------------------------------
Object::c_objReg Object::objReg=Object::c_objReg();
//------------------------------------------------------------------------------
Object::Object() {}
//------------------------------------------------------------------------------
Object::~Object() {}
//------------------------------------------------------------------------------
string Object::getName() {
return name; // или typeid(*this).name()
}
//------------------------------------------------------------------------------
Object* Object::findObjectByName(const string &name) {
return objReg[name];
}
//------------------------------------------------------------------------------
bool Object::registerName(const string &in_name) {
if (in_name.size() && objReg.insert(make_pair(in_name, this)).second)
name=in_name;
return true;
}
Соответственно в конструкторах производных классов сделать registerName(typeid(*this).name()); или произвольное(удобное) имя
class foo1: public Object {
public:
foo1() { registerName("Object_foo1"); }
};
class foo2: public Object {
public:
foo2() { registerName("Object_foo2"); }
};
Найти его: Object::findByName(<desired_object_name>);
Здравствуйте, Seigram, Вы писали:
S>Я думаю, — решение можно представить в виде регистратора(статического) объектов(рожденных от class Object)
я думал о чем-то подобном, однако такой подход имеет ряд недостатков и накладывает определенные обязанности на пользователя библиотеки, чего не хотелось бы.
Библиотека представляет из себя либу + хидер. На вход получает класс унаследованный от определенного, заранее известного интерфейса, либа заправшивает данные и они приходят в виде xml. потом она заполняет поля класса значениями и возвращает true. Все возможные типы полей заранее известны, точнее известны типы данных хранящихся там. Сами поля представляют из себя сборку класса из нескольких темплейтов, в зависимости от того что ввел пользователь библиотеки, так как поля содержат всякую информацию, к примеру для строк максимальную длинну. таких полей в классе может быть от нескольких штук до нескольких десятков и ничего с этим не поделаешь, если так пожелает пользователь. Поэтому не хотелось бы делать вариант с регистрацией и заставлять пользователя регистрировать все имена полей. По условиям задачи в классе не может быть лишних, системных, не нужных и прочих полей — все именно поля необходимые для заполнения, поэтому не хотелось бы давать лишнюю гибкость пользователю.
Сейчас это сделано с помощью макроса, который собирает класс из темплейтов и создает поле, а пользователю достаточно написать:
FIELD(MyName, 50, INITVALUE("Ivan"))
Соответственно создастся поле, с максимальной длинной 50 и по умолчанию будет инициализировано как "Ivan". Вещей, подобных INITVALUE, может быть несколько (есть обязательные и не обязательные), все примеры приводить не буду, но думаю общий смысл понятен. Сейчас все эти вещи проверяются на этапе компиляции и удобны для пользователя библиотеки.
Здравствуйте, szag, Вы писали:
S>Здравствуйте, Seigram, Вы писали:
S>>Я думаю, — решение можно представить в виде регистратора(статического) объектов(рожденных от class Object)
S>я думал о чем-то подобном, однако такой подход имеет ряд недостатков и накладывает определенные обязанности на пользователя библиотеки, чего не хотелось бы. S>Библиотека представляет из себя либу + хидер. На вход получает класс унаследованный от определенного, заранее известного интерфейса, либа заправшивает данные и они приходят в виде xml. потом она заполняет поля класса значениями и возвращает true. Все возможные типы полей заранее известны, точнее известны типы данных хранящихся там. Сами поля представляют из себя сборку класса из нескольких темплейтов, в зависимости от того что ввел пользователь библиотеки, так как поля содержат всякую информацию, к примеру для строк максимальную длинну. таких полей в классе может быть от нескольких штук до нескольких десятков и ничего с этим не поделаешь, если так пожелает пользователь. Поэтому не хотелось бы делать вариант с регистрацией и заставлять пользователя регистрировать все имена полей. По условиям задачи в классе не может быть лишних, системных, не нужных и прочих полей — все именно поля необходимые для заполнения, поэтому не хотелось бы давать лишнюю гибкость пользователю. S>Сейчас это сделано с помощью макроса, который собирает класс из темплейтов и создает поле, а пользователю достаточно написать: S>
S>FIELD(MyName, 50, INITVALUE("Ivan"))
S>
S>Соответственно создастся поле, с максимальной длинной 50 и по умолчанию будет инициализировано как "Ivan". Вещей, подобных INITVALUE, может быть несколько (есть обязательные и не обязательные), все примеры приводить не буду, но думаю общий смысл понятен. Сейчас все эти вещи проверяются на этапе компиляции и удобны для пользователя библиотеки.
Чесно? -Объяснение не понятное. И что такое "сборку класса из нескольких темплейтов" — агрегация или наследование используется?
Далее, про вышесказанное "колдунство" с формулами, — при данных условиях(вернее ограничениях), по видимому без него не обойтись, но необходимо знать как компилятор размещает в памяти члены класса. И 1-е на чем ты накололся это выравнивания членов класса, т.е.
как правило(если члены не char's все) то sum[sizeof(member[i]] != sizeof(структура их содержащая).
Потому что(цитирую): "структура выравнивается на максимальное выравнивание среди полей. Каждое поле выравнивается на выравнивание типа поля".
И если ты хочешь правильного колдунства, то должен это учесть; как я уже сказал ответами выше есть оператор alignof()/__alignof() который это разрешает узнавать, и — offsetof корректен только для POD типов.
В каком то смысле ты должен имитировать функцию компилятора отвечающую за вычесление размещения.
Просто интересно, а зачем выравнивание если вокруг него(именно в данной ситуации) возникает столько проблем. Можно охватить все pack(push,1)|pack(pop) тогда очевидно даже 1-й код приведенный автором "сойдется".
Здравствуйте, Seigram, Вы писали:
S> Чесно? -Объяснение не понятное. И что такое "сборку класса из нескольких темплейтов" — агрегация или наследование используется?
Используется и агрегация и наследование (но это не важно), в конечном коде это будет выглядеть так (привожу упрощенный пример):
class MyClass : public iClassBase
{
public:
int i1, i2, i3; // 3 поля гарантированные для этого класса
std::size_t GetFirstField() const
{
return offsetof(MyClass, i3) + sizeof(int);
}
std::size_t GetSize() const
{
return sizeof(MyClass);
}
// ниже идут поля классаclass MyField : public MyFieldBase
{
public:
MyField() {/*здесь будет код*/}
std::size_t GetSize() const
{
return sizeof(MyField) + MyAlign<MyField>::Result;
}
};
MyField Fild1Name;
/* и так далее для каждого поля */
};
S>Далее, про вышесказанное "колдунство" с формулами, — при данных условиях(вернее ограничениях), по видимому без него не обойтись, но необходимо знать как компилятор размещает в памяти члены класса. И 1-е на чем ты накололся это выравнивания членов класса, т.е. S>как правило(если члены не char's все) то sum[sizeof(member[i]] != sizeof(структура их содержащая).
Я с этим согласен, поэтому и спросил совета — как лучше сделать.
S>Потому что(цитирую): "структура выравнивается на максимальное выравнивание среди полей. Каждое поле выравнивается на выравнивание типа поля". S>И если ты хочешь правильного колдунства, то должен это учесть; как я уже сказал ответами выше есть оператор alignof()/__alignof() который это разрешает узнавать, и — offsetof корректен только для POD типов. S>В каком то смысле ты должен имитировать функцию компилятора отвечающую за вычесление размещения.
Да, вы правы насчет POD типов, но, к сожалению, у меня они не POD и с этим сложно что-либо поделать. Мне необходимо чтобы этот код можно было использовать под виндами 32/64 бит и *nix 32/64. Поэтому необходима совместимость с гсс. И конечно хотелось бы чтобы была гарантия со стороны стандарта.
Здравствуйте, Тролль зеленый и толстый, Вы писали:
ТЗИ>Используй указатели на члены класса, а не трюки с offset'ов. У меня в одном проекте подобная задача — это, фактически, рефлексия для C++.
я бы рад, но, к сожалению, это невозможно в моей задаче.
Здравствуйте, szag, Вы писали:
S>Пока придумал вот такую конструкцию и проверил на всех смещениях от 1 до 16 — работает. S>Может кто-то покритикует или предложет что-то получше?
Здравствуйте, Seigram, Вы писали:
S>Ты на каких компиляторах пробовал самый 1-й вариант, — без workarounds?
проверял в VS2010, для чистоты эксперимента надо бы еще проверить в gcc. __alignof(), насколько я понимаю, Microsoft specific оператор, т.е. гцц про него ничего не знает, так? Если так то этот вариант не подходит.
Здравствуйте, szag, Вы писали:
S>Здравствуйте, Seigram, Вы писали:
S>>Ты на каких компиляторах пробовал самый 1-й вариант, — без workarounds?
S>проверял в VS2010, для чистоты эксперимента надо бы еще проверить в gcc. __alignof(), насколько я понимаю, Microsoft specific оператор, т.е. гцц про него ничего не знает, так? Если так то этот вариант не подходит.
Верно, верно. Выравние это прямо — тема. Вот ссылка к примеру:
см. последние 2 абзаца. т.е. все сильно зависит от компилятора(padding спереду или сзаду), вообще как на ум компилятору взбредет. Потом все перестает работатть при #pragma pack(push,N) — формулы не справились и т.д.
И поэтому, для БЕЗОПАСНОСТИ кода надо отказаться от твоей затеи. Перейти к указателям на члены. Можно сколько угодно колдовать с offsetof() но тебе придется написать кучу define's чтобы обеспечить приемственность. Опять же никто не гарантирует "подставы".
Лучьше обработай шефа на тему "безопасность и красота" требует жертв, и перепиши lib'ку. Дальше ведь работать и расширять её проще будет. Капитан Очевидность подсказывает — что делать софт гибче, удобнее и надежнее надо не каменным топором, а современными инструментами.
Здравствуйте, Seigram, Вы писали:
S> Верно, верно. Выравние это прямо — тема. Вот ссылка к примеру: S>см. последние 2 абзаца. т.е. все сильно зависит от компилятора(padding спереду или сзаду), вообще как на ум компилятору взбредет. Потом все перестает работатть при #pragma pack(push,N) — формулы не справились и т.д.
вероятность использования подобных конструкций конкретно в моей ситуации крайне мала.
S> И поэтому, для БЕЗОПАСНОСТИ кода надо отказаться от твоей затеи. Перейти к указателям на члены. Можно сколько угодно колдовать с offsetof() но тебе придется написать кучу define's чтобы обеспечить приемственность. Опять же никто не гарантирует "подставы". S> Лучьше обработай шефа на тему "безопасность и красота" требует жертв, и перепиши lib'ку. Дальше ведь работать и расширять её проще будет. Капитан Очевидность подсказывает — что делать софт гибче, удобнее и надежнее надо не каменным топором, а современными инструментами.
Вы все правильно говорите и даже переписать либу не проблема — проблема чтобы не пострадал клиентский код. А как переписать либу, чтобы сделать её гарантированно безопасной и при этом не пострадал клиентский код я не знаю.
К примеру, при текущей реализации я даже не могу обратиться из конструктора класса к одному из его мемберов, так как в конструкторе просто нет такой информации — она генерируется во время компиляции.
Вот упрощенный пример пользовательского кода:
и такого кода тьма тьмущая. Для каждого поля, в приведенном выше примере, генерируется куча кода, реально создается класс, который наследуется от базового, который шаблонный с кучей специализаций... Если подытожить, то я с вами согласен на 100%, но что делать в данной конкретной ситуации?
S>>Может кто-то покритикует или предложет что-то получше?
MS>Что будет если есть подряд 4 или 8 элементов по 1 байту?
Не будет. Как я писал выше, все поля гарантированно известных типом и не могут быть меньше нескольких десятков байт — это классы с виртуальными функциями и мемберами.
MS>>Что будет если есть подряд 4 или 8 элементов по 1 байту? S>Не будет. Как я писал выше, все поля гарантированно известных типом и не могут быть меньше нескольких десятков байт — это классы с виртуальными функциями и мемберами.
Как тогда трактовать предложение
Пока придумал вот такую конструкцию и проверил на всех смещениях от 1 до 16 — работает.
Здравствуйте, MShura, Вы писали:
MS>>>Что будет если есть подряд 4 или 8 элементов по 1 байту? S>>Не будет. Как я писал выше, все поля гарантированно известных типом и не могут быть меньше нескольких десятков байт — это классы с виртуальными функциями и мемберами.
MS>Как тогда трактовать предложение
MS>
MS>Пока придумал вот такую конструкцию и проверил на всех смещениях от 1 до 16 — работает.
MS>Как Вы проверили смещение 1 байт?
проверял 2 вещи:
struct CurrentAligment
{
enum
{
Value = offsetof(iAligment, f) - offsetof(iAligment, e) // это значение
};
};
и работоспособность проекта при выставленном смещении в настройках проекта.
Здравствуйте, szag, Вы писали:
S>Вы все правильно говорите и даже переписать либу не проблема — проблема чтобы не пострадал клиентский код. А как переписать либу, чтобы сделать её гарантированно безопасной и при этом не пострадал клиентский код я не знаю. S>К примеру, при текущей реализации я даже не могу обратиться из конструктора класса к одному из его мемберов, так как в конструкторе просто нет такой информации — она генерируется во время компиляции. S>Вот упрощенный пример пользовательского кода: S>
К>Правильно? К>Тогда кто мешает в список полей добавить не только их размеры, но и смещения (а ещё лучше — указатели-на-члены)? К>Будет там что-то вида К>
1. слишком много изменений в клиентском коде;
2. клиентский код станет писать сложнее, появится много зависимостей, как то, за был прописать поле в табличку или еще чего.
макросы эти были придуманы для того, чтобы сделать жизнь енд юзера проще, хорошо или плохо это было сделано вопрос другой, но сейчас клиентский код менять никто не даст, к тому же, он работает уже более 3-х лет, т.е. отлажен... и работает в разных организациях, которые не обрадуются такому апдейту сервера, при котором надо переписывать код...
Здравствуйте, szag, Вы писали:
S>1. слишком много изменений в клиентском коде; S>2. клиентский код станет писать сложнее, появится много зависимостей, как то, за был прописать поле в табличку или еще чего.
S>макросы эти были придуманы для того, чтобы сделать жизнь енд юзера проще, хорошо или плохо это было сделано вопрос другой, но сейчас клиентский код менять никто не даст, к тому же, он работает уже более 3-х лет, т.е. отлажен... и работает в разных организациях, которые не обрадуются такому апдейту сервера, при котором надо переписывать код...
Почему изменения в клиентском коде? Я спрашивал
1) макрос разворачивается в подобный код?
2) что мешает изменить макрос, чтобы он генерировал таблицу не только с размерами, но и смещениями?
Или же клиентский код уже скомпилирован, и его нельзя трогать?
То есть, — всё, что у нас есть, это таблица с отдельными полями. И по этой таблице надо восстановить лэяут структуры.
Тогда нужно для каждого поля знать не только его размер, но и его выравнивание. Это, по счастью, — свойство типа, а не свойство отдельного члена.
Логика более-менее простая:
int roundUp(int size, int align) { return (size+align-1)%align; }
int overall_tail = sizeof(Base); // текущий хвост структурыint overall_align = _alignof(Base); // выравнивание структурыint overall_size = min(1, roundUp(overall_tail, overall_align); // размер структуры
.....
// для каждого очередного поляint field_size, field_align; // размер и выравнивание текущего поля
assert(field_align > 0);
assert(field_size % field_align == 0);
int field_offset = roundUp(overall_tail, field_align);
overall_align = max(overall_align, field_align);
overall_tail = field_offset + field_size;
overall_size = roundUp(overall_tail, overall_align);
Всё, что надо — это добавить в интерфейс рядом с GetSize() ещё и GetAlign().
Но, всё же, с таблицей смещений будет проще и надёжнее.
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, szag, Вы писали:
[skipped] К>Но, всё же, с таблицей смещений будет проще и надёжнее.
Я бы иначе написал это и думаю угодил бы запросу szag.
Собственно сообразить как компилятор и что размещает не сложно зная типы полей
Примерно так, -для простоты у меня шаблон, а у szag можно сделать табличку для замены sizeof(std::remove_all_extents<T>::type):
template <class T> int next_offset(int &offset, int &total_size) {
int x = offset;
size_t size = sizeof(T), mask = sizeof(std::remove_all_extents<T>::type) - 1,
trusted_offset = offset;
if (offset & mask) {
trusted_offset = offset = (offset + mask) & ~mask;
}
offset += size; total_size += offset - x;
return trusted_offset;
}
финальный размер тоже подровнять
total_size = (total_size + (compiler_opt_align -1)) &~(compiler_opt_align -1)
естественно в начале
int offset=0, total_size =0
p.s.. проверено на POD's включая поля растущие как typedef pod_type type_name[N]
Здравствуйте, MShura, Вы писали:
MS>Это называется, как Вы сами заметили в названии структуры, выравнивание, а не смещение.
да, извините, опечатался — имел ввиду именно выравнивание.
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, szag, Вы писали:
S>>1. слишком много изменений в клиентском коде; S>>2. клиентский код станет писать сложнее, появится много зависимостей, как то, за был прописать поле в табличку или еще чего.
S>>макросы эти были придуманы для того, чтобы сделать жизнь енд юзера проще, хорошо или плохо это было сделано вопрос другой, но сейчас клиентский код менять никто не даст, к тому же, он работает уже более 3-х лет, т.е. отлажен... и работает в разных организациях, которые не обрадуются такому апдейту сервера, при котором надо переписывать код...
К>Почему изменения в клиентском коде? Я спрашивал К>1) макрос разворачивается в подобный код? К>2) что мешает изменить макрос, чтобы он генерировал таблицу не только с размерами, но и смещениями?
1) Видимо не правильно Вас понял. макрос внутри менять можно, нельзя менять клиентский код, т.е. если поменять макрос и клиентский код при этом перекомпилируется и гарантированно будет работать — то проблем нет
2) наверное только незнание того как это сделать
вот пример макроса, который генерит сам класс (выкинул кучу всего что мешает пониманию)
#define TABLE(name, meta, fields) \
class name : public ORMtableBase \
{ \
public: \
\
meta \
\
\
fields \
\
private: \
static FieldsList FieldsMap; \
}; \
ORMtableBase::FieldsList name::FieldsMap; \
т.е. видно, что филды сюда приходят ввиде последовательно идущих макросов, так как количество их не известно, может быть одно а может и 100. meta так же поток макросов.
как я и писал выше, филды достаточно стожные классы, которые генерируются макросами, а дальше шаблонами.
Здравствуйте, szag, Вы писали:
S>есть задача обращаться к полям класса по их имени, т.е. зная строку. Это строка, приходит, парсится потом собственно идет само обращение.
[skipped] S>P.S. Все эти извращения потому, что в месте использования нет информации о конечном типе, а есть только интерфейс.
В принципе решил я это для CodeGear2010 и MSVC2010. 1-й признать порадовал, — в обратном смысле слова
Фукция считает offset, для упрощения оформлена шаблоном
template <class T> int nextP(int &offset, int &total_size, bool &realign) {
int prev_offset = offset;
typedef std::remove_all_extents<T>::type U;
size_t size = sizeof(T), mask = sizeof(U) - 1, trusted_offset = offset;
int c = std::tr1::is_class<U>::value ? alignof(T) : 0;
if (c) mask = c - 1;
if (!realign && (offset & mask)) {
trusted_offset = offset = (offset + mask) & ~mask;
}
#ifdef __CODEGEARC__
if (c) realign = true; // maybe its code_gear bug#endif
offset += size; total_size += offset - prev_offset;
return trusted_offset;
}
Собственно для MSVC "костыль" c realign можно отрезать напрочь. Для [b]szag использовать таблицы вместо tr1 и std::remove_all_extents[/b]
Проверял я на таких структурах:
Здравствуйте, szag, Вы писали:
К>>1) макрос разворачивается в подобный код? К>>2) что мешает изменить макрос, чтобы он генерировал таблицу не только с размерами, но и смещениями?
S>1) Видимо не правильно Вас понял. макрос внутри менять можно, нельзя менять клиентский код, т.е. если поменять макрос и клиентский код при этом перекомпилируется и гарантированно будет работать — то проблем нет S>2) наверное только незнание того как это сделать
Буст-препроцессор может творить чудеса...
Вообще же, каркас макроса выглядит так
Дальше MEMBERS развёртывает макро-цепочку, превращая её в объявления полей, а METADATA — в метаданные (размеры, смещения).
Завтра попробую на BOOST/PP родить рабочий пример.
Здравствуйте, Seigram, Вы писали:
S>Я бы иначе написал это и думаю угодил бы запросу szag. S>Собственно сообразить как компилятор и что размещает не сложно зная типы полей
В момент итерирования типы полей неизвестны. Поля представлены интерфейсом IORMField*, у которого есть GetSize().
По одному только размеру судить о выравнивании сложно: char[8], int[2] и double имеют одинаковый размер и разное выравнивание
Поэтому придётся добавить в интерфейс GetAlign().
Ну а дальше — в реализациях — операторы sizeof и __alignof (или его рукодельная замена, не суть).
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, szag, Вы писали:
К>>>1) макрос разворачивается в подобный код? К>>>2) что мешает изменить макрос, чтобы он генерировал таблицу не только с размерами, но и смещениями?
S>>1) Видимо не правильно Вас понял. макрос внутри менять можно, нельзя менять клиентский код, т.е. если поменять макрос и клиентский код при этом перекомпилируется и гарантированно будет работать — то проблем нет S>>2) наверное только незнание того как это сделать
К>Буст-препроцессор может творить чудеса... К>Вообще же, каркас макроса выглядит так К>
К>Дальше MEMBERS развёртывает макро-цепочку, превращая её в объявления полей, а METADATA — в метаданные (размеры, смещения). К>Завтра попробую на BOOST/PP родить рабочий пример.
не уверен что правильно понял вашу идею.
fields представляет из себя поток дефайнов, вида:
т.е основная задача этого дефайна:
1. сформировать класс, с конструктором не принимающим параметры
2. перекрыть некоторые виртуальные функции, как то GetSize и некоторые функции в __VA_SRGS__, если пользователь указал что-то вроде EDITABLE(false). дальше создается поле по этому классу.
в общем-то функция GetSize сейчас уже включает в себя выравнивание поля.
Дальше вся эта хитрая конструкция обрабатывается кодом см. мой первый пост.
Здравствуйте, Seigram, Вы писали:
S>Здравствуйте, Кодт, Вы писали:
К>>Здравствуйте, szag, Вы писали: S>[skipped] К>>Но, всё же, с таблицей смещений будет проще и надёжнее.
S>Я бы иначе написал это и думаю угодил бы запросу szag. S>Собственно сообразить как компилятор и что размещает не сложно зная типы полей S>Примерно так, -для простоты у меня шаблон, а у szag можно сделать табличку для замены sizeof(std::remove_all_extents<T>::type):
S>p.s.. проверено на POD's включая поля растущие как typedef pod_type type_name[N]
Извините, но я что-то с первого раза не понял, чем ваша конструкция принципиально отличается от того варианта который сейчас сделал я — sizeof() + Aligment, см. посты ниже.
Это очевидно.
S>каждый дефайн вызывает другой дефайн,
А вот здесь мы вас поправим! Пусть этот дефайн не сам вызывает макрос FIELD(.....), а его извне заставляют вызвать тот или иной макрос.
И у нас есть два контекста:
— объявление членов структуры (то, что сейчас уже делается)
— заполнение массива метаданных
S> который формирует класс делает следующее:
S>#define FIELD(TypeID, RealType, name, captionID, ...) \
S>class RealType ## _ ## name : public ORMfield<TypeID, RealType> \
Во-первых, гарантируем, что склеиваться будет окончательное значение name. Во-вторых, просто нагляднее, и избегаем повторения операции (она встречается здесь четырежды: в имени класса, в конструкторе, в sizeof и в типе переменной).
S>в общем-то функция GetSize сейчас уже включает в себя выравнивание поля.
По-моему, это неправильно. В размер нужно добавлять величину зазора между этим полем и следующим. А тип следующего поля неизвестен.
Хотя... может быть, и можно так делать.
Вот! Наконец-то попёрла конкретика!
Только всё равно не понятно, что такое TypeID и зачем он нужен.
Ещё не совсем мне понятно, зачем нужно чтобы на каждое поле был свой класс? Из-за инициализатора только?
IMHO, можно так не делать, а инициализаторы передавать в конструкторе таблицы.
Но я не про это.
Во-первых, даже с классом на каждое поле, конструкцию можно упростить.
Типа написать шаблон
template<typename MDT, typename TypeID, typename TRealType>
class ORMfield {
// тут всё так, как у тебя и есть +
std::size_t GetSize() const;
{ \
return sizeof( RealType ## _ ## name ) + \
MyAlign<RealType ## _ ## name>::Result; \
} \
};
template<typename MDT, typename TypeID, typename TRealType>
std::size_t GetSize();
{
return sizeof( MDT ) + MyAlign<MDT>::Result;
}
Во-вторых, на сколько я понял, место тебе не жаль?
Тогда можно сдать так, что все ORMfield будут выравниваться одинаково. На что-то одно и то же, достаточно большое.
Ну, например, иметь такой вот простенький шаблон:
И внутри ORMfield хранить все данные в виде AlignedData<RealType>
Тогда на GetSize можно будет просто забить, а сделать у всех ORMfield общую базу, типа ORMfieldBase и заиметь у неё метод virtual const ORMfieldBase* GetNext() const... S>fields представляет из себя поток дефайнов, вида: S>
Что касается той идеи, что предлагал КодТ, то там всё просто.
Я напишу так, словно у тебя есть только тип int и немного на псевдокоде, а ты обобщишь потом на всё, что тебе надо.
Пишешь, такую систему макросов:
#define EXTRACT_FIELDS_END_OF_LIST_
#define EXTRACT_FIELDS_INT( NAME, TYPE_ID, INIT_VALUE ) \
/* тут собственно кусок твоего старого определение INT */ FIELD( int, NAME, TYPE_ID, INIT_VALUE )\
EXTRACT_FIELDS_##
EXTRACT_FIELDS( FIELDS ) EXTRACT_FIELDS_##FIELDS END_OF_LIST_
// Тут, на самом деле, надо немного схимичить, чтобы FIELDS подставилось раньше, чем развернётся, но я пока не буду
Потом пишешь ещё макросы EXTRACT_INITIALIZATORS_LIST, EXTRACT_TABLE_OF_OFFSETS и т. д. и живёшь себе счастливо без виртуальных функций GetSize
Да, по поводу "схимичить" всё уже схимичено в бусте. Если ты не можешь его заюзать, а IMHO, это жёсткое требованиек клиентам -- доставить буст. Ты можешь выдрать химию оттуда, или попроси, тебе тут помогут.
Вот.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском