[Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

[Marc Mutz]

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 mouthful, but it's what everyone will
> > > >be using five years from now, so we might as well start it now.
> > >
> > > 
> > >
> > > The original discussion was about Q_NULLPTR. You talk about nullptr.
> > >
> > > 
> > >
> > > This doesn't make the discussion easier, especially if the difference
> > > between them makes a difference to people's willingness to use them.
> >
> > 
> >
> > Q_NULLPTR is nullptr.
> 
> Unless you have a weird font not displaying capital Q's and underscores,
> and no distinction of lower and upper case 'l', 'n', 'p', 'r', 't' and 'u'
> there's already quite a bit of an optical difference between the two.
> 
> Igoring that, Q_NULLPTR depends currently on Q_COMPILER_NULLPTR. You
> seem to assume that this is present everywhere. So please submit a
> patch removing that and replacing all occurences of Q_NULLPTR and a
> big part of the controversy here would vanish.
> 
> I really don't like sprinkling the code base with macros that sometimes
> expand to standard keywords.

If you want *pretty* code, you should not work on a C++ project. I hear Python 
is pretty. :)

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 continuing to use 0.

Thanks,
Marc


-- 
Marc Mutz <marc.mutz at kdab.com> | 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-Independent Software Solutions