C++11

[corristo]

In a nutshell: there's two c++ std lib implementations for clang: old one from gcc, libstdc++ and new one, libc++, developed by LLVM/Clang project.

libstdc++ is pretty old (Apple stopped using gcc since 4.2.1), so it doesn't support fancy C++11 features like std::move.

And main problems is that libstdc++ & libc++ are not binary compatible (mainly because of different std::string implementations).

So, all OpenMW dependencies should be built with libc++, if OpenMW itself will use libc++.

Currently messing with Ogre to build it with libc++.

[Toc1r]

sorry, didn't know the mac libstdc++ was that ancient...
afaik, ogre has a few problems with libc++, so good luck compiling it!
unfortunately that means that we possibly can't use any of the library functions... (except for maybe std::move which we can replace by boost::move)
the list of possible new features is getting pretty thin

[Zini]

That explains it. Thanks. Waiting for feedback on the issue ...

[corristo]

Ogre compiles, but fails to link due to it's precompiled dependencies (they are built with libstdc++).
Will rebuild them today and try again

[corristo]

Okay, Ogre is built with tiny modifications.

std::map<t1, t2>::const_iterator in libc++ hasn't constructor accepting NULL;

what's the difference between this two statements? Is it safe to replace one with another?

Code: Select all

NameValuePairList::const_iterator opt(NULL); // won't build with libc++
NameValuePairList::const_iterator opt; // okay for both stdlibs I think

I think both if them creates invalid iterator not pointing to anywhere, am I right?

[blunted2night]

Okay, Ogre is built with tiny modifications.

std::map<t1, t2>::const_iterator in libc++ hasn't constructor accepting NULL;

what's the difference between this two statements? Is it safe to replace one with another?

Code: Select all

NameValuePairList::const_iterator opt(NULL); // won't build with libc++
NameValuePairList::const_iterator opt; // okay for both stdlibs I think

I think both if them creates invalid iterator not pointing to anywhere, am I right?

Neither is a valid iterator, but I imagine the second value is uninitialized which means it could be mistaken for a valid iterator since its bits might actually point to something. It would be safe to replace as long as the iterator is never looked at until it is properly initialized. I don't think using NULL to initialize is a standard compliant since I don't believe the standard requires an iterator be simple enough to be fully constructable from a pointer to the underling type.

[Toc1r]

A const_iterator should have 2 possible constructors. A default constructor and a copy constructor.
The default constructor should initialize the internal stuff to some sane value (I guess nullptr for pointers or sth).
What they did was basically some strange use of a copy constructor that luckily didn't crash.
Your fix is how they should have done it in the first place. Alternatively they can also just get rid of the NULL and leave the parentheses.

@Zini: I made a pull request that enables building OpenMW with Clang on Linux again by providing it with essentially the same flags as GCC. As the repo is now, Clang doesn't get the -std=c++0x that is provided to GCC, which is why it won't do what GCC does.

[corristo]

Thanks for clarifications, I'll try to submit my changes directly to Ogre

It would be safe to replace as long as the iterator is never looked at until it is properly initialized.

Yep, exactly. They're initialized later before 1st usage.

Vote, please: https://ogre3d.atlassian.net/browse/OGRE-129

[Zini]

@Zini: I made a pull request that enables building OpenMW with Clang on Linux again by providing it with essentially the same flags as GCC. As the repo is now, Clang doesn't get the -std=c++0x that is provided to GCC, which is why it won't do what GCC does.

Yes, I am aware of that. But if the OS X situation does not pan out, the best course of action for now might be to forbid C++11 completely. Without move and r-value references there isn't really anything in there that makes it worth switching standards and I would rather have compiler settings that catch the use of features we do not allow instead of some minor improvements to the language. Therefore I am holding back on that pull request, until the situation becomes more clear.

[corristo]

I have to build Qt & bullet with libc++ and we're good to go.

I think it's not critical to maintain slightly patched ogre repo for one platform before patch will enter upstream. It's not a problem compared to Linux, for example, where dependencies mostly installed through apt/yum/whatever.

Give me a time to next week beginning, I'll report current progress.