On Wed, Jun 12, 2024 at 12:24 AM Michael Wong <fraggamuffin@gmail.com> wrote:
Hi, this SG14 meeting will focus on Games.
We have a few papers on our docket this month.
New Finacne SIG chair
1. An Allocator-Aware inplace_vector
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3160r1.html
2. P3282 "Static Storage for C++ Concurrent bounded_queue"
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3282r0.html
3. P2966R0 – Making C++ Better for Game Developers: Progress Report  
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2966r1.pdf

4.https://isocpp.org/files/papers/P3313R0.html
 
Michael Wong is inviting you to a scheduled Zoom meeting.
Other then Patrice's ongoing Games paper, are there ny other discussions?

Topic: SG14 monthly
Time: 2nd Wednesdays 02:00 PM Eastern Time (US and Canada)
    Every month on the Second Wed,

Join from PC, Mac, Linux, iOS or Android:
https://iso.zoom.us/j/93151864365?pwd=aDhOcDNWd2NWdTJuT1loeXpKbTcydz09
    Password: 789626

Or iPhone one-tap :
    US: +12532158782,,93151864365# or +13017158592,,93151864365#
Or Telephone:
    Dial(for higher quality, dial a number based on your current location):
        US: +1 253 215 8782 or +1 301 715 8592 or +1 312 626 6799 or +1
346 248 7799 or +1 408 638 0968 or +1 646 876 9923 or +1 669 900 6833
 or 877 853 5247 (Toll Free)
    Meeting ID: 931 5186 4365
    Password: 789626
    International numbers available: https://iso.zoom.us/u/abRrVivZoD

Or Skype for Business (Lync):
    https://iso.zoom.us/skype/93151864365

Agenda:

1. Opening and introduction

ISO Code of Conduct
<
https://isotc.iso.org/livelink/livelink?func=ll&objId=20882226&objAction=Open&nexturl=%2Flivelink%2Flivelink%3Ffunc%3Dll%26objId%3D20158641%26objAction%3Dbrowse%26viewType%3D1
*>*

ISO patent policy.
https://isotc.iso.org/livelink/livelink/fetch/2000/2122/3770791/Common_Policy.htm?nodeid=6344764&vernum=-2

IEC Code of Conduct:

https://www.iec.ch/basecamp/iec-code-conduct-technical-work

WG21 Code of Conduct:

https://isocpp.org/std/standing-documents/sd-4-wg21-practices-and-procedures

1.1 Roll call of participants
 
Ville, Andrew  Kostur, Andrew Drakeford, Brad Larson, Bryan St. Armour, Detlef Vollman, Gianluca Delfino, Jonas Persson, Matthew Butler, Pablo Halpern, Patrice Roy, Paul Bendixen, Sebastien Starosz, Michael Caise, Guy, Arthur, Michael W

1.2 Adopt agenda

1.3 Approve minutes from the previous meeting, and approve publishing
 previously approved minutes to ISOCPP.org

1.4 Action items from previous meetings

2. Main issues (125 min)

2.1 General logistics

2024 planning
C++23 and C++26 status
CPPCON SG14
+Guy help
+Bryan ST. Amout, our new Finance SIG chair 

Future and past meeting plans

* Jan 10, 2024 02:00 PM ET: Games DONE
* Feb 14, 2024 02:00 PM ET: Embedded DONE
* Mar 13, 2024 02:00 PM ET: Cancelled due to Tokyo 3-18-23
* Apr 10, 2024 02:00 PM ET: Finance DONE
* May 8, 2024 02:00 PM ET: Games DONE
* June 12, 2024 02:00 PM ET: Embedded; St.louis 6-24-29
* July 10, 2024 02:00 PM ET: Finance
* Aug 14, 2024 02:00 PM ET: Games
* Sep 11, 2024 02:00 PM ET: CPPCON Sept 15-20 so cancelled
* Oct 9, 2024 02:00 PM ET: Embedded
* Nov 13, 2024 02:00 PM ET: Cancelled Wroclaw F2F
* Dec 11, 2024 02:00 PM ET: Finance

2.2 Paper reviews
Embedded:
* P3132 Accept attributes with user-defined prefixes
* P3134 Attribute [[asserts_rvo]]
Deterministic Exception for Embedded by James Renwick
https://www.pure.ed.ac.uk/ws/portalfiles/portal/78829292/low_cost_deterministic_C_exceptions_for_embedded_systems.pdf

Freestanding Updates

Games paper review

