On Tue, 27 Jan 2026 at 08:30, Tomasz Kaminski <[email protected]> wrote:
>
>
>
> On Mon, Jan 26, 2026 at 10:25 PM François Dumont <[email protected]> wrote:
>>
>> Hi
>>
>>      libstdc++: [_GLIBCXX_DEBUG] Make constant evaluation compatible
>>
>>      In a constant evaluation context the _GLIBCXX_DEBUG is working in a
>>      degradated mode where only iterators are keeping a link to their
>> container,
>>      the container won't have a list of its iterators.
>>
>>      In std::__debug::vector and std::__debug::inplace_vector remove all
>> calls to
>>      std::is_constant_evaluated and code associated to it when returning
>> true. The
>>      same code is now used in both contexts.
>
> What are the exact benefits of this change? During constant evaluation we 
> already
> detect all UB caused by access via invalid or past the end pointers, so most 
> of the
> cases are detected.
>
> As this will have non-trivial impact on compile-times of programs operation on
> vector at compile time (including c++26) reflection, I would like to see a 
> more concrete
> cost (how much longer a decently size example using reflection compilers) vs 
> benefits
> (examples of situations where this new implementation will detect breach of 
> library preconditions,
> that are not already detected).

Yes, I share the same concerns. This is a lot of extra code to run
during constant evaluation, for unclear benefit.

This would allow us to diagnose some uses of invalid iterators, like
the topic of https://cplusplus.github.io/LWG/issue2256
Currently that code Just Works, because there is a valid object at
that location, and the rule about invalidating iterators is only
enforced with debug mode, so not during constant evaluation:

#include <vector>
#include <cassert>

constexpr bool f()
{
  typedef std::vector<int> C;
  C c = {1, 2, 3, 4};
  C::iterator i = c.begin() + 1;
  C::iterator j = c.end() - 1;
  assert(*i == 2);
  assert(*j == 4);
  c.erase(c.begin());
  return *i == 3; // Why is this not perfectly fine?!
}

static_assert(f());

But I don't think I really care about this. There *is* a valid object,
and if there wasn't, it would fail to compile.

Reply via email to