Code Ran successfully but not being able to deployed

[Oblarg]

I would also add that C++ is call-by-value where as Java is call-by-reference. This basically means that any parameter that is modified within a function will retain that modified value outside the function. This can be helpful if you want that to happen, but it can be hard to trace down if you are not aware of it happening in someone else’s function that you are calling. (Note that this is related to the “Java doesn’t have pointers” point made above… in C++ you can call-by-reference by passing the parameter as a pointer).

This is not true. Per the official language spec, Java is pass-by-value. This is a common confusion that stems from the fact that all objects in Java are actually references, and so passing an object in Java is passing a reference by value. It is therefore possible for a subroutine to make permanent changes to the object it has been passed by manipulating the memory pointed-to by the reference; but what has been passed is a copy of the reference, not the reference itself.

This distinction is important. If you reassign a passed reference in a Java function, nothing happens to the reference outside of the function. In a true “pass-by-reference” language, this would not be the case.

A typical test for “pass-by-reference” is the possibility of writing a “swap” subroutine on parameters (a,b) of the form “c=b; b=a; a=c;” - in a pass-by-reference language, calling this will swap the values of “a” and “b” in the calling code. In Java, this does nothing.

Edit: Additionally, if I may add my two cents, I strongly discourage the use of C++ for FRC if you are not an experienced programmer, and really even if you are (at least for code running on the RIO). Performance requirements and hardware constraints in FRC, even with the…lackluster…specs of the roboRIO, are not such that there are significant costs to running Java in all but a very small number of situations. Java, by virtue of being a modern VM-based language, is far easier to write, read, compile, and debug. Coding in C++ is well-known to be something of an endeavor at the best of times; many of the language’s design choices (header files, for instance) were made 30 years ago when computers could barely fit the code for a single class into memory during compilation. Unfortunately, there’s something of a pervasive “macho programmer” aesthetic that idolizes the pain and inconvenience of writing in C++ as if it were proof of one’s programming prowess; this is a dumb and counterproductive mindset, and should be avoided. There are use-cases in which C++ is the correct tool for the job; FRC is generally not one of them, especially if you are a new team with limited programming experience.

[calcmogul]

I’m not familiar with that syntax in the last private block, so maybe I’m out to lunch here figuratively as well as literally, but it looks (for example) like you’re initializing myRobot to be an **array **of four numbers, not the result of instantiating it with four numbers as arguments.

That’s uniform initialization syntax. It calls the constructor of RobotDrive with four int arguments. The array thing you’re thinking of requires a std::initializer_list constructor overload. If one existed, it would use that instead and do as you describe (but that would be confusing, so we aren’t doing that with our API).

Just curious, is there a reason you do not have constructor for your Robot class? I certainly don’t claim to know every valid syntax for coding in C++ but it seems very odd that you have these lines of code below (which instantiate your drivetrain and OI objects) sitting in your Robot.cpp file but not in a constructor or other class method.

//Setting up the share Subsystems and oi so that the commands can use it
std::shared_ptr<DriveTrain> Robot::drivetrain = std::make_shared<DriveTrain>();
std::unique_ptr<OI> Robot::oi =  std::make_unique<OI>();

Since these subsystems need to be accessible to all subclasses of Command, they are made static. C++ requires a definition of the static variable outside the class scope, which is what that snippet is. Static variables could be removed if we provided a way for commands to access their parent robot, and thus the subsystems. I still need to explore this before I write up a patch for it.

Although the RobotInit method is called by the framework/base class code once at startup, it is not a replacement for a constructor. C++ code expects that the constructor for any class will instantiate and initialize all class members, like your drivetrain and oi objects.

<…snip…>

If you look that code over you will notice that you have a constructor for your robot class and you don’t have those lines of code sitting there outside of any functions before your RobotInit method. I suspect if you put that code into the class constructor you might have better results.

Since those variables are statics, they should not be initialized in the constructor. If you do that, they will be reinitialized every time you make an instance of the class. It still works because you only ever construct one instance, but that doesn’t make it correct. For C++ statics, you declare the variable with the static keyword in the class definition in the header, then provide a definition of the variable in the .cpp file as follows:

Type Class::name = initialValue;

With all that said, my best guess for the problem at hand is object lifetime issues, but I’m too busy to try this on my roboRIO.

You’ll notice for 2018 we’ve been shifting from using smart pointers everywhere to declaring things inline with the class definition (like the construction of RobotDrive shown by the OP) as well as use references in the constructors. Smart pointers were overkill and made things more complicated than they needed to be.

Edit: Additionally, if I may add my two cents, I strongly discourage the use of C++ for FRC if you are not an experienced programmer, and really even if you are (at least for code running on the RIO).

I’ll be the first to admit that the Java version of command-based is a lot easier to use than the C++ version. This is due to designing the API with Java in mind (new everywhere!), then trying to shoehorn it into C++. The lifetime assumptions in C++ are different as well, so any code that passes a new’ed command into the C++ API leaks memory. In my opinion, the C++ command-based robot examples make C++ look bad and should be cleaned up.

In my experience, modern C++ is a fine language for FRC if you have a mentor who is experienced with it, so the advice to stick with what your mentor knows still stands.

Coding in C++ is well-known to be something of an endeavor at the best of times; many of the language’s design choices (header files, for instance) were made 30 years ago when computers could barely fit the code for a single class into memory during compilation.

While that may have been the original reason, headers also provide a succinct summary of the class interface. Java relies on external tooling to provide that. The way headers bleed their contents into other scopes is bad though.

Unfortunately, there’s something of a pervasive “macho programmer” aesthetic that idolizes the pain and inconvenience of writing in C++ as if it were proof of one’s programming prowess; this is a dumb and counterproductive mindset, and should be avoided.

This is a mischaracterization of most C++ programmers. C++ is definitely an expert-friendly language, and programmers live with the language’s complexity because they want more performance and control. There’s generally a balance between performance and productivity, and C++ and Java sit on opposite ends. For what it’s worth, I teach my rookies C++ using Bjarne Stroustrup’s swan book because I want to teach them how the computer really works underneath. Having the correct mental model of the machine helps even when programming in a high level language. You can be productive, but still know where to look for performance when you need it. The essay http://www.evanmiller.org/you-cant-dig-upwards.html explains this better than I can.

There are use-cases in which C++ is the correct tool for the job; FRC is generally not one of them, especially if you are a new team with limited programming experience.

I agree that C++ isn’t a requirement for a successful robot, but saying it’s a bad tool for FRC is false. Every language has footguns. They are generally overcome with policy and idioms. A big issue the WPILib C++ examples have is they make things more complicated than they need to be (as I’ve said before, command-based robot example is a big offender here), so they are in effect setting up teams for failure.

Java isn’t the perfect language for FRC either. The roboRIO only has 256MB of RAM. We recently had to free up 40MB of memory from LVRT to make process forking in Java work again. By being more forgiving and using GC, it wastes resources and is something we regularly have to combat in the WPILib implementation.

I’d also like to make the point that C++ is still great as a library implementation language. We’ve had much fewer performance and language issues in WPILib with C++ than with Java.