Date: Fri, 10 Sep 2021 13:39:23 +0100
I raised this in P1832R0
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1832r0.html> and
I'm still hopeful that there are implementer solutions to the problem.
There should be no need to force users to step into
someone else code while debugging their own - or incurring all the costs
that this ability incurs. I'm hoping the considerable overhead of ranges
will make this issue more prominent.
On Fri, 10 Sept 2021 at 01:37, Matt Bentley via SG14 <sg14_at_[hidden]>
wrote:
> Since I couldn't attend, a minor note for Patrice's doc, in the
> debug/release scenario:
>
> my take, garnered from watching the various twitter/reddit conversations
> that've cropped up around game dev in c++, is that the main problem is
> the standard and the compilers tend to ignore the fact that many of the
> 'high level' constructs do not optimize at all in debug mode. The
> concept repeated by many is that -O2 will solve things. But for games
> and any other field involving very large executables which require
> running in realtime debug mode, it doesn't.
> It is more of an attitudinal disfunction than an actual technical problem.
>
> Promoting std::fill over memset is one such example.
> Take using std::fill vs memset to zero memory under GCC8:
>
> Results in debug mode (-O0):
> =============================
>
> -----------------------------------------------------
> Benchmark Time CPU Iterations
> -----------------------------------------------------
> memory_filln 87209 ns 87139 ns 8029
> memory_fill 94593 ns 94533 ns 7411
> memory_memset 8441 ns 8434 ns 82833
>
>
>
> Results in -O3 (clang at -O2 is much the same):
> ================================================
>
> -----------------------------------------------------
> Benchmark Time CPU Iterations
> -----------------------------------------------------
> memory_filln 8437 ns 8437 ns 82799
> memory_fill 8437 ns 8437 ns 82756
> memory_memset 8436 ns 8436 ns 82754
>
>
> This is the same in clang. Clang optimizes to memset at -O2, GCC8 at
> -O3. That's a factor of ten difference in speed until you reach -O3.
> Granted memset is very limited in what values it can propagate.
>
> But the way that CPP is often communicated is that, no, you should use
> these high level constructs, not these terrible 'c-style' functions, and
> there will be zero cost - which is not true.
>
> I often see vector naively promoted as being 'a better array' in a
> similar way, which of course it's not, their usages are different.
>
> Ideally students of C++ coming into the industry should understand what
> creates performance - not coming from a viewpoint that high level is
> better, and then having to have those attitudes torn asunder by industry
> vets. The effort to promote C++ as a high level language with zero-cost
> abstractions does not gel with the games industry, or most of the
> industries focussed around performance. My reading on the general
> perception is that the direction which C++ is heading (high level
> abstractions attempting to cater to every scenario) does not match the
> expectations of the workforce.
>
>
> On 9/09/2021 7:57 am, Michael Wong via SG14 wrote:
> > Thanks to Rene for Chairing.
> >
> > On Tue, Sep 7, 2021 at 10:53 AM Michael Wong <fraggamuffin_at_[hidden]
> > <mailto:fraggamuffin_at_[hidden]>> wrote:
> >
> > Topic: SG14 Low Latency Monthly
> >
> > This meeting is focused on Games .
> >
> > Hi,
> >
> > Michael Wong is inviting you to a scheduled Zoom meeting.
> >
> > Topic: SG14 monthly
> > Time: 2nd Wednesdays 02:00 PM Eastern Time 1800 UTC (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
> > <
> 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 <https://iso.zoom.us/u/abRrVivZoD>
> >
> > Or Skype for Business (Lync):
> > https://iso.zoom.us/skype/93151864365
> > <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
> > <
> 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
> > <
> 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
> > <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
> > <
> https://isocpp.org/std/standing-documents/sd-4-wg21-practices-and-procedures
> >
> >
> > 1.1 Roll call of participants
> >
> > 1.2 Adopt agenda
> >
> > 1.3 Approve minutes from 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
> >
> > Future meeting plans
> >
> > July 14, 2021 02:00 PM ET/1800 UTC: Finance/Low Latency
> >
> > Aug 11, 2021 02:00 PM ET/1800 UTC: Games Cancelled
> >
> > Sep 8 , 2021 02:00 PM ET/1800 UTC: Games
> > Oct 13, 2021 02:00 PM ET/1800 UTC: Embedded
> > Nov 10, 2021 02:00 PM ET/1800 UTC: DST change/cancelled
> > Dec 8, 2021 02:00 PM ET/1800 UTC: Finance/Low Latency
> >
> > 2.2 Paper reviews
> >
> > 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>
> >
> > P2388R1:
> > What is stopping static analyzers
> > want to allow programmers to declare good contract annotations in 23
> > so that in 26 tools can have annotations
> > min annotations
> > need from std:
> > portable notatoion
> > type system checking declared expre
> > guarantee that predicates can be rt evaluated if needed
> > ack disappearing side effects in declared expr
> > ack possibility of halting the program
> >
> > ignore mode
> > check and abort: noexcept by default
> > allow compiler to provide a way to install contract violation handler
> > but not require it: how about a compiler flag ?
> > possible to have pre/post-condition in hdr or cpp file: require from
> > first declaration; they are not part of type system
> > builtin unreachable is being standadized
> >
> > side effects in predicates as no way to be sure it is side effect free:
> > allowed but discouraged, may be evaluated, may be evaluated twice
> > ub if evaluation of one affects the other
> >
> > how does it interact with constexpr? constexpr fn with non-constexpr
> > predicate
> >
> > postconditions:
> > eval after destructors of local objects called
> > eval before destructors of function
> > referred objects values are those ...
> >
> > check value of parameter at the point it was passed, so need to make a
> > copy of the parameter in case parameter is changed during execution
> > if copy is made implicitly, then compiler can only optimize copy in some
> > cases by eliding
> > in ignore mode, you can avoid the copy
> >
> > precondition failure reported on caller side, rather then calleebut its
> > not always possible because we can not guarantee
> >
> > dropped from C++20 contracts
> > assertion levels
> > guaranteed non-evaluation of predicates (axiom)
> > continuation mode
> > interface
> >
> > Retained from C++20 contracts
> > contract annotations on first declaration
> > ODR identical annotations on overriding functions
> > access to private and protected members from predicates
> >
> > use case weher you want to widen and narroe the derived class contracts
> > and caller needs to be able to depend on the post condition being true
> > if you want to check you really need to check both the pre and post
> > conditions on the interface fn you call through so if you are calling
> > through a ptr to base , the caller is going to depend on the fact that
> > the post conditions and the pre and post conditions of the ptr you are
> > calling through are checked and the callee is going to depend on the
> > fact that the pre and post conditions it declares are going to be
> > checked. Crrectly checking the right things when they can be different
> > is complicated
> > So MVP approach is just require them to be the same for now and explore
> > what can be done later to be different
> >
> > Not addresign overriding fn issue, then this proposal will survive.
> >
> > Feedback on ignore mode, and const values
> > anything concern you on this approach?
> > in safety critical setting, might not be annotations we want them to be
> > not affecting too deeply the rest of the functions: can make it uniform
> > by referrng to a function input and output by value and are not
> const-able
> >
> > idiomatic constructor with operator plus trick would have to be
> rewritten?
> >
> >
> >
> >
> >
> >
> >
> >
> > Patrice's WIP on Games issues.
> >
> > Making C++ better for Game Developers: some Request
> > based on survey from local Montreal game companies
> > general principles:
> > simplify C++
> > make it teachable due to high turn over
> > avoid negative perf impact
> > debugging matters
> >
> > how to split these 30 proposals?
> >
> > similar to freestanding, chop into many small pieces
> > but also good to have an omnibus paper before the split
> > do a few feature per meeting, or wait until January for the next Games
> focus
> > should address Arthur's feedback and generate V2
> > some are low latency and can be in Dec meeting
> > updates coming
> >
> > Finance topics from July 14, 2021.
> >
> > https://lists.isocpp.org/sg14/2021/06/0636.php
> > <https://lists.isocpp.org/sg14/2021/06/0636.php>
> >
> > https://lists.isocpp.org/sg14/2021/07/0642.php
> > <https://lists.isocpp.org/sg14/2021/07/0642.php>
> >
> > 2.2.1 any other proposal for reviews?
> >
> > 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
> > <
> https://www.pure.ed.ac.uk/ws/portalfiles/portal/78829292/low_cost_deterministic_C_exceptions_for_embedded_systems.pdf
> >
> >
> > Freestanding?
> >
> > SG14/SG19 features/issues/defects:
> >
> >
> https://docs.google.com/spreadsheets/d/1JnUJBO72QVURttkKr7gn0_WjP--P0vAne8JBfzbRiy0/edit#gid=0
> > <
> 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: Staffan
> > TjernstrÃÃâ€
> > ’Ãâ€
> >
> ’¶m,
> > Carl
> > Cooke, Neal
> > Horlock,
> > Mateusz Pusz, Clay Trychta,
> >
> >
> > Richard Smith to take over paper
> >
> > - 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
> > <https://isocpp.org/std/meetings-and-participation/upcoming-meetings
> >
> >
> > -
> >
> > 3. Any other business
> > Reflector
> > https://lists.isocpp.org/mailman/listinfo.cgi/sg14
> > <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/2015/>
> > http://open-std.org/jtc1/sc22/wg21/docs/papers/2016/
> > <http://open-std.org/jtc1/sc22/wg21/docs/papers/2016/>
> >
> > Code and proposal Staging area
> > https://github.com/WG21-SG14/SG14 <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
> >
> > Oct 13, 2021 02:00 PM ET/1800 UTC: Embedded
> >
> > Nov 10, 2021 02:00 PM ET/1800 UTC: DST change/cancelled
> > Dec 8, 2021 02:00 PM ET/1800 UTC: Finance/Low Latency
> >
> > Kind Rgds
> >
> >
> > _______________________________________________
> > SG14 mailing list
> > SG14_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/sg14
> >
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1832r0.html> and
I'm still hopeful that there are implementer solutions to the problem.
There should be no need to force users to step into
someone else code while debugging their own - or incurring all the costs
that this ability incurs. I'm hoping the considerable overhead of ranges
will make this issue more prominent.
On Fri, 10 Sept 2021 at 01:37, Matt Bentley via SG14 <sg14_at_[hidden]>
wrote:
> Since I couldn't attend, a minor note for Patrice's doc, in the
> debug/release scenario:
>
> my take, garnered from watching the various twitter/reddit conversations
> that've cropped up around game dev in c++, is that the main problem is
> the standard and the compilers tend to ignore the fact that many of the
> 'high level' constructs do not optimize at all in debug mode. The
> concept repeated by many is that -O2 will solve things. But for games
> and any other field involving very large executables which require
> running in realtime debug mode, it doesn't.
> It is more of an attitudinal disfunction than an actual technical problem.
>
> Promoting std::fill over memset is one such example.
> Take using std::fill vs memset to zero memory under GCC8:
>
> Results in debug mode (-O0):
> =============================
>
> -----------------------------------------------------
> Benchmark Time CPU Iterations
> -----------------------------------------------------
> memory_filln 87209 ns 87139 ns 8029
> memory_fill 94593 ns 94533 ns 7411
> memory_memset 8441 ns 8434 ns 82833
>
>
>
> Results in -O3 (clang at -O2 is much the same):
> ================================================
>
> -----------------------------------------------------
> Benchmark Time CPU Iterations
> -----------------------------------------------------
> memory_filln 8437 ns 8437 ns 82799
> memory_fill 8437 ns 8437 ns 82756
> memory_memset 8436 ns 8436 ns 82754
>
>
> This is the same in clang. Clang optimizes to memset at -O2, GCC8 at
> -O3. That's a factor of ten difference in speed until you reach -O3.
> Granted memset is very limited in what values it can propagate.
>
> But the way that CPP is often communicated is that, no, you should use
> these high level constructs, not these terrible 'c-style' functions, and
> there will be zero cost - which is not true.
>
> I often see vector naively promoted as being 'a better array' in a
> similar way, which of course it's not, their usages are different.
>
> Ideally students of C++ coming into the industry should understand what
> creates performance - not coming from a viewpoint that high level is
> better, and then having to have those attitudes torn asunder by industry
> vets. The effort to promote C++ as a high level language with zero-cost
> abstractions does not gel with the games industry, or most of the
> industries focussed around performance. My reading on the general
> perception is that the direction which C++ is heading (high level
> abstractions attempting to cater to every scenario) does not match the
> expectations of the workforce.
>
>
> On 9/09/2021 7:57 am, Michael Wong via SG14 wrote:
> > Thanks to Rene for Chairing.
> >
> > On Tue, Sep 7, 2021 at 10:53 AM Michael Wong <fraggamuffin_at_[hidden]
> > <mailto:fraggamuffin_at_[hidden]>> wrote:
> >
> > Topic: SG14 Low Latency Monthly
> >
> > This meeting is focused on Games .
> >
> > Hi,
> >
> > Michael Wong is inviting you to a scheduled Zoom meeting.
> >
> > Topic: SG14 monthly
> > Time: 2nd Wednesdays 02:00 PM Eastern Time 1800 UTC (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
> > <
> 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 <https://iso.zoom.us/u/abRrVivZoD>
> >
> > Or Skype for Business (Lync):
> > https://iso.zoom.us/skype/93151864365
> > <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
> > <
> 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
> > <
> 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
> > <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
> > <
> https://isocpp.org/std/standing-documents/sd-4-wg21-practices-and-procedures
> >
> >
> > 1.1 Roll call of participants
> >
> > 1.2 Adopt agenda
> >
> > 1.3 Approve minutes from 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
> >
> > Future meeting plans
> >
> > July 14, 2021 02:00 PM ET/1800 UTC: Finance/Low Latency
> >
> > Aug 11, 2021 02:00 PM ET/1800 UTC: Games Cancelled
> >
> > Sep 8 , 2021 02:00 PM ET/1800 UTC: Games
> > Oct 13, 2021 02:00 PM ET/1800 UTC: Embedded
> > Nov 10, 2021 02:00 PM ET/1800 UTC: DST change/cancelled
> > Dec 8, 2021 02:00 PM ET/1800 UTC: Finance/Low Latency
> >
> > 2.2 Paper reviews
> >
> > 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>
> >
> > P2388R1:
> > What is stopping static analyzers
> > want to allow programmers to declare good contract annotations in 23
> > so that in 26 tools can have annotations
> > min annotations
> > need from std:
> > portable notatoion
> > type system checking declared expre
> > guarantee that predicates can be rt evaluated if needed
> > ack disappearing side effects in declared expr
> > ack possibility of halting the program
> >
> > ignore mode
> > check and abort: noexcept by default
> > allow compiler to provide a way to install contract violation handler
> > but not require it: how about a compiler flag ?
> > possible to have pre/post-condition in hdr or cpp file: require from
> > first declaration; they are not part of type system
> > builtin unreachable is being standadized
> >
> > side effects in predicates as no way to be sure it is side effect free:
> > allowed but discouraged, may be evaluated, may be evaluated twice
> > ub if evaluation of one affects the other
> >
> > how does it interact with constexpr? constexpr fn with non-constexpr
> > predicate
> >
> > postconditions:
> > eval after destructors of local objects called
> > eval before destructors of function
> > referred objects values are those ...
> >
> > check value of parameter at the point it was passed, so need to make a
> > copy of the parameter in case parameter is changed during execution
> > if copy is made implicitly, then compiler can only optimize copy in some
> > cases by eliding
> > in ignore mode, you can avoid the copy
> >
> > precondition failure reported on caller side, rather then calleebut its
> > not always possible because we can not guarantee
> >
> > dropped from C++20 contracts
> > assertion levels
> > guaranteed non-evaluation of predicates (axiom)
> > continuation mode
> > interface
> >
> > Retained from C++20 contracts
> > contract annotations on first declaration
> > ODR identical annotations on overriding functions
> > access to private and protected members from predicates
> >
> > use case weher you want to widen and narroe the derived class contracts
> > and caller needs to be able to depend on the post condition being true
> > if you want to check you really need to check both the pre and post
> > conditions on the interface fn you call through so if you are calling
> > through a ptr to base , the caller is going to depend on the fact that
> > the post conditions and the pre and post conditions of the ptr you are
> > calling through are checked and the callee is going to depend on the
> > fact that the pre and post conditions it declares are going to be
> > checked. Crrectly checking the right things when they can be different
> > is complicated
> > So MVP approach is just require them to be the same for now and explore
> > what can be done later to be different
> >
> > Not addresign overriding fn issue, then this proposal will survive.
> >
> > Feedback on ignore mode, and const values
> > anything concern you on this approach?
> > in safety critical setting, might not be annotations we want them to be
> > not affecting too deeply the rest of the functions: can make it uniform
> > by referrng to a function input and output by value and are not
> const-able
> >
> > idiomatic constructor with operator plus trick would have to be
> rewritten?
> >
> >
> >
> >
> >
> >
> >
> >
> > Patrice's WIP on Games issues.
> >
> > Making C++ better for Game Developers: some Request
> > based on survey from local Montreal game companies
> > general principles:
> > simplify C++
> > make it teachable due to high turn over
> > avoid negative perf impact
> > debugging matters
> >
> > how to split these 30 proposals?
> >
> > similar to freestanding, chop into many small pieces
> > but also good to have an omnibus paper before the split
> > do a few feature per meeting, or wait until January for the next Games
> focus
> > should address Arthur's feedback and generate V2
> > some are low latency and can be in Dec meeting
> > updates coming
> >
> > Finance topics from July 14, 2021.
> >
> > https://lists.isocpp.org/sg14/2021/06/0636.php
> > <https://lists.isocpp.org/sg14/2021/06/0636.php>
> >
> > https://lists.isocpp.org/sg14/2021/07/0642.php
> > <https://lists.isocpp.org/sg14/2021/07/0642.php>
> >
> > 2.2.1 any other proposal for reviews?
> >
> > 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
> > <
> https://www.pure.ed.ac.uk/ws/portalfiles/portal/78829292/low_cost_deterministic_C_exceptions_for_embedded_systems.pdf
> >
> >
> > Freestanding?
> >
> > SG14/SG19 features/issues/defects:
> >
> >
> https://docs.google.com/spreadsheets/d/1JnUJBO72QVURttkKr7gn0_WjP--P0vAne8JBfzbRiy0/edit#gid=0
> > <
> 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: Staffan
> > TjernstrÃÃâ€
> > ’Ãâ€
> >
> ’¶m,
> > Carl
> > Cooke, Neal
> > Horlock,
> > Mateusz Pusz, Clay Trychta,
> >
> >
> > Richard Smith to take over paper
> >
> > - 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
> > <https://isocpp.org/std/meetings-and-participation/upcoming-meetings
> >
> >
> > -
> >
> > 3. Any other business
> > Reflector
> > https://lists.isocpp.org/mailman/listinfo.cgi/sg14
> > <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/2015/>
> > http://open-std.org/jtc1/sc22/wg21/docs/papers/2016/
> > <http://open-std.org/jtc1/sc22/wg21/docs/papers/2016/>
> >
> > Code and proposal Staging area
> > https://github.com/WG21-SG14/SG14 <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
> >
> > Oct 13, 2021 02:00 PM ET/1800 UTC: Embedded
> >
> > Nov 10, 2021 02:00 PM ET/1800 UTC: DST change/cancelled
> > Dec 8, 2021 02:00 PM ET/1800 UTC: Finance/Low Latency
> >
> > Kind Rgds
> >
> >
> > _______________________________________________
> > SG14 mailing list
> > SG14_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/sg14
> >
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>
Received on 2021-09-10 07:39:38