Re: [Development] Deprecated functions / procedure of removal in Qt6?
Am 22.10.2018 um 00:14 schrieb Giuseppe D'Angelo via Development: Hi, Thus, adding deprecation warnings is definitely the right thing to do: users get the deprecation warnings (*), and we have an easy way to find and drop all those functions. Ok, I'll go on with adding Q_DECL_DEPRECATED + QT_VERSION < QT_VERSION_CHECK(6, 0, 0) in the places where only the documentation states that this function is deprecated then. Otherwise they might get forgotten again :) Thx, Christian ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] HEADS UP : Qt 5.12 string freeze
Hi, As informed earlier string freeze for Qt 5.12 is now in effect. So please, no changes to translatable strings from this point, unless approved by the documentation team. br, Jani From: Development on behalf of Jani Heikkinen Sent: Thursday, October 11, 2018 7:50 AM To: localizat...@qt-project.org Cc: development@qt-project.org; releas...@qt-project.org Subject: [Development] HEADS UP : Qt 5.12 soft string freeze Hi all, First beta release from Qt 5.12 is already out so it is time to start keeping translatable strings as it is. And let's have official string freeze Fri 19th October 2018. br, Jani ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecated functions / procedure of removal in Qt6?
Hi,
Il 21/10/18 19:59, Christian Ehrlicher ha scritto:
there are a lot of deprecated functions in qtbase which are only marked
as deprecated/obsolete in the documentation but don't have a
Q_DECL_DEPRECATED. Most of them were deprecated in the pre Qt5-era.
What's the 'correct' way to make sure they can be removed with Qt6? Must
they marked as QT_DEPRECATED_SINCE(5,x) or is the comment in the
documentation enough?
The documentation comment is enough for us to justify the removal -- in
other words, "formally", we have informed the user to move away, and the
rule is that we can drop deprecated functions any time we want to break
source compatibility.
However, it's nowhere enough to
1) make users _aware_ of the fact that they're using deprecated APIs;
2) make us _remember_ to remove those functions when we have the chance
(like in Qt 6).
Thus, adding deprecation warnings is definitely the right thing to do:
users get the deprecation warnings (*), and we have an easy way to find
and drop all those functions.
The other ways to achieve 2) at the moment are:
* If possible, all the code to be killed in Qt 6 should already be
protected via
#if QT_VERSION < QT_VERSION_CHECK(6, 0, 0)
* Add some comment in the source code like
// ### Qt 6: remove this
Both ways are more general and apply to functions we can't just
deprecate or remove (f.i., marking an overload to be merged with another
one via a default argument, getting rid of useless special member
function declarations, and the like).
Of course, simply leaving a comment requires us to remember find those
usages and act on those, and the code is still full of such TODOs for Qt
5...
(*) I don't like that the deprecation warnings are opt-in and not
opt-out. People deserve to know as soon as possible that they're using
deprecated functionality, rather than have a gigantic unpleasant
surprise ("you're using lots of deprecated stuff that got removed!")
when Qt 6 comes.
My 2 c,
--
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: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Un-inlining members allowed?
On Sunday, 21 October 2018 11:07:38 PDT Christian Ehrlicher wrote: > Hi, > > one more question - is it ok to un-inline a function? For example I want > to move QListWidgetItem::isSelected() to the cpp file so I can properly > mark QListWidget::isItemSelected() as deprecated but I'm unsure if this > is allowed. De-inlining is binary and source compatible, so long as you accept that the old code that did inline the function continues to do what it used o do. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Un-inlining members allowed?
Hi, one more question - is it ok to un-inline a function? For example I want to move QListWidgetItem::isSelected() to the cpp file so I can properly mark QListWidget::isItemSelected() as deprecated but I'm unsure if this is allowed. Thx, Christian ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Deprecated functions / procedure of removal in Qt6?
Hi, there are a lot of deprecated functions in qtbase which are only marked as deprecated/obsolete in the documentation but don't have a Q_DECL_DEPRECATED. Most of them were deprecated in the pre Qt5-era. What's the 'correct' way to make sure they can be removed with Qt6? Must they marked as QT_DEPRECATED_SINCE(5,x) or is the comment in the documentation enough? Thx, Christian ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
Den sön 21 okt. 2018 kl 17:50 skrev Giuseppe D'Angelo
:
>
> Hello,
>
> Il 21/10/18 16:15, Elvis Stansvik ha scritto:
> > I couldn't find a way to contact them.
>
> The best shot would be the std-discussion mailing list, I think.
>
> > In order to try out the unsafe usage you suggested in your other mail,
> > and also another unsafe usage pointed out in an SO question
> > (https://stackoverflow.com/questions/39051460/why-does-as-const-forbid-rvalue-arguments/39051612#39051612),
> > I made the following test program.
> >
> > The output when running is:
> >
> > [estan@newton move-to-const-test]$ ./move-to-const-test
> > without moveToConst:
> > FooPrivate constr from vector
> > Foo constr with arg 0x7fffdb627200
> > Foo begin 0x7fffdb627200
> > Foo end 0x7fffdb627200
> > Foo destr 0x7fffdb627200
> > FooPrivate destr
> >
> > with moveToConst:
> > FooPrivate constr from vector
> > Foo constr with arg 0x7fffdb627208
> > Foo move constr 0x7fffdb627210
> > Foo destr 0x7fffdb627208
> > Foo begin const 0x7fffdb627210
> > Foo end const 0x7fffdb627210
> > Foo destr 0x7fffdb627210
> > FooPrivate destr
> > [estan@newton move-to-const-test]$
> >
> > Which just shows it's working as intended.
>
> However the third test should be a without moveToConst, but storing in a
> temporary, i.e. the current best practice. It should output exactly like
> the first one, but of course call const begin/end.
For completeness sake, indeed
qDebug() << "with recommended way:";
const auto stuff = f();
for (auto v : stuff) { Q_UNUSED(v); }
gives
with recommended way:
FooPrivate constr from vector
Foo constr with arg 0x7ffdc9d50040
Foo begin const 0x7ffdc9d50040
Foo end const 0x7ffdc9d50040
Foo destr 0x7ffdc9d50040
FooPrivate destr
as expected.
Elvis
>
> And note the extra move/destruciton in the second example.
>
>
> > The two unsafe usages are commented out, because they wouldn't compile
> > (good!).
>
>
> Whops, you're absolutely right. My bad. With your proposed implementation:
>
> > template
> > const T moveToConst(T &)
> > {
> > return std::move(t);
> > }
>
> This won't compile when called on a non-const lvalue (the return type
> will be a lvalue reference to const, which won't bind to a non-const
> rvalue). I stand corrected.
>
> Which actually makes me think of yet another possibility of misuse, that
> is, applying moveToConst to a function returning a const object. That
> will compile, using a copy...
>
> > const QVector getVector();
> > for (auto : moveToConst(getVector()) ~~~
>
>
> Long story short, I think it's good if we stay away from this in Qt.
> Clazy warns you if you "do it wrong", and being a Qt-specific problem,
> we better not offer too many ways that could have unpleasant drawbacks.
>
>
> My 2 c,
> --
> 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
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
Den sön 21 okt. 2018 kl 17:50 skrev Giuseppe D'Angelo
:
>
> Hello,
>
> Il 21/10/18 16:15, Elvis Stansvik ha scritto:
> > I couldn't find a way to contact them.
>
> The best shot would be the std-discussion mailing list, I think.
>
> > In order to try out the unsafe usage you suggested in your other mail,
> > and also another unsafe usage pointed out in an SO question
> > (https://stackoverflow.com/questions/39051460/why-does-as-const-forbid-rvalue-arguments/39051612#39051612),
> > I made the following test program.
> >
> > The output when running is:
> >
> > [estan@newton move-to-const-test]$ ./move-to-const-test
> > without moveToConst:
> > FooPrivate constr from vector
> > Foo constr with arg 0x7fffdb627200
> > Foo begin 0x7fffdb627200
> > Foo end 0x7fffdb627200
> > Foo destr 0x7fffdb627200
> > FooPrivate destr
> >
> > with moveToConst:
> > FooPrivate constr from vector
> > Foo constr with arg 0x7fffdb627208
> > Foo move constr 0x7fffdb627210
> > Foo destr 0x7fffdb627208
> > Foo begin const 0x7fffdb627210
> > Foo end const 0x7fffdb627210
> > Foo destr 0x7fffdb627210
> > FooPrivate destr
> > [estan@newton move-to-const-test]$
> >
> > Which just shows it's working as intended.
>
> However the third test should be a without moveToConst, but storing in a
> temporary, i.e. the current best practice. It should output exactly like
> the first one, but of course call const begin/end.
>
> And note the extra move/destruciton in the second example.
Yep, well aware of the extra move/destruction. It's the price we pay
for saving that extra line of code to define a const variable.
>
>
> > The two unsafe usages are commented out, because they wouldn't compile
> > (good!).
>
>
> Whops, you're absolutely right. My bad. With your proposed implementation:
>
> > template
> > const T moveToConst(T &)
> > {
> > return std::move(t);
> > }
>
> This won't compile when called on a non-const lvalue (the return type
> will be a lvalue reference to const, which won't bind to a non-const
> rvalue). I stand corrected.
>
> Which actually makes me think of yet another possibility of misuse, that
> is, applying moveToConst to a function returning a const object. That
> will compile, using a copy...
>
> > const QVector getVector();
> > for (auto : moveToConst(getVector()) ~~~
Yes, that would be useless, but at least not UB :)
>
>
> Long story short, I think it's good if we stay away from this in Qt.
> Clazy warns you if you "do it wrong", and being a Qt-specific problem,
> we better not offer too many ways that could have unpleasant drawbacks.
Yea, I can understand that. And since all it saves is a line of code,
I guess not worth the trouble.
Elvis
>
>
> My 2 c,
> --
> 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
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
Il 21/10/18 17:50, Giuseppe D'Angelo via Development ha scritto: This won't compile when called on a non-const lvalue (the return type will be a lvalue reference to const, To NON-const, that is. -- 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
Hello,
Il 21/10/18 16:15, Elvis Stansvik ha scritto:
I couldn't find a way to contact them.
The best shot would be the std-discussion mailing list, I think.
In order to try out the unsafe usage you suggested in your other mail,
and also another unsafe usage pointed out in an SO question
(https://stackoverflow.com/questions/39051460/why-does-as-const-forbid-rvalue-arguments/39051612#39051612),
I made the following test program.
The output when running is:
[estan@newton move-to-const-test]$ ./move-to-const-test
without moveToConst:
FooPrivate constr from vector
Foo constr with arg 0x7fffdb627200
Foo begin 0x7fffdb627200
Foo end 0x7fffdb627200
Foo destr 0x7fffdb627200
FooPrivate destr
with moveToConst:
FooPrivate constr from vector
Foo constr with arg 0x7fffdb627208
Foo move constr 0x7fffdb627210
Foo destr 0x7fffdb627208
Foo begin const 0x7fffdb627210
Foo end const 0x7fffdb627210
Foo destr 0x7fffdb627210
FooPrivate destr
[estan@newton move-to-const-test]$
Which just shows it's working as intended.
However the third test should be a without moveToConst, but storing in a
temporary, i.e. the current best practice. It should output exactly like
the first one, but of course call const begin/end.
And note the extra move/destruciton in the second example.
The two unsafe usages are commented out, because they wouldn't compile (good!).
Whops, you're absolutely right. My bad. With your proposed implementation:
template
const T moveToConst(T &)
{
return std::move(t);
}
This won't compile when called on a non-const lvalue (the return type
will be a lvalue reference to const, which won't bind to a non-const
rvalue). I stand corrected.
Which actually makes me think of yet another possibility of misuse, that
is, applying moveToConst to a function returning a const object. That
will compile, using a copy...
const QVector getVector();
for (auto : moveToConst(getVector()) ~~~
Long story short, I think it's good if we stay away from this in Qt.
Clazy warns you if you "do it wrong", and being a Qt-specific problem,
we better not offer too many ways that could have unpleasant drawbacks.
My 2 c,
--
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: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
Den sön 21 okt. 2018 kl 16:15 skrev Elvis Stansvik :
>
> Den lör 20 okt. 2018 kl 18:53 skrev Giuseppe D'Angelo via Development
> :
> >
> > Il 20/10/18 14:43, Elvis Stansvik ha scritto:
> > > In our application we added a helper like
> > >
> > > template
> > > const T moveToConst(T &)
> > > {
> > > return std::move(t);
> > > }
> > >
> > > that we use for these cases. It just moves the argument to a const
> > > value and returns it. With that we can do for (auto foo :
> > > moveToConst(returnsQtContainer()) { ... }.
> > >
> > > Since it's such a common pattern to want to iterate a returned Qt
> > > container, what would you think of having such a helper
> > > (qMoveToConst?) in Qt?
> >
> > Possibly... Note however that such a thing was already proposed for
> > qAsConst itself, and shut down to avoid having qAsConst diverge from
> > std::as_const (and I approve of not having Qt-specific behaviours). I
> > can't find the relevant discussion on the mailing list right now.
> >
> >
> > For reference, std::as_const's original authors had doubts about the
> > lifetime issues around this, saying that more investigations were needed:
> >
> > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0007r0.html#9.0
> >
> >
> > After a LEWG meeting it was reworded like this:
> >
> > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0007r1.html#8.0
> >
> >
> > I'm not entirely sure of what prompted the change for as_const -- if
> > just a safety net while waiting for more investigation, or if something
> > more profound was raised.
> >
> >
> > I can easily imagine however a scenario where moveToConst() can lead to
> > worse code than the current solution.
> >
> > Current solution:
> >
> > // GCE may get applied, 0 moves
> > const QVector v = getVector();
> > for (auto : v) ~~~
> >
> > vs.
> >
> > // Always 2 moves
> > for (auto : qMoveToConst(getVector()) ~~~
> >
> >
> > And if the type is not even cheap to move (e.g. QVLA, std::array),
> > qMoveToConst becomes a really unpleasant surprise.
These two points of yours of course still stands, and I can understand
why you wouldn't want this as a helper in Qt because of it.
Elvis
> >
> > How about asking LEWG about their reasoning too?
>
> I couldn't find a way to contact them.
>
> In order to try out the unsafe usage you suggested in your other mail,
> and also another unsafe usage pointed out in an SO question
> (https://stackoverflow.com/questions/39051460/why-does-as-const-forbid-rvalue-arguments/39051612#39051612),
> I made the following test program.
>
> The output when running is:
>
> [estan@newton move-to-const-test]$ ./move-to-const-test
> without moveToConst:
> FooPrivate constr from vector
> Foo constr with arg 0x7fffdb627200
> Foo begin 0x7fffdb627200
> Foo end 0x7fffdb627200
> Foo destr 0x7fffdb627200
> FooPrivate destr
>
> with moveToConst:
> FooPrivate constr from vector
> Foo constr with arg 0x7fffdb627208
> Foo move constr 0x7fffdb627210
> Foo destr 0x7fffdb627208
> Foo begin const 0x7fffdb627210
> Foo end const 0x7fffdb627210
> Foo destr 0x7fffdb627210
> FooPrivate destr
> [estan@newton move-to-const-test]$
>
> Which just shows it's working as intended.
>
> The two unsafe usages are commented out, because they wouldn't compile
> (good!).
>
> Note that the version suggested under Further Discussion in rev 0 is
> different from our helper, we return std::move(t) while they return t.
>
> With the version from rev 0, your example unsafe usage will compile
> (the one from SO still won't).
>
> Elvis
>
> #include
> #include
> #include
> #include
>
> class FooPrivate : public QSharedData {
> public:
> FooPrivate() {
> qDebug() << "FooPrivate default constr";
> };
>
> FooPrivate(const FooPrivate ) : QSharedData(other) {
> qDebug() << "FooPrivate copy constr";
> };
>
> explicit FooPrivate(const QVector ) : v(v) {
> qDebug() << "FooPrivate constr from vector";
> };
>
> ~FooPrivate() {
> qDebug() << "FooPrivate destr";
> };
>
> QVector v;
> };
>
> class Foo {
> public:
> Foo() : d(new FooPrivate) {
> qDebug() << "Foo default constr" << this;
> };
>
> Foo(const Foo ) : d(other.d) {
> qDebug() << "Foo copy constr" << this;
> };
>
> Foo(Foo &) : d(other.d) {
> other.d = nullptr;
> qDebug() << "Foo move constr" << this;
> };
>
> explicit Foo(const QVector ) : d(new FooPrivate(v)) {
> qDebug() << "Foo constr with arg" << this;
> };
>
> ~Foo() {
> qDebug() << "Foo destr" << this;
> };
>
> Foo =(const Foo ) {
> qDebug() << "Foo copy ass op" << this;
> d = other.d;
> return *this;
> };
>
> QVector::iterator begin() {
> qDebug() << "Foo begin" << this;
> return d->v.begin();
> };
>
> QVector::const_iterator begin() const {
> qDebug() << "Foo begin const" << this;
> return d->v.begin();
> };
>
>
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
Den lör 20 okt. 2018 kl 18:53 skrev Giuseppe D'Angelo via Development
:
>
> Il 20/10/18 14:43, Elvis Stansvik ha scritto:
> > In our application we added a helper like
> >
> > template
> > const T moveToConst(T &)
> > {
> > return std::move(t);
> > }
> >
> > that we use for these cases. It just moves the argument to a const
> > value and returns it. With that we can do for (auto foo :
> > moveToConst(returnsQtContainer()) { ... }.
> >
> > Since it's such a common pattern to want to iterate a returned Qt
> > container, what would you think of having such a helper
> > (qMoveToConst?) in Qt?
>
> Possibly... Note however that such a thing was already proposed for
> qAsConst itself, and shut down to avoid having qAsConst diverge from
> std::as_const (and I approve of not having Qt-specific behaviours). I
> can't find the relevant discussion on the mailing list right now.
>
>
> For reference, std::as_const's original authors had doubts about the
> lifetime issues around this, saying that more investigations were needed:
>
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0007r0.html#9.0
>
>
> After a LEWG meeting it was reworded like this:
>
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0007r1.html#8.0
>
>
> I'm not entirely sure of what prompted the change for as_const -- if
> just a safety net while waiting for more investigation, or if something
> more profound was raised.
>
>
> I can easily imagine however a scenario where moveToConst() can lead to
> worse code than the current solution.
>
> Current solution:
>
> // GCE may get applied, 0 moves
> const QVector v = getVector();
> for (auto : v) ~~~
>
> vs.
>
> // Always 2 moves
> for (auto : qMoveToConst(getVector()) ~~~
>
>
> And if the type is not even cheap to move (e.g. QVLA, std::array),
> qMoveToConst becomes a really unpleasant surprise.
>
> How about asking LEWG about their reasoning too?
I couldn't find a way to contact them.
In order to try out the unsafe usage you suggested in your other mail,
and also another unsafe usage pointed out in an SO question
(https://stackoverflow.com/questions/39051460/why-does-as-const-forbid-rvalue-arguments/39051612#39051612),
I made the following test program.
The output when running is:
[estan@newton move-to-const-test]$ ./move-to-const-test
without moveToConst:
FooPrivate constr from vector
Foo constr with arg 0x7fffdb627200
Foo begin 0x7fffdb627200
Foo end 0x7fffdb627200
Foo destr 0x7fffdb627200
FooPrivate destr
with moveToConst:
FooPrivate constr from vector
Foo constr with arg 0x7fffdb627208
Foo move constr 0x7fffdb627210
Foo destr 0x7fffdb627208
Foo begin const 0x7fffdb627210
Foo end const 0x7fffdb627210
Foo destr 0x7fffdb627210
FooPrivate destr
[estan@newton move-to-const-test]$
Which just shows it's working as intended.
The two unsafe usages are commented out, because they wouldn't compile (good!).
Note that the version suggested under Further Discussion in rev 0 is
different from our helper, we return std::move(t) while they return t.
With the version from rev 0, your example unsafe usage will compile
(the one from SO still won't).
Elvis
#include
#include
#include
#include
class FooPrivate : public QSharedData {
public:
FooPrivate() {
qDebug() << "FooPrivate default constr";
};
FooPrivate(const FooPrivate ) : QSharedData(other) {
qDebug() << "FooPrivate copy constr";
};
explicit FooPrivate(const QVector ) : v(v) {
qDebug() << "FooPrivate constr from vector";
};
~FooPrivate() {
qDebug() << "FooPrivate destr";
};
QVector v;
};
class Foo {
public:
Foo() : d(new FooPrivate) {
qDebug() << "Foo default constr" << this;
};
Foo(const Foo ) : d(other.d) {
qDebug() << "Foo copy constr" << this;
};
Foo(Foo &) : d(other.d) {
other.d = nullptr;
qDebug() << "Foo move constr" << this;
};
explicit Foo(const QVector ) : d(new FooPrivate(v)) {
qDebug() << "Foo constr with arg" << this;
};
~Foo() {
qDebug() << "Foo destr" << this;
};
Foo =(const Foo ) {
qDebug() << "Foo copy ass op" << this;
d = other.d;
return *this;
};
QVector::iterator begin() {
qDebug() << "Foo begin" << this;
return d->v.begin();
};
QVector::const_iterator begin() const {
qDebug() << "Foo begin const" << this;
return d->v.begin();
};
QVector::const_iterator cbegin() const {
qDebug() << "Foo cbegin" << this;
return d->v.cbegin();
};
QVector::iterator end() {
qDebug() << "Foo end" << this;
return d->v.end();
};
QVector::const_iterator end() const {
qDebug() << "Foo end const" << this;
return d->v.end();
};
QVector::const_iterator cend() {
qDebug() << "Foo cend" << this;
return d->v.cend();
};
private:
QSharedDataPointer d;
};
template
const T moveToConst(T
