Subsystem::GetName() Doesn't Do What I Expect

[grantf]

Here's some code and expected versus actual results. I'm confident that WPILib would benefit from an update.

The Test Code

MyRobot::RobotInit()
{
//
// The class called "MySubsystem" derives from Subsystem and calls the
// parent class constructor, with a Subsystem name of "MySusbsystem"
//
Subsystem* p_subsystem = new MySubsystem();

//
// This code prints the name of the newly-created subsystem to the
// DriverStationLCD.
//
DriverStationLCD* p_driver_station_lcd = DriverStationLCD::GetInstance();
p_driver_station_lcd->PrintfLine(DriverStationLCD::kUser_Line1, "%s", p_subsystem->GetName().c_str() );
p_driver_station_lcd->UpdateLCD();
}


The Expected Result
After I compile this code and download it to the cRIO, I expect the DriverStationLCD to have a single line of text showing "MySubsystem".

The Actual Result
Instead, I see "Subsystem". If I change the name of the passed-in subsystem name to anything else, I always see "Subsystem" as the returned string.

My Suspicion
Subsystem::GetName() is returning a hard-coded value and not the user-provided name.

Please provide an update to the WPILib that solves this problem :D

[mikets]

My Suspicion
Subsystem::GetName() is returning a hard-coded value and not the user-provided name.
It is returning a hard-coded value. Here is the source code of the function:
std::string Subsystem::GetName()
{
return "Subsystem";
}

[grantf]

It is returning a hard-coded value. Here is the source code of the function:
std::string Subsystem::GetName()
{
return "Subsystem";
}

Indeed, I imagine that the root cause of the issue is that the code from the Subsystem::GetType() method was copy-pasted into the GetName() method - you can see the implementations are the same.

Just in case someone is interested, we implemented a workaround where we simply introduce another intermediate sub-class of Subsystem that extends the GetName() method and returns a local copy of the name. When the WPILib is updated to correct this issue, we will remove our intermediate class.

[Joe Ross]

The fastest way to get this fixed would be to report a bug in the WPILib Tracker (http://firstforge.wpi.edu/sf/tracker/do/listTrackers/projects.wpilib/tracker) and provide a patch.

[grantf]

The fastest way to get this fixed would be to report a bug in the WPILib Tracker (http://firstforge.wpi.edu/sf/tracker/do/listTrackers/projects.wpilib/tracker) and provide a patch.

Thanks for that, but it seems I cannot create an account. That pages gives me a bunch of errors regarding password strength, such as "must have at least one number", "must be at least 6 characters long", etc. I have complied with each and every error message with a new password, and still I cannot get in.

I would gladly contribute a patch, but I simply cannot become a member of the project. Bummer...

[bob.wolff68]

The password strength requirements are VERY harsh. ALL of these are required in your password:
* Uppercase
* Lowercase
* Numeric
* Non-numeric-non-alphabetic (symbols)

bob

[grantf]

The password strength requirements are VERY harsh. ALL of these are required in your password:
* Uppercase
* Lowercase
* Numeric
* Non-numeric-non-alphabetic (symbols)

bob

They certainly are. After applying the Fort-Knox password generator, I'm in. Thanks for that :)