Lists of function call arguments

Another thing not expressible in C++ are lists of arguments to functions, but curiously enough, lists of arguments to templates are actually expressible in a limited way.

Whenever I have referred to inexpressible things, what I have meant is that one loses the help from the compiler to keep track of details it should be able to keep track of, one is forced to do it manually, even resorting to very dangerous copying and pasting.

I’ve just read in the e-zine “Overload” number 130 the QM Bite on boolean parameters. The author points out three issues with boolean parameters, for example’s sake, let’s say a function that takes three flags to construct a font: bold, italic, underlined.

Without any more information, can you tell what does this fragment of code does?

auto userFont = createFont(12, false, true, false, true);

What about this other fragment?:

auto userFont = createFont(12, FontOptions().italic().underlined());

In this article we will work towards implementing a building block that will let us transform lists of boolean arguments into a call as the one just portrayed.

The author of the QM Bite (Matthew Wilson) objects to boolean parameters. The three issues he mentions are:

1. Since they all have the same time, it is easy to to try to set boldness but make a mistake and set italic instead (you’d have to remember the exact position of each parameter)
2. It will be difficult to ever change the order of the arguments, change their number, etc.
3. The arguments obfuscate the code, to see what a true as argument means, the reader needs to jump to the declaration of the argument, manually count how many positions.

I would add a fourth complaint: The quantity of arguments must be minimized, the fewer the number of arguments, the easier to understand, manage what a function does. It improves quality.

Since lists of function call arguments are not expressible, try to avoid passing individual parameters, instead, group them together into sets. As always, the members of the set must be highly cohesive. If you do this right, then you’d have an abstraction improvement that will accelerate your development.

Continuing with the example by Matthew Wilson, imagine you capture the flags from the user: Preserving the list of arguments, there is no recourse but to manually copy the values of each of the flags every time something needs propagating. This makes no sense, it is clear that bold, italic, underlined, strike-through, etc. are a set of configuration options. Implement them exactly like that.

I think Mr. Wilson’s advice is no good, “enumeralization” won’t help you any: You incurr the extra work to create synonims of the type bool (which is not easily supported in C++ either), and you continue to have the problems of remembering the exact order of the arguments, the same inflexibility as to their quantity, etc. All you have helped yourself with is for the compiler catching when you accidentally set, for example, bold when italics was intended, a dubious trade for the extra work.

Here’s a hopefully better solution, if we could get for free the following code, the implementation of the set of options:

struct FontOptions {
    enum Options: unsigned char {
        UNMODIFIED = 0,
        BOLD = 1,
        ITALIC = 2,
        UNDERLINED = 4,
        STRIKE_THROUGH = 8
    };

    unsigned char value = 0;

    FontOptions() = default;
    FontOptions(const FontOptions &) = default;

    FontOptions unmodified() const { return FontOptions(0); }
    FontOptions bold() const { return value | BOLD; }
    bool is_bold() const { return value & BOLD; }
    FontOptions not_bold() const { return value & ~BOLD; }
    FontOptions italic() const { return value | ITALIC; }
    bool is_italic() const { return value & ITALIC; }
    FontOptions not_italic() const { return value & ~ITALIC; }
    FontOptions underlined() const { return value | UNDERLINED; }
    bool is_underlined() const { return value & UNDERLINED; }
    FontOptions not_underlined() const { return value & ~UNDERLINED; }
    FontOptions strike_through() const { return value | STRIKE_THROUGH; }
    bool is_strike_through() const { return value & STRIKE_THROUGH; }
    FontOptions not_strike_through() const { return value & ~STRIKE_THROUGH; }

    // The usual equality, difference operators, perhaps even the relational
    // not implemented for brevity of exposition

private:
    FontOptions(unsigned v): value(v) {}
};

then creating a font could have this signature: Font createFont(unsigned size, FontOptions options). And it could be called like this:

auto myFont = createFont(12, FontOptions().italic().underlined());

