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
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 m
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 met
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.
Fir
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
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
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
> 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
> ot
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 chan
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 chang
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
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
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 nee
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
> > > > -
> 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
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
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 th
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 Stan
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
19 matches
Mail list logo