public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Tim Song <t.canens.cpp@gmail.com>
To: "François Dumont" <frs.dumont@gmail.com>
Cc: Jonathan Wakely <jwakely@redhat.com>,
	libstdc++@gcc.gnu.org, 	gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] 77864 Fix noexcept conditions for map/set default constructors
Date: Wed, 12 Oct 2016 21:26:00 -0000	[thread overview]
Message-ID: <CAPQZVxv-jxMaP7sJsCXY6FkMW7Q1QpnDN68rp2js8U+Kfra+Jg@mail.gmail.com> (raw)
In-Reply-To: <7363dc77-9f64-f2f7-35ea-163f5486f66f@gmail.com>

On Wed, Oct 12, 2016 at 4:36 PM, François Dumont <frs.dumont@gmail.com> 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 <frs.dumont@gmail.com>
>>> 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;
>>> +  _Rb_header_node _M_header;
>>> +#if __cplusplus < 201103L
>>>     size_type _M_node_count; // Keeps track of size of tree.
>>> +#else
>>> +  size_type _M_node_count = 0; // Keeps track of size of tree.
>>> +#endif
>>>
>>> +#if __cplusplus < 201103L
>>>     _Rb_tree_impl()
>>> -  : _Node_allocator(), _M_key_compare(), _M_header(),
>>> -    _M_node_count(0)
>>> -  { _M_initialize(); }
>>> +  : _M_node_count(0)
>>> +  { }
>>> +#else
>>> +  _Rb_tree_impl() = default;
>>> +#endif
>>
>>
>> The default constructor of the associative containers is required to
>> value-initialize the comparator (see their synopses in
>> [map/set/multimap/multiset.overview]).
>
> I don't have latest Standard version so can't see the exact word but I find
> quite annoying that the Standard doesn't allow this simple implementation.

The "exact word" is:

    map() : map(Compare()) { }

which mandates the comparator be copied from a value-initialized Compare.
The use of () means value-initialization.

>
> I don't know if unodered containers have same kind of requirements for equal
> or hash functors but if so current implementation doesn't do this value
> initialization.


Yes, unordered_meows are required to do that as well. See, e.g.,
https://timsong-cpp.github.io/cppwp/unord.map.cnstr:

unordered_map() : unordered_map(size_type(see below)) { }
explicit unordered_map(size_type n,
                                      const hasher& hf = hasher(),
                                      const key_equal& eql = key_equal(),
                                      const allocator_type& a =
allocator_type());

The default constructor is specified to call the second constructor,
which copies the hasher etc. from a value-initialized object.

Tim

>
> So here is another attempt. This time it simply allows to have noexcept
> condition in one place and closer to where operations are being invoked.
>
> Ok to commit after tests ?
>
> François
>
>>
>>   _Rb_tree_impl() = default; doesn't do that; it default-initializes the
>>   comparator instead.
>>
>> Tim
>>
>

  reply	other threads:[~2016-10-12 21:26 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-05 11:56 Jonathan Wakely
2016-10-05 12:11 ` Marc Glisse
2016-10-05 12:13   ` Jonathan Wakely
2016-10-06 20:17     ` François Dumont
2016-10-06 21:34       ` Jonathan Wakely
2016-10-08 20:55         ` François Dumont
2016-10-09 15:14           ` Jonathan Wakely
2016-10-09 15:38             ` Jonathan Wakely
2016-10-10 19:24             ` François Dumont
     [not found]               ` <CAPQZVxvFJb4gwj2cpxvTPZgBtiyZyviqz0iLhW4sAY6rSrjn6w@mail.gmail.com>
2016-10-10 21:01                 ` Tim Song
2016-10-12 20:36                   ` François Dumont
2016-10-12 21:26                     ` Tim Song [this message]
2016-10-23 13:54                     ` François Dumont
2016-10-24 11:03                     ` Jonathan Wakely
2016-10-25 19:55                       ` François Dumont
2016-10-26  8:22                         ` 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=CAPQZVxv-jxMaP7sJsCXY6FkMW7Q1QpnDN68rp2js8U+Kfra+Jg@mail.gmail.com \
    --to=t.canens.cpp@gmail.com \
    --cc=frs.dumont@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jwakely@redhat.com \
    --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).