Generating boilerplate code at compile-time

[Kodiologist]

The C++ codebase has a lot of repetitive code, such as in [tt]Item_factory::init[/tt] and [tt]iexamine::*iexamine_function_from_string[/tt]. To me it seems clearly desirable that rather than this being maintained by hand, with all the attendant hassle and bitrot, it be automatically generated at compile-time. Would the maintainers be interested in pull requests to replace this code with (say) Perl or Python scripts that generate it? Any particular guidelines for what such scripts should or should not do?

[kevin.granade]

I’m not sold on generated code being a good idea for things like this. if you can spot specific repetitive functionality to factor out that’s great, but having generation of the boilerplate doesn’t make things more understandable or maintainable (the primary goals of eliminating boilerplate).
On a more practical note, that would create a new build dependency for the project, which I’m extremely against in general.

[Kodiologist]

having generation of the boilerplate doesn’t make things more understandable or maintainable (the primary goals of eliminating boilerplate).

Understandability is subjective, I guess, but it seems like you gain a lot of in terms of maintainability because you no longer have to add, remove, reformat, sort, etc. etc. the entries. They no longer have to be tracked in Git at all. You have to maintain the scripts, but you won’t need to change those nearly as frequently as the code you’d write without them. Likewise it becomes much easier to make big changes, because you can change the script instead of doing regex replacements on the hand-written boilerplate.

On a more practical note, that would create a new build dependency for the project

True!

[haiironosora]

I think that the more you automate a process, the more you lose your understanding and control of what you are doing. I love IDE’s and cant realy stand codeing with just an editor and inputting compile commands by hand unless its some atupid simple test script.

Still, had way too many times something didn’t compile or had stupid bugs because my IDE had some obscure setting or there was something default in some header file that shouldn’t be there… in the end, its always about control and being aware… If you didn’t write parts of your code yourself, you cant know for sure what is abd isn’t going to be in there. You would just spend more than the time you saved on figuring out how to fix broken code if when it goes wrong.

[jcd]

i believe that such a thing will add a new layer of complexity to the codebase, and maybe one more thing that can go wrong, in exchange for (i guess) removing large-ish parts of the current code.

I do dislike the added complexity layer.

Externalizing via json as much of the code as possible for easy modding, might be a better goal.

[Kodiologist]

Externalizing via json as much of the code as possible for easy modding, might be a better goal.

Actually, it is the use of JSON (and plans to expand the use of Lua) that has necessitated much of the boilerplate code I was thinking of, which maps between strings and C++ methods (because C++ has no capacity for introspection, at least by default).

Similarly, there is a great deal of repetitive JSON, and in my opinion writing code to produce it rather than writing the JSON itself would be a better idea. For example, right now, it’s easy to change something about the jackhammer and forget to make a corresponding change to the jacqueshammer.

[kevin.granade]

The main problem with maintainability of this kind of thing is your source code being incomplete until compile time. You’re trying to trace some issue through the code, and you come upon a function that doesn’t exist. unless you happen to know the function is defined in generated code or you happen to ask someone who does in just the right way, you can spend a huge amount of time searching for the thing.
Macro expansion has the same problem, the source code files no longer have all the source.

[CIB]

The lua-wrappers are already auto-generated, so for most intents and purposes we have that already as “part of the build system”(yeah, you can still compile without lua).

I think if you see something where auto-generating code would really improve things, you could just implement a small demo. Makes it much easier to judge than asking such a general question.

Oh and on the general discussion, template functions sadly suffer from the same issue, which is why debug traces involving STL classes are such a pain.

[Kodiologist]

I think if you see something where auto-generating code would really improve things, you could just implement a small demo.

Tempting, but Kevin is clearly against the idea, so it’s probably not worth it.