Re: [Development] Use of Standard Library containers in Qt source code
On sábado, 2 de julho de 2016 13:11:32 PDT Sergio Martins wrote:
> On Friday, 1 July 2016 11:36:56 WEST Thiago Macieira wrote:
> > Premises not under discussion:
> > Qt source code is product and meant to be read by our users
> > Qt source code must be clean and readable
> >
> > The above is not up for debate.
> >
> > For some time now, we've had a flurry of changes to Qt source code that
> > uses the Standard Library's containers and algorithms, in the name of
> > performance and often code size gains.
>
> and in some cases better readability too. For example, whenever you use
> cbegin, cfind, push_back you're writing code that's not only understandable
> by Qt developers but also C++ developers.
>
> Lowering the bar for C++ developers to start contributing is important.
> I agree that STL also has many examples of worse readability, like very
> verbose algorithms. We should tackle this on a case by case basis.
See also my reply to Stephen on the same topic.
I agree with the logic, but I have to question the effort vs benefit.
This is the same question as with our CLA: how many developers are we turning
away because of the issue? How many would make meaningful contributions if
only the situation were different? You can extend this to other minor issues,
like coding style (use of spaces instead of tabs) or even buildsystems ("I
won't touch qmake").
I honestly do not see a horde of developers stopped at the gates of the API. I
really don't think that's the case, as most of the developers willing to make
contributions have usually used Qt and are somewhat familiar with our API.
That is, the contributors usually are users of Qt that move upstream.
There are a few exceptions of developers moving downstream. For example,
Wayland developers that come take a look at our code. How do we cater for both
low-level C coders and for algorithms-using C++ coders?
> > I'm not disputing that there is a gain. But I am wondering about the
> > trade-off we're making with regards to readability. For example, I was
> > just
> >
> > reviewing this code:
> > if (d->currentReadChannel >= d->readHeaders.size()
> >
> > || d->readHeaders[d->currentReadChannel].empty()) {
> >
> > Q_ASSERT(d->buffer.isEmpty());
>
> "empty" is evil, I've fixed many places where the developer meant "clear()":
Yeah, except that here it *wasn't* clear(). It was "size() == 0" (isEmpty).
But I had to check.
> > What do we do?
>
> What do we do to fix what ? First state the problem.
> You made a case against "empty" and then extrapolated to STL, as if you had
> a 3rd premise "STL is always less readable".
The situation (not everyone will agree there is a problem) is what I said at
the beginning of my email and left quoted here: there's a flurry of new code
using the Standard Library containers and algorithms. Do we do something about
it?
Note that option 1 is status quo.
> > empty -> isEmpty
>
> Agreed, it's error prone.
>
> > push_back -> append
> > front -> first
> > pop_front -> takeFirst
> > cbegin -> constBegin
> > cfind -> constFind
>
> Disagreed, the later form is the common denominator between C++ and Qt
> developers.
You mean the former, not latter.
Indeed, but my whole argument is that developers writing Qt code and, more
importantly, those *reading* Qt code, are more familiar with the latter cases.
If the problem is only "empty", we can get around the problem by requiring
"size() == 0" instead.
--
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
Re: [Development] Use of Standard Library containers in Qt source code
On sábado, 2 de julho de 2016 12:40:53 PDT Stephen Kelly wrote: > So, by sticking to lots of raw loops, you're actually actively excluding > other parts of the C++ community from participating. I don't have numbers > to qualify it, but there seems to me to be a much larger community > following modern C++ practices than following Qt practices on questions > like this. The converse is also true: by using auxiliary functions to do things where a simple loop would do, you're excluding a sizeable community that has never encountered those functions. Especially if those auxiliary types and functions have different and sometimes bewildering names, different from Qt's. Like you, I don't have numbers. But I can tell you one thing for sure: that community that follows non-Qt practices is not here. It would be nice to attract them, but not at the expense of losing the people we already have and are familiar with Qt internals. > I encourage you and everyone else to dive into it. No, thanks. You will also see me iterating over QChar and char instead of using those algorithms or even some of Qt's. See QUrlPrivate::parse, my recent changes to QTzTimeZonePrivate, for examples. -- 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
Re: [Development] Use of Standard Library containers in Qt source code
On sábado, 2 de julho de 2016 15:44:50 PDT Mark Gaiser wrote: > I don't get why you would be confused by - for instance - the empty > method. > STL has that method, but so does Qt [1] apparently in an attempt to be > compatible with the STL API. That doesn't mean we will allow the use of those methods in our own libraries. I *will* reject any code that uses empty() to mean isEmpty() on a Qt container. The whole point of this thread is that using certain methods is misleading or, at best, confusing. > Even if you don't want to learn or know how the STL API looks like, it > should not matter since the very same members also apply on Qt containers > with the same . > This is the case for all your examples in Option 3. > > Imho it would be nice - when using Qt and STL containers in the same > statement - to use common functions that mean the same in both API's. Thus > in your example both should have been empty() calls, even on the Qt > container to be consistent. But that's just my opinion :) I agree with your premise and the benefits in your conclusion. I just don't agree with using the Standard Library names, in detriment to Qt's own API. The whole point of Option 3 is to provide the Qt-like names so that we have *only* Qt-like names in Qt's source code. We'd achieve the same as you proposed (consistency) and we'd be consistent with the rest of the existing code as well as our recommended API. -- 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
Re: [Development] dev branch compile fails module-qtdatavis3d
On sábado, 2 de julho de 2016 10:23:57 PDT Martin Koller wrote: > It seems QtGui is referring to the symbol: > /home/PACKAGES/qt/qt-repo/qt5/qtbase/lib/libQt5GuiWinCC_OA.so: undefined > reference to `qt_version_tag' Oh, right. So the problem is not in the tool being built but in QtGui itself. First question is: how did QtGui link in the first place? It should have the flag to fail to link with undefined symbols, so either that flag is missing or the symbol was found. > so I checked in the gui Makefile and find something I do not understand: > > DEFINES = -DQT_NO_USING_NAMESPACE -DQT_ENABLE_HARFBUZZ_NG > -DENABLE_PIXMAN_DRAWHELPERS -DQT_BUILD_GUI_LIB -DQT_BUILDING_QT > -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT > -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS > -DQT_DISABLE_DEPRECATED_BEFORE=0x05 -DQT_NO_EXCEPTIONS > -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_CORE_LIB > -DQT_NAMESPACE=WinCC_OA > > Why does it use -DQT_NO_USING_NAMESPACE _and_ -DQT_NAMESPACE=WinCC_OA ? They mean different things. QT_NO_USING_NAMESPACE causes qglobal.h NOT to do "using namespace QT_NAMESPACE;". Still, QT_NAMESPACE was set. Can you find which .o in QtGui made a reference to qt_version_tag? -- 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
Re: [Development] Use of Standard Library containers in Qt source code
2016-07-02 16:30 GMT+02:00 Stephen Kelly : > Benjamin TERRIER wrote: > >> But how come a raw loop can be excluding? It should be understandable by >> any C++ developer and, I would dare to say, by any C-style programming >> language developer. > > I don't think anyone can understand or reason about raw-loop-heavy code (see > PS below). I use 'excluded' to refer to people who are not willing to do so. > They exclude themselves from working on Qt code because they can not reason > about it. > > In the same sense, Thiago is 'excluded' from reading and understanding code > which uses 'container.empty()' or which doesn't use raw-loops, because he > would choose to not work on such code. > > There is a divide. The 'exclusion' is self-decided. > > Does that make sense? If you have a better phrase than 'self-exclusion' for > that then it could be useful to share it. Ok for me if you meant it this way. > Someone unwilling to attempt to reason about the code in that function is > 'excluded' from fixing something in it or extending whatever features it > has. I'd boldly reply to that that if one is unwilling to reason about a piece of code, one should not be fixing it. But I'd also agree that the code should be as readable as possible to get a many developers to contribute. Back to Qt current situation I think that the lack of comments in some parts is a bigger throwback than the code style. And back to the actual topic of Qt/STL containers, I am for option 3 if the project can afford the extra development and maintenance otherwise I'd go with option 4. Br, Benjamin Terrier ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use of Standard Library containers in Qt source code
Benjamin TERRIER wrote: >> However, everyone else is excluded by it. When my colleagues find long >> functions, lots of nested if()s and for()s, ++foo somewhere in while > loops, >> they find it much harder to reason about the code. Now I do too. >> >> So, by sticking to lots of raw loops, you're actually actively excluding >> other parts of the C++ community from participating. I don't have numbers > to >> qualify it, but there seems to me to be a much larger community following >> modern C++ practices than following Qt practices on questions like this. > > You can't say that using raw loops (vs stl algorithms) is "actively > excluding" any C++ developer. Yes, maybe 'actively' was not correct. > But how come a raw loop can be excluding? It should be understandable by > any C++ developer and, I would dare to say, by any C-style programming > language developer. I don't think anyone can understand or reason about raw-loop-heavy code (see PS below). I use 'excluded' to refer to people who are not willing to do so. They exclude themselves from working on Qt code because they can not reason about it. In the same sense, Thiago is 'excluded' from reading and understanding code which uses 'container.empty()' or which doesn't use raw-loops, because he would choose to not work on such code. There is a divide. The 'exclusion' is self-decided. Does that make sense? If you have a better phrase than 'self-exclusion' for that then it could be useful to share it. Thanks, Steve. PS: Take QQuickListViewPrivate::applyInsertionChange as it is currently written as an example: http://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/quick/items/qquicklistview.cpp?id=5d23470b#n3068 There's a `++index` somewhere in the middle 3 scopes deep. Further up in the function `index` is assigned, but then assigned again (conditionally) from the `count` of a container. Then `index` is used later in the function, but I can't reason about what it is when it is used. There are many other problems with that function, which are caused by many 'raw' loops nested up to four levels, affecting variables assigned outside top-level if() conditions half a page up. Extracting such code into named functions would indicate the intent of the function. Someone unwilling to attempt to reason about the code in that function is 'excluded' from fixing something in it or extending whatever features it has. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use of Standard Library containers in Qt source code
On Freitag, 1. Juli 2016 14:56:36 CEST Thiago Macieira wrote: > On sexta-feira, 1 de julho de 2016 22:13:42 PDT Giuseppe D'Angelo wrote: > > Even today: where is QList::push_back(T&&)? Where are our emplacement > > functions and their try versions? Where are our exception guarantees?) > > We don't care about exceptions, so we won't be adding those. Ok. > As for the move-versions, since we can't take move-only types in our > containers due to the implicit sharing, does it really make a difference if > we have them or not? Well, you point out another weakness of our contaners (not supporting move- only types). But even then, the push_back(T&&) overload or emplace functions would still usefull to avoid an uneeded copy in some cases. (possibly saving memory alocations) [...] > > Which again seems like a sensible thing to do in general, unless there > > are documented cases in which Qt containers significantly outperform STL > > ones (apart from implicit sharing). > > I would prefer the opposite: use non-Qt only if that is better than the Qt > equivalent. If you can't prove it or if it's too small, it's not worth the > difference in readability that it creates. I think you have an unjustified bias against the STL. With the exception of "empty", you are overestimating the readability problem it pauses. You also write in another email on this thread: > You will always see me write a for-loop to fill something rather than use > std::fill. And I think you are making a mistake. Consider: a) std::fill(vec.begin(), vec.end(), computeBackgroundColor()); b) for(int i = 0; i < vec.size(); i++) vec[i] = computeBackgroundColor(); c) auto backgroundColor = computeBackgroundColor(); for (auto it = vec.begin(); it != vec.end(); ++it) *it = backgroundColor; Personally I find that a. is more readable, as it is objectively more concise and cearly express the intent. b. has some overhead. Conciseness is important as it reduce the likelyhood of mistake. Also more code means more time to read it. It is true that a lot is a matter of taste, but I totaly buy the reasoning behind the "no raw loop". -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use of Standard Library containers in Qt source code
> However, everyone else is excluded by it. When my colleagues find long > functions, lots of nested if()s and for()s, ++foo somewhere in while loops, > they find it much harder to reason about the code. Now I do too. > > So, by sticking to lots of raw loops, you're actually actively excluding > other parts of the C++ community from participating. I don't have numbers to > qualify it, but there seems to me to be a much larger community following > modern C++ practices than following Qt practices on questions like this. You can't say that using raw loops (vs stl algorithms) is "actively excluding" any C++ developer. I would agree to say that simplifying code by using STL makes the code more readable for developers used to the STL. And that raw loops and nested controls can be less readable. But how come a raw loop can be excluding? It should be understandable by any C++ developer and, I would dare to say, by any C-style programming language developer. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use of Standard Library containers in Qt source code
On Fri, Jul 1, 2016 at 8:36 PM, Thiago Macieira
wrote:
> Premises not under discussion:
>
> Qt source code is product and meant to be read by our users
> Qt source code must be clean and readable
>
> The above is not up for debate.
>
> For some time now, we've had a flurry of changes to Qt source code that
> uses
> the Standard Library's containers and algorithms, in the name of
> performance
> and often code size gains.
>
> I'm not disputing that there is a gain. But I am wondering about the
> trade-off
> we're making with regards to readability. For example, I was just reviewing
> this code:
>
> if (d->currentReadChannel >= d->readHeaders.size()
> || d->readHeaders[d->currentReadChannel].empty()) {
> Q_ASSERT(d->buffer.isEmpty());
>
> The use of the Standard Library member "empty" is highly confusing at first
> sight because it does not follow the Qt naming guidelines. It's even more
> confusing because the next line has "isEmpty". When I read this code, I
> had to
> wonder if that "empty" was a verb in the imperative, meaning the author was
> trying to remove all elements from the container.
>
> I had to look up the definition of readHeaders in the review and note that
> it
> was a std::deque, not a Qt container.
>
> What do we do?
>
> Option 1:
> Not use Standard Library containers, just use the Qt containers as they
> exist.
>
> Option 2:
> Create new Qt containers to have the same complexity as Standard Library
> containers, but following the Qt naming conventions. Possibly with implicit
> sharing.
>
> Option 3:
> Create Qt API wrappers for those containers like std::deque, adding only a
> few
> inline functions to match the Qt-style API where the Standard Library API
> deviates. Examples are:
> empty -> isEmpty
> push_back -> append
> front -> first
> pop_front -> takeFirst
> cbegin -> constBegin
> cfind -> constFind
>
> I don't get why you would be confused by - for instance - the empty method.
STL has that method, but so does Qt [1] apparently in an attempt to be
compatible with the STL API.
Even if you don't want to learn or know how the STL API looks like, it
should not matter since the very same members also apply on Qt containers
with the same .
This is the case for all your examples in Option 3.
Imho it would be nice - when using Qt and STL containers in the same
statement - to use common functions that mean the same in both API's. Thus
in your example both should have been empty() calls, even on the Qt
container to be consistent. But that's just my opinion :)
[1] http://doc.qt.io/qt-5/qlist.html#empty
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use of Standard Library containers in Qt source code
On Friday, 1 July 2016 11:36:56 WEST Thiago Macieira wrote:
> Premises not under discussion:
>
> Qt source code is product and meant to be read by our users
> Qt source code must be clean and readable
> The above is not up for debate.
>
> For some time now, we've had a flurry of changes to Qt source code that uses
> the Standard Library's containers and algorithms, in the name of
> performance and often code size gains.
and in some cases better readability too. For example, whenever you use
cbegin, cfind, push_back you're writing code that's not only understandable by
Qt developers but also C++ developers.
Lowering the bar for C++ developers to start contributing is important.
I agree that STL also has many examples of worse readability, like very
verbose algorithms. We should tackle this on a case by case basis.
>
> I'm not disputing that there is a gain. But I am wondering about the
> trade-off we're making with regards to readability. For example, I was just
> reviewing this code:
>
> if (d->currentReadChannel >= d->readHeaders.size()
>
> || d->readHeaders[d->currentReadChannel].empty()) {
>
> Q_ASSERT(d->buffer.isEmpty());
>
"empty" is evil, I've fixed many places where the developer meant "clear()":
https://quickgit.kde.org/?
p=kdelibs4support.git&a=commit&h=c27b851e62307dd16780bf94aff8e6c650ac8dc7
I think we should even remove QList::empty() in Qt6, we want STL compat with
the good things, not the bad things.
> What do we do?
What do we do to fix what ? First state the problem.
You made a case against "empty" and then extrapolated to STL, as if you had a
3rd premise "STL is always less readable".
> empty -> isEmpty
Agreed, it's error prone.
> push_back -> append
> front -> first
> pop_front -> takeFirst
> cbegin -> constBegin
> cfind -> constFind
Disagreed, the later form is the common denominator between C++ and Qt
developers.
Regards,
Sérgio Martins
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use of Standard Library containers in Qt source code
Stephen Kelly wrote: > Thiago Macieira wrote: > >> More to the point, Qt developers don't have to know the Standard Library. >> *I* don't and I don't have time or interest in learning it. > > There is a big division within the C++ community. There is the Qt way and > the non-Qt way, and they don't overlap. This is the real point of my email. There is division along a Qt and non-Qt boundary on things like this. It is analogous to different sides voting in a referendum: Each side is completely perplexed with the other and can't understand their thinking, thinks the other side is 'stupid' or otherwise low-quality, and doesn't want to waste time understanding it. For people who learn programming and learn C++ by learning Qt (myself included), the Qt implementation seems familiar with all the raw loops if you have never encountered the alternative. However, everyone else is excluded by it. When my colleagues find long functions, lots of nested if()s and for()s, ++foo somewhere in while loops, they find it much harder to reason about the code. Now I do too. So, by sticking to lots of raw loops, you're actually actively excluding other parts of the C++ community from participating. I don't have numbers to qualify it, but there seems to me to be a much larger community following modern C++ practices than following Qt practices on questions like this. I encourage you and everyone else to dive into it. Thanks, Steve. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use of Standard Library containers in Qt source code
Thiago Macieira wrote:
> More to the point, Qt developers don't have to know the Standard Library.
> *I* don't and I don't have time or interest in learning it.
There is a big division within the C++ community. There is the Qt way and
the non-Qt way, and they don't overlap.
The approach of many raw loops and no algorithms is taken often in Qt
implementation (and documentation).
On the other side of the dividing line is people who value boost::irange,
boost::indexed_range, boost::max_element and others.
As someone who 'crossed over' to the range/algorithm/stl way after starting
at Ableton, I can say I prefer it greatly.
Here is a patch from me which fixes two bugs in one line of code (which I
wrote several years previously):
https://quickgit.kde.org/?p=kitemmodels.git&a=commitdiff&h=49609b8b53
Those kinds of bugs don't occur if you use algorithms instead of nested
loops. Classes of bugs get eliminated:
for (auto j = 0; j <= model->rowCount(); ++i) { // Double oops!
}
for (auto row : boost::irange(0, model->rowCount()) {
}
Yes, code could still mistakenly use `i` inside the loop, but that is a
different class of bug which would be present in both cases (and the
solution is more scoping by extracting named functions).
Thanks,
Steve.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use of Standard Library containers in Qt source code
Hi all.
Then it is necessary to bring up a question of use of C-style of 'arrays',
e.g. there has to be something like:
qt:containers vs std::containers vs C-arrays
Because I see in Qt sources, that often are uses C-arrays, that is "worse"
than qt:containers vs std::containers.
So, then we need do not use C-arrays at all too.. )))
PS: I prefer to use STL if it is justified, so, seems I vote for p.5.
PS2: If you Qt's developer, you should know STL (at least, you should
read about :) )!
BR,
Denis
01.07.2016 21:36, Thiago Macieira пишет:
Premises not under discussion:
Qt source code is product and meant to be read by our users
Qt source code must be clean and readable
The above is not up for debate.
For some time now, we've had a flurry of changes to Qt source code that uses
the Standard Library's containers and algorithms, in the name of performance
and often code size gains.
I'm not disputing that there is a gain. But I am wondering about the trade-off
we're making with regards to readability. For example, I was just reviewing
this code:
if (d->currentReadChannel >= d->readHeaders.size()
|| d->readHeaders[d->currentReadChannel].empty()) {
Q_ASSERT(d->buffer.isEmpty());
The use of the Standard Library member "empty" is highly confusing at first
sight because it does not follow the Qt naming guidelines. It's even more
confusing because the next line has "isEmpty". When I read this code, I had to
wonder if that "empty" was a verb in the imperative, meaning the author was
trying to remove all elements from the container.
I had to look up the definition of readHeaders in the review and note that it
was a std::deque, not a Qt container.
What do we do?
Option 1:
Not use Standard Library containers, just use the Qt containers as they exist.
Option 2:
Create new Qt containers to have the same complexity as Standard Library
containers, but following the Qt naming conventions. Possibly with implicit
sharing.
Option 3:
Create Qt API wrappers for those containers like std::deque, adding only a few
inline functions to match the Qt-style API where the Standard Library API
deviates. Examples are:
empty -> isEmpty
push_back -> append
front -> first
pop_front -> takeFirst
cbegin -> constBegin
cfind -> constFind
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] dev branch compile fails module-qtdatavis3d
On Friday 01 July 2016 12:45:07 Thiago Macieira wrote: > On sexta-feira, 1 de julho de 2016 21:36:21 PDT Martin Koller wrote: > > On Friday 01 July 2016 08:39:07 Thiago Macieira wrote: > > > On sexta-feira, 1 de julho de 2016 13:26:17 PDT Martin Koller wrote: > > > > g++ -Wl,--gc-sections > > > > -Wl,-rpath,/home/PACKAGES/qt/qt-repo/qt5/qtbase/lib -o > > > > /home/PACKAGES/qt/qt-repo/qt5/qtbase/bin/qml .obj/main.o .obj/qrc_qml.o > > > > .obj/moc_conf.o -L/home/PACKAGES/qt/qt-repo/qt5/qtbase/lib > > > > -lQt5QmlWinCC_OA -lQt5NetworkWinCC_OA -lQt5WidgetsWinCC_OA > > > > -lQt5GuiWinCC_OA > > > > -lQt5CoreWinCC_OA -lGL -lpthread > > > > > > > > /home/PACKAGES/qt/qt-repo/qt5/qtbase/lib/libQt5GuiWinCC_OA.so: undefined > > > > reference to `qt_version_tag' > > > > > > This error indicates your Qt headers do not match the QtCore library. > > > > > > Did you by any chance also build with a namespace? > > > > yes, this is what I said in my first mail. > > "qt_version_tag" is the name of the tag for unnamespaced Qt. If you do > readelf -s libQt5CoreWinCC_OA.so.5 > > You'll probably see "qt_version_tag_X" where X is your namespace, some with > extra suffixes for previous Qt versions and one with @@. Can you confirm that? yes, I find those. e.g. qt_version_tag_WinCC_OA_5 > Can you check if the build of this application had QT_NAMESPACE defined? > Please > paste the command-line that was used to compile main.cpp. It is failing when building qtdeclarative/tools/qml /home/PACKAGES/qt/qt-repo/qt5/qtbase/bin/moc -DQT_QML_DEBUG_NO_WARNING -DQT_USE_QSTRINGBUILDER -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_QML_LIB -DQT_NETWORK_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_NAMESPACE=WinCC_OA -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/mkspecs/linux-g++ -I/home/PACKAGES/qt/qt-repo/qt5/qtdeclarative/tools/qml -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtQml -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtNetwork -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtCore/5.8.0 -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtCore/5.8.0/QtCore -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtWidgets -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtGui -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtCore -I/usr/include/c++/4.8 -I/usr/include/c++/4.8/x86_64-suse-linux -I/usr/include/c++/4.8/backward -I/usr/lib64/gcc/x86_64-suse-linux/4.8/include -I/usr/local/include -I/usr/lib64/gcc/x86_64-suse-linux/4.8/include-fixed -I/usr/x86_64-suse-linux/include -I/usr/include main.cpp -o .moc/main.moc g++ -c -pipe -g -std=c++11 -fno-exceptions -Wall -W -Wvla -Werror -Wno-error=cpp -Wno-error=deprecated-declarations -Wno-error=strict-overflow -D_REENTRANT -fPIC -DQT_QML_DEBUG_NO_WARNING -DQT_USE_QSTRINGBUILDER -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_QML_LIB -DQT_NETWORK_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_NAMESPACE=WinCC_OA -I. -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtQml -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtNetwork -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtCore/5.8.0 -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtCore/5.8.0/QtCore -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtWidgets -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtGui -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtCore -I.moc -isystem /usr/include/libdrm -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/mkspecs/linux-g++ -o .obj/main.o main.cpp /home/PACKAGES/qt/qt-repo/qt5/qtbase/bin/rcc -name qml qml.qrc -o .rcc/qrc_qml.cpp g++ -c -pipe -g -std=c++11 -fno-exceptions -Wall -W -Wvla -Werror -Wno-error=cpp -Wno-error=deprecated-declarations -Wno-error=strict-overflow -D_REENTRANT -fPIC -DQT_QML_DEBUG_NO_WARNING -DQT_USE_QSTRINGBUILDER -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_QML_LIB -DQT_NETWORK_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_NAMESPACE=WinCC_OA -I. -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtQml -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtNetwork -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtCore/5.8.0 -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtCore/5.8.0/QtCore -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtWidgets -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtGui -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtCore -I.moc -isystem /usr/include/libdrm -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/mkspecs/linux-g++ -o .obj/qrc_qml.o .rcc/qrc_qml.cpp /home/PACKAGES/qt/qt-repo/qt5/qtbase/bin/moc -DQT_QML_DEBUG_NO_WARNING -DQT_USE_QSTRINGBUILDER -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_QML_LIB -DQT_NETWORK_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_NAMESPACE=WinCC_OA -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/mkspecs/linux-g++ -I/home/PACKAGES/qt/qt-repo/qt5/qtdeclarative/tools/qml -I/
Re: [Development] Use of Standard Library containers in Qt source code
> The only thing worse than code you don't understand is code that you > misunderstand. Very wise remark ! > STL was standardized 18 years ago, I think it should be enough to get used to > empty(). A bad name remains a bad name. The mind has more important energy to spend than "getting used to". Option 3 has my vote. Philippe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use of Standard Library containers in Qt source code
On 2016-07-01, Thiago Macieira wrote: > confusing because the next line has "isEmpty". When I read this code, I had > to > wonder if that "empty" was a verb in the imperative, meaning the author was > trying to remove all elements from the container. Hah. I found some code in a large project the other day. The code is a monstrosity of stl, mfc and qt code. There was an empty() function. It returned void. and was not const. Yes. it was clearing its internal collections and states. /Sune ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use of Standard Library containers in Qt source code
On sábado, 2 de julho de 2016 08:42:42 PDT Marc Mutz wrote:
> This sort of sentiment fosters mistakes such as looping over
> QVector::erase(it), turning a linear operation quadratic, and people trying
> to reimplement binary search, leading to unstable search results that
> depend on the size of the container. IOW: bugs.
>
> Yes. I'm saying: Less STL use == more bugs.
Which is why I grudgingly accept std::erase + std::remove_if, despite being
ugly-to-read code.
> We should instead foster the use of STL algorithms ("No raw loops"), not use
> ignorance of the greatest C++ library ever written as a reason not to use
> what it has to offer.
If there's no difference in performance, I prefer the raw loop.
> About APIs:
>
> The STL has a great API. push_back() / back() vs. append() / last(), e.g. It
> just happens to be largely consistent with itself instead of with Qt. But
> camelCase is not intrinsically "better" than underscored_names, and I also
> fail to see why first() should be intrinsically superior to front().
Intrinsically, neither is superior to the other. But that was not my point.
My point is that inside Qt, Qt API is more readable than the Standard Library
API because one is consistent with the rest of the code, the other isn't.
> And as an aside: please stop claiming that "the Qt API was there before the
> STL one".
I claimed that Qt had its API published before the C++ standard was out. I
know that SGI had published STL before the standard.
> Tell the world how the Qt containers looked when the STL was released. Go
> on. If you want Qtsy containers, go back _there_. The current Qt containers
> are more STLsy than Qtsy, and they're better for it.
The API style is pretty much the same and this is my only point here: API and
consistency.
--
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
Re: [Development] Use of Standard Library containers in Qt source code
On sábado, 2 de julho de 2016 07:46:28 PDT Marc Mutz wrote: > Don't make this about the STL. Your arguments trivally extend to any third- > party code. > > So what you are actually proposing is to not use any third-party code in Qt > unless it is wrapped in a Qtsy API first. Not exactly. The Standard Library API is close enough to Qt's that it could be mistaken for Qt's, but subtly different. No one will mistake the Win32 API, Objective C API or, for that matter, any C library's API for Qt's. The only thing worse than code you don't understand is code that you misunderstand. > This is a bit over the top, isn't it? We want to allow our users to stay in > the cozy Qt bubble for their own projects. As implementers of that bubble, > we have no right to stay in it ourselves if doing so would be to the > detriment of our users. And even creating an API wrapper is to the > detriment of our users, because it requires resources that are then no > longer available to fix real problems. I get your point: we'd spend resources on something other than fixing real things. My counter point is that creating these wrappers increases our productivity. At the very least, it increases mine. > If this is straw poll, I'm voting for Option 5. C++ programmers (those that > wish to implement a C++ library) should be familiar with the STL. In my opinion, Qt's existence negates your reasoning: we are creating a set of libraries that allow users not to know the Standard Library. And I am a product of that generation, as are many of our own developers. Anyway, for the record, I vote for option 3: create simple wrappers. I will volunteer to do them too, if this is the option we choose. -- 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
Re: [Development] New configuration system
Hi Samuel, On 02/07/16 01:11, "Samuel Gaist" wrote: > Pretty nice ! That will be very useful to simplify Qt customization for > constrained hardware. Yes, that’s one of the goals. > Will there also be a GUI available to help create custom configurations ? We’re planning on having that as part of Qt for Device Creation. > A side question, I've got a few submissions adding handling for a bunch of > missing > QT_NO_DRAGANDDROP/CLIBOARD tests. Should I ping them to get them in before > the > QT_HAS_FEATURE migration or rather wait for it and update the patches then ? I’ll leave that up to you. For a while we’ll anyway need to support both in parallel. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
