Introduction

This article deals with the use of bool in C++. Should we use it or not? That is the question we will try to answer here. However, this is more of an open discussion than a coding rule.

First of all, what is the bool type? A boolean variable is a variable that can be set to false or true.

Imagine you have a simple function to decide whether or not to buy an house, you may design it like this

Problems arrived!

Then, when you want to use it, you can do it like this:

There is no problem here, however the reader may not understand at first glance if the false means no pools, or if it means no energy saving lights.

So, you will try to change the function call like this:

Now you are happy, the reader knows exactly what bool means. Are you sure? A very thorough reader may notice that there is a reversal of the parameters.

How to solve the problem?

There is different ways to solve this type of problem. The first is to use a strong_type. There are many libraries that offer this kind of thing, however, a simple enum class can do the trick.

Not only will the reader know which argument corresponds to which parameter, but also, in the case of a parameter inversion, the compiler will not let the error pass

Let’s rewrite the function declaration:

Conclusion

I would encourage people not to use the bool type for function parameters. What do you think? Do you use bool everywhere?

Thanks for reading !

Previous PostHaving fun with Detection idiom and macros in C++

11 thoughts on “Stop using bool in C++ for function parameters !”

1. Zen
   August 11, 2022 at 2:12 pm

   Awesome article!

   Reply
2. artcats
   August 12, 2022 at 7:36 am

   Agreed! You should use bit fields for this kind of thing!

   Reply
   1. Antoine MORRIER
      August 12, 2022 at 8:42 am

      Would you like to provide an example using bitfields ?

      Reply
3. ctarsoaga
   August 12, 2022 at 9:05 pm

   awful advice. This has nothing to do with enums or bools. Your problem is that you are using const literals instead of symbolic names.

   Reply
   1. Antoine MORRIER
      August 13, 2022 at 7:25 am

      Hello !
      Thanks for comment
      Maybe I should have been less “rude” on the “don’t use bool…” Because as a developer you should not be dogmatic.

      That being said, your advice is the same as mine, without typing. So it is less safe

      Reply
      1. kcris
         August 13, 2022 at 12:16 pm

         Hi,
         the fact that the title makes it look as if the article deals with a bool specific problem is one thing.5

         The worse is that you are dealing with two problems, both real, both having nothing to do with bools.

         problem #1: a literal value does not convey semantics. If I use 3.14 are you sure it’s PI that I want or maybe some other value that might be 3.14? I case of booleans/true/false this is way more obvious.

         So if you just say
         const bool somethingWithAMeaning = true; //solves problem #1

         the name describes the intention. This is an issue even if you have a single variable. It has nothing to do with strong typing nor with problem #2.

         Problem #2: what happens if you have multiple variables of the same type being passed as params. There, yes, you can a different strong type for each one to solve it. If you ask me, that is NOT why I would choose a strong type (I would choose a strong type to make sure that everywhere in my program, not only inside a params list, I cannot pass the wrong type). And by the way, unless you want to go paranoid, you will not create a strong type for each param. That does not make sense. A type too has a meaning. It is not associated with a symbolic name, which is what I think is the main issue here.

         So no, I am not advising strong types for this use case. Nor enums.

         Reply
         1. Antoine MORRIER
            August 13, 2022 at 9:26 pm

            Hello,
            For the problem 1, I’d say that I agree with you. There is a codingrule we defined with my team mates that is : “No magic number!”
            So yes, in general, this is more than enough to do so.

            For the problem 2, I’d say I agree with you again, you, indeed, I would not create strong type(or enum class) only for parameters. As you said, I would use them in my whole code to be sure that there is no type mismatch during the use of my library or other. Maybe the idea I wanted to share was not what I intended to do.

            I agree too about the fact that it is not a problem related with bool, however, in the code base I have worked on, it is on the type bool that such issue appeared the most.
            But well, in the globality, I agree with you :).

            Reply
4. Al
   August 13, 2022 at 8:32 pm

   You have exactly the same problem with any repeated types, not just bool. E.g. a rendering function taking a clipping window (x,y) as int; or was that (rows, cols)? Or (y,x)?

   Reply
   1. Antoine MORRIER
      August 13, 2022 at 9:29 pm

      Hello, sorry for the late answer.
      Yes I totally agree, in this case, you may use also strong type, but for just “coordinates”, I would go with a structure and designated initializers instead of strong type ;).

      Reply
5. Al
   August 13, 2022 at 8:46 pm

   My last post doesn’t seem to have been published. Anyway, you have the same problem with any set of parameters of the same type. Was that clipping function (x,y), (y,x) or maybe (row, column)?

   Anyway, the bitfield solution is an acceptable idiom; shouldbuyhouse(SWIMMINGPOOL & ~LIGHTS), or a more complete idiom is described here: https://isocpp.org/wiki/faq/ctors#named-parameter-idiom

   Reply
   1. Antoine MORRIER
      August 13, 2022 at 9:31 pm

      Hello,
      I must accept each comment one by one, because I got too much comment “spam” recommanding porn web site or other things like that…

      Considering the bitfield, I think it is clearly a good way to use it, however, I’d go with a or instead of a and

      Reply