Re: [Development] Copying a struct the easy (perhaps too easy) way

On 2023-09-16 01:55, Giuseppe D'Angelo via Development wrote: Wrong mailing list? Il 16/09/23 01:41, Henry Skoglund ha scritto: S a; S b = a.clone(); it seems to work like a charm (6.5.2 on Linux and the Mac. 5.15.2 on Windows) but my question is if it's kosher? You class has value

Re: [Development] Copying a struct the easy (perhaps too easy) way

Wrong mailing list? Il 16/09/23 01:41, Henry Skoglund ha scritto: S a; S b = a.clone(); it seems to work like a charm (6.5.2 on Linux and the Mac. 5.15.2 on Windows) but my question is if it's kosher? You class has value semantics, so: S b = a; I have bad memories from my MFC days in the

[Development] Copying a struct the easy (perhaps too easy) way

Hi, just got the need to copy a struct so I started doing it the hard way (i.e. member by member) but on a lark I tried a simple copy from *this, say like this: struct S {     int i;     QString s;     QDate d;     QStringList sl;     S clone() { return *this; } }; S a; S b = a.clone(); it

Re: [Development] How to document API only deprecated in future Qt versions

> I'm not sure how viable this is, it's just an idea off the top of my head: we > could perhaps implement support > for "from/until" e.g. in the class members section, similar to what's on > cppreference.com (e.g. void foo() > [since 5.15, until 6.5]). The docs for

Re: [Development] How to document API only deprecated in future Qt versions

On 15 Sep 2023, at 10:44, Edward Welbourne via Development wrote: On 9/15/23 09:36, Kai Köhne via Development wrote: The methods are formally marked as deprecated for Qt 6.10. But the methods are already in the '-obsolete' page for Qt 6.6, which leaves the API in a weird in-between state.

Re: [Development] How to document API only deprecated in future Qt versions

On 9/15/23 09:36, Kai Köhne via Development wrote: >> The methods are formally marked as deprecated for Qt 6.10. But the >> methods are already in the '-obsolete' page for Qt 6.6, which leaves >> the API in a weird in-between state. Christian Kandeler (15 September 2023 10:31) wrote: > Radical

Re: [Development] How to document API only deprecated in future Qt versions

On 9/15/23 09:36, Kai Köhne via Development wrote: The methods are formally marked as deprecated for Qt 6.10. But the methods are already in the '-obsolete' page for Qt 6.6, which leaves the API in a weird in-between state. Radical idea: Treat all deprecated functions as if they didn't

Re: [Development] How to document API only deprecated in future Qt versions

Hi, > I see two fixes for this; > - Keep the documentation API fix separate from the header file fix, and only > merge it when Qt 6.9 got branched. > This requires 'someone' to follow up on these things, though, more than a > year after the deprecation decision has been made. This approach

Re: [Development] How to document API only deprecated in future Qt versions

Kai Köhne (15 September 2023 09:36) wrote: > I see why this 'conservative' approach is beneficial. Projects like Qt > Creator tend to support multiple Qt versions, and immediately > deprecating an old API in the same version the replacement API got > added makes this hard to handle. Note that

[Development] How to document API only deprecated in future Qt versions

Hi, Eddy and Ivan did a great job in documenting how to formally deprecate API in at https://wiki.qt.io/Deprecation . It's not only giving you the right macros to use ... it also contains some suggestions for which version to do it. About the Qt version to deprecate an API for, the page says: