The TWRoute class has various member functions used to first check validity for a change, then apply it. They have fancy names such as:
TWRoute::is_valid_addition_for_tw (two versions);TWRoute::add to add a single job to a route;TWRoute::replace to replace a (potentially empty) range by another (potentially empty) job range.
The two versions of is_valid_addition_for_tw match the respective situation of add (only a single job with a single insertion position) and replace (using ranges).
This code has been sitting peacefully for quite some time now as the overall TW logic is somehow tricky and I've made a point of not touching anything as long as it works. The problem is that whenever we have to twist this logic (yes I mean #547), this sounds like twice the work for hysterical raisins.
I don't really recall why we have two versions, probably made sense at first to start with the easiest situation, then move to another version for the range situation. Now the sure thing is that the single-job variants could definitely be implemented in term of a single call to the range versions. Only overhead I can see would be creating a dummy vector, so would need some benchmarking but probably worth for the sake of simplifying the code.
The
TWRouteclass has various member functions used to first check validity for a change, then apply it. They have fancy names such as:TWRoute::is_valid_addition_for_tw(two versions);TWRoute::addto add a single job to a route;TWRoute::replaceto replace a (potentially empty) range by another (potentially empty) job range.The two versions of
is_valid_addition_for_twmatch the respective situation ofadd(only a single job with a single insertion position) andreplace(using ranges).This code has been sitting peacefully for quite some time now as the overall TW logic is somehow tricky and I've made a point of not touching anything as long as it works. The problem is that whenever we have to twist this logic (yes I mean #547), this sounds like twice the work for hysterical raisins.
I don't really recall why we have two versions, probably made sense at first to start with the easiest situation, then move to another version for the range situation. Now the sure thing is that the single-job variants could definitely be implemented in term of a single call to the range versions. Only overhead I can see would be creating a dummy vector, so would need some benchmarking but probably worth for the sake of simplifying the code.