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
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 manag
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 that, I'd
change this to: Everyone wishing to use
Den 08-02-2015 kl. 22:42 skrev André Pönitz:
> 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 macros is that they expand to standard keywords when
>> those standard keyw
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?
Ciao,
Mathias
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailm
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 macros is that they expand to standard
> > keywords when those standar
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 macros is that they expand to standard keywords when
> those standard keywords exists.
What's the point of using a macro
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 that, I'd
> change this to: Everyone wishing to use a QMap should implement one before
> using
On Sunday 08 February 2015, 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
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 mouthful, but it's what everyone will be
> > >using
On Sunday 08 February 2015 20:06:14 André Pönitz wrote:
> On Sun, Feb 08, 2015 at 02:28:03PM +0100, Marc Mutz wrote:
> > 3. nullptr - On top of the warning, which I wasn't aware about, I find the
> >
> >code easier to read. It's a mouthful, but it's what everyone will be
> >using
> >fi
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 mouthful, but it's what everyone will be
> >using five years from now, so we might as well start it now.
>
> The origina
On Sun, Feb 08, 2015 at 02:28:03PM +0100, Marc Mutz wrote:
> 3. nullptr - On top of the warning, which I wasn't aware about, I find the
>code easier to read. It's a mouthful, but it's what everyone will be using
>five years from now, so we might as well start it now.
The original discussio
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 to propose the following.
I totally agree, with the following ame
On Wednesday 04 February 2015 12:47:42 Matthew Woehlke wrote:
> However, explicit defaulting is still interesting for the *default*
> constructor. (See
> https://msdn.microsoft.com/en-us/library/dn457344.aspx; apparently in
> MSVC at least there are advantages to an explicitly defaulted default
> c
On 2015-02-02 17:51, Thiago Macieira wrote:
> On Monday 02 February 2015 14:29:21 Matthew Woehlke 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
>>
>> I'd actually like to
On Monday 02 February 2015 14:29:21 Matthew Woehlke 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
>
> I'd actually like to see this used where possible and sensible,
On 2015-01-08 17:33, 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 to propose the following.
>
> Policy per keyword:
>
> * Q_NULLPTR - strongly encouraged
>
> Use it whenever your literal zero is a null
> On Jan 9, 2015, at 10:10 PM, Thiago Macieira
> wrote:
>
> On Friday 09 January 2015 20:19:36 André Pönitz wrote:
>> In some case these macros even expand to something else than the "obviously
>> related" C++ keyword, so potential benefits gained from using the actual
>> feature have to be wei
On Sunday 11 January 2015 13:59:56 Giuseppe D'Angelo wrote:
> > We may have to add that to headersclean, since conceivably our users may
> > want to use it. But we don't have to turn it on for our sources.
>
> Doesn't that already mean an awful lot of work? Thinking of how many
> places there are
On 9 January 2015 at 22:53, Thiago Macieira wrote:
> On Friday 09 January 2015 22:15:25 Giuseppe D'Angelo wrote:
>> On 9 January 2015 at 20:19, André Pönitz wrote:
>> > C++ 'nullptr' only gives a benefit over '0' in the rare cases where it
>> > helps for disambiguation. I would not really like a
On Friday 09 January 2015 22:15:25 Giuseppe D'Angelo wrote:
> On 9 January 2015 at 20:19, André Pönitz wrote:
> > C++ 'nullptr' only gives a benefit over '0' in the rare cases where it
> > helps for disambiguation. I would not really like a policy encouraging
> > 'nullptr' when '0' is just fine, b
On 9 January 2015 at 20:19, André Pönitz wrote:
>
> C++ 'nullptr' only gives a benefit over '0' in the rare cases where it
> helps for disambiguation. I would not really like a policy encouraging
> 'nullptr' when '0' is just fine, but at least that would be tolerable.
Not only that, compilers are
On Friday 09 January 2015 20:19:36 André Pönitz wrote:
> In some case these macros even expand to something else than the "obviously
> related" C++ keyword, so potential benefits gained from using the actual
> feature have to be weighed with the costs of obfuscation.
They expand to the correct key
On Thu, Jan 08, 2015 at 02:33:34PM -0800, 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.
That sounds good, but is not what is proposed in the text below. Instead,
the proposal is to use non-standard Q_KEY
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.
Policy per keyword:
* Q_NULLPTR - strongly encouraged
Use it whenever your literal zero is a null pointer. You can leave it out when
it cannot be mis
101 - 126 of 126 matches
Mail list logo
