Thanks to everyone who participated; it was a good and instructive meeting!

Le mer. 13 avr. 2022 à 16:15, Michael Wong via SG14 <sg14_at_[hidden]>
a écrit :

>
>
> On Tue, Apr 12, 2022 at 10:02 PM Michael Wong <fraggamuffin_at_[hidden]>
> wrote:
>
>> Topic: SG14 Low Latency Monthly This meeting is focused on Low Latency/
>> Finance.
>>
>>
>> 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
>> 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
>>
> Staffan Tjernstom, Andrew Lumsdaine, Ben Saks, Guy Davidson, Henry Mille,
> Jens Maurer, Patrice Roy, Rene Riviera, Ronen Friedman, Michael Wong, Timur
> Doumler
>
>
>>
>>
>> 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
>>
>> *Apr 13, 2022 02:00 PM ET/1800 UTC: Finance/Low Latency
>> *May 11, 2022 02:00 PM ET/1800 UTC: Games
>> *June 8, 2022 02:00 PM ET/1800 UTC: Embedded
>> *Jul 13, 2022 02:00 PM ET/1800 UTC: Finance/Low Latency
>> *Aug 10, 2022 02:00 PM ET/1800 UTC: Games
>> *Sep 12, 2022 02:00 PM ET/1800 UTC: Embedded
>> *Oct 12, 2022 02:00 PM ET/1800 UTC: Finance/Low Latency
>>
>> 2.2 Paper reviews
>> Discussion on Embedded:
>> 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
>>
> presented by Timur
> hard to access byte of object, not type punning which affects aliasing
> char can alias any other type, not undefined.
> char -> int, value does not fit in a char, can chop pointer, which can be
> undefined behaviour,
> lots of old code that does reinterpret cast to print the bytes, and this
> was valid until C++17,
> proposal is to un-UB this
> what about launder? it is covered in a section
> 7.4.1 p3 can only access current active member of union
> what happens if it is a null ptr? null_ptr_t with be all 0 on most
> platforms,
> P0137R1 made it into UB, and we think that was just an inadverdant mistake
> while fixing the lifetime
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0137r1.html
>
> How is this affected/different when using std::bit_cast instead of
> reinterpret_cast - if at all? bit_cast is different way, just a wrapper on
> memcpy, here we want to look at the byte as they are in memory. Cool -
> would be good to clarify that in the paper - as far as I can tell so far,
> every bit_cast implementation - when used on pointers at least - seems to
> just effectively do no memcpy and just is equivalent to reinterpret_cast.
>
> ptr to vtable, 4 byte offset issue from Andrew
>
> bit cast gives u fully live object
> memcpy can only copy between object of same type
> no requirement in C++ that random object need to have continuous value
> representation, so should not work for virtual functions or virtual base
> classes - but that is not what the wording saids in p6.1 has a requirement
> for object continguous property - then that could be a bug in the wording
> may need to limit the effect to object that is well behaved - contiguous?
> looking at 7.1.2 green blob of words
> I can confirm that classes with virtual functions are not standard-layout
> classes.
> We have a trait named has_unique_representations that comes close to
> expressing contiguousness in terms of (essentially) having no padding, but
> it's a Library trait :
> https://en.cppreference.com/w/cpp/types/has_unique_object_representations
> In the sense of "I'm unsure if it can be used in a Core language
> discussion"
>
> follow on paper:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1945r0.pdf
> has definition of contiguous bytes of storage, so please add a
> cross-reference
> The reference.. https://eel.is/c++draft/intro.object#8.4
>
>
>
>> Patrice's paper on Making C++ better for game developers.
>>
> V4
> How to proceed with this big paper?
> do we agree with general principles
> - simple teachable C++
> - no negative performance impact
> - debugging matters (fast debug builds) that can be turned off in release
> mode
> (due to high turn over)
> finance care about how the code will run
> ranges, monadic types, futures, a lot more processing embedded in C++ Std
> makes it hard for RTOS, deep call stack of ranges is hard to debug
>
>
> Traits section removed
>
> Compile time computing requested by games
>
> allow overloading by constexpr arguments
> use case is string literal, and runtime produced by character pointer, so
> can we see use case that don't involved string literals
>
> Source location with nameof (C# style) for logging core dump
> Is it compiler or runtime info?
> data members should not be variable unless they are static data members,
> may be object scope
> also having reflection support would be nice
> reflection features should ask SG7, enum inspections
>
> Not going to keep all of this, but remove some and give form to the rest
> of the request
>
> Compile-time string interpolation
> For the runtime a nicer looking syntax that defies the lexing convention
> of C++ is novelty
>
> Determinism: need to know it never allocates from embedded side, with
> static assert to say that might be ok
> also important for audio (but static assert could be error prone)
> and safety critical applications like autonomous vehicles
>
>
>
>
>
> Options:
> Or take option one by one
> take self evident ones first
> removed solved ones
> identify missing pieces
>
>
>
>
>
>
>
>
> .
>>
> On Hive from Matthew Bentley
> I have feedback to share from the final LEWG talk (until next month) -
> will take some time when you're all ready - shouldn't take more than 5
> minutes :)
> Priority parameter has been removed, is biggest news
> Probably right thing to do
>
>>
>> P2300
>> Swift
>>
>>
>>
>> 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>
>>
>> Patrice's WIP on Games issues.
>>
>> Finance topics from July 14, 2021.
>>
>> https://lists.isocpp.org/sg14/2021/06/0636.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
>>
>> Freestanding?
>>
>> 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: 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
>>
>>
>> *Apr 13, 2022 02:00 PM ET/1800 UTC: Finance/Low Latency
>> *May 11, 2022 02:00 PM ET/1800 UTC: Games
>> *June 8, 2022 02:00 PM ET/1800 UTC: Embedded
>> *Jul 13, 2022 02:00 PM ET/1800 UTC: Finance/Low Latency
>> *Aug 10, 2022 02:00 PM ET/1800 UTC: Games
>> *Sep 12, 2022 02:00 PM ET/1800 UTC: Embedded
>> *Oct 12, 2022 02:00 PM ET/1800 UTC: Finance/Low Latency
>>
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>