public inbox for libstdc++@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely@redhat.com>
To: "François Dumont" <frs.dumont@gmail.com>
Cc: "libstdc++@gcc.gnu.org" <libstdc++@gcc.gnu.org>,
	gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] Fix algo constexpr tests in Debug mode
Date: Tue, 01 Oct 2019 11:21:00 -0000	[thread overview]
Message-ID: <20191001112058.GN9487@redhat.com> (raw)
In-Reply-To: <b984dee2-8728-f12f-ad91-5eecc171bbec@gmail.com>

On 30/09/19 22:21 +0200, François Dumont wrote:
>On 9/30/19 11:03 AM, Jonathan Wakely wrote:
>>These changes are fine but should have been a separate, unrelated
>>commit.
>
>Ok, sorry, I consider that just a comment change was fine.

It's fine, but it is unrelated so should be a separate commit. That
makes it easier to backport the documentation fix independently of the
rest of the patch. Or if the patch had to be reverted for some reason,
we wouldn't also revert the doc fix if it was in a separate commit.

Unrelated changes should usually be separate commits.


>>>@@ -157,10 +192,16 @@ namespace __gnu_debug
>>>   *  otherwise.
>>>  */
>>>  template<typename _InputIterator>
>>>+    _GLIBCXX20_CONSTEXPR
>>>    inline bool
>>>    __valid_range(_InputIterator __first, _InputIterator __last,
>>>          typename _Distance_traits<_InputIterator>::__type& __dist)
>>>    {
>>>+#ifdef __cpp_lib_is_constant_evaluated
>>>+      if (std::is_constant_evaluated())
>>>+    // Detected by the compiler directly.
>>>+    return true;
>>>+#endif
>>
>>Should this be using the built-in, not the C++20 function?
>>
>>
>>In practice it's probably equivalent, because the function is only
>>going to be constant-evaluated when called from C++20 code, and in
>>that case the std::is_constant_evaluated() function will be available.
>
>
>Yes, this is why I did it this way. And moreover it is using std::pair 
>move assignment operator which is also C++20 constexpr.
>
>>
>>It just seems inconsistent to use the built-in in one place and not in
>>the other.
>
>It is also the reason why the simple simple __valid_range is not using 
>the other anymore.
>
>Maybe once I'll have check all the algo calls I'll find out that this 
>one need _GLIBCXX_CONSTEXPR.
>
>I got the sensation that library is being 'constexpr' decorated only 
>when needed and when properly Standardise so are the Debug helpers.

The standard says when something should be a constexpr function, we
don't get to decide. So if a function is not constexpr in C++17 and is
constexpr in C++20, we have to conform to that. For functions that are
not part of the standard and are our own implementation details, we
can choose when to make them constexpr. We could make all the debug
helpers use _GLIBCXX14_CONSTEXPR (or even _GLIBCXX_CONSTEXPR if they
meet the very restrictive C++11 constexpr requirements) but since they
are never going to be constant evaluated except in C++20, there
doesn't seem to be much point to doing that.

  reply	other threads:[~2019-10-01 11:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-19 20:28 [PATCH] Help compiler detect invalid code François Dumont
2019-09-20  5:08 ` François Dumont
2019-09-25 20:40   ` François Dumont
2019-09-27 11:24   ` Jonathan Wakely
2019-10-01 20:05     ` François Dumont
2019-10-10 20:03       ` Jonathan Wakely
2019-10-16 20:22         ` François Dumont
2019-09-27 12:11 ` Jonathan Wakely
2019-09-27 16:24   ` François Dumont
2019-09-27 16:45     ` Jonathan Wakely
2019-09-28 21:12       ` [PATCH] Fix algo constexpr tests in Debug mode François Dumont
2019-09-30  9:03         ` Jonathan Wakely
2019-09-30 20:21           ` François Dumont
2019-10-01 11:21             ` Jonathan Wakely [this message]
2019-10-23 15:26         ` Jonathan Wakely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191001112058.GN9487@redhat.com \
    --to=jwakely@redhat.com \
    --cc=frs.dumont@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=libstdc++@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).