No objections to previous minutes
No action items from prev meeting

Cppcon:
will go ahead, online/offline ratio undecided
sg14 face to face cppcon will not happen, will have regular online
meetup instead
submissions still (sort of) open
reviewers for papers for embedded track appreciated

Future CPP standard meetings:
ISO & Insights have put face-to-face meetings on hold for moment
Currently moratorium on forwarding papers on, but may not continue due
to length of covid lockdowns


Papers:

Colony:
Wording is progressing with help from Jens
Question around having reserve function - whether necessary:
- not present in deque
- performance detriment when present in previous benchmarks (for full
reserve implementation)
- question whether necessary regarding shifting allocation out of hot
loop code - suggestion that this is solved to an extent via allocators
when this is necessary
- also question around whether is necessary to stop colony from
allocating lots of small memory blocks when the rough number of total
elements is known in advance - suggestion that this is solved by
adjusting minimum block capacities
- suggestion that we can always add this later in standardization process
- inclusion may force necessity of another function to free up unused
memory blocks - as opposed to shrink_to_fit, which is not required to
keep iterators to elements valid
- retaining memory blocks where all elements have been erased - could
be problematic in terms of creating uncertainty for developers as to
whether a memory block is freed
- question for later paper revision - should shrink_to_fit consolidate
container and remove skips, or reallocate elements to maximum capacity
blocks and create best-case cache locality


Question around supplying min/max block capacity limits to
constructors/functions - whether invalid (out-of-range) supplied
limits should be silently corrected, or if functions should
throw/return an error code/some combination of these:
- Constructors can throw anyway, so throwing or defining as UB most logical
- Settle for throwing as more straightforward
- Is skipfield necessary - seems to be for any future implementation
- Nathaniel Niel's suggestion of alternative index - unclear as to
what implementation would be - may get back to Matt later


Affinity:
New paper, 2155, following on from 1436
Summary of changes
Overview:
- p1436  -executor-centric with hints - required knowledge of
abstraction of executor
- Switch to algorithmic-centric properties - describes what freedoms
implementation has, semantics of algorithm
- Can be applied more generically to more executors
- Executor properties + execution policy properties
- Algorithm can execute what user is requesting based on executor's
hardware abstraction
- Definition of 'locality interference' - metric

Jens wording critique:
- should contain editorial instruction that this should apply on top of p0443
- virtual machines/GPU's/explicit hardware descriptions do not fit
within C++ abstract machine, should be moved to proposal
- 'bulk algorithm' concept/word is not existing word in C++ standard,
needs explicit explanation if used
- 'must' too ambiguous, use 'shall'. 'should' similarly cannot be used
- only italicize terms when defining them, not elsewhere
- 'higher constructive interference' not defined, 'hardware
constructive interference' is
- changes/additions to abstract machine potentially affects ability of
compiler to optimize
- work items needs explaining


CPP deterministic exception group: nothing
Embedded: Nothing to report
Financial: nobody present
Games: Linear algebra reviewing next week in LEWG online, BLAS &
operator overload, 1500 UTC monday
Kona is next CPP standards meeting in line

Paul: Is there a face-to-face SG14 in november for MeetingCPP? Unlikely as it will be virtual but may be the next Israel F2F meeting.

 Agenda
item for next meeting.