My working version of the patch has something that has not been our convention, but might make sense to introduce here. It adds struct "_remove" within unit_type struct, and moves "require_advance" in there. The idea is that it should alert any contributors to the fact that no new code should use "require_advance" that's going to be retired (hmm.. maybe "_retire" would be better than "_remove"?)
Thoughts?
alienvalkyrie Reply To cazfi
My working version of the patch has something that has not been our convention, but might make sense to introduce here. It adds struct "_remove" within unit_type struct, and moves "require_advance" in there. The idea is that it should alert any contributors to the fact that no new code should use "require_advance" that's going to be retired (hmm.. maybe "_retire" would be better than "_remove"?) Thoughts?
Might be sensible to make something like this a convention, some general way to mark code-internal things as deprecated; whether that's via moving those things into sub-structs, renaming them accordingly, or adding an attribute (or some other way) is a decision I'd rather leave to the people with more C experience.
The main unit_tech_reqs_iterate() confuses advance pointers and advance number A_NONE.
- Many bugs with A_NONE used as a pointer, or compared against a pointer, fixed
Add iterator macros unit_tech_reqs_iterate() and unit_tech_reqs_iterate_end, and use them instead of accessing unit_type->require_advance directly.
That prepares us for later retire require_advance.