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

__>>кста, давече по поводу placement new натолкнулся на строгое предупреждение — мол, вам никто не гарантирует, что объект будет размещен именно с начала указателя на буфер. при размещении могут еще учитываться всякие выравнивания и проч.
__>>потому я бы тоже побоялся такое использовать.

TB>Ну дык нефиг невыровненные указатели использовать.

А разве this может быть неправильно выровнен ?

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

BFE>А разве this может быть неправильно выровнен ?

reinterpret_cast<MyClass*>(size_t(1))->DoSome();

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

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

__>>>>Может, появилась какая-нить возможность принудительно вызывать конструктор копирования по умолчанию внутри перегрузки конструктора копирования?
__>>да, это немного не то — это как определить присваивание через конструктор копирования

BFE>А, чёрт! Дак это, делегирующие конструкторы вам в помощь.

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

СopyCtr(const СopyCtr& Inst): СopyCtr(Inst)default
{
   //<particular reinitialization>
}

не пройдет.

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

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

__>>извиняюсь, а как в с++ можно удостовериться, что они выровнены нужным образом?

TB>Ну можно завести структуру CheckAlign{ char c; MyClass obj; }, тогда sizeof(CheckAlign)-sizeof(MyClass) будет выравниванием, осталось проверить, что значение указателя делится на это выравнивание.
а кто гарантирует, что компилятор выравнивание для obj внутри CheckAlign и для obj самого по себе делает одинаково?

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

__>а кто гарантирует, что компилятор выравнивание для obj внутри CheckAlign и для obj самого по себе делает одинаково?

Правила выравнивания подробно описаны в стандарте.

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

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

__>>п.с. и вообще код
__>>

__>>MyClass (const MyClass & other) : MyClass ()
__>>

__>>разве пройдет?

BFE>Да. Это нововведение С++11. см. здесь

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

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

__>уж лучше тогда обернуть указатели в какие-нибудь смарт-поинтеры, которые автоматически при копировании клонируют свои объекты (кстати, а такого плана умные указатели вообще существуют, например, в том же бусте?).
тогда непонятно зачем вообще эти смарт поинтеры держать, а не положить сам объект в класс по значению а не ссылке/указателю.
Если они не копируемые, то вам и такой смарт поинтер ничем не поможет, т.к. опять не будет компилироваться из-за запрета на копирование. А если объект клонируемый, то обычно делают отдельную функцию создания/копирования и тогда не понятно как такой смартпоинтер должен быть генерализован, потому-что как правило функция клонирования уже использует смарт поинтер для возврата объекта. Проще тогда просто создавать класс объекта+смарт поинтер вокруг него с блекджеком и ...

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


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

Можно без него, в ++03 можно так:

void Init ()
{
  m_ptr = NULL;
}

MyClass () 
{ 
  Init ();
}

MyClass& operator = (const MyClass& other)
{
  //...
}


MyClass (const MyClass& other)
{
  Init();
  operator = (other);
}

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

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

__>>зачем? присваивание и есть инициализация.

TB>Затем, что присваивание не инициализация. Присваивание ещё и смотрит на то, что было в объекте до этого. Например, в умном указателе, такой утрированный пример:

TB>

TB>clever_ptr& operator = (const clever_ptr& other)
TB>{
TB>  if (!m_ptr) // опа опа
TB>    m_ptr = new T(*other.m_ptr);
TB>  else
TB>    *m_ptr = *other.m_ptr;
TB>}

TB>Поэтому очень важно, чтобы перед вызовом = объект находился в самосогласованном состоянии. Вызов пустого конструктора это и делает.

ну, в общем случае, наверное, да, согласен, что лучше все-таки его предварительно инициализировать, а потом уже делать присваивание.

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

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

__>>уж лучше тогда обернуть указатели в какие-нибудь смарт-поинтеры, которые автоматически при копировании клонируют свои объекты (кстати, а такого плана умные указатели вообще существуют, например, в том же бусте?).
V>тогда непонятно зачем вообще эти смарт поинтеры держать, а не положить сам объект в класс по значению а не ссылке/указателю.

я же писал в самом начале:

__>На всякий случай — у меня внутри класса гетерогенный контейнер (контейнер указателей на базовый класс, от которого наследуются разные классы объектов). Соответственно, именно для него приходится ручками писать копирование (а создавать отдельный копируемый класс для него как-то лень).

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

