U++ forum: Welcome to the forum

Search on this site

Search in forums

Home » U++ Library support » U++ Core » MSC problems: pick_ != const

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

MSC problems: pick_ != const [message #20931]

Sun, 19 April 2009 23:07

Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.

Experienced Contributor

For example, this code causes error:

struct AOp : Moveable<AOp>
{
	One<AOpHardware> hardware;
};

class AOps : public Vector<AOp>
{
public:
	void Xmlize(XmlIO xml) {XmlizeContainer(xml, "aop", *this);}
};

This is caused by the fact that pick != const in MSC compiler. And somewhere within U++ Core we have copying of Vector member with const argument (not pick_!):

//Core/Topt.h @ 135
template <class T>
inline void DeepCopyConstruct(void *p, const T& x) {
	::new(p) T(x);
}

This is strange. Class One supports pick behaviour, so accroding to U++ principles this code should compile without errors.
Am I right?

Report message to a moderator

Re: MSC problems: pick_ != const [message #20932 is a reply to message #20931]

Mon, 20 April 2009 00:25

mirek
Messages: 13975
Registered: November 2005

Ultimate Member

Mindtraveller wrote on Sun, 19 April 2009 17:07

For example, this code causes error:

struct AOp : Moveable<AOp>
{
	One<AOpHardware> hardware;
};

class AOps : public Vector<AOp>
{
public:
	void Xmlize(XmlIO xml) {XmlizeContainer(xml, "aop", *this);}
};

This is caused by the fact that pick != const in MSC compiler. And somewhere within U++ Core we have copying of Vector member with const argument (not pick_!):

//Core/Topt.h @ 135
template <class T>
inline void DeepCopyConstruct(void *p, const T& x) {
	::new(p) T(x);
}

This is strange. Class One supports pick behaviour, so accroding to U++ principles this code should compile without errors.
Am I right?

Yes and no.

pick definitely is not equal to semantics of const. (const guarantees no change).

That, after all, is why there is #define pick_...

Anyway, we are sort of at odds with C++ standard here as we would like to have pick_ constructors used when returning containers from functions. According to C++ standard, this is only possible if they are const (the critical rule is "nonconst references cannot be bound to temporaries").

Surprisingly, MSC++ has relaxed rules (you can call it a bug) w.r.t. to this, probably because some old MFC code was breaking the rule too. As we know when we are compiling with MSC, I decided make #define pick_ empty in that case; it better matches wanted pick_ semantics and is able to catch a bug here are there, like if you are trying to use DeepCopyConstruct on pick type.

Mirek

Report message to a moderator

Re: MSC problems: pick_ != const [message #20934 is a reply to message #20932]

Mon, 20 April 2009 08:11

Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.

Experienced Contributor

Then the question is why U++ uses DeepCopyConstruct for Vector elements? The code seems "clean" from U++ point of view. So why isn`t it compiled successfully?

ADD: If the problem is with Xmlize, could you please tell why and how to solve it for pick types?

[Updated on: Mon, 20 April 2009 08:13]

Report message to a moderator

Re: MSC problems: pick_ != const [message #20936 is a reply to message #20934]

Mon, 20 April 2009 09:22

mirek
Messages: 13975
Registered: November 2005

Ultimate Member

You need to add deep copy contructor to AOp.

It can either be 'implicit' one or 'optional'.

With optional, you need to add uniform access using DeepCopyOption.

See

http://www.ultimatepp.org/srcdoc$Core$pick_$en-us.html

Note that would it be your way, data would be destroyed during 'Store' operation. I guess that is not one would expect...

Mirek

Report message to a moderator

Previous Topic:	[REQUEST] IsHidden for POSIX platforms
Next Topic:	Add the replace string with wildcards from editor to core

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Thu Apr 25 05:40:13 CEST 2024

Total time taken to generate the page: 0.05283 seconds