ср, 22 сент. 2021 г. в 20:44, Jonathan Wakely :
>
> On Wed, 22 Sept 2021 at 18:09, Antony Polukhin wrote:
> >
> > std::unique_ptr allows construction from std::unique_ptr of derived
> > type as per [unique.ptr.single.asgn] and [unique.ptr.single.ctor]. If
> > std::default_delete is used with
ср, 22 сент. 2021 г. в 20:23, Ville Voutilainen :
>
> On Wed, 22 Sept 2021 at 20:09, Antony Polukhin via Libstdc++
> wrote:
> >
> > std::unique_ptr allows construction from std::unique_ptr of derived
> > type as per [unique.ptr.single.asgn] and [unique.ptr.single.ctor]. If
> > std::default_delete
std::unique_ptr allows construction from std::unique_ptr of derived
type as per [unique.ptr.single.asgn] and [unique.ptr.single.ctor]. If
std::default_delete is used with std::unique_ptr, then after such
construction a delete is called on a pointer to base. According to
[expr.delete] calling a
вт, 17 авг. 2021 г. в 16:37, Jonathan Wakely :
<...>
> Thanks, this is a nice improvement. We can avoid tag dispatching to
> make it simpler though:
>
> @@ -3248,6 +3249,9 @@ namespace __detail
> template
> seed_seq::seed_seq(_InputIterator __begin, _InputIterator __end)
> {
> + if
When std::seed_seq is constructed from random access iterators we can
detect the internal vector size in O(1). Reserving memory for elements
in such cases may avoid multiple memory allocations.
libstdc++-v3/ChangeLog:
* include/bits/random.tcc: Optimize seed_seq construction.
--
Best
ср, 12 мая 2021 г. в 18:38, Antony Polukhin :
>
> ср, 12 мая 2021 г. в 17:44, Jonathan Wakely :
> >
> > On 12/05/21 12:58 +0300, Antony Polukhin wrote:
> > >ср, 12 мая 2021 г. в 12:18, Jonathan Wakely :
> > ><...>
> > >> Or just leave it undefined, as libc++ seems to do according to your
> > >>
ср, 12 мая 2021 г. в 17:44, Jonathan Wakely :
>
> On 12/05/21 12:58 +0300, Antony Polukhin wrote:
> >ср, 12 мая 2021 г. в 12:18, Jonathan Wakely :
> ><...>
> >> Or just leave it undefined, as libc++ seems to do according to your
> >> comment in PR 89728:
> >>
> >> error: implicit instantiation of
ср, 12 мая 2021 г. в 12:58, Antony Polukhin :
<...>
> Should we care about those users?
Looks like the answer is "yes". There are tests for that in
22_locale/ctype/requirements/explicit_instantiation.cc and
22_locale/money_get/cons/3.cc
Attaching a patch with review fixes (with ctype
ср, 12 мая 2021 г. в 12:18, Jonathan Wakely :
<...>
> Or just leave it undefined, as libc++ seems to do according to your
> comment in PR 89728:
>
> error: implicit instantiation of undefined template
> 'std::__1::ctype >'
>
> Was your aim to have a static_assert that gives a more descriptive
>
This patch provides compile time diagnostics for common misuse of
[locale.convenience] functions with std::string as a character type.
2021-05-11 Antony Polukhin
PR libstdc++/89728
* include/bits/locale_facets.h (ctype) Add static assert.
*
Rebased the patch on current master. Please review.
Changelog stays the same:
New std::common_type assertions attempt to give a proper 'required from
here' hint for user code, do not bring many changes to the
implementation and check all the template parameters for completeness.
In some cases
On Thu, Nov 12, 2020, 21:55 Antony Polukhin wrote:
> Final bits for libstdc/71579
>
Gentle reminder on last patch
>
Final bits for libstdc/71579
std::common_type assertions attempt to give a proper 'required from
here' hint for user code, do not bring many changes to the
implementation and check all the template parameters for completeness.
In some cases the type could be checked for completeness more than
Looks like the last patch was not applied. Do I have to change something in
it?
ср, 19 авг. 2020 г. в 14:29, Jonathan Wakely :
<...>
> Do we also want to check
> (std::__is_complete_or_unbounded(__type_identity<_ArgTypes>{}) && ...)
> for invoke_result and the is_invocable traits?
Done.
Changelog:
2020-08-20 Antony Polukhin
PR libstdc/71579
*
ср, 19 авг. 2020 г. в 14:29, Jonathan Wakely :
<...>
> Do we also want to check
> (std::__is_complete_or_unbounded(__type_identity<_ArgTypes>{}) && ...)
> for invoke_result and the is_invocable traits?
>
> We can use a fold expression there, because those traits are not
> defined before C++17.
Fixed patch for type traits hardening
Changelog
2020-08-12 Antony Polukhin
PR libstdc/71579
* include/std/type_traits (invoke_result, is_nothrow_invocable_r)
Add static_asserts to make sure that the argument of the type
trait is not misused with incomplete types.
17 matches
Mail list logo
