I'm not 100% sure whether we want these, but they are a quick
find and replace to do.
Basically, there are two primary things that we have done
this summer that break existing user code:
-Changing GetInstance() calls to return references instead
of pointers. This forces users to change from doing something
like LiveWindow::GetInstance()->AddSensor() to LiveWindow::GetInstance().AddSensor().
-Making PIDGet() and related calls const, forcing users to change
the function signatures wherever they override them.
The GetInstance() calls don't really matter to me either way,
especially since there are no real ownership issues going on there,
unlike the rest of the smart pointer-related changes.
For the const stuff, it is certainly more correct to mandate that
user PIDGet() functions be const and the such, but at the same time,
I'm not sure that there is any strong need for it, and the errors
generated are not the most helpful. While this wouldn't necessarily
be an issue for more experienced teams or completely new teams (who
don't have any old code to be reusing), it may cause issues for more
average teams who aren't familiar with the intricacies of C++ anything.
Change-Id: I6e7007982069292ea70e6d0fc8ca40203340df1b
Also added some references/smart pointers to a couple places
that seemed convenient to the user.
I haven't updated the constructors for RobotDrive() related
examples, pending the results of gerrit change https://usfirst.collab.net/gerrit/#/c/960/
A few things that we are noticing:
--It might be nice if ReturnPIDInput() didn't have to be const;
when people try to override it, they have to remember to put
the const in and if they don't, then the compiler error isn't the
most obvious (especially since this is a change). This would also
apply to PIDGet() in the PIDSource interface.
--SendableChooser still takes raw pointers. This could lead to an
issue I had to debug briefly where you accidentally call
GetSelected() on autoChooser and put the resulting raw pointer
into a unique_ptr, which destroys the pointer when it goes out of
scope. Specifically, I was testing the PacGoat example and
I ended up with a situation where if auto mode was run once, it
was fine, but if it was run twice, the selected command would
have been destroyed by the unique_ptr. I believe that this
just requires updating SendableChosser to take shared_ptr.
--When the samples are compiled with -pedantic, it points out that
START_ROBOT_CLASS macro expansion results in a redundant semicolon.
Change-Id: Ib4c025a61263d0d2780d4253faa31713e15333a5
