хитрый автоконструктор - C/C++

Уважаемые гуру!

вопрос такой: можно ли написать такой автоконструктор, который знал бы об экземпляре объекта в котором он создается?
поясню:

class A{...
// здесь мы знаем о "b"
}


class B{
  A a; // 
}

B b;

интересует любой вариант (макрос, шаблон) с любым классом/объявлением.

Здравствуйте, Oleg A. Bachin, Вы писали:

class B;
class A
{
   B* pb_;
public:
   A(B* pb = 0) : pb_(pb) {}
};

class B
{
   A a;
public:
   B() : a(this) {}
};

int main()
{
   B b;
}

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

B>Здравствуйте, Oleg A. Bachin, Вы писали:

B>

B>class B;
B>class A
B>{
B>   B* pb_;
B>public:
B>   A(B* pb = 0) : pb_(pb) {}
B>};

B>class B
B>{
B>   A a;
B>public:
B>   B() : a(this) {}
B>};

B>int main()
B>{
B>   B b;
B>}
B>

Прошу прощения, но возможно я не правильно выразился...
Я имел ввиду под "автоконструктор" — это конструктор по-умолчанию.
Т.е. то, что Вы написали я прекрасно понимаю, но мне хотелось бы описать класс (написать макрос если такой возможен) при котором this передавался автоматически.

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

OAB> вопрос такой: можно ли написать такой автоконструктор, который знал бы об
OAB> экземпляре объекта в котором он создается?

OAB>

 OAB> class B{
 OAB>   A a; //
 OAB> }
 OAB>

Только если заранее известно, что объекты A всегда будут создаваться как члены B.
В этом случае можно пользоваться какими-нибудь платформенно-зависимыми штучками
для вычисления адреса полного объекта из адреса члена.

Posted via RSDN NNTP Server 1.7 "Bedlam"

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

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

OAB>> вопрос такой: можно ли написать такой автоконструктор, который знал бы об
OAB>> экземпляре объекта в котором он создается?

OAB>>

 OAB>> class B{
 OAB>>   A a; //
 OAB>> }
 OAB>>

ПК>Только если заранее известно, что объекты A всегда будут создаваться как члены B.
ПК>В этом случае можно пользоваться какими-нибудь платформенно-зависимыми штучками
ПК>для вычисления адреса полного объекта из адреса члена.

О! А можно поконкретнее... и сразу еще,платформо- или компиляторо- ? а может еще линкер вмешается?

допустим так, A всегда создается как екземпляр B (ну или Bxxx: public B).
пусть даже (скорее всего так и будет) A — это простой (забыл как точно называется, вобщем тот который нормально передается по значению,

class A{
  _v int;
}

)
т.е. память для него будет зарезервирована в экземпляре класса B.
как в таком случае получить сам экземпляр? чуть усложним:

class B{
  A a1;
  A a2;
}

Здравствуйте, Oleg A. Bachin, Вы писали:

OAB>допустим так, A всегда создается как екземпляр B (ну или Bxxx: public B).
OAB>пусть даже (скорее всего так и будет) A — это простой (забыл как точно называется, вобщем тот который нормально передается по значению,
OAB>

OAB>class A{
OAB>  _v int;
OAB>}
OAB>

OAB>)
OAB>т.е. память для него будет зарезервирована в экземпляре класса B.
OAB>как в таком случае получить сам экземпляр? чуть усложним:
OAB>

OAB>class B{
OAB>  A a1;
OAB>  A a2;
OAB>}
OAB>

ну, например, так:

class B;

class A
{
   int _v;
   B* container;
public:
   A() : container(_B::currentB) {}
};

//-------

class _B
{
  friend class A;
  _B();
protected:
  _B(B* pB) { currentB = pB; }
  static B* currentB;
};

_B::currentB = NULL;

//-------

class B: _B
{
  A a1;
  A a2;
  B() : _B(this) { currentB = NULL; }
};

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

J>ну, например, так:

J>

J>class B;

J>class A
J>{
J>   int _v;
J>   B* container;
J>public:
J>   A() : container(_B::currentB) {}
J>};

J>//-------

J>class _B
J>{
J>  friend class A;
J>  _B();
J>protected:
J>  _B(B* pB) { currentB = pB; }
J>  static B* currentB;
J>};

J>_B::currentB = NULL;

J>//-------

J>class B: _B
J>{
J>  A a1;
J>  A a2;
J>  B() : _B(this) { currentB = NULL; }
J>};
J>

