Boost-free C++11 (or TR1?) version of the clientkit C++ bindings

[rpavlik]

Per a presentation I read re: Ubisoft's dev. of games in C++ , they don't allow boost in their main tree, and I'm sure they're not the only ones. The main reason we're using Boost in the clientkit bindings is for relatively simple things (shared_ptr, etc) that we could get if the user agreed to a higher C++ standard (Not sure if TR1 suffices or if C++11 is needed, offhand)

(presentation is here: https://github.com/CppCon/CppCon2014/blob/master/Presentations/C%2B%2B%20in%20Huge%20AAA%20Games/C%2B%2B%20in%20Huge%20AAA%20Games%20-%20Nicolas%20Fleury%20-%20CppCon%202014.pdf I just read the slides, didn't watch the video)

[rpavlik]

@yboger Can you get in touch with your game industry contacts to see if this is worthwhile? We were going for minimum compiler requirements/max compatibility on the API wrapper (it works at least as far back as VS 2008), hence the usage of Boost instead of C++11 or TR1, but what I've seen so far of game engines is that they're mostly all already using VS 2013. What I really wouldn't want to see is the (slightly unsafe, less usable) C API being used (or a wrapper re-invented) in C++ games/engines because the wrapper uses things that aren't allowed.

[VRguy]

what's the downside of using Boost?

[rpavlik]

Well, it's a huge library collection, and apparently, at least according to that presentation, it's banned in some codebases. I think such a ban would have one of these causes:

• to reduce deps (particularly for projects that basically stick every dependency in their source tree - for instance, see the massive 1.5gb repo of just the VR-related components of the Steam SDK)
• a mis-placed or over-strict philosophical stance: it's possible to write crazy-complicated meta-style impossible-to-maintain code or code that incurs unexpected performance hits with some Boost libraries, but some Boost libraries are so basic and useful they've ended up in newer versions of the C++ standard.

It's the latter category of libraries we use in the wrappers, hence why we could basically replace/alternate the boost usage with newer C++ standards. They are close enough that we could maintain essentially the same interface, just letting the user pick whether they want to require Boost or a newer C++ compiler than VS2008.

[VRguy]

so if we got rid of Boost, we'd need VS2010? Something newer?

On 4/1/2015 1:48 PM, Ryan Pavlik wrote:

Well, it's a huge library collection, and apparently, at least
according to that presentation, it's banned in some codebases. I think
such a ban would have one of these causes:

• to reduce deps (particularly for projects that basically stick
  every dependency in their source tree - for instance, see the
  massive 1.5gb repo of just the VR-related components of the Steam SDK)
• a mis-placed or over-strict philosophical stance: it's possible to
  write crazy-complicated meta-style impossible-to-maintain code or
  code that incurs unexpected performance hits with some Boost
  libraries, but some Boost libraries are so basic and useful
  they've ended up in newer versions of the C++ standard.

It's the latter category of libraries we use in the wrappers, hence
why we could basically replace/alternate the boost usage with newer
C++ standards. They are close enough that we could maintain
essentially the same interface, just letting the user pick whether
they want to require Boost or a newer C++ compiler than VS2008.

—
Reply to this email directly or view it on GitHub
#44 (comment).

[rpavlik]

The core internally uses boost and C++11, so it requires boost and VS2013 (or a not-ancient gcc or clang), which would be hard and counterproductive to change, so we're only talking about the C++ header-only API wrapper that takes the stable C API and makes it easier to use and safer.

So I'd imagine that for the C++ wrapper on ClientKit, we'd have some #ifdef OSVR_HAVE_MODERN_CPP wrapping the C++11 stuff vs. the Boost-based stuff. So, if someone wanted to use really old compilers, they still could, with Boost. I haven't gone through specifically what we use, but a quick skim of the include graph reveals:

• shared_ptr (which is in TR1 and so in VS2008SP1 and newer)
• noncopyable (which can be re-written trivially)
• scoped_array - can be replaced with unique_ptr (C++11) to an array - looks like unique_ptr is in VS2010. I think I could also do this with shared_ptr and a custom deleter, which would lower it to TR1 aka 2008SP1
• function - TR1 and thus 2008SP1
• type_traits - TR1, so 2008SP1
• One tiny piece of MPL that is 3 lines of code to replace

So, for ClientKit, 2010 easily, 2008SP1 with a little poking (sometimes getting things from TR1 is weird because of namespaces, and the scoped array replacement is less clear).

Didn't realize so much was in TR1.

[CrossVR]

Boost is only allowed as an optional dependency in the Dolphin Emulator project, which means that building Dolphin with OSVR support has to remain optional as long as there is a boost dependency in the Client Kit.

C++11 is now widely support, no developer in VR would still be using an IDE as ancient as VS2005. I would argue that we should expand this issue to not just the ClientKit, but the entire OSVR Core since C++11 is already required there. Me and @feilen can definitely help you with the porting process.

[rpavlik]

In the core, we do use more boost functionality than has been integrated in C++11, so I don't think removing boost from internal libraries is likely to be a wise (or easy) road. The C++ header-only wrappers for pluginkit and clientkit were designed for minimal dependencies, which is why they're C++98 and ancient boost headers, but I agree that at this point, at least for the client side (plugins are a whole other issue, since some vendors provide C++ APIs only so you have to match compilers on Windows) there's probably more devs who can use C++11 than Boost. Should be relatively straightforward to make this change and/or make it optional (behind ifdefs) since we're primarily using shared_ptr on the clientkit C++ headers, IIRC.

Happy to offer guidance where needed, and review pull requests.

[CrossVR]

I've posted about this issue on the mailing list: http://comments.gmane.org/gmane.comp.vr.osvr.devel/23