Codechange: use vector with struct for string parameter backups

[rubidium42]

Motivation / Problem

Use of two or three parameters to retain the backup, and as such making it harder to generalize.
Furthermore the use of stredup and the associated manual memory management.

Description

Add StringParameterBackup struct that contains either a uint64_t or std::string, a std::vector for it and the needed functions for it to create a backup or restore it.
Convert the different users of the parameter backups to the new type/functions.
Remove the old functions.

Limitations

None that I can think of, except a bit more memory usage. But in the end, when next PRs get merged safer and simpler code differentiating between strings and integers.

Checklist for review

Some things are not automated, and forgotten often. This list is a reminder for the reviewers.

• The bug fix is important enough to be backported? (label: 'backport requested')
• This PR touches english.txt or translations? Check the guidelines
• This PR affects the save game format? (label 'savegame upgrade')
• This PR affects the GS/AI API? (label 'needs review: Script API')
  • ai_changelog.hpp, gs_changelog.hpp need updating.
  • The compatibility wrappers (compat_*.nut) need updating.
• This PR affects the NewGRF API? (label 'needs review: NewGRF')
  • newgrf_debug_data.h may need updating.
  • PR must be added to API tracker

[nielsmh]

I could be slightly worried that introducing the variant type could be a performance problem, depending on how often it would be used. Some strings are certainly queried a lot.

Another thought: Combine the string id with its parameter vector, as well as an (optional) cached formatted version of the string, and the language the string was formatted with (for invalidating the cache). It would use more memory, but could avoid a number of string formatting calls.
(It could also result in stale strings in a few situations, e.g. if stations or vehicles are renamed, which might be difficult to catch.)

[rubidium42]

I could be slightly worried that introducing the variant type could be a performance problem, depending on how often it would be used. Some strings are certainly queried a lot.

I wouldn't know; it's only for cases where an actual backup of the string parameters is made, that is restored at some later point (tooltip, news, errors). Would having a struct with std::optional<uint64_t> data and std::optional<std::string> string be much better? That feels like way more boilerplate code that needs to be written to achieve approximately the same, while using more memory.

Another thought: Combine the string id with its parameter vector, as well as an (optional) cached formatted version of the string, and the language the string was formatted with (for invalidating the cache). It would use more memory, but could avoid a number of string formatting calls. (It could also result in stale strings in a few situations, e.g. if stations or vehicles are renamed, which might be difficult to catch.)

I'm not sure whether that's going to work nicely when there are multiple format calls with different string ids with the same parameter vector. See for example the news code.

[rubidium42]

So essentially the question is: is master...rubidium42:string-backup-struct better or worse than this PR?

[rubidium42]

Changed this over to the struct variant over std::variant variant (master...rubidium42:string-backup-variant)

[PeterN]

Magic 20, presumably that's just some limit that was set elsewhere before.

[rubidium42]

Yes, error.h:34/35 to be precise. In the end only the needed amount of parameters should be copied, but that's for later.

[PeterN]

Magic 10, as above I suppose.

[rubidium42]

Yes, misc_gui.cpp:1101 to be precise.