C++ dynamic code generation based on input parameter

Question

I have the following function:

void scan(DataRow& input) {
    if(input.isRaw()) {
        ...
    }
    if(input.isExternal()) {
        ...
    }
    if(input.hasMultipleFields()) {
        ...
        for(auto& field: input.fields()) {
            if(field.size() == 2) {
                ...
            }
        }
    }

}

The DataRow class has many sub-classes and all the is functions above are virtual.

This function is used to scan several large groups of data rows. For each group, all data row instances will have the same property (e.g., all raw, all external).

So instead of having all these if/else logics in the scan function, I am thinking if there is a way to generate ad-hoc code. For example, now I already know my next group are all raw (or all not), then I can get rid of the first if branch.

In Java, I used to do such kind of things by generating byte code for class and dynamically load the generated class in JVM. I know the same trick does not work for C++ but I have little experience how to do this. Can anyone give some hint? Thanks!

Answer 1

You cannot easily manipulate executable code during runtime. But your question doesn’t look like you’d have to go down that road anway.

You have groups of rows with similar properties and special processing logic for each group. Also, there seems to be a small fixed number of different kinds of groups.

You have all necessary information to split up your code at compile time – “programming time” actually. Split the scan() function into one function for each kind of group and call scan_raw(), scan_external(), etc. accordingly.

This reduces the number of if condition checks from once per row to once per group. As an added benefit the separate scan functions can use the appropriate derived class as their parameter type and you can get rid of the whole isSomething() machinery.

Hm, at this point I’m tempted to point you towards std::variant and std::visit (or their Boost equivalents). That could be a larger refactoring, though. Because when using them you’d ideally use them as a complete replacement for your current inheritance based polymorphism approach.