пн, 27 мая 2019 г. в 11:46, Edward Welbourne :
> сб, 25 мая 2019 г., 12:30 Mutz, Marc via Development
> Repeat after me: default ctors do _not_ establish a valid value.
>
> As an aged C programmer I can respect that ;^>
>
> On 2019-05-25 17:24, Konstantin Ritt wrote:
> >>> Perhaps you mean
сб, 25 мая 2019 г., 12:30 Mutz, Marc via Development
Repeat after me: default ctors do _not_ establish a valid value.
As an aged C programmer I can respect that ;^>
On 2019-05-25 17:24, Konstantin Ritt wrote:
>>> Perhaps you mean "trivial type's default ctors do _not_ establish a
>>> valid
сб, 25 мая 2019 г., 20:42 Mutz, Marc via Development <
development@qt-project.org>:
> On 2019-05-25 17:24, Konstantin Ritt wrote:
> > сб, 25 мая 2019 г., 12:30 Mutz, Marc via Development
> >> Repeat after me: default ctors do _not_ establish a valid value.
> >
> > Perhaps you mean "trivial type's
On 2019-05-25 17:24, Konstantin Ritt wrote:
сб, 25 мая 2019 г., 12:30 Mutz, Marc via Development
Repeat after me: default ctors do _not_ establish a valid value.
Perhaps you mean "trivial type's default ctors do _not_ establish a
valid value"?
No, I actually meant default ctor. What should
сб, 25 мая 2019 г., 12:30 Mutz, Marc via Development <
development@qt-project.org>:
> Further to the question about default ctors for such "obvious" stuff as
>
> On 2019-05-21 10:27, Mutz, Marc via Development wrote:
> > class QRect {
> >int x, y, w, h;
> > public:
> >
Further to the question about default ctors for such "obvious" stuff as
On 2019-05-21 10:27, Mutz, Marc via Development wrote:
class QRect {
int x, y, w, h;
public:
QRect() = default;
};
QRect r; // partially-formed
r.x(); // compilers _already_ warn about
Hi,
Il 19/05/19 14:24, Giuseppe D'Angelo via Development ha scritto:
Hence, I'll ask here: what should the status of a moved-from object be?
I'm not really interested in_how_ to achieve such status (although of
course it's very important, and should influence the decision); I'm
interested in
Hi,
Il 24/05/19 15:24, Simon Hausmann ha scritto:
Hi,
I don't think our users should have to use a build of Qt that has its
internal Q_ASSERTs enabled. IMHO Q_ASSERT should be used by developers
in Qt to express invariants that, if violated, represent a bug in Qt
that needs fixing. I don't
Subject: Re: [Development] What's the status of a moved-from object?
Il 23/05/19 09:36, Simon Hausmann ha scritto:
> I think a well-formed state is more likely to enable our users to have a
> productive time. Operating - by accident - on a partially-formed object
> and either
>
> (1
Il 23/05/19 09:36, Simon Hausmann ha scritto:
I think a well-formed state is more likely to enable our users to have a
productive time. Operating - by accident - on a partially-formed object
and either
(1) seeing a back-trace that points into Qt, not my application code
(2)
D'Angelo via Development
Sent: Sunday, May 19, 2019 14:24
To: development@qt-project.org
Subject: [Development] What's the status of a moved-from object?
Hi,
I'm trying to find a resolution for
> https://codereview.qt-project.org/#/c/261564/
TL;DR: the patch removes the move constructor f
вт, 21 мая 2019 г., 14:25 Mutz, Marc via Development <
development@qt-project.org>:
> On 2019-05-21 13:03, Konstantin Ritt wrote:
> > вт, 21 мая 2019 г., 11:32 Mutz, Marc via Development
> > :
> >
> >> And while the partially-formed
> >> state can be extended to non-pimpled classes easily:
> >>
>
On 2019-05-21 13:03, Konstantin Ritt wrote:
вт, 21 мая 2019 г., 11:32 Mutz, Marc via Development
:
And while the partially-formed
state can be extended to non-pimpled classes easily:
class QRect {
int x, y, w, h;
public:
QRect() = default;
};
QRect r; // partially-formed
r.x(); // compilers
On 2019-05-21 12:52, Julien Cugnière wrote:
Le mar. 21 mai 2019 à 10:32, Mutz, Marc via Development
a écrit :
It is, however, be an acceptable stop-gap measure, and here a
compromise
may emerge, for keeping old code working while preparing for a
fully-implemented partially-formed state. This
вт, 21 мая 2019 г., 11:32 Mutz, Marc via Development <
development@qt-project.org>:
> And while the partially-formed
> state can be extended to non-pimpled classes easily:
>
> class QRect {
> int x, y, w, h;
> public:
> QRect() = default;
> };
> QRect r; //
Le mar. 21 mai 2019 à 10:32, Mutz, Marc via Development
a écrit :
> It is, however, be an acceptable stop-gap measure, and here a compromise
> may emerge, for keeping old code working while preparing for a
> fully-implemented partially-formed state. This would mean we do assign
> meaning to a
Den tis 21 maj 2019 kl 10:57 skrev Giuseppe D'Angelo via Development
:
>
> Il 21/05/19 10:26, Elvis Stansvik ha scritto:
> > They will not show up in the web search (I think).
> >
> > They are however available in the debian-debug archive, see
> > https://wiki.debian.org/AutomaticDebugPackages
>
>
Il 21/05/19 10:26, Elvis Stansvik ha scritto:
They will not show up in the web search (I think).
They are however available in the debian-debug archive, see
https://wiki.debian.org/AutomaticDebugPackages
[snip]
Genuine question, are those just the debug builds of a release build, or
are
On Tue, May 21, 2019 at 11:26 AM Elvis Stansvik wrote:
> They will not show up in the web search (I think).
>
> They are however available in the debian-debug archive, see
> https://wiki.debian.org/AutomaticDebugPackages
Oh! You got me there. I was not aware of that. Thanks for pointing it
Hi Lars,
There is a fine line between a proper partially-formed state and
basically folding std::optional into every value class.
The former is a compile-time state. It is not observable at runtime,
because any code which would observe a difference invokes UB. This is
the same principle as
Den tis 21 maj 2019 kl 09:55 skrev Konstantin Shegunov :
>
> On Tue, May 21, 2019 at 9:49 AM Mutz, Marc via Development
> wrote:
>>
>> Oh, a nullptr deref is pretty clear in a backtrace.
>
>
> Indeed, but my point is that it's relatively useless for the user (or for the
> developer for that
On Tue, May 21, 2019 at 9:49 AM Mutz, Marc via Development <
development@qt-project.org> wrote:
> Oh, a nullptr deref is pretty clear in a backtrace.
Indeed, but my point is that it's relatively useless for the user (or for
the developer for that matter). As you pointed out the dev sees the
> On 20 May 2019, at 20:18, Mutz, Marc via Development
> wrote:
>
> On 2019-05-20 17:16, Thiago Macieira wrote:
>> On Monday, 20 May 2019 05:51:49 PDT Mutz, Marc via Development wrote:
>>> Or maybe we don't disagree at all and Thiago would accept allocating
>>> memory (or, by extension,
On 2019-05-20 22:58, Konstantin Shegunov wrote:
[...]
I agree as well, although I have a minor nitpick. Q_ASSERT works only
if it was not stripped while building Qt. Meaning that I'm often
working, as I'm sure other users, on Linux especially, with the
default (i.e. release) version of Qt from
On Monday, 20 May 2019 12:05:58 PDT Allan Sandfeld Jensen wrote:
> I agree. I would consider anything other than deleting or reassigning a
> moved object undefined behavior, so asserting on it seems like a good help
> to users of our APIs.
I agree, but we should leave this as a fallback case,
On Montag, 20. Mai 2019 22:58:49 CEST Konstantin Shegunov wrote:
> On Mon, May 20, 2019 at 10:07 PM Allan Sandfeld Jensen
>
> wrote:
> > On Montag, 20. Mai 2019 20:18:32 CEST Mutz, Marc via Development wrote:
> > > Where we still, maybe, disagree, is whether d == nullptr is a valid
> > > state.
Il 20/05/19 22:58, Konstantin Shegunov ha scritto:
I agree as well, although I have a minor nitpick. Q_ASSERT works only if
it was not stripped while building Qt. Meaning that I'm often working,
as I'm sure other users, on Linux especially, with the default (i.e.
release) version of Qt from
On Tue, May 21, 2019 at 12:27 AM André Pönitz wrote:
> > Somehow *suggest* to the user that [s]he's supposed to build in
> > debug mode otherwise they're on their own?
>
> Nobody forces you to use Q_ASSERT.
>
Now you lost me. I don't, it was suggested as a means to prevent at-library
site
On Mon, May 20, 2019 at 11:58:49PM +0300, Konstantin Shegunov wrote:
> I agree as well, although I have a minor nitpick. Q_ASSERT works only if it
> was not stripped while building Qt. Meaning that I'm often working, as I'm
> sure other users, on Linux especially, with the default (i.e. release)
>
On Mon, May 20, 2019 at 10:07 PM Allan Sandfeld Jensen
wrote:
> On Montag, 20. Mai 2019 20:18:32 CEST Mutz, Marc via Development wrote:
> > Where we still, maybe, disagree, is whether d == nullptr is a valid
> > state. The difference is whether member functions other then destruction
> > and
Il 20/05/19 20:36, André Pönitz ha scritto:
I actually think we should consider getting rid of shared_null and
instead have d == nullptr as the null/default constructed state of the
object. Yes, that means we need to check for d == nullptr in member
functions, but I don’t think the overhead is a
On Montag, 20. Mai 2019 20:18:32 CEST Mutz, Marc via Development wrote:
> On 2019-05-20 17:16, Thiago Macieira wrote:
> > On Monday, 20 May 2019 05:51:49 PDT Mutz, Marc via Development wrote:
> >> Or maybe we don't disagree at all and Thiago would accept allocating
> >> memory (or, by extension,
On Mon, May 20, 2019 at 01:56:56PM +, Lars Knoll wrote:
> > On 20 May 2019, at 14:51, Mutz, Marc via Development
> > wrote:
> >
> > On 2019-05-20 11:25, Giuseppe D'Angelo via Development wrote:
> >> Hi, Il 19/05/19 18:54, Thiago Macieira ha scritto:
> >>> But I think all Qt classes should go
On 2019-05-20 17:16, Thiago Macieira wrote:
On Monday, 20 May 2019 05:51:49 PDT Mutz, Marc via Development wrote:
Or maybe we don't disagree at all and Thiago would accept allocating
memory (or, by extension, anything that's noexcept(false)) as a very
good reason to have a nullptr d?
I hadn't
On Monday, 20 May 2019 06:56:56 PDT Lars Knoll wrote:
I actually think we should consider getting rid of shared_null and
instead have d == nullptr as the null/default constructed state of
the object. Yes, that means we need to check for d == nullptr in
member functions, but I
On 20.05.19 17:27, Konstantin Tokarev wrote:
20.05.2019, 18:21, "Thiago Macieira" :
On Monday, 20 May 2019 06:56:56 PDT Lars Knoll wrote:
I actually think we should consider getting rid of shared_null and instead
have d == nullptr as the null/default constructed state of the object. Yes,
20.05.2019, 18:21, "Thiago Macieira" :
> On Monday, 20 May 2019 06:56:56 PDT Lars Knoll wrote:
>> I actually think we should consider getting rid of shared_null and instead
>> have d == nullptr as the null/default constructed state of the object. Yes,
>> that means we need to check for d ==
On Monday, 20 May 2019 06:56:56 PDT Lars Knoll wrote:
> I actually think we should consider getting rid of shared_null and instead
> have d == nullptr as the null/default constructed state of the object. Yes,
> that means we need to check for d == nullptr in member functions, but I
> don’t think
On Monday, 20 May 2019 05:51:49 PDT Mutz, Marc via Development wrote:
> Or maybe we don't disagree at all and Thiago would accept allocating
> memory (or, by extension, anything that's noexcept(false)) as a very
> good reason to have a nullptr d?
I hadn't thought of noexcept, but let's be clear:
> On 20 May 2019, at 14:51, Mutz, Marc via Development
> wrote:
>
> On 2019-05-20 11:25, Giuseppe D'Angelo via Development wrote:
>> Hi,
>> Il 19/05/19 18:54, Thiago Macieira ha scritto:
>>> But I think all Qt classes should go beyond that, unless they have VERY good
>>> reasons not to do so
On 2019-05-20 11:25, Giuseppe D'Angelo via Development wrote:
Hi,
Il 19/05/19 18:54, Thiago Macieira ha scritto:
But I think all Qt classes should go beyond that, unless they have
VERY good
reasons not to do so (and document so). The moved-from object should
also be
in a valid state so all
Hi,
Il 19/05/19 18:54, Thiago Macieira ha scritto:
But I think all Qt classes should go beyond that, unless they have VERY good
reasons not to do so (and document so). The moved-from object should also be
in a valid state so all the accessor and mutation API in the class can operate
in the
On Sunday, 19 May 2019 05:24:14 PDT Giuseppe D'Angelo via Development wrote:
> Hence, I'll ask here: what should the status of a moved-from object be?
> I'm not really interested in _how_ to achieve such status (although of
> course it's very important, and should influence the decision); I'm
>
Hi,
I'm trying to find a resolution for
https://codereview.qt-project.org/#/c/261564/
TL;DR: the patch removes the move constructor from QColorSpace, because
that move constructor leaves the moved-from object in a partially-formed
state.
I have nothing against that idea (on the
44 matches
Mail list logo
