View Single Post
  #19   Spotlight this post!  
Unread 17-01-2013, 07:38
rbmj rbmj is offline
Registered User
FRC #0612 (Chantilly Robotics)
Team Role: Alumni
 
Join Date: Apr 2011
Rookie Year: 2011
Location: DC Area/Fairfax County
Posts: 192
rbmj is a jewel in the roughrbmj is a jewel in the roughrbmj is a jewel in the rough
Re: Alternate GCC Toolchain

Quote:
Originally Posted by CodeYeti View Post
Sounds good. I'll have to get working on the compatibility issue. I've fixed all the errors, and some of the warnings for WPILib with C++11. I can confirm that at least the memory management features of C++11 work on hardware as of tonight!

The C++11 only version of WPILib is here: https://github.com/mcoffin/wpilib/tree/cxx11.

As for making sure we're backwards compatible, from what I've read, WPILib as it is shouldn't compile under C++98 either, it's just a fluke that GCC is playing loose with the standards there. Therefore, I think that when making a fix, it would be best to avoid the initialization of static constant members that are floats/doubles from within the class declaration all together. I think that the next best solution would just be to put them in the constructor? That would work on both standards, whereas the constexpr fix defining them as expressions would only work for C++11.
Ha yes, as it stands a *lot* of code shouldn't compile under C++98 either. However GCC 3.x is *very* lax with compliance. GCC 4 really stepped up on its strictness, which is great except it also causes cases like these. I think in c++98 mode there's a little more leniency built in just for backwards compatibility.

Well, if it's a static const you can:
Code:
//foo.h
class foo {
   static const float bar;
};
//foo.cpp
#include "foo.h"
const float foo::bar = 1.0;
AFAIK that will work.

Quote:

EDIT: The contents of include-fixed are as follows. I'm going to re-start from scratch just in case I missed a flag somewhere that caused fixincludes to mess up, but here are the contents in case I get the error again:
Code:
limits.h
README
syslimits.h
If you get this, that indicates that fixincludes was screwed up. If you look now you should see a *lot* more files. These are replacement headers that deal with the various errors in the actual headers
Quote:
EDIT 2: To anybody that's thinking of dealing with WPILib, I suggest adding the following flag in CMAKE_CXX_FLAGS to filter out all the deprecated string literal warnings. There's no way that anybody is going to go through the whole library and convert it to using std::string unless that have absolutely no life.
Code:
-Wno-write-strings
Agreed. This is an issue with vxWorks itself. Not much we can do here. If we wanted to we could add a rule to fixincludes, but I don't think a warning that we know to be spurious and can disable is worth the extra effort involved in getting accepted upstream or the complications of building patched source.
Quote:
EDIT 3: Build error was just a fluke. I have no idea what happened. Deleted my build directory, reconfigured and it worked. That was pretty stupid on my part. Sorry for the hassle on that one.
No problem. Sometimes GCC builds fail for random unknown reasons...
Quote:
EDIT 4: The virtual destructor warnings are legit. These are abstract classes with pure abstract methods, and the classes have derived classes. This means that if a derived class were to have an explicit destructor, it wouldn't be getting called. I'll be sure to fix those warnings in the next round of fixes.
And this is why we use compiler warnings!
Quote:
EDIT 5: The master branch on my git repository should fix many of the compiler warnings for wpilib on C++98 as well. I haven't tested compatibility with old versions of GCC yet though. I did leave some unnecessary typedef's in there because I think that they, at some point, were necessary, so WindRiver's version of GCC might still want them and I don't want to break compatibility with it. The C++11 branch has these changes pulled in as well.
Awesome!