On Mon, Nov 9, 2015 at 6:11 PM, Dirk Hohndel <[email protected]> wrote:
> On Mon, Nov 09, 2015 at 11:51:30AM -0800, Thiago Macieira wrote: > > On Sunday 08 November 2015 22:57:03 Dirk Hohndel wrote: > > > > On Nov 8, 2015, at 10:41 PM, Thiago Macieira <[email protected]> > 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. > > Fun. Gotta love Apple. > > > > 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. > it deletes the Copy Constructor and the operator=, if you don't declare them the compiler will declare one anyhow. the way one does that in pre c++11 is to declare an empty copy constructor and equal operator on the private area, but they are implemented by the constructor, only hard to reach. > > > 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? > the ones after the } > > > Maybe a compromise is to use Q_DISABLE_COPY(PluginManager). > > Or get rid of plugins that I don't really see the value of... > you are no fun :P > > > 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. > > I'll burn that bridge when we get there. > > 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? > yes, it will be required a compiler that uses c++11 to build Qt. > > Because if Qt wants to stay somewhat compatible to its existing user base > then it should be careful about staying USABLE with C++98 mode... > > > 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. > > /D > _______________________________________________ > subsurface mailing list > [email protected] > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface >
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
