auto-generated dynamic_reconfigure headers fail to compile depending on field names

edit

In Fuerte, if a .cfg file used with dynamic_reconfigure contains a field named "i":

...
gen.add( "i", double_t, SensorLevels.RECONFIGURE_RUNNING, "i gain", 1, 0, 200 )
...

the header will fail to compile with:

no match for ‘operator=’ in ‘i = boost::any_cast [with ValueType = double]((* & val))’

class DEFAULT
{
  public:
    DEFAULT()
    {
      state = true;
      name = "Default";
    }

    void setParams(PIDConfig &config, const std::vector<abstractparamdescriptionconstptr> params)
    {
      for (std::vector<abstractparamdescriptionconstptr>::const_iterator i = params.begin(); i != params.end(); i++)
      {
        boost::any val;
        (*i)->getValue(config, val);

        if("p"==(*i)->name){p = boost::any_cast<double>(val);}
        if("i"==(*i)->name){i = boost::any_cast<double>(val);}
      }
    }

    double p;
double i;

    bool state;
    std::string name;


}groups;

Here, it's clear that setParams is using an iterator called "i", yet a member variable "i" of type "double" also exists within the same class.

While the obvious solution is to change the config field name from "i" to something like "i_gain" in this particular case, this issue breaks diamondback-compatible code and limits the names which may be used for dynamic_reconfigure fields.

To clarify, I'm using Ubuntu 12.04 64-bit/gcc 4.6.3 on a VM with a clean ROS install and the latest updates installed via dist-upgrade.

Additional Issues

It appears there are at least two more cases in which dynamic reconfigure param names can cause compilation issues.

When the class "DEFAULT" is added by the cfg generator:

class DEFAULT
{
  public:
    DEFAULT()
    {
      state = true;
      name = "Default";
    }

    ...

    // variables from user-specified fields

    ...

    // internal variables
    bool state;
    std::string name;

}groups;

the variables "state" and "name" appear to always be created, and will therefore conflict with any user-created variables with the same name.

To avoid these issues, it's probably a good idea to manually append "_param" or something similar to the name of all dynamic_reconfigure fields in .cfg files; however, as with the previous part of this issue, it would be great if this stuff would just work out-of-the-box.