[PATH] fix broken mac build on old clangs.

[Thiago Macieira]

On Sunday 08 November 2015 22:57:03 Dirk Hohndel wrote:
> > On Nov 8, 2015, at 10:41 PM, Thiago Macieira <thiago at macieira.org> wrote:
> > 
> > Can you try adding the -stdlib option in the AppleClang branch to see what
> > happens?
> 
> I have an odd question.
> 
> Why?

Well, for one thing, because it would use libc++, which is maintained for 
later versions of OS X, whereas GNU's libstdc++ is old and not updated by 
Apple (GPLv3 controversy).

Both libs are good in their *current* versions. But Apple stopped updating 
libstdc++ 8 years ago.

> What we have in master works.
> 
> I have no interest in seeing Subsurface code made unreadable by C++11
> features - literally every thing I have seen so far from C++11 I find a)
> annoying b) not an improvement.

I partially agree and partially disagree. But I can say I don't like 
gratuitous use of certain features just because they are there, if they reduce 
readability. I'd much rather see a for loop initialising something than a call 
to std::fill_n.

> -               for(ISocialNetworkIntegration *plugin :
> PluginManager::instance().socialNetworkIntegrationPlugins()){ 
> +               Q_FOREACH(ISocialNetworkIntegration *plugin,
> PluginManager::instance().socialNetworkIntegrationPlugins()){ 

Kind of a no-op change. I'd even say that lowercase "for" is less a sore in 
the eyes than "Q_FOREACH". Why isn't it the lowercase "foreach" anyway?

> 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. 
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.

Maybe a compromise is to use Q_DISABLE_COPY(PluginManager).

> What is removed there to go back regular C++ is plain syntactic nonsense...
> the code that it brings back is actually readable and makes sense. So why
> would I want to spend time to figure out how to allow C++11 code in
> Subsurface?

Right. Those two above, even if minor improvements, are not worth the hassle.

What I'm trying to figure out is why it's a hassle in the first place. The 
compiler that comes with Xcode 4.6 should be powerful enough. More 
importantly, this shows there's a problem somewhere, somehow causing problems 
building Qt applications and I should investigate it. 

Qt 5.6 (the Long Term Release) should work with Xcode 4.6.

> All that said? I think I'm happy with just rejecting C++11 code and keeping
> our compilers focused on gnu99

Fair enough, but you won't get away with that for long :-P

Qt 5.6 will be the last release to support building in C++98 mode. Starting 
with Qt 5.7, a great deal of C++11 will be mandatory and the minimum version 
of Xcode will be 5.1.

-- 
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