Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Developing U++ » U++ Developers corner » Changing the pick semantics notation  () 1 Vote
icon4.gif  Changing the pick semantics notation [message #42331] Fri, 07 March 2014 19:01 Go to next message
mirek is currently offline  mirek
Messages: 12105
Registered: November 2005
Ultimate Member

New pick notation[ 12 votes ]
1. I support this 12 / 100%
2. I do not like this 0 / 0%
3. I do not care 0 / 0%

For 12+ years, '=' for pick-types meant 'pick' (destroying source), with implementation that relies on

#define pick_ const


to make it usable for function return values. <<= and T(const T&, int) were used to provide optional 'deep copy' values.

This served well, but it was not really optimal and might have scared some at first. And while in practice much less error-prone that it might look, there was still chance of occasional errors.

Meanwhile, we got C++11 with its rvalues. It would really be nice to replace pick_ with &&. But things are not that simple, OTOH they provide chances for improving things even more.

One thing is clear: we still do not want containers to have implicit deep copy (like STL has).

Now, after a day of experimenting I would like to present/propose new pick notation:

'=' alone is now disallowed for pick-types. Instead, we will write:

a = pick(b); // pick copy


or

a = clone(b); // deep copy


(except when we are assigning temporary value - then by the logic it is clear that we want 'pick').

operator<<= is thus deprecated and deep copy constructor can be written as

A a = clone(b)


When compiling with C++11, this notation becomes enforced.

When compiling with C++03, old things still work without a change and this new notation is optional.

I have already completely changed U++ to support new notation and C++11 compilation (to the point of compiling theide). This is committed in upp/branches/cpp11.

Please comment and/or vote on this change...

[Updated on: Fri, 07 March 2014 19:02]

Report message to a moderator

Re: Changing the pick semantics notation [message #42333 is a reply to message #42331] Fri, 07 March 2014 19:45 Go to previous messageGo to next message
zsolt is currently offline  zsolt
Messages: 590
Registered: December 2005
Location: Budapest, Hungary
Contributor
The current pick behavior was very extreme and hard to explain thing for most of the programmers I know. I think, this change should help a lot in U++'s popularity.
Re: Changing the pick semantics notation [message #42356 is a reply to message #42333] Sat, 08 March 2014 19:05 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3033
Registered: August 2008
Ultimate Member
Very reasonable. My vote is yes.

In addition (if possible) I would like to have some kind of #define to force errors when an = or a <<= is found, to help code updating.


Best regards
IƱaki
Re: Changing the pick semantics notation [message #42358 is a reply to message #42356] Sat, 08 March 2014 20:45 Go to previous messageGo to next message
nlneilson is currently offline  nlneilson
Messages: 644
Registered: January 2010
Location: U.S. California. Mojave &...
Contributor
Vote for the change.

The only down side to the change would be updating current code in existing apps. A few posts covering problems should solve things.

Picking has worked good for me even on menu pull downs in tablet mode with a pen.
Re: Changing the pick semantics notation [message #42359 is a reply to message #42331] Sat, 08 March 2014 21:41 Go to previous message
dolik.rce is currently offline  dolik.rce
Messages: 1758
Registered: August 2008
Location: Czech Republic
Senior Contributor

I cautiously support this Smile

The change seems to touch mostly everything in U++, so I'd be glad if it was very thoroughly tested before merging into trunk. Also some performance checks (on real life applications) would be a nice idea.

If I understand it correctly, it seems to smoothen some rough edges around current pick behavior, so it is a good thing. What I like most is the fact that it should prevent accidental picks, which happen to me quite often Smile

Best regards,
Honza
Previous Topic: Google Summer of Code 2014
Next Topic: D lang support
Goto Forum:
  


Current Time: Thu Nov 21 22:46:06 CET 2019

Total time taken to generate the page: 0.00657 seconds