[PATH] fix broken mac build on old clangs.

Thiago Macieira thiago at macieira.org
Mon Nov 9 13:42:17 PST 2015


On Monday 09 November 2015 12:11:30 Dirk Hohndel wrote:
> > > private:
> > >         PluginManager();
> > > 
> > > -       PluginManager(const PluginManager&) = delete;
> > > -       PluginManager& operator=(const PluginManager&) = delete;
> > > +       PluginManager(const PluginManager&){};
> > > +       PluginManager& operator=(const PluginManager&){};
> > > 
> > >  };
> > 
> > To me, that improves readability, since the = delete is clear in what it
> > does.
> Actually, I have not the faintest idea what it does.

Yeah, if you don't know the syntax, it's quite clear that it would be less 
readable.

The = delete suffix tells the compiler "this function is deleted" (doesn't 
exist). You use it only on functions that would otherwise exist if you don't 
write anything, like the C++ "rule of 5" members:
	* copy constructor: PluginManager(const PluginManager &)
	* move constructor: PluginManager(PluginManager &&)
	* copy-assignment operator: operator=(const PluginManager &)
	* move-assignment operator: operator=(PluginManager &&)
	* destructor: ~PluginManager()

In C++98, the rule was "rule of 3" because the move variants didn't exist.

Anyway, my recommendation is to remove the {} part. Just leave the 
declarations with no corresponding implementation:

	PluginManager(const PluginManager &);
	PluginManager &operator=(const PluginManager &);

With no implementation, even if you accidentally try to copy from somewhere 
that can access the privates, you'll get a linker error later.

> > Moreover, it improves the error message in case you do accidentally try to
> > copy the object. And there's a silly error in the patch, that adds ; that
> > shouldn't be there.
> 
> Which one?

You don't add ; after function bodies:

int main()
{
};

> But I have an important question in that context. Will you be required to
> use C++11 nonsense to USE Qt or will you be required to use a compiler
> that supports this nonsense to BUILD Qt?

No, you don't have to use any C++11 feature in your source code. The language 
is almost entirely backwards compatible, so your existing C++98 code that used 
to work will continue to work. Source compatibility is also very important for 
Qt.

I can't think of anything that would require you to write a specific C++11 
syntax to access new features either.

But Qt will require a C++11 compiler to compile its code and for all code 
#include'ing a Qt header. That is, you will need to pass -std=c++11, 
-std=c++14 or -std=c++1z to the compiler if you want to use Qt.

This is what you will get from qglobal.h if you compile in C++98 mode:

qbasicatomic.h:54:4: error: #error "Qt requires C++11 support"
 #  error "Qt requires C++11 support"
    ^
qbasicatomic.h:83:13: error: ‘QAtomicOps’ does not name a type
     typedef QAtomicOps<T> Ops;
             ^
In file included from ./QtCore/qglobal.h:1:0,
                 from <command-line>:0:
qbasicatomic.h:86:23: error: ‘QAtomicOpsSupport’ was not declared in this 
scope
[another 100 lines of errors relating to atomics]

> But what this might mean is that Subsurface will try to stay on Qt 5.6 for
> quite a while. Given that it's the long term release that may not be
> entirely unreasonable either.

And that's the point of a long-term release. Since we're going to increase the 
compiler requirements, there will be one last release that can be compiled 
with old compilers. 

And since Apple, Microsoft, and QNX tie compiler versions to OS versions, this 
has implications for some OS support too.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358



More information about the subsurface mailing list