Opened 13 years ago
Last modified 7 years ago
#3982 new Bugs
mpl::at documentation out of sync with code
Reported by: | Owned by: | Aleksey Gurtovoy | |
---|---|---|---|
Milestone: | Boost 1.43.0 | Component: | mpl |
Version: | Boost 1.42.0 | Severity: | Problem |
Keywords: | mpl::at default | Cc: |
Description
Documentation of mpl::at indicates that it can take either 2 or 3 template parameters, but in fact only takes just 2. The documentation indicates a third template parameter to forward a default if lookup fails to find a match. This option does not exist.
Code or Documentation should be amended. If there will be no 3 template parameter option, the following would be nice to have in the documentation, as how to achieve a default when no match is found:
typename boost::mpl::eval_if<
typename boost::mpl::has_key< Map, Key >::type
, boost::mpl::at< Map, Key > , boost::mpl::identity< Default >
::type
Change History (8)
comment:1 by , 13 years ago
Component: | Documentation → mpl |
---|
comment:2 by , 12 years ago
comment:3 by , 12 years ago
Having a three argument at in the library is not necessarily more efficient overall, since it will increase the overhead of the two-argument at.
follow-up: 5 comment:4 by , 12 years ago
Steven, are you saying that it should probably have a different name for efficiency reasons?
at_def? at_or?
comment:5 by , 10 years ago
So what's the correct resolution here? Update the documentation to remove the 3-argument version? Or implement the 3rd argument? Seems like the former is easier/safer. I'd be willing to do either to the best of my abilities.
comment:6 by , 10 years ago
The correct resolution would be to add the default argument support. I'd be happy to review your patch.
comment:8 by , 7 years ago
Damn... I've just wasted like 10 hours trying to feed it default value. And I'm complete newbie in C++ and it's templates. Please, please, fix it.. :)
In my experience (with MSVC++) implementing the defaulted at as
...
{
}
or by using find + compare-to-end (instead of void) + deref proved to be more (compile-time) efficient (probably because of skipping the instantiation of has_key<>...)...
In any case, the defaulted at should IMO be provided out-of-the-box by MPL (both because of 'cleanness' and because the library author has the best chance to make it as efficient as possible)...