[PATH] fix broken mac build on old clangs.

[Tomaz Canabrava]

On Mon, Nov 9, 2015 at 6:11 PM, Dirk Hohndel <dirk at hohndel.org> 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 <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.
>
> 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
> subsurface at subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20151109/94f2b2ad/attachment.html>