On 04/10/16 12:41, Jonathan Wakely wrote: > On 4 October 2016 at 10:21, David Brown wrote: >> On 04/10/16 01:48, Martin Sebor wrote: >>> In a recent review Jason and I discussed the style convention >>> commonly followed in the C++ front end to annotate arguments >>> in calls to functions taking bool parameters with a comment >>> along the lines of >>> >>> foo (1, 2, /*bar_p=*/true); > > I like this convention at the call-site, otherwise "true" or "false" > doesn't tell you much and you have to look at the declaration.
Far and away the best solution would be for C++ to support named parameters or named arguments: <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4172.htm> Then you could write: foo(1, 2, bar_p: true); You could also write foo(y: 2, bar_p: true, x: 1) and get the same call. It is always much better if you can put something in code rather than a comment. > > IMHO even better is to not use bool and define an enumeration type, so > the call site has something unambiguous like foo (1, 2, yes_bar) or > foo (1, 2, no_bar). Sometimes that is the case, other times it is inconvenient to have to create a new type just for that purpose. A nice idea would be to extend n4172 so that you could declare foo as: void foo(int x, int y, explicit bool bar_p = true); This would mean that you could call foo as: foo(1, 2); foo(x: 1, y: 2, bar_p: true); foo(y: 2, bar_p: true, x: 1) foo(1, 2, bar_p: true); but /not/ as foo(1, 2, true); as the "explicit" would mean that you can /only/ use a named parameter here. <snip> >> >> If >> it is relevant, perhaps because you want to emphasize a particular path >> for speed, then a comment might be useful - but it is better to use code >> (like __builtin_expect) than comments. Comments make it easy to be >> inconsistent, and are unnecessary when the same information is easily >> available by looking at the header (modern IDE's make that quick). > > That's not very relevant if GCC developers don't use modern IDEs :-) > A few years ago, people would have thought the same about a suggestion to move gcc development to C++ !
