From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hamza.pair.com (hamza.pair.com [209.68.5.143]) by sourceware.org (Postfix) with ESMTPS id 53F3A3858D28; Fri, 3 Mar 2023 22:47:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 53F3A3858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=pfeifer.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=pfeifer.com Received: from hamza.pair.com (localhost [127.0.0.1]) by hamza.pair.com (Postfix) with ESMTP id 0893633EC4; Fri, 3 Mar 2023 17:47:44 -0500 (EST) Received: from [192.168.1.80] (188-23-63-229.adsl.highway.telekom.at [188.23.63.229]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hamza.pair.com (Postfix) with ESMTPSA id 5F83933EC1; Fri, 3 Mar 2023 17:47:43 -0500 (EST) Date: Fri, 3 Mar 2023 23:47:41 +0100 (CET) From: Gerald Pfeifer To: Jonathan Wakely cc: gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org Subject: Re: [wwwdocs] Document allocator_traits::rebind_alloc assertion with GCC 13 In-Reply-To: <20230302205614.1564709-1-jwakely@redhat.com> Message-ID: References: <20230302205614.1564709-1-jwakely@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: mailmunge 3.11 on 209.68.5.143 X-Spam-Status: No, score=-9.2 required=5.0 tests=BAYES_00,GIT_PATCH_0,KAM_DMARC_STATUS,KAM_NUMSUBJECT,RCVD_IN_BARRACUDACENTRAL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, 2 Mar 2023, Jonathan Wakely via Gcc-patches wrote: > Pushed to wwwdocs. Thank you! > +If an allocator type Alloc<T> Note that HTML 5 complains about the use of and we are using instead. I just pushed the following patch addressing that. (The diff looks a bit bigger due to changes re line breaks.) Gerald 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.