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 » Community » PR, media coverage, articles and documentation » Is U++ Core open for suggestions?
icon3.gif  Is U++ Core open for suggestions? [message #920] Wed, 08 February 2006 21:08 Go to next message
royalstream is currently offline  royalstream
Messages: 3
Registered: February 2006
Junior Member
I have a question regarding the stage of development of U++.
Is it possible to make suggestions regarding core functionality such as the pick semantics?
The reason I ask is because U++ might be past that point.
I like the Pick Semantics but I think there is room for improvement in the way they are implemented. For example, in several situations is not clear wether deep copy or picking is taking place (unless you know the way the specific type works Confused).
I have several ideas (nothing on paper yet Smile) but I want to know beforehand if there's any chance for them to be taken seriously.

Thanks!

Steven

Re: Is U++ Core open for suggestions? [message #921 is a reply to message #920] Wed, 08 February 2006 21:45 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Hi,

well, with 20MB of commercial codebase, doing huge changes to "pick" is hard Smile

However, we are always open to discussion.

I agree that cleaner syntax sugar there would be nice. However, the trouble is that as long as pick semantics is supposed to be used for function return values, there does not seem to be any other option (we need to use regular copy constructors there to pass return value to target).

Even worse, we like compiler to generate default copy constructors / assignment operators (doing that manually is way too much trouble).

So in the end it goes down to "you need to know type's transfer semantics".

I was trying to find alternatives (especially I do not like that const cast ugliness) for years, but was unable to come up with anything better.

Mirek
icon14.gif  Re: Is U++ Core open for suggestions? [message #947 is a reply to message #921] Thu, 09 February 2006 21:59 Go to previous messageGo to next message
royalstream is currently offline  royalstream
Messages: 3
Registered: February 2006
Junior Member
I had several ideas, all of them more or less revolved around auxiliary types.
But just as you said, I always found things I didn’t like about each one of them.
I came to think that even though there may be other ways of doing it; they all have shortcomings that defeat the whole purpose.
However, I am new to the project and it makes a very big difference to hear about a similar experience from you.

Thanks a lot for your prompt answer.

Steven




Re: Is U++ Core open for suggestions? [message #949 is a reply to message #947] Thu, 09 February 2006 22:12 Go to previous message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
BTW, there were some similar movements in C++ community, try to google for "MOJO Alexandrescu" or "Hinnant r-value reference".

First one is done using current C++, but has the exactly the sortcomings we both have encountered.

Second one is C++0x proposal, unfortunately it missed the composition issue... so very likely no help from there either Smile

In the end, the best help comes from MSC compiler bug that actually allows binding temporaries to non-const references, so it is possible to define pick_ empty for MSC and detect at least some cases.

All of that said, maintaining pick semantics is much easier than it might seem. Yes, from time to time I do encounter "pick assert failed" (runtime enforcment of pick semantics in debug mode), but generally, effort is quite simple to get things work...

Mirek
Previous Topic: Ultimate++ in wtl.wiki
Next Topic: Do not forget to take this survey!
Goto Forum:
  


Current Time: Thu Mar 28 10:23:03 CET 2024

Total time taken to generate the page: 0.00985 seconds