<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 9, 2015 at 6:11 PM, Dirk Hohndel <span dir="ltr"><<a href="mailto:dirk@hohndel.org" target="_blank">dirk@hohndel.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Nov 09, 2015 at 11:51:30AM -0800, Thiago Macieira wrote:<br>
> On Sunday 08 November 2015 22:57:03 Dirk Hohndel wrote:<br>
> > > On Nov 8, 2015, at 10:41 PM, Thiago Macieira <<a href="mailto:thiago@macieira.org">thiago@macieira.org</a>> wrote:<br>
> > ><br>
> > > Can you try adding the -stdlib option in the AppleClang branch to see what<br>
> > > happens?<br>
> ><br>
> > I have an odd question.<br>
> ><br>
> > Why?<br>
><br>
> Well, for one thing, because it would use libc++, which is maintained for<br>
> later versions of OS X, whereas GNU's libstdc++ is old and not updated by<br>
> Apple (GPLv3 controversy).<br>
><br>
> Both libs are good in their *current* versions. But Apple stopped updating<br>
> libstdc++ 8 years ago.<br>
<br>
</span>Fun. Gotta love Apple.<br>
<span class=""><br>
> > private:<br>
> >         PluginManager();<br>
> > -       PluginManager(const PluginManager&) = delete;<br>
> > -       PluginManager& operator=(const PluginManager&) = delete;<br>
> > +       PluginManager(const PluginManager&){};<br>
> > +       PluginManager& operator=(const PluginManager&){};<br>
> >  };<br>
><br>
> To me, that improves readability, since the = delete is clear in what it does.<br>
<br>
</span>Actually, I have not the faintest idea what it does.<br></blockquote><div><br></div><div>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.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> Moreover, it improves the error message in case you do accidentally try to<br>
> copy the object. And there's a silly error in the patch, that adds ; that<br>
> shouldn't be there.<br>
<br>
</span>Which one?<br></blockquote><div><br></div><div>the ones after the }<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> Maybe a compromise is to use Q_DISABLE_COPY(PluginManager).<br>
<br>
</span>Or get rid of plugins that I don't really see the value of...<br></blockquote><div><br></div><div>you are no fun :P<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> What I'm trying to figure out is why it's a hassle in the first place. The<br>
> compiler that comes with Xcode 4.6 should be powerful enough. More<br>
> importantly, this shows there's a problem somewhere, somehow causing problems<br>
> building Qt applications and I should investigate it.<br>
><br>
> Qt 5.6 (the Long Term Release) should work with Xcode 4.6.<br>
><br>
> > All that said? I think I'm happy with just rejecting C++11 code and keeping<br>
> > our compilers focused on gnu99<br>
><br>
> Fair enough, but you won't get away with that for long :-P<br>
><br>
> Qt 5.6 will be the last release to support building in C++98 mode. Starting<br>
> with Qt 5.7, a great deal of C++11 will be mandatory and the minimum version<br>
> of Xcode will be 5.1.<br>
<br>
</span>I'll burn that bridge when we get there.<br>
<br>
But I have an important question in that context. Will you be required to<br>
use C++11 nonsense to USE Qt or will you be required to use a compiler<br>
that supports this nonsense to BUILD Qt?<br></blockquote><div><br></div><div>yes, it will be required a compiler that uses c++11 to build Qt.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Because if Qt wants to stay somewhat compatible to its existing user base<br>
then it should be careful about staying USABLE with C++98 mode...<br></blockquote><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
But what this might mean is that Subsurface will try to stay on Qt 5.6 for<br>
quite a while. Given that it's the long term release that may not be<br>
entirely unreasonable either.<br>
<span class="HOEnZb"><font color="#888888"><br>
/D<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
subsurface mailing list<br>
<a href="mailto:subsurface@subsurface-divelog.org">subsurface@subsurface-divelog.org</a><br>
<a href="http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface" rel="noreferrer" target="_blank">http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface</a><br>
</div></div></blockquote></div><br></div></div>