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 had
On 23/07/15 19:16, Thiago Macieira thiago.macie...@intel.com 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
On Thursday 23 July 2015 16:29:12 Knoll Lars wrote:
On 23/07/15 14:27, Marc Mutz marc.m...@kdab.com 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
On 24/07/15 13:34, Marc Mutz marc.m...@kdab.com wrote:
On Thursday 23 July 2015 16:29:12 Knoll Lars wrote:
On 23/07/15 14:27, Marc Mutz marc.m...@kdab.com 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
-
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 marc.m...@kdab.com 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
-
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 marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt
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 that a)
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 will
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_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 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 compiler
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
On 23/07/15 14:27, Marc Mutz marc.m...@kdab.com 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
On 23/07/15 14:23, Marc Mutz marc.m...@kdab.com 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
On 23/07/15 14:27, Marc Mutz marc.m...@kdab.com 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
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 not
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-null
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
pointers
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 23 July 2015 15:47:10 Knoll Lars wrote:
On 23/07/15 14:23, Marc Mutz marc.m...@kdab.com 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
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 marc.m...@kdab.com wrote:
On Tuesday 10 February 2015 08:41:47 Ziller Eike wrote:
On Feb 9, 2015, at 3:40 PM, Marc Mutz marc.m...@kdab.com wrote:
On Monday 09 February 2015 09:54:12 Smith Martin wrote:
This is the kind of thing we should add to the
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 to me
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 reading
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 saying that
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 ptr = 0
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, but just
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 something
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 examples:
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
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 like
11.02.2015, 12:13, Marc Mutz marc.m...@kdab.com:
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,
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:12
On 11/02/15 10:46, Marc Mutz marc.m...@kdab.com 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
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 aesthetic
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=ApLLVY6MZaIlist=PLHxtyCq_WDLXFAEA-
On 09/02/15 22:50, André Pönitz apoen...@t-online.de 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é
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
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 to
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 :
- implicit sharing
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?
--
Thiago
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
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 developer
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::string is
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 to
On Tuesday 10 February 2015 08:41:47 Ziller Eike wrote:
On Feb 9, 2015, at 3:40 PM, Marc Mutz marc.m...@kdab.com 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
From: m...@kdab.com m...@kdab.com on behalf of Marc Mutz marc.m...@kdab.com
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 February
from
them as well.
martin
From: m...@kdab.com m...@kdab.com on behalf of Marc Mutz marc.m...@kdab.com
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 C
of
Smith Martin martin.sm...@theqtcompany.com
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
10.02.2015, 14:37, Smith Martin martin.sm...@theqtcompany.com:
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
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 to make
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 is
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 need to
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 enough. But
On 09/02/15 15:56, Oswald Buddenhagen
oswald.buddenha...@theqtcompany.com 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.
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 clean
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:53:23PM +0100, Marc Mutz wrote:
On Tuesday 10 February 2015 17:28:09 Thiago Macieira wrote
: [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 February 2015 15:34:45 Knoll
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 Knoll Lars
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 doesn't support
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 warnings (if
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
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
void something()
{
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/nullptr/.
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 wrote:
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;
...
}
over
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=ApLLVY6MZaIlist=PLHxtyCq_WDLXFAEA-
lYoRNQIezL_vaSX-index=7 start at 30:00
for the
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 able to
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 than
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 clean
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 don't have
] 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:34 Thiago Macieira wrote:
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
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 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 possibly be
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 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 even
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 to
On Monday 09 February 2015 08:48:06 André Somers wrote:
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 Sunday 08 February 2015 21:47:35 André Pönitz wrote:
On Sun, Feb 08, 2015 at 09:08:01PM +0100, Marc Mutz wrote:
On Sunday 08 February 2015 20:06:14 André Pönitz wrote:
3. nullptr - On top of the warning, which I wasn't aware about, I
find the
code easier to read. It's a
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.
Boom.
On Feb 9, 2015, at 3:40 PM, Marc Mutz marc.m...@kdab.com 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,
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 of these
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 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 part of
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 git
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 to just
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 in a
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 -
-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:34 Thiago Macieira wrote:
I think it's time to institute a policy that we should
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
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 more
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 marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland)
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 whitespace
...@kdab.com
Sent: Sunday, February 8, 2015 2: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:34
On 9 Feb 2015, at 13:42, Smith Martin martin.sm...@theqtcompany.com 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
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 from
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 removals, and
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 what
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, and
1 - 100 of 120 matches
Mail list logo
