From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) by sourceware.org (Postfix) with ESMTPS id 4240A3857356 for ; Sun, 22 May 2022 18:23:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4240A3857356 Received: by mail-wr1-x42e.google.com with SMTP id u27so17308348wru.8 for ; Sun, 22 May 2022 11:23:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SY2Q33zx+Lrw5c9Bz4xs7zWF1AXTwS9lo+WXimqNQn8=; b=jQJTHPdwpbBwgmqGl3MqrnWDsgYXYh24ij2WichP27DLX4YvY+KUL6OH8fWcU7wprW GfgbKfQvpkWFjHEEXxFFsf4XArbNpaZjFJUfnNKgIpMFukmVKRR6+7H1Jbqj5HTMrAX0 bHDGdmcI87JnRkBJvKtteuCVHIrFgLwQFDNsNLQL+LNuQ/CsFViH6ckz2cMoCHQCmVGB 2jQtF8iOAkXulyrJp05VYma4nf8C6PNq1rID85SsqK1SQSUPALIyf1WkTuOW94XWDRo2 gedGxrPBojovGZx0R09vz6kb5EmiSfreCO1LorMiAMzO1ZzxHoAgjoTYDYNpUTCBX9YS 3/rw== X-Gm-Message-State: AOAM531b7pVn59pUfYmTrTfmPFaGag1wCw6IHll9BoNTZUKhYEo8zkZ1 wn3Erjfl2Es0qRvpm9XtUGlqt03kZa10d7pXKwk= X-Google-Smtp-Source: ABdhPJzOeDhlQBozbydK+1PlmTwILjKMBW1wQG3I5flOcgRS7LllYI3B2dA6XkzhB0IqGeCL6Gg+xQV8QkX097PQjRw= X-Received: by 2002:a5d:6c66:0:b0:20f:86f3:ea05 with SMTP id r6-20020a5d6c66000000b0020f86f3ea05mr9888397wrz.154.1653243812936; Sun, 22 May 2022 11:23:32 -0700 (PDT) MIME-Version: 1.0 References: <786553971.2049625.1653240191948.ref@mail.yahoo.com> <786553971.2049625.1653240191948@mail.yahoo.com> In-Reply-To: <786553971.2049625.1653240191948@mail.yahoo.com> From: Jonathan Wakely Date: Sun, 22 May 2022 19:23:22 +0100 Message-ID: Subject: Re: Question related to changes in template handling To: Klaus Lindemann Cc: "gcc-help@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_ASCII_DIVIDERS, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2022 18:23:36 -0000 On Sun, 22 May 2022 at 18:25, Klaus Lindemann via Gcc-help wrote: > > Hello, > was the handling of templates changed for g++12? I've run across some programs > which did compile with e.g. g++8, g++11, but no longer compile with g++12. > The fix is quite easy, but I wonder if this change is a bug, or a more strict > implementation of the standard. > Here is a short example program:================================================// compiles with g++ 11, not g++ 12 > #include namespace NN // if namespace is removed (i.e. global namespace is used), problem does not occur{ class OStr {};} > template NN::OStr& operator<<(NN::OStr& lhs, const std::vector& rhs) { return lhs << rhs[0]; } > // moving this definition before the other template definition fixes gcc 12 compile problemtemplate NN::OStr& operator<< (NN::OStr& lhs, const T& rhs) { return lhs << rhs; } > int main(){ std::vector a; NN::OStr os; os << a; return 0;}================================================= Reformatted so it's not illegible: #include namespace NN // if namespace is removed (i.e. global namespace is used), // problem does not occur { class OStr {}; } template NN::OStr& operator<<(NN::OStr& lhs, const std::vector& rhs) { return lhs << rhs[0]; } // moving this definition before the other template definition // fixes gcc 12 compile problem template NN::OStr& operator<< (NN::OStr& lhs, const T& rhs) { return lhs << rhs; } int main(){ std::vector a; NN::OStr os; os << a; return 0; } GCC 12 is correct. Your code is wrong. In the expression lhs << rhs[0], name lookup is done for operator<< by considering the overloads already visible at that point, and overloads that can be found by ADL in the associated namespaces. The associated namespaces for OStr and int are NN, and there is no viable overload in namepace NN. An operator that is part of the API of NN::OStr should be defined in namespace NN, not the global namespace. If you define both your operator<< overloads in the same namespace as class OStr it will work. N.B. this lookup is consistent for the non-template case, because GCC 12 has been fixed to stop looking in the global namespace when that is not an associated namespace.