[allocator.adaptor] consolidate memory utilities #683
Conversation
|
Makes sense. Can you rebase? Your change to move compile-time integer sequences conflicts with this one. |
|
If I rebase, is the preference to apply a 'force push' to my fork, as otherwise the histories are incompatible? |
|
@AlisdairM: Yes. Everyone except for cplusplus should only ever rebase and force-push, and never merge. Merging is the sole prerogative of the main fork. |
AlisdairM
force-pushed
the
consolicate_allocators
branch
from
13bd4f8
to
882be33
Compare
|
rebased within the last hour, and force-pushed to my branch - it should land cleanly again. |
|
Waiting for #704 to land before resolving conflicts and rebasing again. |
This patch simply moves the scoped allocator clause to be adjacent to the other memory and allocator clauses for a more consistent sub-organization of clause 20. The patch looks pretty awful thanks to the diff algorithm treating it as a lot of interspersed edits, where in fact is way a single cut/paste for the bulk of the test (plus a second one-liner for the clause 20 table of contents).
AlisdairM
force-pushed
the
consolicate_allocators
branch
from
882be33
to
15a6868
Compare
|
Rebased and pushed again; ready for review. |
|
N.B. The change looks good to me. |
This patch simply moves the scoped allocator clause to
be adjacent to the other memory and allocator clauses
for a more consistent sub-organization of clause 20.
The patch looks pretty awful thanks to the diff
algorithm treating it a lot of interspersed edits,
where in fact is way a single cut/paste for the
bulk of the test (plus a second one-liner for the
clause 20 table of contents).