View Single Post
  #1   Spotlight this post!  
Unread 15-11-2016, 10:43
egaudet egaudet is offline
Registered User
FRC #4917
 
Join Date: Nov 2016
Location: Ontario, Canada
Posts: 2
egaudet is on a distinguished road
Should we use std::unique_ptr?

When creating a new project and using "Robot C++ Project" (command-based), the example subsystem is declared as a std::unique_ptr rather than an old-style standard pointer:

Code:
static std::unique_ptr<ExampleSubsystem> examplesubsystem;
vs
Code:
ExampleSubsystem *examplesubsystem;
Given that the example code is using this pointer type, I figured it was probably a good idea for us to start using it too. Might as well take advantage of the memory-management features that unique_ptr provides.

That was great until we tried to use the subsystem as a Requires() parameter. Requires() only accepts a Subsystem *. You can get around that with unique_ptr's get() method but the result is a bit messy:

Code:
Requires((Subsystem *)(examplesubsystem.get()));
If you use unique_ptr's across the board, you'll also run into the same issue with things like joystick buttons and anywhere else where you have to pass in a pointer to an object.

My questions are:
- Should we be using std::unique_ptr like the example code is leading us to do?
- Is FRC/WPILib moving towards using std::unique_ptr's?
- Will they overload existing methods to accept both types of pointers (old and new)?

Thanks in advance for any info you can provide.
Reply With Quote