U++ forum: Welcome to the forum

Status & Roadmap

Authors & License

Funding Ultimate++

Search on this site

Search in forums

Home » Developing U++ » U++ Developers corner » Should the pick semantics be changed?

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

Return to the default flat view

Create a new topic

Submit Reply

Re: Should the pick semantics be changed? [message #42329 is a reply to message #42317]

Fri, 07 March 2014 16:23

piotr5 is currently offline

piotr5
Messages: 107
Registered: November 2005

Experienced Member

I agree, imho this is a bug in gcc (or maybe also in c++11 standard): every return statement should pass the arguments as rvalue to the return-type constructor since the return statement is leaving scope and thereby its parameters have the same properties as all implicite rvalue objects: unlikely to remain (unless static), should not be altered except for purposes of picking, definitely a temporary value.

as for pick and clone I am unsure if we need both. this is the actual question of this thread: which of the two should we drop? in std-c++11 clone is implicitely done, always the default. in u++ the default is picking and clone would need to be stated. a good choice since picking is more efficient.

looking at this new idea with clone() I guess my fears about diverging from the standard has been soothed: if I want to use std::vector as drop-in replacement for Upp::Vector, I could specialize a clone() function for it. so I would be happy to see a clone function in Core, maybe already specialized for std library containers.

btw, I heard that according to the standard compilers are free to remove calls to the initializer of an object, so also from that side pick-construction can be realized. I haven't observed that behaviour though...

Report message to a moderator

Send a private message to this user

[Message index]

		Should the pick semantics be changed? By: piotr5 on Tue, 04 March 2014 11:00
		Re: Should the pick semantics be changed? By: mirek on Tue, 04 March 2014 12:12
		Re: Should the pick semantics be changed? By: piotr5 on Tue, 04 March 2014 23:14
		Re: Should the pick semantics be changed? By: mirek on Wed, 05 March 2014 08:54
		Re: Should the pick semantics be changed? By: piotr5 on Wed, 05 March 2014 10:27
		Re: Should the pick semantics be changed? By: mirek on Wed, 05 March 2014 12:02
		Re: Should the pick semantics be changed? By: mirek on Fri, 07 March 2014 09:00
		Re: Should the pick semantics be changed? By: piotr5 on Fri, 07 March 2014 16:23
		Re: Should the pick semantics be changed? By: mirek on Fri, 07 March 2014 16:44
		Re: Should the pick semantics be changed? By: mirek on Sun, 09 March 2014 09:34
		Re: Should the pick semantics be changed? By: piotr5 on Sun, 09 March 2014 13:28
		Re: Should the pick semantics be changed? By: Lance on Sun, 23 March 2014 22:02
		Re: Should the pick semantics be changed? By: piotr5 on Tue, 25 March 2014 19:35
		Re: Should the pick semantics be changed? By: Lance on Wed, 26 March 2014 02:37
		Re: Should the pick semantics be changed? By: Lance on Wed, 26 March 2014 02:48
		Re: Should the pick semantics be changed? By: piotr5 on Wed, 26 March 2014 10:35
		Re: Should the pick semantics be changed? By: mirek on Wed, 26 March 2014 11:38
		Re: Should the pick semantics be changed? By: Lance on Wed, 26 March 2014 21:25
		Re: Should the pick semantics be changed? By: Lance on Wed, 26 March 2014 21:21

Previous Topic:	D lang support
Next Topic:	[Compilation] Include .asm files in build

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

PDF

]

Current Time: Tue May 14 19:26:13 CEST 2024

Total time taken to generate the page: 0.02584 seconds