Arthur's suggestions:
(1) I put in the Slack channel
<https://cpplang.slack.com/archives/C3TK2M6HH/p1703947057425609> a while
ago Clang PR #76596 <https://github.com/llvm/llvm-project/pull/76596>, from
one Max Winkler, apparently in game dev. I don't think the PR stands much
chance of getting merged into Clang; but it might still be of interest to
SG14 folks. The issue description is very long and somewhat detailed, and
then there's more discussion/debate in the comments
<https://github.com/llvm/llvm-project/pull/76596#issuecomment-1872601156>.
(I'd actually be interested in talking to Max, but he doesn't publish his
email address on GitHub and I guess that might be on purpose.)

(2) LEWG will be seeing my P3055 "Relax wording to permit relocation
optimizations in the STL"
<https://quuxplusone.github.io/draft/d3055-relocation.html> in a telecon on
February 20th. (Related blog post.
<https://quuxplusone.github.io/blog/2024/01/02/bsl-vector-erase/>) Might
be interesting to folks who do EASTL-style containers. I'd be interested in
early feedback and/or telecon attendance.


Discussion on Embedded:
Paul's suggestions
The next meeting would then be Embedded and I would be interested in
knowing if people think a module std.freestanding is worth pursuing.
In that context I'd like to get some feedback perhaps already for the
upcoming meeting, if people have started using modules, and if so if it has
brought the promised expectations or if you are holding back if you see any
relevance in modules.

Review latest mailings:
P2532 Removing exception_ptr from the receivers concept
Based on the last meeting and the discussions here.
P2544 C++ Exceptions are becoming more and more problematic
We might want to chime in here.
/Paul
P. S. P2327 de-deprecating volatile received a "consensus" straw poll.


Discussion on Low Latency/Finance topics

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1839r4.pdf





Discussion about Games topics:

 P2388R1 - Minimum Contract Support: either Ignore or Check_and_abort
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2388r1.html>


1. An Allocator-Aware inplace_vector
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3160r1.html
Pablo presenting.
motivating example
pushing small string back to inplace vector
but if we push large strings, it needs to allocate
have space set aside to allocate content of strings
if inplace _vector were not allocator aware, cant we just pass to the elements? yes but it reduces the level of abstraction, and now you have to know about the elements, and it will be error prone
little runtime costs
want fine grain control for embedded/games/performance
allocators are in std lib and interoperate with all containers except std array
inplace_vector doesnt allocate memory but can contain objects that allocate memory, for itself and its contained elements

GD: LEWG gave tepid guidance so wants to seek stronger guidance from SG14 who wants this
some motivation was not presented in LEWG,  like non-PMR example
Yes, we should add that example

PR: space cost is missing, important for embedded? if you dont use the feature, its 0, if you use it, it is the size of the stable allocator

VV: std::allocator is not freestanding? WHat about string in free-standing? but can use a non-standard allocator because std::allocator is a problem for embedded and there is no fallback
attempt here is to make things consistent, but those facilities in the standard dont help me
nested thing that would require full allocators. That demand isn't there when we look at embedded.
It doesn't matter here because we are talking about PMR allocator. It is stateless, 


PB: elaborate on freestandding where you can make your own, not what we are looking in an embedded system, the short one is the array

AO: SF for this, they snap together like legos, but no mention of optional, it is isomorphic, should propose how to solve the problem. They can be disengaged, can hold or not hold an object. When destroyed still needs an allocator (though is it designed to hold optional?) How does that work with inplace_vector (normal vector move assignment allows me to pilfer the RHS) can you show this? move assigning or move constructing element using allocator, if propagation involved, it will just propagate. That would be bad for PMR because some elements will  ... No always use destination allocator. Will clarify, but not a problem. You dont have to erase all on the LHS. CAn do an element by element move

DV: many embedded systems would use inplace_vector but not allocator, it also have a lot of use outside the embedded world. U should look for support also outside of this group.

KE: +1 to DV can use in a lot of the places, having anallocator does not make me not want it, as long as default allocator

VV: AO,the explanation for how a type like this works, and how propagation works in it, is in https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2047r7.html
propagation traits assignment ... destruction prior assignment ... PMRs are not the problem here; our allocator API do not support non-eh behaviour? we dont subset the language; embedded to day is different; ok to have that complexity in a separate type: POCA is always false, AO: but it is what LEWG spends time specifying

 AO: I believe it's feasible to make the skeleton of `std::allocator` freestanding, and just omit the `allocate` and `deallocate` methods. See Ben Craig's recent https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2407r5.html for the standardese.


MC: we dont have EH, this allows me to pay for an expense, the container is super useful in a place that dont have containers
and having inplace_vector vocabulary type is always important
OK to not solve some of the stickier problems.
Get this useful type, then add something else later

PH: IF inplace vector gets in without allocator, then we can do a separate type


Poll: If the embeded issues can be solved, would you be OK with adding the allocator template parameter to inplace vector 
6/8/1/3/0
33/44/6/17/0%
18 voted
In favor

2. P3282 "Static Storage for C++ Concurrent bounded_queue"
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3282r0.html

bounded queues constructor only has the number elements and then allocator, when u have allocator it will use new for it, and it only allocates in its constructor, it never allocate later

added required_size and alignment 
now you can define type alias
giving ptr to constructor

do you like this? its not part of the type whether the object owns the storage or not, object has to remember it internally

KE: unsafe? like span. Preferred API for constructing a bounded queue? I can live with span

AO: looks unsafe, ordered length, ptr, at least switch, seems like 2 features, one change memory footprint to say if I own my memory, static members require alignment. What is alignment of list node? what about the rest? this looks like a major feature trying to get out?
A queue is not a container, its more like a future
in embeded world there is no new, so size must be known at compile time (same with lists, deque) but these allocate all the time at each push whereas this only allocates at construction.


VV: seems to be trying to convey require size. Why 8? its my static storage because I dont know the implementation of bounded queue works.

aiming for SG1 as well. 
Who is in favor of this interface
1/2/5/5/2
7/13/33/33/13%
Not in favor

3. P2966R0 – Making C++ Better for Game Developers: Progress Report  
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2966r1.pdf
Patrice presenting
a spreadsheet of the subpapers will add to Google sheet
so others can add as authors specific papers:
https://docs.google.com/spreadsheets/d/1uCP49gOKZvheLGDZnbliCg50nHMEaxmjqWVLoc-Gz_A/edit?gid=0#gid=0


4. https://isocpp.org/files/papers/P3313R0.html
Khalil presenting
writing my own EH for arm
Function EH rank:
1. no index entry: leaf function
2. inlined index data: inlined into index directly
3. table unwinding instructions: additional data outside of index 
4. GCC LSDA: generic data structure to manage try/catch blocks
GCC uses large data structures for fns with noexcept
include a single except function will poison
GUidance on how to save space
deduce noexcept in functions

PR: conditional noexcept: code gen improvement through tooling.

MC: LTO used? no cant get it to work, mess up my build

MW: what about other platforms? No change expected.

VV: enabling LTO in package build may have caused/or not caused more problems



2.2.1 any other proposal for reviews?



SG14/SG19 features/issues/defects:

https://docs.google.com/spreadsheets/d/1JnUJBO72QVURttkKr7gn0_WjP--P0vAne8JBfzbRiy0/edit#gid=0

2.3 Domain-specific discussions

2.3.1 SIG chairs

   - Embedded Programming chairs: Ben Craig, Wouter van Ooijen and Odin
 Holmes, John McFarlane

   - Financial/Trading chairs: Robin Rowe, Staffan TjernstrÃm
Carl Cooke, Neal Horlock,
   - Games chairs: Rene Riviera, Guy Davidson and Paul Hampson, Patrice Roy

   - Linear Algebra chairs: Bob Steagall, Mark Hoemmen, Guy Davidson

2.4 Other Papers and proposals

2.5 Future F2F meetings:

2.6 future C++ Standard meetings:
https://isocpp.org/std/meetings-and-participation/upcoming-meetings

-

3. Any other business
Reflector
https://lists.isocpp.org/mailman/listinfo.cgi/sg14
As well as look through papers marked "SG14" in recent standards committee
paper mailings:
http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/
http://open-std.org/jtc1/sc22/wg21/docs/papers/2016/

Code and proposal Staging area
https://github.com/WG21-SG14/SG14
4. Review

4.1 Review and approve resolutions and issues [e.g., changes to SG's
working draft]

4.2 Review action items (5 min)

5. Closing process

5.1 Establish next agenda

5.2 Future meeting


* Jan 10, 2024 02:00 PM ET: Games DONE
* Feb 14, 2024 02:00 PM ET: Embedded DONE
* Mar 13, 2024 02:00 PM ET: Cancelled due to Tokyo 3-18-23
* Apr 10, 2024 02:00 PM ET: Finance DONE
* May 8, 2024 02:00 PM ET: Games DONE
* June 12, 2024 02:00 PM ET: Embedded; St.louis 6-24-29
* July 10, 2024 02:00 PM ET: Finance
* Aug 14, 2024 02:00 PM ET: Games
* Sep 11, 2024 02:00 PM ET: CPPCON Sept 15-20 so cancelled
* Oct 9, 2024 02:00 PM ET: Embedded
* Nov 13, 2024 02:00 PM ET: Cancelled Wroclaw F2F
* Dec 11, 2024 02:00 PM ET: Finance