чего ж запрета то? я же не про unique_ptr вел речь, а про некий обобщенный смарт-поинтер, который умеет копироваться, и при копировании копирует еще и объект, на который указывает образец.

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

__>Например, если в классе очень много копируемых полей, и очень мало указателей (unique owners), то такое перечисление выглядит очень дико (к тому же вероятность пропустить, не дописать и т.п. многократно увеличивается).
__>Может, появилась какая-нить возможность принудительно вызывать конструктор копирования по умолчанию внутри перегрузки конструктора копирования?
__>...а создавать отдельный копируемый класс для него как-то лень...

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

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

__>чего ж запрета то? я же не про unique_ptr вел речь, а про некий обобщенный смарт-поинтер, который умеет копироваться, и при копировании копирует еще и объект, на который указывает образец.
при клонировании конструктор копирования обычно прикрывают.

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

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


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

TB>Можно без него, в ++03 можно так:
TB>

TB>void Init ()
TB>{
TB>  m_ptr = NULL;
TB>}

TB>MyClass () 
TB>{ 
TB>  Init ();
TB>}

TB>MyClass& operator = (const MyClass& other)
TB>{
TB>  //...
TB>}


TB>MyClass (const MyClass& other)
TB>{
TB>  Init();
TB>  operator = (other);
TB>}
TB>

угу. токо так не всегда удобно делать, если, например, код инициализации должен быть гарантированно вызван только один раз — при конструировании объекта.

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

__>угу. токо так не всегда удобно делать, если, например, код инициализации должен быть гарантированно вызван только один раз — при конструировании объекта.

А где он у меня вызывается два раза?

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

__>я же писал в самом начале:
__>>На всякий случай — у меня внутри класса гетерогенный контейнер (контейнер указателей на базовый класс, от которого наследуются разные классы объектов). Соответственно, именно для него приходится ручками писать копирование (а создавать отдельный копируемый класс для него как-то лень).
ну положите оффсеты относительно базы, зачем там именно поинтеры на this? чтобы осложнить себе жизнь?

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

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

__>>чего ж запрета то? я же не про unique_ptr вел речь, а про некий обобщенный смарт-поинтер, который умеет копироваться, и при копировании копирует еще и объект, на который указывает образец.
V>при клонировании конструктор копирования обычно прикрывают.

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

грубо горя, ситуация типа такой:

enum KINDs{kind_a, kind_b};

class CAbstactItem
{
    virtual KINDs kind_of()= 0;
};

class CItemA : public CAbstactItem{ //<implementation>};
class CItemB : public CAbstactItem{ //<implementation>};



class CFoo
{
   //<100500 копируемых полей>


   std::vector<CAbstactItem*> m_ItemsStock;
};

и нужно организовать возможность копирования объектов класса CFoo при условии, что CItemA и CItemB сами по себе copyable

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

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

__>>я же писал в самом начале:
__>>>На всякий случай — у меня внутри класса гетерогенный контейнер (контейнер указателей на базовый класс, от которого наследуются разные классы объектов). Соответственно, именно для него приходится ручками писать копирование (а создавать отдельный копируемый класс для него как-то лень).
V>ну положите оффсеты относительно базы, зачем там именно поинтеры на this? чтобы осложнить себе жизнь?
вы о чем. какие оффсеты?

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

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

__>>угу. токо так не всегда удобно делать, если, например, код инициализации должен быть гарантированно вызван только один раз — при конструировании объекта.

TB>А где он у меня вызывается два раза?

у вас нигде. но никто не запрещает это сделать в любом месте и по многу раз

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

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

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

__>>>Может, появилась какая-нить возможность принудительно вызывать конструктор копирования по умолчанию внутри перегрузки конструктора копирования?

BFE>>Давно существует:

TB>ТС не то спрашивал.
TB>Но я так и делаю, как ты написал.
TB>Конструктор копирования должен быть ноэксепт для этого, конечно.

а где вам такое приходится делать? не проще ли все-таки конструктор копирования через оператор присваивания определять?

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

__>>>я же писал в самом начале:
__>>>>На всякий случай — у меня внутри класса гетерогенный контейнер (контейнер указателей на базовый класс, от которого наследуются разные классы объектов). Соответственно, именно для него приходится ручками писать копирование (а создавать отдельный копируемый класс для него как-то лень).
V>>ну положите оффсеты относительно базы, зачем там именно поинтеры на this? чтобы осложнить себе жизнь?
__>вы о чем. какие оффсеты?
у вас m_ItemsStock куда указывает, как выделены объекты в нём?