> (*) That macro that does nothing until C++20 anyway, so I’d also add the > support for the optional string-literal that C++20 also introduces..
Our tests actually show that this macro provides an expected warning on most of the compilers that we use in the CI, even in C++17 mode. IIRC, in my tests I only had issues with INTEGRITY, GCC 9.3.1 on OpenSuse 15.4, and QCC 8.3.0 on QNX. For these platforms the macro currently does nothing. Best regards, Ivan ------------------------------ Ivan Solovev Senior Software Engineer The Qt Company GmbH Erich-Thilo-Str. 10 12489 Berlin, Germany ivan.solo...@qt.io www.qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ________________________________ From: Development <development-boun...@qt-project.org> on behalf of Volker Hilsheimer via Development <development@qt-project.org> Sent: Sunday, June 18, 2023 2:59 PM To: Macieira, Thiago <thiago.macie...@intel.com>; development@qt-project.org <development@qt-project.org> Subject: Re: [Development] C++20 ctor-level [[nodiscard]] (was: Re: C++20 @ Qt) > On 16 Jun 2023, at 20:25, Thiago Macieira <thiago.macie...@intel.com> wrote: > > On Friday, 16 June 2023 11:05:30 PDT Giuseppe D'Angelo via Development wrote: >> On 16/06/2023 18:00, Thiago Macieira wrote: >>> On Friday, 16 June 2023 01:06:33 PDT Stephen Kelly wrote: >>>> Make sure you're not hitting >>>> >>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96117 >>> >>> We are indeed hitting that. But there's nothing we can currently do about >>> it. >> Why can't we turn Q_DECL_EXPORT to [[gnu::visibility("default")]] to >> work around the bug? > > Marc to comment, but I don't think it solves the MSVC problem we're also > hitting, which means that adding no_discard to classes is still a problem. > Therefore, there's no point in changing our Q_DECL_EXPORT. > > We'd also need to change *all* our __attributes__, not just the visibility > ones, and we still risk breaking users' code that have __attributes__ in their > classes and especially functions but use Q_DECL_EXPORT. > > Think of declarations like: > > [[nodiscard]] Q_CORE_EXPORT Q_DECL_PURE_FUNCTION qsizetype qustrlen(const > char16_t *str) noexcept; My take-away is: What we should care about is the small set of RAII classes where the side-effects of the constructor and destructor are the whole point. E.g. it would be good if we can reliably encourage a compiler warning for Listing 1: QMutexLocker(&mutex); because that mistake is easily made and positively harmful. >From what I get out of this recap of the state of standard and compilers, it >seems that we can't: class-level [[nodiscard]] doesn’t give us that warning >(reliably, on all compilers), while it does give us warnings that we might not >want (ie when not using the return value of a function). And it’s problematic >to use with whole-sale exported classes; but since RAII types like >QMutexLocker shouldn’t be exported whole-sale anyway, that’s perhaps not a >problem in practice. So, agree with Marc’s proposal to drop (or at least not add any new) usage of class-level [[nodiscard]], and to use constructor-level [[nodiscard]] instead via Q_NODISCARD_CTOR (*). This still makes it a good service to Qt users that are on C++ 20. For everyone else, things are as they were before. For all other types, I think it’s quite alright that users writing code as per Marc's Listings 2-4: QSize(12, 32); have to figure out the “hard" way why there is no variable to pass into the function that they were planning on calling. Volker (*) That macro that does nothing until C++20 anyway, so I’d also add the support for the optional string-literal that C++20 also introduces.. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
