Date: Wed, 23 Oct 2024 13:31:17 +0200
On Wed, Oct 23, 2024 at 12:57 PM Jonathan Wakely via SG15 <
sg15_at_[hidden]> wrote:
>
>
> On Wed, 23 Oct 2024 at 10:55, Ville Voutilainen <
> ville.voutilainen_at_[hidden]> wrote:
>
>> On Wed, 23 Oct 2024 at 12:01, Jonathan Wakely via SG15
>> <sg15_at_[hidden]> wrote:
>> > My use case for constexpr_print is for "interactive" development during
>> compile-edit-debug cycles. You add some prints, but then take them out
>> again once you've understood how the code is compiling. So IMHO it really
>> doesn't matter how that output is displayed. It could even go to a separate
>> file.
>>
>> Thanks, there's the answer to my pondering how the compiler could
>> control the output of a constexpr_print.
>>
>> c++ -fconstexpr-print-output-file=-
>> c++ -fconstexpr-print-output-file=myprintzlog.txt
>>
>
>
> Yeah, and that output could be completely disabled by default, if dumping
> unstructured messages to a file/terminal is not a fit for the compiler's
> typically high quality user experience. Document that you need to use
> something like -fconstexpr-print-spew to enable those messages, but that
> the output might be interleaved with the usual diagnostics and might not be
> easily parsed by automated tooling.
>
> There seem to be several ways to support this in *some* form without
> compromising how compilers currently present output to users.
>
> (I'm amused that Aaron said the only form he wants to support for Clang is
> just print, no bells and whistles, but Corentin said the opposite and
> suggested dropping the "just print" form, also for Clang :-)
>
Heh, having a different perspective is useful sometimes!
Aaron pointed out that every time these discussions come around we struggle
to reach a community consensus as to what we would actually need to meet
the needs of users.
But, I'm fairly confident both Aaron and I would favor a simple interface
that can be iterated upon as we gather usage experience, and that we both
want to make sure not to compromise the output, as you put it.
We are acutely aware of a growing need for constexpr-debugging capabilities
(which would be fairly different than poking at template instantiations)
and in fact we have been musing with the idea of hooking constexpr
evaluation to an actual debugger protocol,
that would be quite neat - print-debugging gets annoying fast. Long term
project though :)
(Note that I'm not completely opposed to print, but there is the potential
for it being a mess and having ways to disable that or even not having it
own by default is probably going to be necessary)
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
sg15_at_[hidden]> wrote:
>
>
> On Wed, 23 Oct 2024 at 10:55, Ville Voutilainen <
> ville.voutilainen_at_[hidden]> wrote:
>
>> On Wed, 23 Oct 2024 at 12:01, Jonathan Wakely via SG15
>> <sg15_at_[hidden]> wrote:
>> > My use case for constexpr_print is for "interactive" development during
>> compile-edit-debug cycles. You add some prints, but then take them out
>> again once you've understood how the code is compiling. So IMHO it really
>> doesn't matter how that output is displayed. It could even go to a separate
>> file.
>>
>> Thanks, there's the answer to my pondering how the compiler could
>> control the output of a constexpr_print.
>>
>> c++ -fconstexpr-print-output-file=-
>> c++ -fconstexpr-print-output-file=myprintzlog.txt
>>
>
>
> Yeah, and that output could be completely disabled by default, if dumping
> unstructured messages to a file/terminal is not a fit for the compiler's
> typically high quality user experience. Document that you need to use
> something like -fconstexpr-print-spew to enable those messages, but that
> the output might be interleaved with the usual diagnostics and might not be
> easily parsed by automated tooling.
>
> There seem to be several ways to support this in *some* form without
> compromising how compilers currently present output to users.
>
> (I'm amused that Aaron said the only form he wants to support for Clang is
> just print, no bells and whistles, but Corentin said the opposite and
> suggested dropping the "just print" form, also for Clang :-)
>
Heh, having a different perspective is useful sometimes!
Aaron pointed out that every time these discussions come around we struggle
to reach a community consensus as to what we would actually need to meet
the needs of users.
But, I'm fairly confident both Aaron and I would favor a simple interface
that can be iterated upon as we gather usage experience, and that we both
want to make sure not to compromise the output, as you put it.
We are acutely aware of a growing need for constexpr-debugging capabilities
(which would be fairly different than poking at template instantiations)
and in fact we have been musing with the idea of hooking constexpr
evaluation to an actual debugger protocol,
that would be quite neat - print-debugging gets annoying fast. Long term
project though :)
(Note that I'm not completely opposed to print, but there is the potential
for it being a mess and having ways to disable that or even not having it
own by default is probably going to be necessary)
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
Received on 2024-10-23 11:31:42