<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 20, 2019 at 10:07 PM Allan Sandfeld Jensen <<a href="mailto:kde@carewolf.com">kde@carewolf.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Montag, 20. Mai 2019 20:18:32 CEST Mutz, Marc via Development wrote:<br>> Where we still, maybe, disagree, is whether d == nullptr is a valid<br>
> state. The difference is whether member functions other then destruction<br>
> and assignment check for a nullptr d. I'd propose that on classes under<br>
> the above premiss, Q_D contains Q_ASSERT(d). This, I think, strikes the<br>
> best balance between safety and speed.<br>
<br>
I agree. I would consider anything other than deleting or reassigning  a moved <br>
object undefined behavior, so asserting on it seems like a good help to users <br>
of our APIs.<br></blockquote><div><br></div><div>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 the repo. Granted it may be my own fault, but in this case the assert isn't tripped and this code simply segfaults for reasons that aren't so obvious. Any suggestions how to mitigate that? Somehow *suggest* to the user that [s]he's supposed to build in debug mode otherwise they're on their own?<br></div></div></div>