[print.fun] requires a system_error, but I don't think
[ostream.formatted.print] does?
On Tue, Feb 27, 2024 at 5:47 AM Jonathan Wakely wrote:
> Tested x86_64-linux. Reviews invited.
>
> -- >8 --
>
> The standard requires an exception if std::print fails to write to a
> std::ostream.
>
> libstdc+
On Fri, Dec 15, 2023 at 4:43 AM Jonathan Wakely wrote:
> On Fri, 15 Dec 2023 at 01:17, Tim Song wrote:
> >
> > On Thu, Dec 14, 2023 at 6:05 PM Jonathan Wakely
> wrote:
> >> + inline void
> >> + vprint_unicode(ostream& __os, string_view __fmt, format_
On Thu, Dec 14, 2023 at 6:05 PM Jonathan Wakely wrote:
> Tested x86_64-linux. Pushed to trunk.
>
> -- >8 --
>
> This adds the C++23 std::print functions, which use std::format to write
> to a FILE stream or std::ostream (defaulting to stdout).
>
> The new extern symbols are in the libstdc++exp.a
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)
> > > v
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
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
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
On Mon, Feb 17, 2020 at 12:34 PM Jonathan Wakely wrote:
> This removes the complicated std::boolean concept, as agreed in Prague.
>
> * include/bits/ranges_algo.h (__find_fn, __find_first_of_fn)
> (__adjacent_find_fn): Cast result of predicate to bool.
Um, why? These look fine
On Thu, Jan 24, 2019 at 4:14 PM Jason Merrill wrote:
>
> On 1/24/19 2:16 PM, Marek Polacek wrote:
> > This test ICEs since r159006 which added
> >
> > type = ENUM_UNDERLYING_TYPE (type);
> >
> > to type_promotes_to. In this test ENUM_UNDERLYING_TYPE is null because we
> > haven't yet parsed '
On Tue, Dec 18, 2018 at 10:57 AM Jonathan Wakely wrote:
> * include/bits/fs_dir.h (operator<<): Overload for directory_entry,
> as per LWG 3171.
> * testsuite/27_io/filesystem/directory_entry/lwg3171.cc: New test.
>
> Tested x86_64-linux, committed to trunk.
>
>
>
The test
On Wed, Jul 4, 2018 at 4:17 PM, Jonathan Wakely wrote:
> + std::is_trivially_convertible, and
s/trivially/nothrow/
Since param_type's constructors are defined by reference to the
constructors of the distribution, P0935's changes to the distribution's
constructors apply to their param_type as well.
On Tue, Feb 27, 2018 at 9:41 AM, Jonathan Wakely wrote:
> Since the fix for PR c++/80955 any suffix on a string literal that
> begins with an underscore is assumed to be a user-defined literal
> suffix, not a macro. This assumption is invalid for a suffix beginning
> with two underscores, because
What if the file to be removed is externally removed between the
symlink_status and the ::remove call? This is probably QoI because
filesystem race, but it seems reasonable to double check errno if
::remove fails and not fail if the failure is due to the file not
existing.
On Mon, Nov 13, 2017 at 3:32 PM, Daniel Krügler
wrote:
> but as Jonathan already said, for std::istreambuf_iterator this can
> never be true (because of the involved IO operations).
>
Except, of course, if you advance by zero. It's not a very useful
case, for sure...
Um, why are those member get's there at all (and with an index mapping
that doesn't agree with the member order)? [container.insert.return]
says that "It has no base classes or members other than those
specified."
On Tue, Sep 19, 2017 at 8:54 AM, Jakub Jelinek wrote:
> Hi!
>
> The following patch implements P0386R1 - NSDMIs for bit-fields.
It's P0683R1.
On Wed, Sep 13, 2017 at 10:55 AM, Jonathan Wakely wrote:
>
> +// DR 1177
> +static_assert(is_constructible, duration>{},
> +"can convert duration with one floating point rep to another");
> +static_assert(is_constructible, duration>{},
> +"can convert duration with integral rep to one with
On Sat, Sep 9, 2017 at 2:34 AM, Gerald Pfeifer wrote:
> + href="http://www-cs-faculty.stanford.edu/~knuth/mmix.htmll";>MMIX
This one has one too many l's.
On Thu, Aug 24, 2017 at 4:55 AM, Petr Ovtchenkov wrote:
> istream_iterator do unexpected read from stream
> when initialized by istream&.
>
This is pretty much required by the specification. See the discussion
in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0738r0.html
And the "fix"
On Fri, Aug 4, 2017 at 1:32 PM, Paolo Carlini wrote:
> About the exact wording, I'm a little puzzled, because, besides the
> "implicit" nit, the "copy-inizialization" already occurs in two other places
> in that function, in the preceding:
>
> if (elided && !cands)
> {
> error ("canno
On Mon, Jul 31, 2017 at 11:13 AM, Tim Song wrote:
>
> https://clang.llvm.org/docs/LanguageExtensions.html#checks-for-type-trait-primitives
> seems to suggest using __has_extension instead.
Hmm, that doesn't work. Oh well.
On Mon, Jul 31, 2017 at 10:53 AM, Jonathan Wakely wrote:
> On 27/07/17 16:27 +0900, Katsuhiko Nishimra wrote:
>>
>> From 56c4a18d0d8c8ce7aa1239880138775e4db06645 Mon Sep 17 00:00:00 2001
>> From: Katsuhiko Nishimra
>> Date: Thu, 27 Jul 2017 16:03:54 +0900
>> Subject: [PATCH] libstdc++: Support st
On Fri, Jul 28, 2017 at 4:10 PM, Daniel Krügler
wrote:
> + // Performs an implicit conversion from _Tp to __sv_type.
> + template
> +static __sv_type _S_to_string_view(const _Tp& __svt)
> +{
> + return __svt;
> +}
I might have gone for
+static _
On Fri, Jun 2, 2017 at 9:07 AM, Jonathan Wakely wrote:
> we aren't qualifying calls to __ref_cast,
Turns out this is fine. I somehow managed to completely misread the
last sentence of [basic.lookup.argdep]/2. It's talking about the case
where an argument to the call is a set of overloaded functio
On Fri, Jun 2, 2017 at 3:19 PM, Tim Shen wrote:
> On Fri, Jun 2, 2017 at 6:07 AM, Jonathan Wakely wrote:
>> As the PR points out, we aren't qualifying calls to __ref_cast, and
>> have 'constexpr' on function templates that can never be usable in
>> constant expressions.
>
> Apology for the constex
This is not a patch. Nor is it an implementation of
std::binary_search, which is a function template that accepts
arbitrary forward iterators and optionally arbitrary comparator
objects, rather than just pointers.
If you want to find someone to review your code, consider something
like https://cod
libstdc++ has a to_chars implementation already. Assuming that the
locale issue isn't a problem, can that be reused?
On Mon, May 22, 2017 at 4:14 PM, Tim Song wrote:
> assuming core issue 1227's resolution
Actually, 1227 doesn't touch default template arguments :( OTOH, the
paragraph dealing with default template arguments seems to be full of
issues - it says "invalid type" rathe
On Mon, May 22, 2017 at 9:21 AM, Jonathan Wakely wrote:
> On 19/05/17 22:40 -0700, Tim Shen via libstdc++ wrote:
>>
>> diff --git a/libstdc++-v3/include/std/variant
>> b/libstdc++-v3/include/std/variant
>> index 0e04a820d69..b9824a5182c 100644
>> --- a/libstdc++-v3/include/std/variant
>> +++ b/lib
On Tue, May 16, 2017 at 3:24 PM, Nathan Sidwell wrote:
> On 05/16/2017 03:20 PM, Tim Song wrote:
>
>> Also, operator bool() seems suspect. Consider the safe bool idiom?
>
> ?
https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Safe_bool
I suspect that we don't want a
On Tue, May 16, 2017 at 2:50 PM, Martin Sebor wrote:
> I'm not sure I understand why the ovl_iterator assignment needs
> to be provided but if it does, not also defining one on the derived
> class will call the base and return a reference to the base, making
> the result no longer suitable where t
On Thu, Mar 23, 2017 at 1:45 PM, Jonathan Wakely wrote:
> + // NOTE: This makes use of the fact that we know how moveable
> + // is implemented on pair, and also vector. If the implementation
> + // changes this test may begin to fail.
Maybe drop this comment?
On Sat, Mar 11, 2017 at 3:37 PM, Daniel Krügler
wrote:
> 2017-03-11 21:23 GMT+01:00 Tim Song :
>> On Sat, Mar 11, 2017 at 1:32 PM, Daniel Krügler
>> wrote:
>>> This patch applies inline to all namespace scope const variables
>>> according to options A and B2 vote
On Sat, Mar 11, 2017 at 1:32 PM, Daniel Krügler
wrote:
> This patch applies inline to all namespace scope const variables
> according to options A and B2 voted in during the Kona meeting, see:
>
> http://wiki.edg.com/pub/Wg21kona2017/StrawPolls/p0607r0.html
>
> During that work it has been found t
On Tue, Jan 31, 2017 at 1:54 AM, Jonathan Wakely wrote:
> after including unrelated headers such as , , , and
>
or ?
On Wed, Feb 8, 2017 at 10:08 PM, Nathan Sidwell wrote:
>
> 'potentially constructed subobject' appears to be a term without definition.
[special]/5:
For a class, its non-static data members, its non-virtual direct base
classes, and, if the class is not abstract, its virtual base classes
are call
On Tue, Jan 31, 2017 at 8:48 AM Ville Voutilainen
wrote:
>
> On 31 January 2017 at 00:41, Ville Voutilainen
> wrote:
>
> I don't actually need to constrain it, I could just add a guide like
>
> template optional(optional<_Tp>) -> optional<_Tp>;
>
> However, I'm not convinced I need to. The prefe
On Mon, Jan 30, 2017 at 9:36 PM Jonathan Wakely wrote:
>
> On 30/01/17 13:28 +, Jonathan Wakely wrote:
> >On 30/01/17 13:47 +0200, Ville Voutilainen wrote:
> >>Tested on Linux-x64.
> >
> >OK, thanks.
>
> To be clear: this isn't approved by LWG yet, but I think we can be a
> bit adventurous wit
On Sun, Jan 22, 2017 at 10:42 AM, Ville Voutilainen
wrote:
> + _GLIBCXX14_CONSTEXPR
> + bool
> + operator()(_Tp* __x, _Tp* __y) const
> + { return uintptr_t(__x) > uintptr_t(__y); }
These reinterpret_casts can't possibly be constexpr.
Simple test case:
#include
constexpr b
On Thu, Jan 19, 2017 at 6:33 PM, Jonathan Wakely wrote:
> std::advance(__first, 1);
Why not just ++__first;?
On Fri, Jan 13, 2017 at 9:26 AM, Ville Voutilainen
wrote:
> Update patch with splices for __carry added. Hopefully this resolves
> the remaining concerns that we had.
On rereading the patch today, the size calculation for merge() appears
to be backwards. [__first2, __last2) consists of the nodes
On Fri, Jan 13, 2017 at 3:27 AM, Ville Voutilainen
wrote:
> On 13 January 2017 at 10:09, Ville Voutilainen
> wrote:
Ah, I think I see what you're saying. Just splice them back in any
order. Ok, I'll give that a spin.
>>>
>>> Right, list::sort doesn't promise strong exception safety, so
On Fri, Jan 13, 2017 at 3:00 AM, Ville Voutilainen
wrote:
> On 13 January 2017 at 09:56, Ville Voutilainen
> wrote:
>>> problem with just going through all of them and splicing the contents
>>> (if any) back to *this?
>>
>> Well, in addition to the computational complexity of it, not knowing
>> w
On Fri, Jan 13, 2017 at 1:39 AM, Ville Voutilainen
wrote:
> On 13 January 2017 at 08:01, Tim Song wrote:
>> On Thu, Jan 12, 2017 at 8:11 PM, Ville Voutilainen
>> wrote:
>>> This patch doesn't try to fix the reported sort() issue, because
>>> a) it would req
On Thu, Jan 12, 2017 at 8:11 PM, Ville Voutilainen
wrote:
> This patch doesn't try to fix the reported sort() issue, because
> a) it would require undoing a throwing move operation, which
> is impossible.
> b) in order to avoid the throwing move, we would need to add a
> level of indirection and t
On Wed, Jan 11, 2017 at 8:30 AM, Jonathan Wakely wrote:
>>> Re the new DMI, my brain compiler says that _Sequence c = _Sequence();
>>> breaks anything with an explicit copy/move constructor pre-C++17, but
>>> I also don't think we care about those, right?
>>
>>
>> I dislike them,
>
>
> I meant to
On Wed, Jan 11, 2017 at 7:21 AM, Jonathan Wakely wrote:
> This patch uses the _Enable_default_constructor mixin to properly
> delete the default constructors. It's a bit cumbersome, because we
> have to add an initializer for the base class to every
> ctor-initializer-list, but I think I prefer th
On Tue, Jan 10, 2017 at 12:33 PM, Jonathan Wakely wrote:
> The standard says that the container adaptors have a constructor with
> a default argument, which serves as a default constructor. That
> involves default-constructing the underlying sequence as the default
> argument and then move-constru
On Tue, Dec 6, 2016 at 6:00 AM, Jonathan Wakely wrote:
> Oh, but if you mean what the standard should say, my issue submission
> proposed "Throws: Nothing." for the ones with a narrow contract. It
> should be in the issue list soon, but I only sent it yesterday.
>
Yes, I was talking about the st
On Tue, Dec 6, 2016 at 5:43 AM, Jonathan Wakely wrote:
> None of these functions can throw, so we should mark them as such.
> I've reported this as a defect against C++17, because they should have
> been made noexcept after the application of https://wg21.link/p0254r2
Surely the const _CharT* var
On Fri, Nov 11, 2016 at 10:39 PM, Jonathan Wakely wrote:
> making the existing not-required-by-the-standard constructor private.
> + public:
> +explicit
> +future_error(error_code __ec)
> +: logic_error("std::future_error: " + __ec.message()), _M_code(__ec)+
> { }
That doesn't l
On Fri, Oct 28, 2016 at 1:47 PM, Jonathan Wakely wrote:
> For some reason the Filesystem library says that you can construct
> paths from iterators with value_type that is a possibly const encoded
> character type. I don't know why we support const value_type in this
> place, when normally that is
On Wed, Oct 12, 2016 at 4:36 PM, François Dumont wrote:
> On 10/10/2016 23:01, Tim Song wrote:
>>
>> Trying again...with a few edits.
>>
>>> On Mon, Oct 10, 2016 at 3:24 PM, François Dumont
>>> wrote:
>>>
>>> @@ -602,24 +612,32
Trying again...with a few edits.
> On Mon, Oct 10, 2016 at 3:24 PM, François Dumont
> wrote:
>
> @@ -602,24 +612,32 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> struct _Rb_tree_impl : public _Node_allocator
> {
>_Key_compare _M_key_compare;
> - _Rb_tree_node_base _M_header;
> + _
65 matches
Mail list logo
