C++ design : functions with boolean options

Question

I have a question of "good design practices" in C++. I am writing a numerical library in C++11 and I use at lot of metaprogramming and template-based technique. But I have a very basic question :

Consider a function that can have a two very close behaviours excepted an option that can be activated by a boolean flag. I consider only a flag that can be set/unset by the developer and not a flag that can be set/unset at runtime. There are 3 possibilities of design :

---

1) Write two functions with the explicit option in their name :

myFunctionFlag1(...);
myFunctionFlag2(...); 

2) Use a template parameter :

template<bool Flag> myFunction(...);

3) Use a variable parameter :

myFunction(..., const bool flag);

---

In terms of good design practices which solution is acceptable/unacceptable ? If there is a best solution, which one is it and why ? If there is a worst solution, which one is it and why ?

EDIT : for the considered functions the runtime overhead could be considered as negligible, so this is not the most critical point.

EDIT 2 : I know that all the three work. But as my library will have users, it needs to have a reliable/good design.

Is the option 2 common (because it seems to me to be a good compromise) ?

Answer 1

None of the above. Boolean flags are terrible for code readability. If the flag-controlled functionality is sufficiently small that it makes sense to use a single function, then use a single function, but don't use bool as the type of the flag. Instead, use an enumeration with enumerators that have useful names:

enum class MyFunctionMode { EnableFoo, DisableFoo };

void myFunction(..., MyFunctionMode mode);

This pattern makes it easy to understand at the call site what options are being provided to the function. Multiple options may be combined using flags.

Answer 2

My recommendation would be to use the option 1.

Comments:

1. The most simple and clear. It does not have run time overhead.
2. I do not see enough justification (that might be still present if more details are given) for using this approach. It is more complex than option 1.
3. This variant has run time overhead. It can be still used in a non time/CPU critical code. If your function is large (100+ lines), then this variant becomes more attractive,

My 2 cents.