On Mon, Oct 10, 2022 at 8:09 AM Patrick Palka via Libstdc++
wrote:
>
> On Mon, 10 Oct 2022, Jonathan Wakely via Libstdc++ wrote:
>
> > Tested powerpc64le-linux. Pushed to trunk.
> >
> > -- >8 --
> >
> > Currently we only reject std::make_signed_t but not cv bool.
> > Similarly for std::make_unsign
On Tue, Oct 19, 2021 at 9:05 AM Jonathan Wakely via Gcc-patches
wrote:
>
> +constexpr bool
> +test_copy_elision()
> +{
> + return true;
> +}
> +
> +static_assert( test_copy_elision() );
> +
This isn't much of a test :)
That example violates http://eel.is/c++draft/unique.ptr.runtime.general#3
On Thu, Jun 24, 2021 at 1:55 PM Patrick Palka via Gcc-patches
wrote:
>
> On Thu, 24 Jun 2021, Jonathan Wakely via Libstdc++ wrote:
>
> > The LWG issue proposes to add a conditional noexcept-specifier to
> > std::unique_p
CPOs are specified as actual semiregular function objects that can be
copied and constructed freely, so it seems a bit hostile to make them
final/non-addressable? (It's debatable whether the type of a CPO is a
type "specified in the C++ standard library" for which [derivation]/4
would apply.)
On
On Wed, May 26, 2021 at 2:55 PM Jonathan Wakely wrote:
>
> On Wed, 26 May 2021 at 20:11, Patrick Palka via Libstdc++
> wrote:
> >
> > On Wed, 26 May 2021, Tim Song wrote:
> >
> > > I noticed that output_iterator_wrapper still has a (non-void)
> > > value_type. Perhaps we can get better coverage i
On Wed, May 26, 2021 at 1:43 PM Patrick Palka wrote:
>
> On Wed, 26 May 2021, Tim Song wrote:
> >
> > On Wed, May 26, 2021 at 12:00 PM Patrick Palka via Libstdc++
> > wrote:
> > >
> > > - else if constexpr (input_iterator<_Out>
> > > - && same_as,
> > > iter_value_
I noticed that output_iterator_wrapper still has a (non-void)
value_type. Perhaps we can get better coverage if it doesn't have one?
The existing tests should have caught this case with that change, at least.
On Wed, May 26, 2021 at 12:00 PM Patrick Palka via Libstdc++
wrote:
>
> - else if
On Mon, May 17, 2021 at 2:59 PM Patrick Palka wrote:
>
> + constexpr _CachedPosition&
> + operator=(_CachedPosition&& __other) noexcept
> + {
> + if (std::__addressof(__other) != this)
I don't think we need this check - self-move-assigning the underlying
view isn't requi
On Mon, May 17, 2021 at 12:21 PM Patrick Palka via Gcc-patches
wrote:
>
> using _Base = elements_view::_Base<_Const>;
> sentinel_t<_Base> _M_end = sentinel_t<_Base>();
> @@ -3800,7 +3807,7 @@ namespace views::__adaptor
> requires sized_sentinel_for, iterator_t<_Base
On Mon, May 17, 2021 at 11:46 AM Patrick Palka via Libstdc++
wrote:
> constexpr void
> _M_set(const _Range&, const iterator_t<_Range>& __it)
> {
> __glibcxx_assert(!_M_has_value());
> - _M_iter = __it;
> + this->_M_payload._M_payload._M_value = __i
On Fri, Apr 30, 2021 at 12:11 PM Patrick Palka via Libstdc++
wrote:
>
> + template
> + _Tp&
> + _M_emplace_deref(const _Iter& __i)
> + {
> + this->reset();
> + return this->emplace(*__i);
> + }
This incurs a move, avoiding of which is the
On Sat, Mar 20, 2021 at 3:58 AM Jonathan Wakely wrote:
>
>
>
> On Sat, 20 Mar 2021, 01:13 Tim Song via Libstdc++,
> wrote:
>>
>> On Fri, Mar 19, 2021 at 3:13 PM Jonathan Wakely via Libstdc++
>> wrote:
>> >
>> > Implement this C++23 feature, as proposed by P1048R1.
>> >
>> > This implementation
On Fri, Mar 19, 2021 at 3:13 PM Jonathan Wakely via Libstdc++
wrote:
>
> Implement this C++23 feature, as proposed by P1048R1.
>
> This implementation assumes that a C++23 compiler supports concepts
> already. I don't see any point in using preprocessor hacks to detect
> compilers which define __c
I thought LWG approved the other option in the PR (changing views::join to
not use CTAD)?
On Mon, Aug 24, 2020 at 10:22 AM Jonathan Wakely via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> This implements the proposed resolution for LWG 3474.
>
> libstdc++-v3/ChangeLog:
>
> * include/st
14 matches
Mail list logo
