[GEN][ZH] Fix ThingTemplate copying to prevent mismatch with mod maps and quickstart

[xezon]

• Fixes Mismatches when using -quickstart #856
• Closes [GEN][ZH] Fix ThingTemplate override copy to prevent mismatch with mod map and quickstart #1194

This change fixes #856 and is an alternative implementation to #1194.

TODO

• Replicate in Generals
• Test against replays in VC6

[Caball009]

Is this needed? Unless I'm missing something, I think it'd be better to get rid of this typedef.

[xezon]

This is the imgui style of declaring enums for flags.

The reason for this is that

SparseMatchFinderFlags flags = flagName1 | flagName2;

does not work if SparseMatchFinderFlags is an enum. And it is bad to use int for flag types, because it is more difficult to follow what this flag type is then.

[Caball009]

It would work if you do it inside the enum itself (flags1 = flagName1 | flagName2), which may not be feasible for larger enums, but fair enough.

[Caball009]

Is it necessary to define the constructor?

[Caball009]

Technically we should define a destructor if we're following the rule of 3, but in this case it'd be empty and C++98 doesn't support the default keyword.

[xezon]

There was a compile error when I did not add it. So I added that.

[Caball009]

Shouldn't the copy flag be checked here as well?

[xezon]

It is checked in the assignment operator (which this calls).

[Caball009]

Ah right.

[Caball009]

I think this is a little awkward to have the copy constructor call the copy assignment operator and also potentially slightly inefficient if the data is copied. I'd propose this instead:

SparseMatchFinder(const SparseMatchFinder& other) : 
	m_bestMatches((FLAGS & SparseMatchFinderFlags_NoCopy) == 0 ? MatchMap() : other.m_bestMatches)
{}

[xezon]

If this construction was more simple then I would agree, but I think in this case it is easier to just write the code once for simpler C++ code. std::map does not allocate anything on default construction and there should be no worry about inefficiency - if the function was even called.

[Caball009]

The code looks alright. I can verify tomorrow whether the original issue is still fixed, although I don't see no reason why that wouldn't be the case.

I hope someone can run this against a large number of replays.