I think Arthur is correct in that the idea is outside of scope in terms
of the group's aims, however that doesn't mean it's not an interesting
idea to talk about, and I think he's wrong to jump to conclusions about
how and why you're presenting this.

Generally, yes, I think in order to reduce overall noise we should be
focused on things that can actually be brought to bear before the
standards committee, however discussions around what can and cannot be
brought to bear are welcome.


On 17/02/2019 4:03 p.m., Scott Wardle wrote:
> Hi Arthur,
>
> Thanks for the feedback.
>
> I think many would agree with you. In fact I often tell most of my game
> programming friends, for the problem you are trying to solve we should
> just work with tools venders directly. Certainly what debugging data is
> stored is not standardized nor I am suggesting it should be.
>
> I think your email Arthur brings up another thing I have been thinking
> about. Why has there never been a paper on debugging?
>
> I think we don’t have papers on debuggers because, while it might be
> good to talk to the C++ cabal about debuggers, mostly debuggers don’t
> effect standard's documentation so these ideas just don’t belong or at
> least don’t get brought up. We should just post them on twitter, or
> write the vender directly etc…
>
> I choose to write SG14 as it was a good small group of customers and
> also maybe some tool venders. I could see if other people liked the
> idea and if there was research in the space I am not aware of. I think
> SG14 is not a bad place to see if this is a real problem in industry or
> not. If the problem was popular enough with customers maybe then it
> would be worth investment by venders. Even if this does not become a
> paper maybe talking about it in SG14, then posting on twitter and
> emailing the vender is a good idea. I mean SG14 is a group made because
> the C++ standard was having trouble talking to some industries after all.
>
> SG15 might have more venders… but I think are more interested in modules
> and build systems. So it was not my first idea, but I have sent the
> email now. My guess is the idea is so big anyways no one will bite
> unless they can see money to be made. So the email chain I bet will die
> quick no harm done.
>
> I don’t really want to sprint plan or manage the development of such a
> new debugger. I wanted to bring up the problem, you can’t debug large
> parts of C++. The set of C++ the can’t be debugged is getting larger and
> here is an idea for part of a solution. I think the full solution is out
> of scope for this group but the fact that we have a problem here and it
> is getting larger is maybe is in scope for SG14. It would be
> interesting to see how many lines of code can have break points in
> optimized code 10 years ago vs 5 years ago vs now. Though I don’t know
> how to make this data. This would feel more like a good paper to me for
> SG14.
>
> I would love to have your (and other people on SG14) feedback on the
> question, If it does not effect the standard should the idea be talked
> about in SG14? Maybe this is why we will never get an ISO paper on
> debugging? Maybe that is ok. But this communication problem is a very
> interesting problem in its own right.
>
> Scott
>
>
>> On Feb 16, 2019, at 5:09 PM, Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]
>> <mailto:arthur.j.odwyer_at_[hidden]>> wrote:
>>
>> 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 onlists.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]>>
>>>> >> 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] <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
>>
>> _______________________________________________
>> SG14 mailing list
>> SG14_at_[hidden] <mailto:SG14_at_[hidden]>
>> http://lists.isocpp.org/mailman/listinfo.cgi/sg14
>
>
>
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> http://lists.isocpp.org/mailman/listinfo.cgi/sg14
>