Log in

View Full Version : Using a variable as a class object in Windriver/C++


Stonemotmot
03-12-2011, 14:36
Hello, I am currently working on streamlining our teams code and was wondering if it is possible to use a variable to reference a specific object.
For Example
Say I named a solenoid object 1 and had a int variable named b that stored 1 could i say
b.Set(true) and have the same result as 1.Set(True)
If it cannot be done this way is there another way to get the same result. The key to what I want is to have a numeric value that relates to a specific object.

Thanks for any help in advance. :)

connor.worley
03-12-2011, 16:15
Try a map.


#include <map>

...

map<int, Solenoid*> solenoids;
solenoids[1] = new Solenoid(1);

...

theprgramerdude
03-12-2011, 20:25
A map is the only way to "map" (hint hint nudge nudge) integer values to solenoid references.

WizenedEE
04-12-2011, 00:05
Why doesn't an array work?


Solenoid* solenoids[3];
solenoid[0] = new Solenoid(5);
//...

theprgramerdude
04-12-2011, 01:03
It does, at the penalty of having a fixed number of spots with fixed names to map to unless additional code is written.

To be clear, I was referring to the data type map, not necessarily the c++ implementation. I can count at least 8 ways in C++ to implement the map with varying degrees of effectiveness, map and hash_map (assuming that library is included in Windriver by default) being the most flexible with mapping names.

Point being, the map structure could accept any valid integer and associate the corresponding solenoid with it; with an array, you are forced to associate a solenoid with a specific value from 0 to size - 1.

Tom Bottiglieri
04-12-2011, 04:14
Use an array. The amount of solenoids you have is known, so the associative array (map) doesn't add any value.

jhersh
04-12-2011, 12:36
Say I named a solenoid object 1 and had a int variable named b that stored 1 could i say
b.Set(true) and have the same result as 1.Set(True)

Many people are answering your question, but no one has asked why you want to do this. Generally numbers are a poor way to refer to things. Especially if the numbers are arbitrary (don't have any meaning in the mechanism you are controlling).

The best generic way to do this is to simply name variables or pointers for each mechanism and use those to refer to the solenoids or anything else.

Such as:

Solenoid *leftGripper = new Solenoid(2);
Solenoid *impaler = new Solenoid(3);

impaler->Set(true);

or

class MyRobot : public IterativeRobot
{
...
Solenoid leftGripper;
Solenoid impaler;
...
MyRobot() :
leftGripper(2),
impaler(3)
{
}
...
void AutonomousInit(void)
{
impaler.Set(true);
}
...
};


Do you have some compelling reason not to refer to each object directly?

WizenedEE
05-12-2011, 20:46
Do you have some compelling reason not to refer to each object directly?

Last year, we wanted to program the robot to set all the solenoids on to power the line tracking sensors. We just looped through each of the ports (it was in labview though).

theprgramerdude
06-12-2011, 01:37
Well, if you had an array of solenoid pointers for this, it'd just be something simple as having:

for(int solenoidPort = 0; 0 < 8; solenoidPort++){
solenoids[solenoidPort]->set(true);
}

Stonemotmot
07-12-2011, 14:32
Thanks for all the imput. I was wondering if any of you could elaborate on how to implement a solenoid array.

connor.worley
07-12-2011, 14:50
Thanks for all the imput. I was wondering if any of you could elaborate on how to implement a solenoid array.

See WizenedEE's first reply. I think we could provide more useful feedback if you could post your team's code.

Joe Ross
07-12-2011, 18:16
Last year, we wanted to program the robot to set all the solenoids on to power the line tracking sensors. We just looped through each of the ports (it was in labview though).

I'm don't really know C++, so I'm not sure if it is accessible, but SolenoidBase has a set which takes a value and mask and writes the whole module at once. For something simple like your use case, I would do something like that (value 0xFF, mask 0xFF).

However, trying to do something like that to for anything less trivial would greatly trade readability and maintainability for compactness, which for FIRST is not something I would try to do.