sage, I think 1a+2+3 comes closest to what everyone
thinks primitive types mean, so I'd like to update the docs accordingly.
Opinions?
Thanks,
Marc
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325
Info practice.
Q_MOVABLE_TYPE is equivalent to eastl::has_trivial_relocate, though nothing
of that sort exists in C++11 (yet).
> Note that when all four traits are grouped together, C++11 defines them as
> "trivial type".
And a trivial type that is standard-layout is a C++11-POD.
Thanks,
Ma
On Friday March 30 2012, Jedrzej Nowacki wrote:
> On Wednesday 28. March 2012 15.37.46 ext Marc Mutz wrote:
> > Hi,
> >
> > Over at http://codereview.qt-project.org/21518, we're discussing whether
> > QUuid is Q_PRIMITIVE_TYPE or only Q_MOVABLE_TYPE.
> >
>
y it is a bit out of
> scope.
If you want to avoid double initialisation, the correct way is
reserve()+push_back(), not resize()+operator[]. That works even for complex
types.
Thanks,
Marc
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www
ch that makes Q_DECLARE_SHARED
implement the two op='s with (copy)-swap (and adds swap() to classes that
would benefit from it, but don't have it yet).
Foo &Foo::operator=(const Foo &other)
{ if ( this != &other ) { Foo copy(other); swap(other); } return *this; }
Foo &
on-inline move operations yet).
[1]
http://stackoverflow.com/questions/9417477/where-does-the-destructor-hide-in-this-code
Thanks,
Marc
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-
Hi Olivier,
Please excuse the delay in answering.
On Wednesday April 25 2012, Olivier Goffart wrote:
> On Wednesday 25 April 2012 15:07:24 Marc Mutz wrote:
[...]
> > > We could implement a move setter (Foo::setText(QString&&)). But that
> > > would
> > >
On Tuesday May 8 2012, Thiago Macieira wrote:
> On terça-feira, 8 de maio de 2012 15.22.55, Marc Mutz wrote:
> > I'm also giving each class a move constructor. There, the classes which
> > hold their pimpl in smart pointers create the problem[1] that the move
> >
se it because it has a nicer name than QVector.
Thanks,
Marc
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Pl
On Thursday June 21 2012, André Pönitz wrote:
> On Wed, Jun 20, 2012 at 08:52:55AM +0200, Marc Mutz wrote:
> > Hi Thiago,
> >
> > [you knew this would be coming, I don't let you down]
> >
> > On Monday June 18 2012, Thiago Macieira wrote:
> > > * p
On Thursday June 21 2012, André Pönitz wrote:
> On Thu, Jun 21, 2012 at 01:06:16AM +0200, Marc Mutz wrote:
> > On Thursday June 21 2012, André Pönitz wrote:
> > > On Wed, Jun 20, 2012 at 08:52:55AM +0200, Marc Mutz wrote:
> > > > Hi Thiago,
> > > >
>
On Thursday June 21 2012, Marc Mutz wrote:
> > A(const A &b) : a(sin(b.a) + cos(b.a)) {}
Btw: this class doesn't meet normal copy operation semantics and is therefore
not something anyone would ever stuff into a container (copies do not compare
equal). Such a class would be
On Thursday June 21 2012, Thiago Macieira wrote:
> On quarta-feira, 20 de junho de 2012 08.52.55, Marc Mutz wrote:
[...]
> > So, can we please just have the equivalent of
> > template
> > using QList = QVector;
> > after moving the members that QList has but QVecto
On Thursday June 21 2012, Thiago Macieira wrote:
> On quinta-feira, 21 de junho de 2012 08.26.23, Marc Mutz wrote:
> > You meant
> >sizeof(T) <_=_ 32 _||_ T is movable,
> > right?
>
> Yes and no.
>
> sizeof(T) <= 32 && T is movable
>
&
t,
say, the linker level, lest they ran into such hidden BiC issues unawares.
Thanks,
Marc
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Indepen
but that might be a
bit subtle once a new QFuture appears in QtCore).
Any opinions either way?
Thanks,
Marc
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Expert
On Thursday July 5 2012, Thiago Macieira wrote:
> On quarta-feira, 4 de julho de 2012 23.09.03, Marc Mutz wrote:
> > Any opinions either way?
>
> There are no plans to write any class to replace QFuture. However, renaming
> the class right now is close to impossible due to so
E_METATYPE that's inconsistent, since it violates the "put Qt
stuff
into QT_BEGIN_NAMESPACE if you want to be compatible with a namespaced Qt,
otherwise don't bother" assumption.
What's the general opinion on this?
Thanks,
Marc (& Ossi)
--
Marc Mutz | Senior So
stly,
probably others. That would require a patch that made QList and QVector
identical, API-wise, and that, in turn, would require "using member;" support
in the compiler (the QT_NO_USING define is still in the code).
Thanks,
Marc
--
Marc Mutz | Senior Software Engineer
KDAB (Deu
gt;
> Can you check the status of your headers (the include dirs)? Looks like you
> have an old set of QtCore headers that are being found.
I wonder why it's this change in particular that keeps popping up on the ML...
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH &
e uses the old
ones. That will exclude non-C++11 compilers from seeing the more efficient
implementations, or else from the BC guarantee. Do we care?
Thanks,
Marc
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-5213
On Wednesday July 18 2012, Oswald Buddenhagen wrote:
> On Wed, Jul 18, 2012 at 12:25:37PM +0200, ext Marc Mutz wrote:
> > We don't even need to break binary compatibility. We could use inline
> > namespaces to let new code see the new containers while old code uses the
>
On Wednesday July 18 2012, Olivier Goffart wrote:
> On Wednesday 18 July 2012 14:00:08 Marc Mutz wrote:
> > On Wednesday July 18 2012, Oswald Buddenhagen wrote:
> > > On Wed, Jul 18, 2012 at 12:25:37PM +0200, ext Marc Mutz wrote:
> > > > We don't even need to b
On Thursday July 19 2012, joao.abeca...@nokia.com wrote:
> Marc Mutz wrote:
> > On Wednesday July 18 2012, joao.abeca...@nokia.com wrote:
> >> I think it would be feasible to do a binary-only break somewhere
> >> around the 5.2 timeframe (say, ~12 months) where we add
hi Thiago,
There are two sides to this coin.
On Thursday July 19 2012, Thiago Macieira wrote:
> On quinta-feira, 19 de julho de 2012 14.19.36, Marc Mutz wrote:
> > Even with inline namespaces? Then they would have failed to achieve their
> > goal to hide the fact that the type
ent names.
Yes, with the difference that a Qt5 application can't link against a Qt6 Qt
w/o recompilation.
I'm not fighting for this, don't get me wrong, I'm just setting misconceptions
straight.
Thanks,
Marc
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) Gm
On Friday July 20 2012, Olivier Goffart wrote:
> On Thursday 19 July 2012 14:19:36 Marc Mutz wrote:
> > On Wednesday July 18 2012, Olivier Goffart wrote:
> > > We discussed namespaces long time ago already, and decided not to put
> > > Qt in
> > > a namespace
s even uglier :)
Re: ugliness: I expect people will become familiar with this sooner than
later. The C++11 std library is _full_ of noexcept tags.
Thanks,
Marc
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-52
> potentially cause allocations.
That begs the question whether this is what should happen for a _hash_, which
is supposed to be _fast_ :)
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Swed
On Thursday August 2 2012, Thiago Macieira wrote:
> On quinta-feira, 2 de agosto de 2012 16.02.43, Marc Mutz wrote:
[]
> By the way, I'm running into an issue which I'm not entirely sure whether
> it's a design issue. Imagine this case:
>
> class Object
&g
hat the assertion failed, if not from the resulting backtrace) :)
Even if it isn't a full 200 bytes overhead, we should make qt_assert()
noexcept before putting it on, say, QMutex::lock() which calls it.
Thanks,
Marc
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH
On Friday August 3 2012, Thiago Macieira wrote:
> On quinta-feira, 2 de agosto de 2012 23.57.58, Marc Mutz wrote:
> > noexcept(std::declval().f()) should work.
>
> Unfortunately, while the C++11 compiler support seems to be going fine, the
> library support is lagging WAY behind
On Friday August 3 2012, Thiago Macieira wrote:
> On quinta-feira, 2 de agosto de 2012 23.57.58, Marc Mutz wrote:
> > noexcept(std::declval().f()) should work.
>
> error: invalid use of incomplete type ‘struct Object’
Of course the type needs to be complete. How would the compile
/c++cs.htm, in case you'd like to
prepare :)
Outside C++/Qt, I'm (in)famous for my Sushi appetite and insisting on quality
food, of which I sadly eat too much.
Having passed through Oslo and Berlin, I currently live near Frankfurt/Main
with my wife.
Thanks,
Marc
--
Marc Mutz | Senio
On Tuesday August 14 2012, Donald Carr wrote:
> I walked home with the man from a party at Volkers: Don't all germans
> just default to black as a favourite colour?
>
> Visigothic incursions noted
Only at Kraftverk... *sigh* sadly long since shut down...
--
Marc Mutz | Senior
ross purposes, it sounds to me like you
> > aren't talking about raw sockets as in SOCK_RAW. Are you simply
> > talking about the ability to perform distributed IPC using signals and
> > slots?
>
> Essentially yes. Or rather RPC since I think Qt should make it easy to
&g
On Monday August 20 2012, Thiago Macieira wrote:
> > It seems a QVariant constructor that takes a QMetaType::Type is needed.
>
> No, we don't think so.
We probably should add it, but deleted. To prevent that porting mistake.
--
Marc Mutz | Senior Software Engineer
KDAB (
On Monday August 20 2012, Thiago Macieira wrote:
> On segunda-feira, 20 de agosto de 2012 18.22.53, Marc Mutz wrote:
> > On Monday August 20 2012, Thiago Macieira wrote:
> > > > It seems a QVariant constructor that takes a QMetaType::Type is
> > > > needed.
e a QtWidgets
maintainer. I've talked with Till and other KDABians, and I have been ensured
of their full support on this.
So I guess the question now becomes: would you, the community, have me? :)
Thanks,
Marc
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG,
On Thursday September 6 2012, Marc Mutz wrote:
> [DRAFT]
Erhm, this isn't draft anymore, promised :)
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Expert
Hi Lars,
On Wednesday September 19 2012, Knoll Lars wrote:
> For the rest of Qt Widgets Marc Mutz has volunteered. I'm really happy to
> see him step up to this and support the nomination. But as the area is
> rather large, I would longer term be happier if we have separate
>
rmat is used, so as to allow easy
linking to Qt documentation with Doxygen-based projects (Doxygen used to be
able to harvest a tag file from Qt's HTML docs, but at some Qt version this
broke).
Thanks,
Marc
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co
s-a QStringList, so don't inherit from QStringList,
aggregate instead: http://en.wikipedia.org/wiki/Liskov_substitution_principle
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden
in the light
of the fwd-compatibility requirement, I'd say we play it safe and stay with
the two-line fix.
Thanks,
Marc
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-
erhaps, I can help a little bit if I get some pointer.
>
> Laszlo
git bisect --run should help. It works unattended if you have a test case that
you check with a shell script, and spits out the commit that introduced the
regression.
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschla
> link
The compiler also devirtualises function calls if it can prove that the
dynamic type is the same as the static type, e.g. in constructors, or just
after a new-expression, or when the type has been created as an automatic
object.
If it does, the symbol needs to be available.
--
Mar
end to prevent the Gerrit review of the patch (a
necessary precondition for obtaining a final SHA1 of the commit) from
(prematurely) disclosing the vulnerability?
Thanks,
Marc
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germ
patch release[1]?
Thanks,
Marc
[1] Though we're talking about 4.8.x here, to which some want to add new API
(I don't have an opinion, yet).
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 |
On Tuesday October 9 2012, Knoll Lars wrote:
> On Oct 9, 2012, at 12:31 PM, Marc Mutz wrote:
> > On Wednesday September 26 2012, Thiago Macieira wrote:
> >> But note that there's one stricter requirement: the forwards
> >> compatibility that applies within
On Tuesday October 9 2012, Thiago Macieira wrote:
> On terça-feira, 9 de outubro de 2012 18.19.19, Marc Mutz wrote:
> > > It would still break forward compatibility. Assume you do the change in
> > > 5.0.1, and an app gets compiled against 5.0.1 using the new symbol (by
> &
e.
If it worked for you before, try bisecting qtbase to find the commit that
introduced the regression.
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-5
would
require a disconnect/connect pair.
The full solution would be to try to remove all _q_slots() from Qt 5.0. Seeing
as this change could also be done in 5.1, I'd only propose to ban _new_
_q_slots() from being added.
Opinions?
Thanks,
Marc
--
Marc Mutz | Senior Software Engineer
KDAB (D
On Friday October 12 2012, Thiago Macieira wrote:
> On sexta-feira, 12 de outubro de 2012 07.27.51, Marc Mutz wrote:
> > Hi,
> >
> > I was wondering whether we should stop using the pattern of declaring
> > _q_privateSlots() in favour of connecting to functors or functi
On Friday October 12 2012, Olivier Goffart wrote:
> On Friday 12 October 2012 10:26:04 Olivier Goffart wrote:
> > On Thursday 11 October 2012 23:06:18 Thiago Macieira wrote:
> > > On sexta-feira, 12 de outubro de 2012 07.27.51, Marc Mutz wrote:
> > > > Hi,
> >
ing connect() for presence of the fifth argument only reduces text
size by 500 bytes, so I'm out of ideas.
Thanks,
Marc
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ)
gt;
> Would anyone like to second?
+1 from me
Disclaimer: I'm at KDAB, like he is, too.
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-5
in the
resulting rush pre-5.1 :) The work needs to be done anyway, the question is
just when it's done.
We don't yet have a large list of 'dev' changes, and I'd like QtWidgets not to
be the only module requiring this.
Or do we ignore changes-x.y.z going forward (like
ted order).
> I'd suggest that bug fixes should not touch the changes
> file, only new features.
That would be a change from previous practice (changes-4.8.x, say; I've
understood changes-5.0.0 to be a one-time glitch), which probably didn't
include all, but at least some bug f
it acceptable in 'stable',
please?
Case in point is the following, btw:
https://codereview.qt-project.org/41507
Thanks,
Marc
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +4
> alternative is nice, because it would work with the current work flow,
> without changing anything, we only need to be strict about feature merge
> commit message, it should be verbose, describing the feature. That is all,
> everything else can be gene
es that require new strings or BiC changes should
be submitted to 'dev' directly.
Correct?
BTW: Two of the three commits that have landed in 'dev' so far are bug-fixes
(one bug-fix and one tests/-only change, to be precise; the third is the
addition of changes-5.1.0),
commit (followed by any number of 'oops' commits, which a topic branch
wouldn't help with, either).
Are you suggesting to enforce the use of a topic branch for new features,
regardless of how small they are?
I'm sorry if I seem like the devil's advocate here, but I
On Sunday December 9 2012, Sune Vuorela wrote:
> On 2012-12-09, Sune Vuorela wrote:
> > On 2012-12-09, Marc Mutz wrote:
> >> 3. new features and bug-fixes that require new strings or BiC changes
> >> should be submitted to 'dev' directly.
> >
&g
instead.
So I wasn't suggesting to "just put all bug fixes blindly into stable". I want
to avoid them going blindly to dev, though, esp. without the commit message
explaining why.
I agree with you otherwise.
Thanks,
Marc
--
Marc Mutz
On Sunday December 9 2012, Marc Mutz wrote:
> Burdening the maintainer with generating the changes file after an
> onslaught of dozens of committers and 100s of changes without regards to
> the changes file is - I repeat - not an attractive prospect :(
How about we make qdoc generate a l
es+qml (assuming that's what you meant with BB above)
Mentioning in each (because you don't have a separate document) that +qml is
supposed to be used for all qml formats.
Something like that.
Thanks,
Marc
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.
On Tuesday December 11 2012, Marc Mutz wrote:
> text/vnd.qt.quick+qml
> text/vnd.rim.cascades+qml (assuming that's what you meant with BB above)
or +vnd.t.qml, just to be extra paranoid in case W3C develops a Quantum
Modelling Language anytime soon and finds their suffix gone.
--
not sure 3rd parties would like to place their mime types in the vnd.qt
tree :)
There are trees other than vnd., btw, but I forgot which ones. One of them
might lend itself better to this kind of prefixing that vnd.
Thanks,
Marc
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH
Hi all,
On Wednesday December 19 2012, Marc Mutz wrote:
> ... please cut me some slack while I handle the attached non-maskable
> interrupt :)
It took longer than initially expected, but I'm told that's to be expected,
too.
But I'm back in business again, trying to get a
On 2013-09-12 08:07, André Somers wrote:
> Op 11-9-2013 17:19, David Faure schreef:
>>> Couldn't such a class be part of the hopefully coming QtConcurrent
>>> replacement?
>> Can we forget about threads for a second?
> No, I'd rather not forget that huge pink elephant in the room... In
> this
> ag
Hi,
The following backtrace shows QXcbIntegration's ctor, which is called
from QCoreApplication's ctor, call
QGuiApplicationPrivate::setEventDispatcher(). At that time, the
application object isn't yet a QGuiApplication.
#1 0x2aaac96e100d in QGuiApplicationPrivate::q_func
(this=)
at
On 2013-09-17 12:30, Sze Howe Koh wrote:
[...]
> Example:
> #include pulls in the QMultimedia namespace only, but
> #include pulls in the QMultimedia namespace PLUS all
> the audio, video, radio, camera etc. classes. This can adversely
> impact compilation times for large projects.
[...]
...unle
On 2013-09-27 06:22, Mandeep Sandhu wrote:
[...]
> How do I find the next-best person for review? Check a file's git log
> and see who's committed to it most often?
[...]
I usually check who's active in a file, or failing that, in a
subdirectly, with git log, mentally removing the shotgun surgery
Hi,
I'm seeing a .data.rel.ro.local for staticMetaObject in objdump -TtRr
for (apparently) each Q_GADGET use (say, QEvent, QSizePolicy), but not
for any Q_OBJECT use (say QWidget, but funnily enough for QObject).
I don't see any difference between the staticMetaObject's declared in
and generat
On 2013-10-02 20:39, André Pönitz wrote:
[...]
>
>
> tp://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions
> is for instance pretty concise: "We don't use C++ exceptions". They
> later
> give detailed reasoning and a conclusion including "Our advice against
> using exceptions
On 2013-10-04 07:34, Kurt Pattyn wrote:
> In some markets like Avionics and Defense, it is simply forbidden for
> us to use exceptions.
The only reason to forbid exceptions on technical (as opposed to
uneducated or -worse- political) grounds is in hard real-time systems,
because throwing an exce
On Friday, October 18, 2013 12:55:07 AM Jiergir Ogoerg wrote:
> Thanks, that worked.
> I compiled the 72...49 snapshot on both Ubuntu 13.10 and Fedora 20 and I
> still get the same 130-160ms, though I clearly recall getting about 70ms
> with the first pre-beta.
> Since I have no idea what's the dea
On Tuesday, October 29, 2013 01:21:08 Jiergir Ogoerg wrote:
> Hi,
> There's an enum:
>
> //==> code
> enum TableState
> {
> UnsupportedLocale,
> EmptyTable,
> UnknownSystemComposeDir,
> MissingComposeFile,
> NoErrors
> };
> //<== code
>
> and this:
On Friday, November 01, 2013 15:35:50 Marc Mutz wrote:
> enum object that does have one of the declared enum values results in
does _not_ have, of course.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mail
On Thursday, October 31, 2013 16:52:28 Jiergir Ogoerg wrote:
> Is there a list of other startup optimizations you're working on
> so that we don't dilute the efforts by working on the same thing?
Not directly related, but I've got some WIP on reducing relocations in Qt.
I've pretty much removed a
On Saturday, November 02, 2013 02:35:20 Thiago Macieira wrote:
> On sexta-feira, 1 de novembro de 2013 15:35:50, Marc Mutz wrote:
> > According to the standard, they are equivalent, since reading a value
> > from an enum object that does have one of the declared enum values
On Monday, November 04, 2013 12:24:37 Marc Mutz wrote:
> The issue is with the casts to enums in some of the QFlags operators, IIRC,
> but the log I cited is old and the line numbers might not match anymore.
I've dug up attached attempt to fix the issue, with which I am, however, n
On Friday, November 01, 2013 23:49:22 Jiergir Ogoerg wrote:
> Anyway who's the hero of the day (and is a contributor) to commit a fix for
> this bug?
Finders keepers ;)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/m
On Monday, November 04, 2013 17:15:26 Thiago Macieira wrote:
> On segunda-feira, 4 de novembro de 2013 12:31:22, Marc Mutz wrote:
> > +Q_DECL_CONSTEXPR inline QFlags operator|(QFlags f) const { return
> > QFlags(i | f.i, true); } +Q_DECL_CONSTEXPR inline QFlags
> > op
On Tuesday, November 05, 2013 01:07:32 Thiago Macieira wrote:
> @@ -206,7 +212,8 @@ protected:
> int qt4D;
> Qt::Orientation qt4O;
> Qt::MouseButtons mouseState;
> -int reserved;
> +uint ph : 2;
> +int reserved : 30;
> };
> #endif
is sizeof(int) == 4 everywhere?
> ---
On Tuesday, November 05, 2013 01:07:32 Thiago Macieira wrote:
> @@ -101,9 +102,10 @@ public:
> {
> if (dirty) {
> dirty = false;
> -QVector sorted = values;
> -qSort(sorted);
> -currentMedian = sorted.at(bufferSize / 2 + 1);
> +
On Tuesday, November 05, 2013 01:07:32 Thiago Macieira wrote:
> diff --git a/src/corelib/json/qjsonvalue.h b/src/corelib/json/qjsonvalue.h
> index b8bdf55..c0ecdd2 100644
> --- a/src/corelib/json/qjsonvalue.h
> +++ b/src/corelib/json/qjsonvalue.h
> @@ -79,6 +79,7 @@ public:
> QJsonValue(bool b
On Tuesday, November 05, 2013 01:07:32 Thiago Macieira wrote:
> +// ### Qt 6: Merge with above with default offsetSeconds = 0
> +QDateTime(const QDate &date, const QTime &time, Qt::TimeSpec spec, int
> offsetSeconds);
> +#ifndef QT_BOOTSTRAPPED
> +QDateTime(const QDate &date, const QTim
On Tuesday, November 05, 2013 01:07:32 Thiago Macieira wrote:
> +++ b/src/corelib/tools/qmargins.h
> @@ -242,6 +242,24 @@ inline QMargins &QMargins::operator-=(const QMargins
> &margins) return *this = *this - margins;
> }
>
> +inline QMargins &QMargins::operator+=(int margin)
> +{
> +m_left
On Tuesday, November 05, 2013 01:07:32 Thiago Macieira wrote:
> -return (void *)qptrdiff(data);
> +char *null = 0;
> +return null + qptrdiff(data);
Since this is equivalent to
return 0[qptrdiff(data)];
isn't that dereferencing the nullptr and therefore und
On Tuesday, November 05, 2013 12:24:32 Marc Mutz wrote:
> What's wrong with
>
>reinterpret_cast(qptrdiff(data));
-> https://codereview.qt-project.org/70402
___
Development mailing list
Development@qt-project.org
http://lists.qt-pr
On Tuesday, November 05, 2013 18:00:02 Nicolás Alvarez wrote:
> 2013/11/5 Marc Mutz :
> > On Tuesday, November 05, 2013 01:07:32 Thiago Macieira wrote:
> >> -return (void *)qptrdiff(data);
> >> +char *null = 0;
> >> +return n
On Tuesday, November 05, 2013 17:42:38 Thiago Macieira wrote:
> I think that was intentional since JSON is still using ECMAScript data
> types, whose Number type is a double precision floating point. Inserting
> any integer larger than 2^52 will result in loss of precision. So this
> forces people
On Tuesday, November 05, 2013 14:32:03 John Layt wrote:
> On 5 November 2013 12:03, Marc Mutz wrote:
> > On Tuesday, November 05, 2013 01:07:32 Thiago Macieira wrote:
> >> +// ### Qt 6: Merge with above with default offsetSeconds = 0
> >> +QDateTime(const QDa
On Tuesday, November 05, 2013 17:51:25 Thiago Macieira wrote:
> On terça-feira, 5 de novembro de 2013 11:09:48, Giuseppe D'Angelo wrote:
> > > class Q_WIDGETS_EXPORT QMacCocoaViewContainer : public QWidget
> > > {
> > >
> > > Q_OBJECT
> > >
> > > public:
> > > -QMacCocoaViewCo
-project.org/70800
https://codereview.qt-project.org/70801
https://codereview.qt-project.org/70802
That's all from the header diff.
Thanks,
Marc
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (H
/*implicit*/.
Thanks,
Marc
[1] I used this command to find them:
git log --diff-filter=A --stat v5.1.1..gerrit/release -- src | grep src | \
grep \\.h | grep -v _p\\.h | cut -d\ -f2
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.k
On Tuesday, November 19, 2013 05:02:32 AM Thiago Macieira wrote:
> There were exactly 31 commits with [ChangeLog]. Please start using it more.
Samuel Gaist (thanks) suggested in PM to add a check to the sanity bot.
Good idea? I think it is.
Thanks,
Marc
--
Marc Mutz | Senior Softw
On Monday, November 25, 2013 12:20:05 PM Joerg Bornemann wrote:
> On 25.11.2013 10:53, Marc Mutz wrote:
> >> There were exactly 31 commits with [ChangeLog]. Please start using it
> >> more.
> >
> > Samuel Gaist (thanks) suggested in PM to add a check to the sanity
On Monday, November 25, 2013 06:26:38 PM Alan Alpert wrote:
> On Mon, Nov 25, 2013 at 7:49 AM, Thiago Macieira
>
> wrote:
> > On segunda-feira, 25 de novembro de 2013 12:49:11, Marc Mutz wrote:
> >> I have found that significantly more than 50% of commits that touched
1 - 100 of 1074 matches
Mail list logo
