From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 2142) id B49C63858D28; Fri, 3 Mar 2023 22:41:57 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B49C63858D28 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1677883317; bh=CA8akz6NZ2LjlQ5+NviEuB0GZFZZc6iceek3gmMBlgQ=; h=To:Subject:Date:From:From; b=YO1vMRfjTls95yG5U5msAyzBUhW71ufXac5AP2GAVXSefbIqPEpw+5XKlAC1s1P86 jj0J7LmudR5oMuHwhJAuvrpgn0oycR2rvUFMkC6hovrpjCRc0EglFcvLmSIu6e0iDp COAxNTl2ca8azMqCRby7zbUzwgiCu3tWvDjW80d8= To: gcc-cvs-wwwdocs@gcc.gnu.org Subject: gcc-wwwdocs branch master updated. 5a75fbda8c3c647b2ef659ffe67a031ee957abe6 X-Git-Refname: refs/heads/master X-Git-Reftype: branch X-Git-Oldrev: 935fcdebfb2fb4dcd89edb51ebed5f1be0fb41e5 X-Git-Newrev: 5a75fbda8c3c647b2ef659ffe67a031ee957abe6 Message-Id: <20230303224157.B49C63858D28@sourceware.org> Date: Fri, 3 Mar 2023 22:41:57 +0000 (GMT) From: Gerald Pfeifer List-Id: This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "gcc-wwwdocs". The branch, master has been updated via 5a75fbda8c3c647b2ef659ffe67a031ee957abe6 (commit) from 935fcdebfb2fb4dcd89edb51ebed5f1be0fb41e5 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 5a75fbda8c3c647b2ef659ffe67a031ee957abe6 Author: Gerald Pfeifer Date: Fri Mar 3 23:41:36 2023 +0100 gcc-13: Use instead of diff --git a/htdocs/gcc-13/porting_to.html b/htdocs/gcc-13/porting_to.html index 953e1453..733bb254 100644 --- a/htdocs/gcc-13/porting_to.html +++ b/htdocs/gcc-13/porting_to.html @@ -150,8 +150,8 @@ previous behavior. GCC 13 now checks that allocators used with the standard library can be "rebound" to allocate memory for a different type, as required by the allocator requirements in the C++ standard. -If an allocator type Alloc<T> -cannot be correctly rebound to another type Alloc<U>, +If an allocator type Alloc<T> +cannot be correctly rebound to another type Alloc<U>, you will get an error like this:

@@ -161,26 +161,27 @@ you will get an error like this:

The assertion checks that rebinding an allocator to its own value type is a -no-op, which will be true if its rebind member is defined correctly. +no-op, which will be true if its rebind member is defined correctly. If rebinding it to its own value type produces a different type, then the allocator cannot be used with the standard library.

-The most common cause of this error is an allocator type Alloc<T> -that derives from std::allocator<T> but does not provide its own -rebind member. When the standard library attempts to rebind the -allocator using Alloc<T>::rebind<U> it finds the -std::allocator<T>::rebind<U> member from the base class, -and the result is std::allocator<U> instead of -Alloc<U>. +The most common cause of this error is an allocator type +Alloc<T> that derives from +std::allocator<T> but does not provide its own +rebind member. When the standard library attempts to rebind the +allocator using Alloc<T>::rebind<U> it finds the +std::allocator<T>::rebind<U> member from the base +class, and the result is std::allocator<U> instead of +Alloc<U>.

-The solution is to provide a correct rebind member as shown below. -A converting constructor must also be provided, so that that an -Alloc<U> can be constructed from an Alloc<T>, -and vice versa: +The solution is to provide a correct rebind member as shown +below. A converting constructor must also be provided, so that that an +Alloc<U> can be constructed from an +Alloc<T>, and vice versa: 


 template<class T>
@@ -197,9 +198,10 @@ class Alloc

-Since C++20, there is no rebind member in std::allocator, -so deriving your own allocator types from std::allocator is simpler -and doesn't require the derived allocator to provide its own rebind. +Since C++20, there is no rebind member in +std::allocator, so deriving your own allocator types from +std::allocator is simpler and doesn't require the derived +allocator to provide its own rebind. For compatibility with previous C++ standards, the member should still be provided. The converting constructor is still required even in C++20.

----------------------------------------------------------------------- Summary of changes: htdocs/gcc-13/porting_to.html | 36 +++++++++++++++++++----------------- 1 file changed, 19 insertions(+), 17 deletions(-) hooks/post-receive -- gcc-wwwdocs