As I'm a little obsessed with emulating Python-style named parameters in C++ (of which several previous posts on this blog could serve as witnesses) when I saw the following line of code*:
auto p = Popen({"cat", "-"}, input{PIPE}, output{"cat_fredirect.txt"});
I wanted to see how named parameters are implemented in this library.
Variadic templates implementation
So, without much ado, here is the implementation of Popen. It is using variadic templates, but don't fear, it's not as complicated as it sounds:
// 1. named parameters are bound to the variadic param set ...args
template <typename... Args>
Popen(std::initializer_list<const char*> cmd_args, Args&& ...args)
{
vargs_.insert(vargs_.end(), cmd_args.begin(), cmd_args.end());
init_args(std::forward<Args>(args)...);
// ...
}
// 2. named params are forwarded to:
template <typename F, typename... Args>
inline void Popen::init_args(F&& farg, Args&&... args)
{
// 3. let ArgumentDeducer do the job!
detail::ArgumentDeducer argd(this);
argd.set_option(std::forward<F>(farg));
// 4. now process next named param from variadic parameter pack:
init_args(std::forward<Args>(args)...);
}
// the ArgumentDeducer class has an overload for each of the named parameter types
inline void ArgumentDeducer::set_option(output&& out) {
if (out.wr_ch_ != -1) popen_->stream_.write_to_parent_ = out.wr_ch_;
if (out.rd_ch_ != -1) popen_->stream_.read_from_child_ = out.rd_ch_;
}
inline void ArgumentDeducer::set_option(environment&& env) {
popen_->env_ = std::move(env.env_);
}
// etc, etc...
This all is very nice, but also very tedious. You can implement it as part of your library to be friendly to your users, but most people won't be bothered to go to that lengths. What about some support from our language? Let have a look at the shiny new C++ standard (most of us aren't allowed to use yet...):
In C++20 we can employ the following hack** that is using C99's init designators:
struct Named
{
int size; int defaultValue; bool forced; bool verbose;
Named() : size(0), defaultValue(0), forced(false), verbose(false) {};
};
void foo(Named);
void bar()
{
foo({ .size = 44, .forced = true});
}
Discussion: OK, this just looks like a hack, sorry! We could as well use a JSON literal as input parameter and circumvent the normal C++ function parameter mechanism altogether:
foo({ "size": 44, "forced": true});The difference is that the Named-hack will result in members passed in registers, and JSON-hack won't. Unfortunately, the latter is more readable, and that's why we are doing all that in first place! 😞
The language proposal
As so often with C++, the various workarounds don't really cut it. So please, please Mr. Stroustrup, can we have named parameters as a language feature?
As a matter of fact, there's even a "minimal" proposal for this feature:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0671r2.html
but unfortunately, I don't know what it's status is just now... Is there even a possibility to check for status of different standard proposals??? Does anybody know? 🤔 (Please respond in the comments!)
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0671r2.html
but unfortunately, I don't know what it's status is just now... Is there even a possibility to check for status of different standard proposals??? Does anybody know? 🤔 (Please respond in the comments!)
If accepted, we could write in our case:
void bar()
{
foo(size: 44, forced: true);
}Another example taken from the proposal:
gauss(x: 0.1, mean: 0., width: 2., height: 1.);
Here you can see the benefits of that feature in its entirety as all the parameter passed to the gauss() functions are floats!!!
AFAIK). What can I say - this just fits nicely in the more general notion of legendary user-unfriendliness of C++... 😞 To cheer everybody up - a classic: "but... we have ranges!".
Update
Reading the "2021 C++ Standardization Highlights" blogpost*** I stumbled upon following formulation:
"Named Arguments Making a Comeback?
While it has not yet been officially submitted as a P-numbered paper, nor has it been reviewed by EWG, I’ve come across a draft proposal for named arguments (in this formulation called designated arguments) which was circulated on the committee mailing lists (including the public std-discussion list); there’s also an accompanying video explainer.
This looks to me like a thorough, well-researched proposal which addresses the concerns raised during discussions of previous proposals for named arguments ..."
So maybe there's hope after all? Never say never!
--
Blogpost: http://templated-thoughts.blogspot.de/2016/03/sub-processing-with-modern-c.html** source: https://twitter.com/jfbastien/status/941740836135374848 -> "Actually you don't even need to repeat "Named". The wonderful ({ .params }) style!"
*** found here: https://botondballo.wordpress.com/2022/01/03/2021-c-standardization-highlights/. the referenced quasi-proposal is: "D2288R0 Proposal of Designated Arguments DRAFT 2" to be found at Google Docs here.
