On Sunday 08 November 2015 22:57:03 Dirk Hohndel wrote: > > On Nov 8, 2015, at 10:41 PM, Thiago Macieira <thi...@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 _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface