On Friday 24. July 2015 08:43:59 Thiago Macieira wrote:
> So the question is only whether we want to add the [Q_DECL_OVERRIDE] macro
> now and replace with the keyword in 5.7.
>
> I'd say no.
I already used clang-modernize in qtbase to add the macro everywhere in Qt 5.5
Even other modules have ha
On Friday 24 July 2015 20:23:45 Marc Mutz wrote:
> Fair enough, but seeing all the commits flying by that add Q_D_O to "fix
> warnings with clang", it's not hard to imagine that a) the problem will
> solve itself by a grass roots movement and b) people will a
> not-too-unrealistic future warning
On Friday 24 July 2015 20:23:45 Marc Mutz wrote:
> itself by a grass roots movement and b) people will a not-too-unrealistic
s/people will//
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
On Friday 24 July 2015 17:43:59 Thiago Macieira wrote:
> So the question is only whether we want to add the macro now and replace
> with the keyword in 5.7.
>
> I'd say no.
Fair enough, but seeing all the commits flying by that add Q_D_O to "fix
warnings with clang", it's not hard to imagine th
On Friday 24 July 2015 13:34:39 Marc Mutz wrote:
> On Thursday 23 July 2015 16:29:12 Knoll Lars wrote:
> > On 23/07/15 14:27, "Marc Mutz" wrote:
> > >On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote:
> > >> * Q_DECL_OVERRIDE - required in new code, don't add to old code
> > >
> > >- Req
On 24/07/15 13:34, "Marc Mutz" wrote:
>On Thursday 23 July 2015 16:29:12 Knoll Lars wrote:
>> On 23/07/15 14:27, "Marc Mutz" wrote:
>> >On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote:
>> >> * Q_DECL_OVERRIDE - required in new code, don't add to old code
>> >
>> >- Required to be use
On Thursday 23 July 2015 16:29:12 Knoll Lars wrote:
> On 23/07/15 14:27, "Marc Mutz" wrote:
> >On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote:
> >> * Q_DECL_OVERRIDE - required in new code, don't add to old code
> >
> >- Required to be used consistently within a class, because Clang w
On 23/07/15 19:16, "Thiago Macieira" wrote:
>On Thursday 23 July 2015 19:22:46 Marc Mutz wrote:
>> I believe we should strive to have the LTS release warning-free in this
>> regard. It's going to be in use for a long time, and the demand for
>>nullptr-
>> correctness will only grow with time.
>
>
On Thursday 23 July 2015 19:22:46 Marc Mutz wrote:
> I believe we should strive to have the LTS release warning-free in this
> regard. It's going to be in use for a long time, and the demand for nullptr-
> correctness will only grow with time.
Agreed.
I'd say go ahead with cleaning up zero-as-nul
On Thursday 23 July 2015 15:47:10 Knoll Lars wrote:
> On 23/07/15 14:23, "Marc Mutz" wrote:
> >On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote:
> >> * Q_NULLPTR - strongly encouraged
> >
> >Ok, trying to summarize the discussion so we can move forward.
> >
> >There's a bug report (http
On 2015-07-23 08:23, Marc Mutz wrote:
> On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote:
>> * Q_NULLPTR - strongly encouraged
>
> Ok, trying to summarize the discussion so we can move forward.
>
> There's a bug report (https://bugreports.qt.io/browse/QTBUG-45291) about Qt
> headers n
On 23/07/15 14:27, "Marc Mutz" wrote:
>On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote:
>> * Q_DECL_OVERRIDE - required in new code, don't add to old code
>
>- Required to be used consistently within a class, because Clang warns be
> default if one function has override and another
On 23/07/15 14:27, "Marc Mutz" wrote:
>On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote:
>> * Q_DECL_OVERRIDE - required in new code, don't add to old code
>
>- Required to be used consistently within a class, because Clang warns be
> default if one function has override and another
On 23/07/15 14:23, "Marc Mutz" wrote:
>On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote:
>> * Q_NULLPTR - strongly encouraged
>
>Ok, trying to summarize the discussion so we can move forward.
>
>There's a bug report (https://bugreports.qt.io/browse/QTBUG-45291) about
>Qt
>headers not
On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote:
> Non-C++11 but also useful:
>
> * Q_DECL_{PURE,CONST}_FUNCTION - encouraged
>
> A pure function is a function that will return the same value if called
> twice with the same parameters. Pure functions are allowed to read from
> pointe
On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote:
> * Q_DECL_NOTHROW / Q_DECL_NOEXCEPT - strongly encouraged
>
> To public functions (all modules); any function in modules compiled with
> exception (QtCore, QtXmlPatterns, QtConcurrent).
>
> You probably want Q_DECL_NOTHROW instead of
On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote:
> * Q_CONSTEXPR - use only where required
>
> You probably don't need this. You'll need it when accessing const data from
> a Q_DECL_CONSTEXPR function. Otherwise, you won't need it.
>
> You could use this to create a static-initialisa
On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote:
> * Q_DECL_OVERRIDE - required in new code, don't add to old code
- Required to be used consistently within a class, because Clang warns be
default if one function has override and another doesn't.
- Even add to old code. The benefits
On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote:
> * Q_DECL_EQ_DEFAULT - really discouraged
>
> I can't think of any case where you could use this and let the code still
> compile in C++98, so don't use it
>
> * Q_DECL_EQ_DELETE - strongly encouraged, use with care
>
> Let's the co
On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote:
> * Q_NULLPTR - strongly encouraged
Ok, trying to summarize the discussion so we can move forward.
There's a bug report (https://bugreports.qt.io/browse/QTBUG-45291) about Qt
headers not compiling with -Wzero-as-null-pointer-constant,
On Wednesday 27 May 2015 09:46:08 Marc Mutz wrote:
> On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote:
> > Hello
> >
> > I think it's time to institute a policy that we should fix our sources to
> > use the new C++11 keywords. I'd like to propose the following.
>
> Can we move all (excl
On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote:
> Hello
>
> I think it's time to institute a policy that we should fix our sources to
> use the new C++11 keywords. I'd like to propose the following.
Can we move all (excl. Q_NULLPTR, which is controversial) forward?
Thanks,
Marc
--
> On Feb 10, 2015, at 10:51 AM, Marc Mutz wrote:
>
> On Tuesday 10 February 2015 08:41:47 Ziller Eike wrote:
>>> On Feb 9, 2015, at 3:40 PM, Marc Mutz wrote:
>>>
>>> On Monday 09 February 2015 09:54:12 Smith Martin wrote:
This is the kind of thing we should add to the documentation, but c
On Wednesday 11 February 2015 18:05:09 Matthew Woehlke wrote:
> > Only if we build with -Werror -- which we do, in the compilers that
> > support __null.
>
> Um... do you not have *any* C++11 builds? If Q_NULLPTR == nullptr (which
> I assume it is in C++11?), and you try to pass Q_NULLPTR to some
On 2015-02-11 16:21, Thiago Macieira wrote:
> On Wednesday 11 February 2015 15:54:40 Matthew Woehlke wrote:
>> On 2015-02-11 15:38, Marc Mutz wrote:
>>> On Wednesday 11 February 2015 00:37:18 Matthew Woehlke wrote:
(Oh... and 'auto ptr = 0;' does not give you a pointer. Not relevant to
Qt
On Wednesday 11 February 2015 15:54:40 Matthew Woehlke wrote:
> On 2015-02-11 15:38, Marc Mutz wrote:
> > On Wednesday 11 February 2015 00:37:18 Matthew Woehlke wrote:
> >> (Oh... and 'auto ptr = 0;' does not give you a pointer. Not relevant to
> >> Qt, but just saying...)
> >
> > You said auto pt
On 2015-02-11 15:38, Marc Mutz wrote:
> On Wednesday 11 February 2015 00:37:18 Matthew Woehlke wrote:
>> (Oh... and 'auto ptr = 0;' does not give you a pointer. Not relevant to
>> Qt, but just saying...)
>
> You said auto ptr = 0 doesn't give you a pointer. By extension, I thought you
> were sayi
On Wednesday 11 February 2015 18:02:53 Matthew Woehlke wrote:
> On 2015-02-11 04:18, Marc Mutz wrote:
> > On Wednesday 11 February 2015 00:37:18 Matthew Woehlke wrote:
> >> Marc, I'm not sure if you're arguing for or against nullptr :-)...
> >
> >
> >
> > Then I agree with André; you need to start
On 2015-02-11 04:18, Marc Mutz wrote:
> On Wednesday 11 February 2015 00:37:18 Matthew Woehlke wrote:
>> Marc, I'm not sure if you're arguing for or against nullptr :-)...
>
> Then I agree with André; you need to start reading mails (threads) before
> responding :)
Will someone *please* explain
On Wednesday 11 February 2015 10:56:29 Olivier Goffart wrote:
> On Wednesday 11 February 2015 10:49:31 Marc Mutz wrote:
> > On Wednesday 11 February 2015 07:54:52 Hausmann Simon wrote:
> > > I suppose that it is absolutely unlikely that we are going to find a
> > > consensus on what is purely an ae
On 11/02/15 10:46, "Marc Mutz" wrote:
>On Wednesday 11 February 2015 08:27:24 Knoll Lars wrote:
>> To settle this, I am also with Andre and Simon.
>
>Please don't evade: how is the situation different for emit vs. Q_NULLPTR?
emit IMO helps code readability, as you know this is not a regular
func
On Wednesday 11 February 2015 10:49:31 Marc Mutz wrote:
> On Wednesday 11 February 2015 07:54:52 Hausmann Simon wrote:
> > I suppose that it is absolutely unlikely that we are going to find a
> > consensus on what is purely an aesthetic issue.
> >
> > I for one am entirely with André and I do not
On Wednesday 11 February 2015 07:54:52 Hausmann Simon wrote:
> I suppose that it is absolutely unlikely that we are going to find a
> consensus on what is purely an aesthetic issue.
>
> I for one am entirely with André and I do not like UPPERCASE macros in my
> face unless I can avoid them. It's a
On Wednesday 11 February 2015 08:27:24 Knoll Lars wrote:
> To settle this, I am also with Andre and Simon.
Please don't evade: how is the situation different for emit vs. Q_NULLPTR?
> let’s not go and replace 0 with the macro in places where
> things are unambiguous.
For old code, by definition,
Den 10-02-2015 kl. 23:17 skrev Thiago Macieira:
> My current thinking is:
> 1) modernise our headers with macros, now
> 2) allow people to use Q_NULLPTR where it helps with readability
> 3) disallow replacing of zeroes with Q_NULLPTR except as required by rules
> #1
> or #2
>
> Two exam
11.02.2015, 12:13, "Marc Mutz" :
> On Wednesday 11 February 2015 00:37:18 Matthew Woehlke wrote:
>> Marc, I'm not sure if you're arguing for or against nullptr :-)...
>
> Then I agree with André; you need to start reading mails (threads) before
> responding :)
>> On 2015-02-10 18:23, Marc Mutz
On Wednesday 11 February 2015 00:37:18 Matthew Woehlke wrote:
> Marc, I'm not sure if you're arguing for or against nullptr :-)...
Then I agree with André; you need to start reading mails (threads) before
responding :)
> On 2015-02-10 18:23, Marc Mutz wrote:
> > On Tuesday 10 February 2015 20:13
tz
>Sent: Wednesday, February 11, 2015 00:19
>To: André Pönitz
>Cc: development@qt-project.org
>Subject: Re: [Development] Upgrading the sources to C++11 keywords
>(Q_NULLPTR, etc.)
>
>
>On Tuesday 10 February 2015 20:13:12 André Pönitz wrote:
>> On Tue, Feb 10, 2015 at 07
t: Re: [Development] Upgrading the sources to C++11 keywords
(Q_NULLPTR, etc.)
On Tuesday 10 February 2015 20:13:12 André Pönitz wrote:
> On Tue, Feb 10, 2015 at 07:53:23PM +0100, Marc Mutz wrote:
> > On Tuesday 10 February 2015 17:28:09 Thiago Macieira wrote:
> > > On Tuesday 10
Marc, I'm not sure if you're arguing for or against nullptr :-)...
On 2015-02-10 18:23, Marc Mutz wrote:
> On Tuesday 10 February 2015 20:13:12 André Pönitz wrote:
>> Can't you simply wait until 'nullptr' is available?
>
> No.
>
> For a simple reason: using nullptr (Q_ or not) is more expressive
On Tuesday 10 February 2015 20:13:12 André Pönitz wrote:
> On Tue, Feb 10, 2015 at 07:53:23PM +0100, Marc Mutz wrote:
> > On Tuesday 10 February 2015 17:28:09 Thiago Macieira wrote:
> > > On Tuesday 10 February 2015 15:34:45 Knoll Lars wrote:
> > > > +1. I’m ok with us making sure our headers are c
On 2015-02-10 17:44, André Pönitz wrote:
> On Tue, Feb 10, 2015 at 05:15:03PM -0500, Matthew Woehlke wrote:
>> On 2015-02-08 16:42, André Pönitz wrote:
>>> I.e. in case of a simple pointer initialization, why should one *ever*
>>> prefer
>>>
>>> void something()
>>> {
>>> Foo *f = Q_NULLPTR;
On 2015-02-09 15:05, Marc Mutz wrote:
> On Monday 09 February 2015 20:10:44 André Pönitz wrote:
>> On Mon, Feb 09, 2015 at 09:36:46AM +0100, Marc Mutz wrote:
>>> I find Q_NULLPTR *beautiful* (bautyful is deeper than pretty), because I
>>> know at some point we will be able to just s/Q_NULLPTR/nullp
On Tue, Feb 10, 2015 at 05:15:03PM -0500, Matthew Woehlke wrote:
> On 2015-02-08 16:42, André Pönitz wrote:
> > I.e. in case of a simple pointer initialization, why should one *ever*
> > prefer
> >
> > void something()
> > {
> > Foo *f = Q_NULLPTR;
> > ...
> > }
> >
> > over
> >
> > vo
On Tue, Feb 10, 2015 at 11:25:52PM +0100, Mathias Hasselmann wrote:
>
>
> Am 10.02.2015 um 20:13 schrieb André Pönitz:
> >On Tue, Feb 10, 2015 at 07:53:23PM +0100, Marc Mutz wrote:
> >>On Tuesday 10 February 2015 17:28:09 Thiago Macieira wrote:
> >>>On Tuesday 10 February 2015 15:34:45 Knoll Lars
On 2015-02-09 15:30, André Pönitz wrote:
> Will you propose to use 'auto' instead of 'int' whenever it compiles?
> Just because 'auto' *sometimes* makes sense?
Personally, I'm a fan of AAA :-). However that's not an option for Qt
because there is no reasonable way to use it while still supporting
Am 10.02.2015 um 20:13 schrieb André Pönitz:
> On Tue, Feb 10, 2015 at 07:53:23PM +0100, Marc Mutz wrote:
>> On Tuesday 10 February 2015 17:28:09 Thiago Macieira wrote:
>>> On Tuesday 10 February 2015 15:34:45 Knoll Lars wrote:
+1. I’m ok with us making sure our headers are clean against war
On Tuesday 10 February 2015 23:10:01 André Pönitz wrote:
> > > Can't you simply wait until 'nullptr' is available? Do you really *need*
> > > to use macros instead of the core language?
> >
> > We go back to the discussion of VS2008. That's the only major compiler we
> > still care about that does
On 2015-02-08 16:42, André Pönitz wrote:
> I.e. in case of a simple pointer initialization, why should one *ever* prefer
>
> void something()
> {
> Foo *f = Q_NULLPTR;
> ...
> }
>
> over
>
> void something()
> {
> Foo *f = 0;
> ...
> }
>
> ?
For the same reason that *any* styl
On Tue, Feb 10, 2015 at 01:17:25PM -0800, Thiago Macieira wrote:
> On Tuesday 10 February 2015 20:13:12 André Pönitz wrote:
> > On Tue, Feb 10, 2015 at 07:53:23PM +0100, Marc Mutz wrote:
> > > On Tuesday 10 February 2015 17:28:09 Thiago Macieira wrote:
> > > > On Tuesday 10 February 2015 15:34:45 K
On Tuesday 10 February 2015 20:13:12 André Pönitz wrote:
> On Tue, Feb 10, 2015 at 07:53:23PM +0100, Marc Mutz wrote:
> > On Tuesday 10 February 2015 17:28:09 Thiago Macieira wrote:
> > > On Tuesday 10 February 2015 15:34:45 Knoll Lars wrote:
> > > > +1. I’m ok with us making sure our headers are c
On Tue, Feb 10, 2015 at 07:53:23PM +0100, Marc Mutz wrote:
> On Tuesday 10 February 2015 17:28:09 Thiago Macieira wrote:
> > On Tuesday 10 February 2015 15:34:45 Knoll Lars wrote:
> > > +1. I’m ok with us making sure our headers are clean against warnings (if
> > > possible), but I don’t see a real
On Tuesday 10 February 2015 16:33:23 Knoll Lars wrote:
> Not a whole lot? That Atomic COW is around 10% slower than a Plain string
> (does Atomic COW use a fast allocator?) in the use case where you copy
> strings once and modify them in 2/3 of the cases ;-)
I guess the slowdown from -fexceptions
On Tuesday 10 February 2015 17:28:09 Thiago Macieira wrote:
> On Tuesday 10 February 2015 15:34:45 Knoll Lars wrote:
> > +1. I’m ok with us making sure our headers are clean against warnings (if
> > possible), but I don’t see a real need to enforce it’s usage in
> > implementations.
>
> Fair enoug
On Tuesday 10 February 2015 18:01:09 Christian Kandeler wrote:
> On 02/10/2015 05:33 PM, Olivier Goffart wrote:
> > Note that some STL implementation (most notably the GNU one) use implicit
> > sharing for std::string
>
> I thought that was prohibited in C++11?
It is. But the C++98 mode std::stri
On Tuesday 10 February 2015 18:01:09 Christian Kandeler wrote:
> On 02/10/2015 05:33 PM, Olivier Goffart wrote:
> > Note that some STL implementation (most notably the GNU one) use implicit
> > sharing for std::string
>
> I thought that was prohibited in C++11?
That's right, but GCC did not want
On 10/02/2015 17:33, Olivier Goffart wrote:
> On Tuesday 10 February 2015 17:08:55 Julien Blanc wrote:
>> On 10/02/2015 16:33, Knoll Lars wrote:
>>> IMO there’s simply too many questions that this one example doesn’t answer
>>> to conclude that what we are doing is bad.
>> Two arguments :
>> - impl
On 02/10/2015 05:33 PM, Olivier Goffart wrote:
> Note that some STL implementation (most notably the GNU one) use implicit
> sharing for std::string
I thought that was prohibited in C++11?
Christian
___
Development mailing list
Development@qt-project.
On Tuesday 10 February 2015 17:08:55 Julien Blanc wrote:
> On 10/02/2015 16:33, Knoll Lars wrote:
> > IMO there’s simply too many questions that this one example doesn’t answer
> > to conclude that what we are doing is bad.
>
> Two arguments :
> - implicit sharing is convenient, and really develop
On Tuesday 10 February 2015 15:34:45 Knoll Lars wrote:
> +1. I’m ok with us making sure our headers are clean against warnings (if
> possible), but I don’t see a real need to enforce it’s usage in
> implementations.
Fair enough. But how about allowing people to change zeroes to Q_NULLPTR?
--
Thia
On 10/02/2015 16:33, Knoll Lars wrote:
> IMO there’s simply too many questions that this one example doesn’t answer
> to conclude that what we are doing is bad.
Two arguments :
- implicit sharing is convenient, and really developer friendly. It is
probably a good idea since strings are really pre
On 09/02/15 22:50, "André Pönitz" wrote:
>On Mon, Feb 09, 2015 at 01:28:18PM -0800, Thiago Macieira wrote:
>> On Monday 09 February 2015 22:10:09 André Pönitz wrote:
>> > On Mon, Feb 09, 2015 at 12:58:45PM -0800, Thiago Macieira wrote:
>> > > On Monday 09 February 2015 21:21:12 André Pönitz wrote
On 09/02/15 15:56, "Oswald Buddenhagen"
wrote:
>On Mon, Feb 09, 2015 at 03:30:06PM +0100, Marc Mutz wrote:
>> On Monday 09 February 2015 14:21:44 Rutledge Shawn wrote:
>> > But the advantage of Qt data structures is the implicit sharing.
>>
>> Cough, cough.
>>
>> http://www.gotw.ca/publications
Marc Mutz schreef op 10-2-2015 om 14:19:
> On Tuesday 10 February 2015 13:05:32 Olivier Goffart wrote:
>> I think using a QMap is fine in most case.
> Sorry, no.
>
> I know you don't believe me. Maybe you believe your own eyes:
>
> https://www.youtube.com/watch?v=ApLLVY6MZaI&list=PLHxtyCq_WDLXFAEA-
On Tuesday 10 February 2015 13:05:32 Olivier Goffart wrote:
> I think using a QMap is fine in most case.
Sorry, no.
I know you don't believe me. Maybe you believe your own eyes:
https://www.youtube.com/watch?v=ApLLVY6MZaI&list=PLHxtyCq_WDLXFAEA-
lYoRNQIezL_vaSX-&index=7 start at 30:00
for the r
On Tuesday 10 February 2015 12:37:28 Smith Martin wrote:
> >For those guys, no amount of documentation will save them from writing
> >bad code, so I don't think we should concern ourselves much with this
> >case.
> >
> >I'm happy with the documentation if an educated developer reads it, and
> >is
On Tuesday 10 February 2015 11:37:28 Smith Martin wrote:
> >For those guys, no amount of documentation will save them from writing
> >bad code, so I don't think we should concern ourselves much with this case.
> >
> >I'm happy with the documentation if an educated developer reads it, and
> >is able
10.02.2015, 14:37, "Smith Martin" :
>> For those guys, no amount of documentation will save them from writing
>> bad code, so I don't think we should concern ourselves much with this case.
>> I'm happy with the documentation if an educated developer reads it, and
>> is able to make the correct
rtin
Sent: Tuesday, February 10, 2015 12:20 PM
To: Marc Mutz
Cc: development@qt-project.org
Subject: Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR,
etc.)
>I'm not saying that the docs should not contain some information. I'm saying
>that this is not about our
bet they our users will benefit from
them as well.
martin
From: m...@kdab.com on behalf of Marc Mutz
Sent: Tuesday, February 10, 2015 11:35 AM
To: Smith Martin
Cc: Ziller Eike; development@qt-project.org
Subject: Re: [Development] Upgrading the sources to
On Tuesday 10 February 2015 11:01:50 Smith Martin wrote:
> >So, no, I don't think we should discuss everthing ever written about C++
> >efficiency in the Qt docs. But we need to point it out to each other in
> >code reviews and become better at not writing sloppy code.
>
> The suggestion was not
e
something in QML.
martin
From: m...@kdab.com on behalf of Marc Mutz
Sent: Tuesday, February 10, 2015 10:51 AM
To: Ziller Eike
Cc: Smith Martin; development@qt-project.org
Subject: Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR,
etc.)
On Tuesday 10 Februa
On Tuesday 10 February 2015 08:41:47 Ziller Eike wrote:
> > On Feb 9, 2015, at 3:40 PM, Marc Mutz wrote:
> >
> > On Monday 09 February 2015 09:54:12 Smith Martin wrote:
> >> This is the kind of thing we should add to the documentation, but can
> >> you elaborate? I mean, illustrate the meaning of
> On Feb 9, 2015, at 3:40 PM, Marc Mutz wrote:
>
> On Monday 09 February 2015 09:54:12 Smith Martin wrote:
>> This is the kind of thing we should add to the documentation, but can you
>> elaborate? I mean, illustrate the meaning of "locality of reference,"
>> "wildly mixing insertions, lookups,
On Mon, Feb 09, 2015 at 01:28:18PM -0800, Thiago Macieira wrote:
> On Monday 09 February 2015 22:10:09 André Pönitz wrote:
> > On Mon, Feb 09, 2015 at 12:58:45PM -0800, Thiago Macieira wrote:
> > > On Monday 09 February 2015 21:21:12 André Pönitz wrote:
> > > > I don't think the argument of whitesp
On Monday 09 February 2015 22:10:09 André Pönitz wrote:
> On Mon, Feb 09, 2015 at 12:58:45PM -0800, Thiago Macieira wrote:
> > On Monday 09 February 2015 21:21:12 André Pönitz wrote:
> > > I don't think the argument of whitespace changes making the history
> > > hard to read carries a lot of weight
On Mon, Feb 09, 2015 at 12:58:45PM -0800, Thiago Macieira wrote:
> On Monday 09 February 2015 21:21:12 André Pönitz wrote:
> > I don't think the argument of whitespace changes making the history
> > hard to read carries a lot of weight in a git world.
>
> Whitespaces can be ignored in git diff and
On Monday 09 February 2015 21:21:12 André Pönitz wrote:
> I don't think the argument of whitespace changes making the history
> hard to read carries a lot of weight in a git world.
Whitespaces can be ignored in git diff and git blame. You can't do that with
C++ keywords.
--
Thiago Macieira - thi
On Mon, Feb 09, 2015 at 09:11:54PM +0100, Marc Mutz wrote:
> On Monday 09 February 2015 19:49:19 André Pönitz wrote:
> > I am fairly sure that we won't reach consensus on what the set of such
> > selected places exactly look like, that's why the plan to reach some
> > conclusion was to restrict a p
On Mon, Feb 09, 2015 at 09:05:09PM +0100, Marc Mutz wrote:
> On Monday 09 February 2015 20:10:44 André Pönitz wrote:
> > On Mon, Feb 09, 2015 at 09:36:46AM +0100, Marc Mutz wrote:
> > > I find Q_NULLPTR *beautiful* (bautyful is deeper than pretty), because I
> > > know at some point we will be able
On Monday 09 February 2015 19:49:19 André Pönitz wrote:
> I am fairly sure that we won't reach consensus on what the set of such
> selected places exactly look like, that's why the plan to reach some
> conclusion was to restrict a part of the discussion to one case where I
> think there's a chance
On Monday 09 February 2015 20:10:44 André Pönitz wrote:
> On Mon, Feb 09, 2015 at 09:36:46AM +0100, Marc Mutz wrote:
> > I find Q_NULLPTR *beautiful* (bautyful is deeper than pretty), because I
> > know at some point we will be able to just s/Q_NULLPTR/nullptr/. That's
> > not possible with 0 (not
On Mon, Feb 09, 2015 at 09:36:46AM +0100, Marc Mutz wrote:
> I find Q_NULLPTR *beautiful* (bautyful is deeper than pretty), because I know
> at some point we will be able to just s/Q_NULLPTR/nullptr/. That's not
> possible with 0 (not even with NULL (could be C code)), so I don't see the
> point in
On Mon, Feb 09, 2015 at 08:36:53AM +0100, Bo Thorsen wrote:
> >
> > For the sake of keeping this part of the discussion simple, I specifically
> > mean 'Q_NULLPTR, the macro', _not_ 'nullptr', and I specifically mean the
> > context of initializing a local pointer variable. So: Any advantage? Any
>
On Mon, Feb 09, 2015 at 12:07:15AM +0100, Allan Sandfeld Jensen wrote:
> On Sunday 08 February 2015, André Pönitz wrote:
> > On Sun, Feb 08, 2015 at 10:17:40PM +0100, Allan Sandfeld Jensen wrote:
> > > What would be the point of macros if they always expanded? The entire
> > > point and usefulness
On Monday 09 Feb 2015 16:12:06 Marc Mutz wrote:
> On Monday 09 February 2015 15:56:28 Sean Harmer wrote:
> [...]
>
> > I guess depending upon the sizes of your key and value types and number of
> > elements and typical frequencies of operations (inserts vs lookups vs
> > removals) it may also poss
On Monday 09 February 2015 15:56:28 Sean Harmer wrote:
[...]
> I guess depending upon the sizes of your key and value types and number of
> elements and typical frequencies of operations (inserts vs lookups vs
> removals) it may also possibly be better to use two vectors, one for the
> keys and one
On Monday 09 Feb 2015 09:49:08 Marc Mutz wrote:
> On Monday 09 February 2015 09:32:56 Marc Mutz wrote:
> > > Something like this should work just as well on QVector, right? If you
> > > are doing multiple inserts, perhaps you should keep the inserts outside
> > > the main vector while you make them
On Mon, Feb 09, 2015 at 03:30:06PM +0100, Marc Mutz wrote:
> On Monday 09 February 2015 14:21:44 Rutledge Shawn wrote:
> > But the advantage of Qt data structures is the implicit sharing.
>
> Cough, cough.
>
> http://www.gotw.ca/publications/optimizations.htm (watch the publication date)
>
and w
Am 09.02.2015 um 15:40 schrieb Marc Mutz:
> On Monday 09 February 2015 09:54:12 Smith Martin wrote:
>> This is the kind of thing we should add to the documentation, but can you
>> elaborate? I mean, illustrate the meaning of "locality of reference,"
>> "wildly mixing insertions, lookups, and remo
On Monday 09 February 2015 09:54:12 Smith Martin wrote:
> This is the kind of thing we should add to the documentation, but can you
> elaborate? I mean, illustrate the meaning of "locality of reference,"
> "wildly mixing insertions, lookups, and removals," and "batch updates and
> separate them fro
On Monday 09 February 2015 14:21:44 Rutledge Shawn wrote:
> But the advantage of Qt data structures is the implicit sharing.
Cough, cough.
http://www.gotw.ca/publications/optimizations.htm (watch the publication date)
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a K
On Monday 09 February 2015, Mathias Hasselmann wrote:
> Am 09.02.2015 um 00:07 schrieb Allan Sandfeld Jensen:
> > I am not a big fan of nullptr,
>
> Out of curiosity: What's wrong with nullptr in your opinion?
>
Nothing, except it is just usually not needed, so coding styles that enforce
it are
On 9 Feb 2015, at 13:42, Smith Martin wrote:
>>> Everyone wishing to use a QMap should implement one before
>>> using it for the first time. Then you'd see what you inflict on the world.
>
> If that sentiment is valid, then we owe it to our users who are contemplating
> using a QMap to explain
out of a CS course.
martin
From: development-bounces+martin.smith=theqtcompany@qt-project.org
on behalf of
Bo Thorsen
Sent: Monday, February 9, 2015 12:05 PM
To: development@qt-project.org
Subject: Re: [Development] Upgrading the sources to C++11 ke
28 PM
> To: development@qt-project.org
> Cc: Thiago Macieira
> Subject: Re: [Development] Upgrading the sources to C++11 keywords
> (Q_NULLPTR, etc.)
>
> Hi,
>
> Sorry for being late, didn't see the thread before.
>
> On Thursday 08 January 2015 23:33:
Hi, just my 2 cents: just coding some database stuff using QVariants,
and invariably (especially Monday mornings) it takes me a couple of
milliseconds extra to comprehend what the tooltip for QVariant's toInt()
means:
int toInt(bool *ok = 0) const;
instead, if qvariant.h could be written
from lookups, time-wise."
martin
From: development-bounces+martin.smith=theqtcompany@qt-project.org
on behalf of
Marc Mutz
Sent: Sunday, February 8, 2015 2:28 PM
To: development@qt-project.org
Cc: Thiago Macieira
Subject: Re: [Development] Upgrading the sources to C+
Am 09.02.2015 um 08:48 schrieb André Somers:
> Mathias Hasselmann schreef op 8-2-2015 om 22:28:
>>
>> Am 08.02.2015 um 14:28 schrieb Marc Mutz:
>>
>>> c. Using QMap. As Alex Stepanov put it: every use of a map should be
>>> discussed
>>> in a face-to-face meeting with your manager. Since we
On Monday 09 February 2015 09:32:56 Marc Mutz wrote:
> > Something like this should work just as well on QVector, right? If you
> > are doing multiple inserts, perhaps you should keep the inserts outside
> > the main vector while you make them, and only at the end do a single
> > std::merge.
>
> B
1 - 100 of 125 matches
Mail list logo
