On 19/06/2019 18:42, Matthew Woehlke wrote:
On 18/06/2019 19.59, Giuseppe D'Angelo via Development wrote:On 18/06/2019 23:27, Matthew Woehlke wrote:So... to be clear, your plan is to deprive Qt users of a (mostly) perfectly good wheel, that *is* being used by said users, and instead tell all of those users that they need to go (individually) reinvent the wheel?Why depriving? They can stay around, as-is. Current (and future) users can still use them...Mark wants to deprecate Q[E]SDP. That implies eventual removal, which absolutely *is* depriving users of something they were previously using. (Even just deprecating is requiring users to either a) stop using it, which again, is depriving them of it, or b) ignore deprecation warnings, which will not end well.)
I don't agree with the deprecation until we have a better alternative as public APIs. There's too much code using them.
Here's a thought... how about, instead, just [...] mark the conversions-to-pointer deprecated.I don't see why people writing "if (d)" should now get deprecation warnings and require const_casts to avoid them,...because, as previously noted, that code *detaches*, which is almost certainly not what you want!
I know that; I'm saying that 1) it's too late to change it (if we want, put it in QESDPV2); and 2) if (d) is supposed to be legitimate code to write, not something to trigger a deprecation warning.
And no cast is required to fix it; just write `if(d.constData())` instead. (Also as previously noted.)
"Just" is a huge understatement. This is a workaround for an API flaw. Not something to put under "best practices" of any kind, nor an acceptable solution for a deprecation warning.
Besides, I question the usefulness of implicit casts to pointer. The STL smart pointer classes don't have those, probably for a reason...
For the same reason implicit conversions are nitroglycerin: AnySmartPointer p; use(p + 42);
Personally, I only ever use Q[E]SDP via a d-func and associated helper
macros that make it clear if I'm detaching or not, and so (AFAIK) I've
never had such "surprises".
Compare:
// n.b. decltype(d) == QSharedDataPointer<MyClassData>
if (d->m_visible) // did this detach?
{
d->m_visible = false; // what about this?
}
- vs. -
QTE_D_SHARED();
// n.b. decltype(d) == MyClassData const*
if (d->m_visible) // definitely did not detach
{
QTE_D_DETACH(); // definitely *did* detach
// n.b. decltype(d) == MyClassData*
d->m_visible = false;
}
This is interesting, but I'd like to find a solution which avoids enforcing the scope/block structure of the program. Compare that with QEDSP, which allows to be more "streamlined" (of course at the cost of const incorrectness):
if (d->foo == foo)
return;
detach();
d->foo = foo;
d->bar = calc();
Note that proposing such macros is a case for deprecating QSDP/QESDP in
favour of something else.
My 2c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
