Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
8 years, 9 months ago.
Passing a BusOut object to a function within a class.
Hallo community, I seem to have become a bit stuck within the tangled web of object-oriented programming for the mBED. Here is the issue:
In my main program I make the following declaration:
Creating a BusOut for the LEDs in main.
BusOut LEDbus(LED1, LED2, LED3, LED4);
Next, I have a class called AdvMod that currently only includes some testing code:
A class that contains a public function that requires a BusOut object as an input.
class AdvMod {
public:
AdvMod();
void readMemristor(...single cell, BusOut LEDbus, ...);
void LiveTest(..., int w, int b, BusOut LEDbus, bias control, ...);
private:
//DigitalOut A0;
};
Finally, in the .cpp file containing the function definition I have something like this:
Fragment of .cpp file for the class above
void AdvMod::LiveTest(..., int w, int b, BusOut LEDbus, bias control, ...){
int a = 0; //General purpose counter variable.
int c = 0; //Counter for pulse trains.
int index = 1; //Keeps index of which type of pulses are being applied.
for(c = 0; c < M; c++) { //Sweep through stimulation trains.
if(index == 1) { //If processing 1st type of pulses.
for(a = 0; a < Pre+N-1; a++) { //For each pulse in the train except the last one.
cell.pulseIt(type, Vpos, pwpos, pSR); //Apply pulse as defined by input arguments.
wait(dtpos); //Leave inter-pulse interval of dtpos (in seconds).
if(a >= Pre) { //Only read after pulses from Pre onwards.
readMemristor(...cell, LEDbus, ...); //Perform read operation to obtain data point.
printf("%f %f\n\r", 1.0, Mnow); //Display type of data and value. - Upstroke (can be downstroke, so long as it is distinguishable) memristance (code 1).
}
}
Problem is that this code results in a compiler error at line 15 in the code just above:
Error: "mbed::BusOut::BusOut(const mbed::BusOut &)" (declared at /extras/mbed_b9ad9a133dc7/BusOut.h:95 is inaccessible in "mCAT5_v4/Libraries/AdvMod/AdvMod.cpp", Line: 156, Col: 78
Problem is that I cannot see why this should be the case. Why does the readMemristor function access the BusOut object without a problem on its own whilst it complains that it cannot access it when it is passed through LiveTest?
Many thanks.
As a quick guess without looking into this too much try passing a BusOut pointer rather than the object itself.
If nothing else it's good practice to do this for any non-trivial data structures for speed/memory reasons.
posted by Andy A 18 Aug 2015Indeed it passes the compile test! Thanks! However I still don't see why it should fail when being passed by value.
Also, on the subject of passing by value vs by reference, is it not the case that if you pass an input argument to a function by reference, then the function can modify that input? This would entail the danger of inadvertently modifying those complicated structures within the function unless good discipline is maintained. In this case, however, we are talking about pins, so I guess this makes the point above moot...
posted by Nano Group 18 Aug 2015What you describe is correct. This can also (and is often) intended. Sometimes to move data, but in this case it is also intended since it is actually weird to have 3 BusOut objects to control the same pins, which one actually controls it? (The last one to set them at a certain state obviously, but it is still better practise not to have multiple identical objects controlling the same thing).
If it is not intended, then good discipline helps, but depending on the situation you can also as safety define them as pointers to a constant variable for example.
posted by Erik - 18 Aug 2015Indeed. The whole object-oriented approach was an exercise in OOP and we learned that when you have a single physical object (the pins) it may not be wise to reference it from all these different classes... Also thanks for answering another question, namely who ultimately controls the state of those pins. I was expecting it to be the 'last one at the controls' but wasn't certain.
At the end of the day I think logically and intuitively it is better to pass these objects around as pointers. The variable defining which pins will become part of the BusOut refers to something real, of which there is only one per microcontroller. As such, passing a pointer to that BusOut makes more sense than passing the object itself I guess.
Thanks everyone!
posted by Nano Group 19 Aug 2015