search

asrob-uc3m / robotDevastation

A new-generation shooter with augmented reality and real robots. You can play online with other users with your PC, moving robots in championships and campaigns: all 24/7!
http://asrob-uc3m.github.io/workgroups/2017-05-28-robot-devastation.html
GNU Lesser General Public License v2.1
9 stars 4 forks source link

Upgrade code base to use C++11 #104

Open PeterBowman opened 7 years ago

PeterBowman commented 7 years ago

Backward compatibility should not be an issue unless we plan on supporting quite old systems (e.g. Ubuntu Precise, which is reaching its EOL at the time of writing).

PeterBowman commented 7 years ago

Starting from YARP 2.3.72 (scheduled release on 15th November), C++11 will be required for YARP-dependent code (2.3.70 added this prerequisite to compile YARP itself). Cron jobs are currently breaking on upstream devel branch: https://travis-ci.org/asrob-uc3m/robotDevastation/builds/266750949.

PS said errors can be easily solved by switching the adequate compiler option. This issue aims at introducing C++11 features into RD code.

PeterBowman commented 6 years ago

See #109 regarding previous comment. This issue is blocked for that reason.

PeterBowman commented 6 years ago

Question: do we want a smooth transition to C++11 so that unsupported compilers may still build RD (CMake has tools for gradually introducing new language features), or just start using modern C++ constructs straight away?

Remark: Trusty fully supports C++11 via gcc (ref1 + ref2). Same applies for MSVC starting from VS 2015 (ref). The previous question boils down to deciding on which distros are supported by RD.

jgvictores commented 6 years ago

This can be answered from diverse perspectives.

  1. YARP. In relation to connecting PC and robots, both parts should agree on protocol. If YARP versions have to match, the device with the oldest OS would be the bottleneck (i.e. the TEO Debian 6.0 affair). Luckily, the low-level of YARP doesn't break compatibility that often. The part that does often change protocol is remote_controlboard, which is used in TEO but not in RD. This means that in RD, YARP versions do not have to match perfectly. We can use the latest stuff on the PC version (which is where we are considering c++11) and maybe older stuff on more limited equipment.
  2. Trusty/gcc is good. Regarding Windows, a though experiment would be to think about supporting XP. It seems kind of possible via the 140_xp platform toolset. If not, well, mingw also seems to provide some support.
  3. Robot Devastation has always been about playing around, trying to do things we have no idea of how to do!

Given (3), and since we are not breaking backward compatibility in terms of (1) or (2), I'd say "Let's go for it!" and would move on to using modern C++ (as in c++11, not c++17 yet) constructs straight away!