Opened 13 years ago
Last modified 13 years ago
#3114 new Feature Requests
Modified interface to allow even lazier return types for defaults
| Reported by: | Jeremiah Willcock | Owned by: | Jeremiah Willcock |
|---|---|---|---|
| Milestone: | Boost 1.42.0 | Component: | parameter |
| Version: | Boost 1.38.0 | Severity: | Problem |
| Keywords: | Cc: |
Description
There are some use cases where the return type of operator() in a default computation class is not valid in some cases when that default is not used. The current interface to such classes does not allow that case; see the message at http://lists.boost.org/Archives/boost/2009/05/152009.php for more information. The attached patch allows a special member type (that must be void) to be used to change the interface to pass a single int argument to operator(), while keeping the old no-parameter interface for function objects without the special tag. The tag could also have been implemented as a traits class used with enable_if. The patch passes all of the Boost.Parameter tests except two (which appear to freeze up). I only changed the normal path through the code, and not the compatibility code which I am unable to test. A test for the new functionality added by the patch is also attached.
Attachments (4)
Change History (10)
by , 13 years ago
| Attachment: | parameter_interface.patch added |
|---|
comment:1 by , 13 years ago
| Type: | Patches → Feature Requests |
|---|
comment:2 by , 13 years ago
The patch might need to be changed so that it gets result_of<F(int)>::type rather than result_of<F()>::type because that second case does not use a result member template in F while the first one does.
comment:3 by , 13 years ago
| Owner: | changed from to |
|---|
Jeremiah,
I don't completely understand the problem you're solving, but if you can assure me that no documentation changes are needed for this, then I trust you to check in your changes on trunk and move them to release when the results look clean.
comment:4 by , 13 years ago
| Milestone: | Boost 1.40.0 → Boost 1.42.0 |
|---|---|
| Owner: | changed from to |
I believe that it should require documentation changes (to document the new interface), and possibly a change (backwards-incompatible) to only use the new interface with the dummy parameter (if you want). I do not believe this patch is ready for 1.41 and should be understood fully before being added. You may want to rewrite it anyway to match your coding standard, naming conventions, etc. I am sending this back to you to be delayed until 1.42 and checked in more detail.
by , 13 years ago
| Attachment: | parameter_extra_lazy.cpp added |
|---|
An example program that fails with zero-argument use of result_of (the old behavior)
comment:5 by , 13 years ago
Okay, the things you want here might be nice to have overall, but you don't need them to solve your problems. You're doing everything the hard way by not using the macros that generate the overload set. I'm attaching a patch to depth_first_search that makes everything work.
If you read the comments in the patch, you'll see that there are a few places here and there where Boost.Parameter could be a big help if it did things differently. We should generate tickets for those.
by , 13 years ago
| Attachment: | depth_first_search.hpp.patch added |
|---|
Patch that parameter-enables depth_first_search without changes to Boost.Parameter
comment:6 by , 13 years ago
| Owner: | changed from to |
|---|
Patch to allow alternative interface