Thanks John for forwarding it.

On Wed, Feb 14, 2024 at 1:51 PM John McFarlane via SG14 <
sg14_at_[hidden]> wrote:

> ---------- Forwarded message ---------
> From: Michael Wong via SG19 <sg19_at_[hidden]>
> Date: Tue, 13 Feb 2024 at 20:43
> Subject: [SG19] SG14 Feb 14 Monthly call
> To: <sg19_at_[hidden]>
> Cc: Michael Wong <fraggamuffin_at_[hidden]>
>
>
> Topic: SG14 Monthly This meeting is focused on Embedded.
>
>
>
> Hi,
>
> Michael Wong is inviting you to a scheduled Zoom meeting.
>
> 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
>
Michael, Paul Bendixen, Andre Kostur, Arthur O'Dwyer, Ben Craig, Ben Deane,
Brett, Bryan St. Amour, Henry Miller, Jens Maurer, John McFarlane, Lauri
Vasama, Nathan Owen, River, Robin Rowe, Stefano Fiorentino, Michael Caisse.

>
>
> 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
>
> Future and past meeting plans
>
> * Jan 10, 2024 02:00 PM ET: Games
> * Feb 14, 2024 02:00 PM ET: Embedded
> * Mar 13, 2024 02:00 PM ET: Cancelled due to Tokyo 3-18-23
> * Apr 10, 2024 02:00 PM ET: Finance
> * May 8, 2024 02:00 PM ET: Games
> * 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
>
RTTI enhancement, from QT remarks: if we do this, can we do this without
using the unreal, not use and just fix cluncky macros


> * P3134 Attribute [[asserts_rvo]]
>
Arthur working on a patch NRVO attribute on a return statement;
[[clang::nrvo]] return x; // guarantee NRVO here

Paul Bendixen:
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.

might ask Odin
can I write import std , will that give me freestanding? Yes been thinking
about it, if on a FS implementation, yes import std will
but if you are on multi-platform mix with hosted systems, with bare metal,
should get a compile error even if on a hosted tool chain, (this is the
dream). Alistair is also interested in a std FS module by adding an
deprecated attribute that would be hosted attribute.this warns me whenever
I use hosted things

FS roadmap:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2268r0.html
3 papers: utilities, iterators,
optional operator new and feature test macro is all in working draft for 26
P2338 is the working draft now
catchup paper on inout ptr, std span and mdspan
Laurie is working on P2889
Paul has requested to work on assert
because codebases may not work with ssert, so neeed modification
I recently noted that <exception> is mandated for freestanding by
<stdexcept> is not. However <stdexcept> would be nice (actual use of
language exceptions or not aside) as it basically contains vocab types
that are commonly used in libraries like libfmt.?
necause std string is not appropriate at runtime with FS

new concern is reflectionP2996 is all compiele time, has stuff defined in
terms of std vector (which is not in freestanding) due to heap alloc and
exceptions)

Need help with some testing with consteval, constexpr

support for ocntainers? in_place vectors has a lot of stuff supporting FS,
otherwise, array, the other containers all have allocator concept, which
has no way of signalling failure, cant be null as that would break the
world; at runtime, containers need a lot more work or get P0709, or similar
deterministic exceptions, use your own allocator, not std allocator

custom allocator would have to be stack and not heap, or even static global
array

Why not use PM allocator? PMR mostly work except failure when it throws an
exception; using a runtime switchable mechanism is fine

future discussion on allocation in embedded space ? yes its very domain
specific , may be we an only do hooks, we an't say specific technique,
even class based op new/delete can go a long way, default one if you have
exception on, which is kind of a hook
regarding modules, we are using clang 16, module support might get better
later; its compile time heavy

oen thing that might still be missing from FS: FS with senders? Seems Ok?
If u ignore exec facility like GPu, then it explicitly not do memory
allocation, just template magic to build call graph at compile time.
BD has an impl on sender and receiver for embedded (not FS), so use
atomics, arrays, concurrency model is on interrupts, sync wait is never
what you
always need detach because u are going to complete when interrupting
returns, and doing start detached out allocation is more challenging; so u
need to have all embedded allocation techniques that we talked about -
static allocators, stack, nothing from heap
https://github.com/intel/cpp-baremetal-senders-and-receivers

agree sync wait is difficult to work with, now what about the spec? what
goes in there? will it have //FS? No not in the first bit, will need it to
be added to the roadmap, Eric N may be doing it
Stefano Fiorentino is interested to help, please send to ben Craig

what is the status of P2855 change in this one? still using tag_invoke,
member functions are great if you deducing this to make that work, else u
are delaing with value categories the old way





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


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>
>
>
>
>
>
> 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
> * Mar 13, 2024 02:00 PM ET: Cancelled due to Tokyo 3-18-23
> * Apr 10, 2024 02:00 PM ET: Finance
> * May 8, 2024 02:00 PM ET: Games
> * 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
> --
> SG19 mailing list
> SG19_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg19
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>