Date: Sun, 17 Feb 2019 23:41:35 +0000
The reason I figured SG15 was worth poking: I guessed (and I may be wrong about this) that SG15 was the study group where the people (from the tool vendors) who’re most likely to be directly interested in this *are* listening.
I should check the Study Group definitions list, perhaps compilers and debugging aren’t considered “tooling”?
--
Paul “TBBle” Hampson
From: SG14 <sg14-bounces_at_[hidden]> On Behalf Of Arthur O'Dwyer
Sent: Sunday, 17 February 2019 12:09 PM
To: Low Latency:Game Dev/Financial/Trading/Simulation/Embedded Devices <sg14_at_[hidden]>
Subject: Re: [SG14] [EXT] Ideas on debug constexpr functions or other functions that have been 100% removed from the EXE
Scott, it seems that what you're proposing is not a paper specification but rather a new kind of debugging tool with its own debug info and so on — maybe a plugin for MSVC or gdb or something. I think the proper audience to "get interested" in this idea would be a tool vendor, not WG21. WG21 cannot usefully innovate in tool development. WG21 cannot tell tool developers what to build, nor can it magically determine what tools will be useful to real programmers. The only way to see if "constexpr debugging" would be useful is for someone — a vendor or even a hobbyist — to go build this debugging tool and see whether it gets any adoption in the field. If it's really useful, it will get adopted.
In terms of getting MSVC interested: Is Herb Sutter listening to this thread? ;)
(I do recognize that even if a bunch of people are listening, building a new debugger is a humongous and costly task. Let alone building a new kind of debugger. Still, please don't try to enlist SG15 to do your debugger team's sprint planning and product management. Write the product internally and then see if gains traction before proposing it.)
–Arthur
On Sat, Feb 16, 2019 at 6:48 PM Scott Wardle <swardle_at_[hidden]<mailto:swardle_at_[hidden]>> wrote:
Hi Everyone,
I updated the blog entry to have a 2nd example. Now it includes a simple inline wrapper function and how I could see virtual co-processor working. I think would be a fair bit harder but I am mostly out of my depth here anyways. I think me talking about the problem is more important than my idea on the solution. Even just the leaf constexpr-ish function idea is not too bad and might be easier. But it shows the limits of the idea better then my last version.
http://www.swardle.com/sweb/blog5.html
I will see if the SG15 is interested in the idea. It would be nice to know more about the ideas that debugger people are thinking about and how many we can solve the current problem of how bad the debugging experience is in C++.
Scott
On Feb 15, 2019, at 12:41 AM, Scott Wardle <swardle_at_[hidden]<mailto:swardle_at_[hidden]>> wrote:
Hi Paul,
I am in both groups. So I can add SG15 soon. (I wanted to keep an eye on modules and build systems. I didn’t think that maybe debugger should also be in SG15 too.)
Before I do I wanted to add a better example that shows a inline wrapper function that calls a non-inline function. I think a lot of company wrap stl or other standard functions. Mostly they inline wrapper should just go away but some change defaults and parameters. This is a harder example but i think is shows more of what would need to be written.
My own personal thoughts is I am like to find out why this is hard but I might find some cool ideas on how to fix this problem that are easier to implement. We sure could use some idea like this given our current direction.
Scott
On Feb 14, 2019, at 23:55, Paul Hampson <p_hampson_at_[hidden]<mailto:p_hampson_at_[hidden]>> wrote:
I love the idea of a compile-time break-point, for constexpr-evaluated code. That would even work sensibly for maybe-constexpr code, because if you don’t hit it at compile-time, it wasn’t evaluated there for some reason.
I feel like this would be a whole new (and exciting!) branch of compiler research. As has been mentioned, this might be an SG15 thing, for SG14 we’re more focussed (I guess?) on using it than on specifying/standardising it.
I’m not connected with the SG15 group at all, is anyone connected and interested in carrying some of these ideas over there, or bringing in an appropriate joined mail thread? I assume they’ll be joining us on lists.isocpp.org<http://lists.isocpp.org/> at some point in the near future.
--
Paul “TBBle” Hampson
From: SG14 <sg14-bounces_at_[hidden]<mailto:sg14-bounces_at_[hidden]>> On Behalf Of Ben Craig
Sent: Friday, 15 February 2019 1:34 AM
To: Low Latency:Game Dev/Financial/Trading/Simulation/Embedded Devices <sg14_at_[hidden]<mailto:sg14_at_[hidden]>>
Subject: Re: [SG14] [EXT] Ideas on debug constexpr functions or other functions that have been 100% removed from the EXE
Some of the meta-class proposals (and prototypes!) allow for printf style debugging at compile time. I agree that it would be awful nice if I could debug the compile time constexpr things, or step through overload resolution somehow.
From: SG14 <sg14-bounces_at_[hidden]<mailto:sg14-bounces_at_[hidden]>> On Behalf Of Clément Grégoire
Sent: Thursday, February 14, 2019 2:13 AM
To: Low Latency:Game Dev/Financial/Trading/Simulation/Embedded Devices <sg14_at_[hidden]<mailto:sg14_at_[hidden]>>
Subject: [EXTERNAL] Re: [SG14] [EXT] Ideas on debug constexpr functions or other functions that have been 100% removed from the EXE
Hi,
I do agree with what's being said, but I think you will get better feedback if you reach SG15 (tooling group) if not done already!
Cheers,
Clément
Le jeu. 14 févr. 2019 à 08:33, Scott Wardle <swardle_at_[hidden]<mailto:swardle_at_[hidden]>> a écrit :
Thanks for the feedback Paul, I fixed the image VPU0SINCOS.png forgot to upload to my web server.
You have the idea exactly.
There are a lot of different versions of the idea I can think of. I have not written a debugger my self but I have worked with people who have back on ps1. I don’t think the debugger runtime is hard to write. As you can see with the python mixed language debuggers it is not that original or do I think that hard.
The compiler side however I don’t know at all and don’t know how to start work on an idea like this. But as I have never seen any ISO papers on debugging maybe I should write a paper anyways :)
Maybe Paul, you are getting at this. I don’t really talk about parameters in the blog post. Each return value has to be mapped to a load of a bunch of parameters and then a call to the code to debug. I should write something on that. It is more than just the debug version of the code.
Would any of these parameters be non-const if the function is “constexper”? I don’t see how, but if they can be then you would need to load a value into this virtual co-processor memory space not so hard either way.
Scott
> On Feb 13, 2019, at 10:40 PM, Paul Hampson <p_hampson_at_[hidden]<mailto:p_hampson_at_[hidden]>> wrote:
>
> I had a 404'd image about 30% down: https://www.swardle.com/sweb/img/VPU0SINCOS.png<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.swardle.com_sweb_img_VPU0SINCOS.png&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=X0uWc7GSCQVpJqj-LfrZbAy5Vy-EMyme5GbyQodZ5H8&s=A_con8RPxCMPVByykG5YYfhKm_RqC4Gs0DGfu6FItZI&e=>
>
> Thinking about the practicalities of this idea, what if the debug symbol blobs contains unoptimized versions of constexpr, inlined, and other (perhaps #pragma-marked?) functions, which were used for breakpointing? The debug blobs could know that a particular static value is the result of a constexpr call, since the code=>asm mapping must already see something like "call constExpr(X)" => "LOAD accumulator, some constant value". Same for inlining, a function call that maps to something other than a function-call preamble is presumably an inlined function.
>
> Then the debugger could step-through that side-lined code blob, but discard the results (and side-effects?) at the end, and execute the code in the function itself. *Or* it could actually execute the side-lined code, giving you the runtime effect of MSVC's "#pragma optimize(off)" triggered only by placing a breakpoint at a certain point.
>
> Constexpr might be an easier place to start, since we know the side-effects of such a function are limited, and it's really a code->value transform, and they're evaluated down to constants, while inlined and optimised functions are more-arbitrary code->code transforms.
>
> I don't know enough about the internals of debug tables and debuggers to know if this is practical, but it sounds useful for the use-case you've described.
>
> On a side-note, we use mixed C++/Python, and it's a delight when we (occasionally) use the MSVC mixed-mode debugging support for Python, and get mixed Python/C++ stack traces. It sounds like the VPU debugger gave the same thing, so there' definitely mixed-mode debugging traditions around we could leverage.
>
> Not sure if there's a C++ paper in this, probably more of a clang/lld/gdb hackathon opportunity and a nice presentation at CppCon. ^_^
>
> --
> Paul “Hampy” Hampson
>
>> -----Original Message-----
>> From: SG14 <sg14-bounces_at_[hidden]<mailto:sg14-bounces_at_[hidden]>> On Behalf Of Scott Wardle
>> Sent: Thursday, 14 February 2019 12:26 PM
>> To: Low Latency:Game Dev/Financial/Trading/Simulation/Embedded Devices
>> <sg14_at_[hidden]<mailto:sg14_at_[hidden]ocpp.org>>
>> Subject: [EXT] [SG14] Ideas on debug constexpr functions or other functions
>> that have been 100% removed from the EXE
>>
>> Hi Everyone,
>>
>> I was looking through C++ papers and since 2010 (and maybe before) not one
>> iso C++ paper has been submitted on debugging. So maybe now is a good
>> time to think about how we should debug C++ in a new way.
>>
>> To that end I had an idea the other day on debugging and wrote a blog on it
>> and finally posted it. I don’t see how this would effect the standard but it is
>> quality of implementation idea.
>>
>> If we want to constexpr all of the things it would nice if we could printf debug
>> at least. But my idea is maybe we can get the whole debugger to work.
>>
>> Check it out on my blog. http://www.swardle.com/sweb/blog5.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.swardle.com_sweb_blog5.html&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=X0uWc7GSCQVpJqj-LfrZbAy5Vy-EMyme5GbyQodZ5H8&s=IQk0_888aKBOp7QPfhrz4wlbrrsPitUZViQ47AjXtLs&e=>
>>
>> Tell me if you have any feedback (spelling grammar or good counter ideas
>> that shows why the idea is not posable etc...)
>>
>> Scott
>>
>> _______________________________________________
>> SG14 mailing list
>> SG14_at_[hidden]<mailto:SG14_at_[hidden]>
>> http://lists.isocpp.org/mailman/listinfo.cgi/sg14<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.isocpp.org_mailman_listinfo.cgi_sg14&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=X0uWc7GSCQVpJqj-LfrZbAy5Vy-EMyme5GbyQodZ5H8&s=bNMfEt-nwdGg7B0i9XNPOeIN9lPnUoe01JEygcHLbAc&e=>
> [wargaming.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__wargaming.net&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=X0uWc7GSCQVpJqj-LfrZbAy5Vy-EMyme5GbyQodZ5H8&s=itWScybEslu8w7rjoFQLVjtuN375stib-CWz7dRtCGY&e=>]
> EgzO3mXGcK
> This e-mail may contain CONFIDENTIAL AND PROPRIETARY INFORMATION and/or PRIVILEGED AND CONFIDENTIAL COMMUNICATION intended solely for the recipient and, therefore, may not be retransmitted to any party outside of the recipient's organization without the prior written consent of the sender. If you have received this e-mail in error please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Wargaming.net<http://wargaming.net/> accepts no liability for any losses or damages resulting from infected e-mail transmissions and viruses in e-mail attachment. kgzO3mXGcg
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]socpp.org<mailto:SG14_at_[hidden]>
> http://lists.isocpp.org/mailman/listinfo.cgi/sg14<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.isocpp.org_mailman_listinfo.cgi_sg14&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=X0uWc7GSCQVpJqj-LfrZbAy5Vy-EMyme5GbyQodZ5H8&s=bNMfEt-nwdGg7B0i9XNPOeIN9lPnUoe01JEygcHLbAc&e=>
_______________________________________________
SG14 mailing list
SG14_at_[hidden]<mailto:SG14_at_[hidden]>
http://lists.isocpp.org/mailman/listinfo.cgi/sg14<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.isocpp.org_mailman_listinfo.cgi_sg14&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=X0uWc7GSCQVpJqj-LfrZbAy5Vy-EMyme5GbyQodZ5H8&s=bNMfEt-nwdGg7B0i9XNPOeIN9lPnUoe01JEygcHLbAc&e=>
_______________________________________________
SG14 mailing list
SG14_at_[hidden]<mailto:SG14_at_[hidden]>
http://lists.isocpp.org/mailman/listinfo.cgi/sg14
_______________________________________________
SG14 mailing list
SG14_at_[hidden]<mailto:SG14_at_[hidden]>
http://lists.isocpp.org/mailman/listinfo.cgi/sg14
I should check the Study Group definitions list, perhaps compilers and debugging aren’t considered “tooling”?
--
Paul “TBBle” Hampson
From: SG14 <sg14-bounces_at_[hidden]> On Behalf Of Arthur O'Dwyer
Sent: Sunday, 17 February 2019 12:09 PM
To: Low Latency:Game Dev/Financial/Trading/Simulation/Embedded Devices <sg14_at_[hidden]>
Subject: Re: [SG14] [EXT] Ideas on debug constexpr functions or other functions that have been 100% removed from the EXE
Scott, it seems that what you're proposing is not a paper specification but rather a new kind of debugging tool with its own debug info and so on — maybe a plugin for MSVC or gdb or something. I think the proper audience to "get interested" in this idea would be a tool vendor, not WG21. WG21 cannot usefully innovate in tool development. WG21 cannot tell tool developers what to build, nor can it magically determine what tools will be useful to real programmers. The only way to see if "constexpr debugging" would be useful is for someone — a vendor or even a hobbyist — to go build this debugging tool and see whether it gets any adoption in the field. If it's really useful, it will get adopted.
In terms of getting MSVC interested: Is Herb Sutter listening to this thread? ;)
(I do recognize that even if a bunch of people are listening, building a new debugger is a humongous and costly task. Let alone building a new kind of debugger. Still, please don't try to enlist SG15 to do your debugger team's sprint planning and product management. Write the product internally and then see if gains traction before proposing it.)
–Arthur
On Sat, Feb 16, 2019 at 6:48 PM Scott Wardle <swardle_at_[hidden]<mailto:swardle_at_[hidden]>> wrote:
Hi Everyone,
I updated the blog entry to have a 2nd example. Now it includes a simple inline wrapper function and how I could see virtual co-processor working. I think would be a fair bit harder but I am mostly out of my depth here anyways. I think me talking about the problem is more important than my idea on the solution. Even just the leaf constexpr-ish function idea is not too bad and might be easier. But it shows the limits of the idea better then my last version.
http://www.swardle.com/sweb/blog5.html
I will see if the SG15 is interested in the idea. It would be nice to know more about the ideas that debugger people are thinking about and how many we can solve the current problem of how bad the debugging experience is in C++.
Scott
On Feb 15, 2019, at 12:41 AM, Scott Wardle <swardle_at_[hidden]<mailto:swardle_at_[hidden]>> wrote:
Hi Paul,
I am in both groups. So I can add SG15 soon. (I wanted to keep an eye on modules and build systems. I didn’t think that maybe debugger should also be in SG15 too.)
Before I do I wanted to add a better example that shows a inline wrapper function that calls a non-inline function. I think a lot of company wrap stl or other standard functions. Mostly they inline wrapper should just go away but some change defaults and parameters. This is a harder example but i think is shows more of what would need to be written.
My own personal thoughts is I am like to find out why this is hard but I might find some cool ideas on how to fix this problem that are easier to implement. We sure could use some idea like this given our current direction.
Scott
On Feb 14, 2019, at 23:55, Paul Hampson <p_hampson_at_[hidden]<mailto:p_hampson_at_[hidden]>> wrote:
I love the idea of a compile-time break-point, for constexpr-evaluated code. That would even work sensibly for maybe-constexpr code, because if you don’t hit it at compile-time, it wasn’t evaluated there for some reason.
I feel like this would be a whole new (and exciting!) branch of compiler research. As has been mentioned, this might be an SG15 thing, for SG14 we’re more focussed (I guess?) on using it than on specifying/standardising it.
I’m not connected with the SG15 group at all, is anyone connected and interested in carrying some of these ideas over there, or bringing in an appropriate joined mail thread? I assume they’ll be joining us on lists.isocpp.org<http://lists.isocpp.org/> at some point in the near future.
--
Paul “TBBle” Hampson
From: SG14 <sg14-bounces_at_[hidden]<mailto:sg14-bounces_at_[hidden]>> On Behalf Of Ben Craig
Sent: Friday, 15 February 2019 1:34 AM
To: Low Latency:Game Dev/Financial/Trading/Simulation/Embedded Devices <sg14_at_[hidden]<mailto:sg14_at_[hidden]>>
Subject: Re: [SG14] [EXT] Ideas on debug constexpr functions or other functions that have been 100% removed from the EXE
Some of the meta-class proposals (and prototypes!) allow for printf style debugging at compile time. I agree that it would be awful nice if I could debug the compile time constexpr things, or step through overload resolution somehow.
From: SG14 <sg14-bounces_at_[hidden]<mailto:sg14-bounces_at_[hidden]>> On Behalf Of Clément Grégoire
Sent: Thursday, February 14, 2019 2:13 AM
To: Low Latency:Game Dev/Financial/Trading/Simulation/Embedded Devices <sg14_at_[hidden]<mailto:sg14_at_[hidden]>>
Subject: [EXTERNAL] Re: [SG14] [EXT] Ideas on debug constexpr functions or other functions that have been 100% removed from the EXE
Hi,
I do agree with what's being said, but I think you will get better feedback if you reach SG15 (tooling group) if not done already!
Cheers,
Clément
Le jeu. 14 févr. 2019 à 08:33, Scott Wardle <swardle_at_[hidden]<mailto:swardle_at_[hidden]>> a écrit :
Thanks for the feedback Paul, I fixed the image VPU0SINCOS.png forgot to upload to my web server.
You have the idea exactly.
There are a lot of different versions of the idea I can think of. I have not written a debugger my self but I have worked with people who have back on ps1. I don’t think the debugger runtime is hard to write. As you can see with the python mixed language debuggers it is not that original or do I think that hard.
The compiler side however I don’t know at all and don’t know how to start work on an idea like this. But as I have never seen any ISO papers on debugging maybe I should write a paper anyways :)
Maybe Paul, you are getting at this. I don’t really talk about parameters in the blog post. Each return value has to be mapped to a load of a bunch of parameters and then a call to the code to debug. I should write something on that. It is more than just the debug version of the code.
Would any of these parameters be non-const if the function is “constexper”? I don’t see how, but if they can be then you would need to load a value into this virtual co-processor memory space not so hard either way.
Scott
> On Feb 13, 2019, at 10:40 PM, Paul Hampson <p_hampson_at_[hidden]<mailto:p_hampson_at_[hidden]>> wrote:
>
> I had a 404'd image about 30% down: https://www.swardle.com/sweb/img/VPU0SINCOS.png<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.swardle.com_sweb_img_VPU0SINCOS.png&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=X0uWc7GSCQVpJqj-LfrZbAy5Vy-EMyme5GbyQodZ5H8&s=A_con8RPxCMPVByykG5YYfhKm_RqC4Gs0DGfu6FItZI&e=>
>
> Thinking about the practicalities of this idea, what if the debug symbol blobs contains unoptimized versions of constexpr, inlined, and other (perhaps #pragma-marked?) functions, which were used for breakpointing? The debug blobs could know that a particular static value is the result of a constexpr call, since the code=>asm mapping must already see something like "call constExpr(X)" => "LOAD accumulator, some constant value". Same for inlining, a function call that maps to something other than a function-call preamble is presumably an inlined function.
>
> Then the debugger could step-through that side-lined code blob, but discard the results (and side-effects?) at the end, and execute the code in the function itself. *Or* it could actually execute the side-lined code, giving you the runtime effect of MSVC's "#pragma optimize(off)" triggered only by placing a breakpoint at a certain point.
>
> Constexpr might be an easier place to start, since we know the side-effects of such a function are limited, and it's really a code->value transform, and they're evaluated down to constants, while inlined and optimised functions are more-arbitrary code->code transforms.
>
> I don't know enough about the internals of debug tables and debuggers to know if this is practical, but it sounds useful for the use-case you've described.
>
> On a side-note, we use mixed C++/Python, and it's a delight when we (occasionally) use the MSVC mixed-mode debugging support for Python, and get mixed Python/C++ stack traces. It sounds like the VPU debugger gave the same thing, so there' definitely mixed-mode debugging traditions around we could leverage.
>
> Not sure if there's a C++ paper in this, probably more of a clang/lld/gdb hackathon opportunity and a nice presentation at CppCon. ^_^
>
> --
> Paul “Hampy” Hampson
>
>> -----Original Message-----
>> From: SG14 <sg14-bounces_at_[hidden]<mailto:sg14-bounces_at_[hidden]>> On Behalf Of Scott Wardle
>> Sent: Thursday, 14 February 2019 12:26 PM
>> To: Low Latency:Game Dev/Financial/Trading/Simulation/Embedded Devices
>> <sg14_at_[hidden]<mailto:sg14_at_[hidden]ocpp.org>>
>> Subject: [EXT] [SG14] Ideas on debug constexpr functions or other functions
>> that have been 100% removed from the EXE
>>
>> Hi Everyone,
>>
>> I was looking through C++ papers and since 2010 (and maybe before) not one
>> iso C++ paper has been submitted on debugging. So maybe now is a good
>> time to think about how we should debug C++ in a new way.
>>
>> To that end I had an idea the other day on debugging and wrote a blog on it
>> and finally posted it. I don’t see how this would effect the standard but it is
>> quality of implementation idea.
>>
>> If we want to constexpr all of the things it would nice if we could printf debug
>> at least. But my idea is maybe we can get the whole debugger to work.
>>
>> Check it out on my blog. http://www.swardle.com/sweb/blog5.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.swardle.com_sweb_blog5.html&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=X0uWc7GSCQVpJqj-LfrZbAy5Vy-EMyme5GbyQodZ5H8&s=IQk0_888aKBOp7QPfhrz4wlbrrsPitUZViQ47AjXtLs&e=>
>>
>> Tell me if you have any feedback (spelling grammar or good counter ideas
>> that shows why the idea is not posable etc...)
>>
>> Scott
>>
>> _______________________________________________
>> SG14 mailing list
>> SG14_at_[hidden]<mailto:SG14_at_[hidden]>
>> http://lists.isocpp.org/mailman/listinfo.cgi/sg14<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.isocpp.org_mailman_listinfo.cgi_sg14&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=X0uWc7GSCQVpJqj-LfrZbAy5Vy-EMyme5GbyQodZ5H8&s=bNMfEt-nwdGg7B0i9XNPOeIN9lPnUoe01JEygcHLbAc&e=>
> [wargaming.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__wargaming.net&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=X0uWc7GSCQVpJqj-LfrZbAy5Vy-EMyme5GbyQodZ5H8&s=itWScybEslu8w7rjoFQLVjtuN375stib-CWz7dRtCGY&e=>]
> EgzO3mXGcK
> This e-mail may contain CONFIDENTIAL AND PROPRIETARY INFORMATION and/or PRIVILEGED AND CONFIDENTIAL COMMUNICATION intended solely for the recipient and, therefore, may not be retransmitted to any party outside of the recipient's organization without the prior written consent of the sender. If you have received this e-mail in error please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Wargaming.net<http://wargaming.net/> accepts no liability for any losses or damages resulting from infected e-mail transmissions and viruses in e-mail attachment. kgzO3mXGcg
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]socpp.org<mailto:SG14_at_[hidden]>
> http://lists.isocpp.org/mailman/listinfo.cgi/sg14<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.isocpp.org_mailman_listinfo.cgi_sg14&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=X0uWc7GSCQVpJqj-LfrZbAy5Vy-EMyme5GbyQodZ5H8&s=bNMfEt-nwdGg7B0i9XNPOeIN9lPnUoe01JEygcHLbAc&e=>
_______________________________________________
SG14 mailing list
SG14_at_[hidden]<mailto:SG14_at_[hidden]>
http://lists.isocpp.org/mailman/listinfo.cgi/sg14<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.isocpp.org_mailman_listinfo.cgi_sg14&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=X0uWc7GSCQVpJqj-LfrZbAy5Vy-EMyme5GbyQodZ5H8&s=bNMfEt-nwdGg7B0i9XNPOeIN9lPnUoe01JEygcHLbAc&e=>
_______________________________________________
SG14 mailing list
SG14_at_[hidden]<mailto:SG14_at_[hidden]>
http://lists.isocpp.org/mailman/listinfo.cgi/sg14
_______________________________________________
SG14 mailing list
SG14_at_[hidden]<mailto:SG14_at_[hidden]>
http://lists.isocpp.org/mailman/listinfo.cgi/sg14
Received on 2019-02-17 17:43:01