Може ли обединението да съдържа обекти от клас с потребителски дефиниран конструктор? Когато се опитам да създам, той дава грешка, казваща „членът „c::aa“ на съюз „c“ има дефиниран от потребителя конструктор или нетривиален конструктор по подразбиране“ Това стандарт ли е или има грешка в моя код?
Кодът, който тествах, е
class a
{
public:
int aaa;
a(){}
};
class b
{
public :
long bbb;
b() { }
};
union c
{
public :
c() {}
a aa;
b bb;
};
Преди C++11 отговорът е "не" - union може да съдържа само типове стойности (за заемане на термин от управляван код), тоест тип, който съдържа само членове с данни.
Unions споделят своя отпечатък от паметта между всички членове. Наличието на сложни членове в обединение би довело до ситуация, при която методите, действащи върху членове на данни от един клас, биха затрили членове на данни на другия клас в обединението.
Може би това, което искате, е struct.
union само когато изрично искате два обекта да споделят едно и също пространство в паметта. Девет пъти от десет почти винаги трябва да използвате struct, а не union.
- person Brian A. Henning; 09.01.2014
this някога се съхранява в паметта на обект?
- person Rob Kennedy; 09.01.2014
Това е възможно след C++11 ("неограничени съюзи").
class a
{
public:
int aaa;
a(){}
};
class b
{
public :
long bbb;
b() { }
};
union c
{
public :
c() {}
a aa;
b bb;
};
int main()
{
return 0;
}
Горният код работи добре с помощта на следния онлайн компилатор. http://www.compileonline.com/compile_cpp11_online.php
Така че отговорът е да и не, в зависимост от вашия компилатор. MS VS 2010 не компилира този код, защото все още не е напълно C++11. Очевидно най-новият C++11 GCC компилатор ще го компилира добре! Според мен това е страхотно, защото тривиалният дефиниран от потребителя конструктор просто инициализира данните и не променя оформлението на паметта.
Стандартът C++ 03 гласи, че всеки клас или структура с дефиниран от потребителя конструктор не е POD. Bjarn Stroustrup написа нещо за това на началната си страница, като посочи, че това е твърде строго определение за POD срещу не-POD, тъй като дефинираните от потребителя функции не винаги причиняват нетривиално оформление на паметта. Ето защо правилото беше облекчено.