As you can see, instead of suffering of problems mentioned, this example:

• shows how easy it is to understand exactly what are the options set,
• there is no need to remember the order,
• introducing new options won’t even necessarily require recompilation, and in particular no code change,
• and should you want to change the meaning of any of the options, a simple grep of the desired setter will tell you reliably all the call sites so that you change accordingly.

Very probably inside the Font implementation you’d want to have a set of options. You could use ‘FontOptions’ exactly as it is inside Font. You could communicate internally the whole set of options using FontOptions. It is useful.

Observe that the implementation of FontOptions is very repetitive. And incomplete, since the constructors, setters, etc, are not constexpr noexcept, there is no operator for comparison, etc; it is error prone too, at any moment one could have written ‘italic’ meaning ‘bold’. These things are best left to something automated. Unfortunately, we begin with a list of identifiers (bold, …) and as already explained in the previous article, there is no support in pure C++ for them; we have turned the inexpressible function call argument list into a list of identifiers, thus, as done in the previous article, the next best choice is to use preprocessing:

#include <boost/preprocessor/seq/for_each_i.hpp>
#include <boost/preprocessor/cat.hpp>

#define PP_SEQ_I_DECLARE_ENUMERATION_VALUE(r, dummy, i, e) e = (1 << i),
#define PP_SEQ_I_FLAG_SET_MEMBER_FUNCTIONS(r, name, i, e)\
    constexpr name e() const noexcept { return value | internal::e; }\
    constexpr name BOOST_PP_CAT(not_, e)() const noexcept { return value & ~internal::e; }\
    constexpr bool BOOST_PP_CAT(is_, e)() const noexcept { return value & internal::e; }

#define BOOLEAN_FLAG_SET(name, flags)\
    class name {\
        struct internal { enum: unsigned char {\
            EMPTY = 0,\
            BOOST_PP_SEQ_FOR_EACH_I(PP_SEQ_I_DECLARE_ENUMERATION_VALUE, ~, flags)\
        }; };\
        unsigned char value = 0;\
        constexpr name(unsigned v) noexcept: value(v) {}\
    public:\
        name() = default;\
        name(const name &) = default;\
        BOOST_PP_SEQ_FOR_EACH_I(PP_SEQ_I_FLAG_SET_MEMBER_FUNCTIONS, name, flags)\
        constexpr bool operator==(name other) const noexcept { return value == other.value; }\
        constexpr bool operator!=(name other) const noexcept { return !(*this == other); }\
    }

The use of the macro BOOLEAN_FLAG_SET is very easy, for example:

BOOLEAN_FLAG_SET(FO, (bold)(italic)(underlined)(strike_through));

This would declare and define a class FO that does the same things as FontOptions. I hope you’d agree that declaration and definition takes very little effort and prevents lots of errors. Also, we could improve this so that we also get inserter and extractor operators with minimal effort.

Before explaining the implementation, as a conclusion to this article, I advocate for the following:

• Because there is no support for list of arguments, avoid them
• Strive to minimize the number of arguments in your function calls
• Grouping parameters into a single aggregate tends to capture useful semantics of the application domain that will speed up development and improve quality
• Pure C++ offers limited support for expressing the groups of parameters identified, typically, the preprocessor may palliate this defficiency.

The same technique illustrated in this example can be generalized for arbitrary collections of parameters; for example, to build a date:

Date().month(FEBRUARY).year(2015).day(28)

That is, the same pattern can be used but the setters may take a value argument. Expressing the type of these arguments make the macro more complicated, hence its exposition will be postponed.

Also, there is no need to worry about returning by value and potentially doing wasteful copies of returned values, observe that the compiler has full visibility into what is going on, all the intermediate values are temporaries, and the “return value optimization” can be applied recursively from last to first (in this case from calling day back to Date()); hopefully this will be illustrated in the real world. Also notice that this pattern of acting on a value and not changing it but returning a modified copy is a tried and true technique in functional programming languages.