Added const references to various function parameters

[Rubonnek]

This pull request adds a small enhancement by avoiding copying data when unnecessary and mitigates the following cppcheck messages:

[sim/src/ConfUtils.cc:41]: (performance) Function parameter 'val_' should be passed by reference.
[sim/src/ConfUtils.cc:42]: (performance) Function parameter 'newsection_' should be passed by reference.
[sim/src/ConfUtils.cc:42]: (performance) Function parameter 'comment_' should be passed by reference.
[sim/src/ConfUtils.h:40]: (performance) Function parameter 'val_' should be passed by reference.
[sim/src/ConfUtils.h:41]: (performance) Function parameter 'newsection_' should be passed by reference.
[sim/src/ConfUtils.h:41]: (performance) Function parameter 'comment_' should be passed by reference.
[sim/src/str_list.h:96]: (performance) Function parameter 'sep' should be passed by reference.
[sim/src/simulate.h:308]: (performance) Function parameter 'time_unit' should be passed by reference.
[sim/src/simulate.h:354]: (performance) Function parameter 'time_unit' should be passed by reference.
[support/src/run_every.h:55]: (performance) Function parameter '_body' should be passed by reference.

[chardan]

If these "Id" types are actually just ints, you're probably better off passing them as const values rather than const references.

[Rubonnek]

Thanks for pointing it out, but ClientId is not a primitive type.

[chardan]

No problem-- the other thing I should point out after I hem and haw with myself is that with const& in tricker situations (like here, where I wrongly assumed it was as per the definition at "https://github.com/Rubonnek/dmclock/blob/41d97df5493b23bcbb8c3aaf53934231c82e48e4/sim/src/sim_recs.h"), any errors will be on the side of good. ;-)

[Rubonnek]

Welp, now I think you are right. I first saw the ClientId when I scanned the whole ceph repository with cppcheck which included this dmclock repository. I thought ClientId was also defined as a struct here, but it's not, it's just what you pointed out.

I also didn't notice the inconclusive flag from cppcheck. That usually brings up false positives and this change is included with that flag.

Thanks for the review! I'll drop these changes, and the other inconclusive ones.

[chardan]

Glad to be of help!

[chardan]

Same here with a function pointer. As a general rule if you're using small/built-in types (ints, chars, iterators, etc.) usually it's best to pass them by const value if you in effect want to make a copy.

[Rubonnek]

I understand, but std::function is not the same as a function pointer as far as I know. They are similar indeed, but a pointer cannot hold data other than the address it points to. An std::function can copy the function which this const reference will avoid if its not necessary.

[chardan]

std::function<> is a bit of a magical beast, as you're right, it's not the same as a function pointer. Instead, it's wrapping a Callable. I looked into this in more detail, and the answer is interesting: the code generated for a function pointer or reference-to-lambda is impressively concise. So the real question is "what happens when we copy a std::function that's pointing to some big Callable object" and the answer is... it will have to do the right thing and make a copy. Which could be expensive.
So, one of two things needs to happen in that case: either the object needs to be moved, or the cost of that copy is something that's expected. So, you're right: if you want to avoid that happening at all, passing by const& looks like the way to go! Thanks for giving me the opportunity to look into it more.

[Rubonnek]

Anytime! And thanks for the explanation! I was going to do that myself since I really didn't recall the details.

[chardan]

+1