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

[mikets]

Originally Posted by grantf

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]

Originally Posted by mikets

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 and provide a patch.

[grantf]

Originally Posted by Joe Ross

The fastest way to get this fixed would be to report a bug in the 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]

Originally Posted by 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

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