я думал о таком варинте — регистрироваться в статической переменной на время создания класса... и в задаче вроде как не предвидится дерева (в классе B не присутствует член типа B)... и потокобезопастность можно добавить (учитывая предыдущее ограничение дабы небыло неразрешимых блокировок)... но почему-то мне это не эстетично показалось... что скажете?

Здравствуйте, Oleg A. Bachin, Вы писали:

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

OAB>я думал о таком варинте — регистрироваться в статической переменной на время создания класса... и в задаче вроде как не предвидится дерева (в классе B не присутствует член типа B)... и потокобезопастность можно добавить (учитывая предыдущее ограничение дабы небыло неразрешимых блокировок)... но почему-то мне это не эстетично показалось... что скажете?

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

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

V>Если не присутствует в классе В, то просто передавай как параметр, и используй только в конструкторе.
V>От статической глобальной переменной откажись сразу.

не понял... можно на примере плиииз

честно говоря в голове крутятся свои не сформированные до конца идеи, поэтому не совсем понял что Вы хотели сказать...

Здравствуйте, Oleg A. Bachin, Вы писали:

OAB>Здравствуйте, Павел Кузнецов, Вы писали:

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

OAB>>> вопрос такой: можно ли написать такой автоконструктор, который знал бы об
OAB>>> экземпляре объекта в котором он создается?

OAB>>>

 OAB>>> class B{
 OAB>>>   A a; //
 OAB>>> }
 OAB>>>

ПК>>Только если заранее известно, что объекты A всегда будут создаваться как члены B.
ПК>>В этом случае можно пользоваться какими-нибудь платформенно-зависимыми штучками
ПК>>для вычисления адреса полного объекта из адреса члена.

OAB>О! А можно поконкретнее... и сразу еще,платформо- или компиляторо- ? а может еще линкер вмешается?

OAB>допустим так, A всегда создается как екземпляр B (ну или Bxxx: public B).
OAB>пусть даже (скорее всего так и будет) A — это простой (забыл как точно называется, вобщем тот который нормально передается по значению,

Расскажи подробнее про свою задачу. Может быть, существует какой-то изъян в дизайне.
Если дизайн поправить, так может задача сама собой разрешится.

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

S>Расскажи подробнее про свою задачу. Может быть, существует какой-то изъян в дизайне.
S>Если дизайн поправить, так может задача сама собой разрешится.

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

Сейчас вот придумал себе задачку такого рода...
Просто пытаюсь изучить возможности С++ и как можно упрощать код, а значит уменьшать возможность описок.
типа:

class B{
  A a1;
  A a2;
  ...
  B(): a1(0), a2(0){B::SomeFunc(a1); B::SomeFunc(a2); ... };
}

Хочу, чтобы для класса (группы классов) A функция B::SomeFunc вызывалась автоматически (дабы не забыть написать).

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

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

А>

А>class B{
А>  A a1;
А>  A a2;
А>  ...
А>  B(): a1(0), a2(0){B::SomeFunc(a1); B::SomeFunc(a2); ... };
А>}
А>

А>Хочу, чтобы для класса (группы классов) A функция B::SomeFunc вызывалась автоматически (дабы не забыть написать).

А конкретнее? Только одна эта функция? Или любая функция? функция статическая? когда именно вызывалась?

ставь максимально конкретизированную задачу, иначе слишком много вариантов, а писать их все ломает, если честно

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

J>А конкретнее? Только одна эта функция? Или любая функция? функция статическая? когда именно вызывалась?
J>ставь максимально конкретизированную задачу, иначе слишком много вариантов, а писать их все ломает, если честно

ОК!

class TestRecord: public DBSTEP::Record
{
protected:
public:
DBSTEP::int4_t id;
std::string name;
DBSTEP::int4_t level;

TestRecord(DBSTEP::Db* db_ptr)
{
addField("id", id, DBSTEP_ALLOP_FIELD | DBSTEP_PRIMARY_KEY | DBSTEP_AUTOINC_FIELD);
addField("name", name);
addField("level", level);
};
};

Можно ли написать что-то, дабы не писать объявление и addField отдельно?

	От:	Oleg A. Bachin
	Дата:	04.02.04 10:09
	Оценка:

	От:	Bell
	Дата:	04.02.04 10:26
	Оценка:

	От:	Oleg A. Bachin
	Дата:	04.02.04 13:22
	Оценка:

	От:	Павел Кузнецов
	Дата:	04.02.04 13:32
	Оценка:

	От:	Oleg A. Bachin
	Дата:	04.02.04 13:53
	Оценка:

От:	jazzer	Skype: enerjazzer
Дата:	04.02.04 14:02
Оценка:

	От:	Аноним
	Дата:	05.02.04 08:24
	Оценка: