「view this page in B3 βῆτα server」

Revisions №61032

branch: master 「№61032」
Commited by: Jack Maguire
GitHub commit link: 「cbb227abd9c8ea71」 「№4262」
Difference from previous tested commit:  code diff
Commit date: 2019-11-08 14:48:23

Merge pull request #4262 from RosettaCommons/JackMaguire/StrongTypeAliases Strong Sizes in JD3 `core::Size` is used frequently in JD3 (and Rosetta as a whole) to represent values that are conceptually different types but are all best represented with a simple `int`. Nobody should need to reinvent the `int` wheel every time we need a new integral type. `core::Size` is technically fine for all of these types but its ubiquitousness can lead to logic errors. The goal of this PR is to introduce distinct types for some common integral concepts in JD3. This will hopefully prevent bugs in JD3's already hard-to-understand framework. Here is a good example of this feature being added. Existing code: ```c++ StandardInnerLarvalJobOP create_inner_larval_job( core::Size nstruct, core::Size job_node, core::Size preliminary_job_node ) const; InnerLarvalJobOP create_and_init_inner_larval_job_from_preliminary( core::Size nstruct, core::Size prelim_job_node, core::Size job_node ) const; ``` These are two functions that JobQueen writers might replace with one another as drop-in replacements. If they do that, the compiler will not warn them that they need to _switch the 2nd and 3rd arguments_ because both arguments are core::Sizes. This logic error might not even be caught at runtime because `prelim_job_node` and `job_node` are often the same value for some JobQueens. The logic error might take months to reveal itself (like it did for MultistageRosettaScripts in #4238 ). New code: ```c++ StandardInnerLarvalJobOP create_inner_larval_job( core::Size nstruct, JobDagID job_node, PrelimJobNodeID preliminary_job_node ) const; InnerLarvalJobOP create_and_init_inner_larval_job_from_preliminary( core::Size nstruct, PrelimJobNodeID prelim_job_node, JobDagID job_node ) const; ``` This new code requires minimal boilerplate (thanks to Rocco's suggestions in #4237 ) and would immediately alert developers _at compile time_ when they are using values incorrectly. Performance hits will not be a concern because the compiler completely optimizes this feature away, even in debug mode (see godbolt links in #4237 ).

...