Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Passing Variables and Classes

Status
Not open for further replies.

spootnik

Technical User
Jul 20, 2005
4
CA
Anyone know how to tackle this...
I've got file1.h, file1.cpp, file 2.h, file2.cpp. I want to be ablte to access a variable in file1.cpp from file2.cpp. The Variables are in classes. I've tried creating file3.h&cpp that would carry a class accessable from files 1&2, but when I do this, both files create their own separate instances of the class/variable.
any ideas what to do ?
 
Could you provide a little more detail about the basic structure of the classes?

Are forward declarations not cutting it?
 
Well - this is more of a hypothetical setup. I'm using MFC and have a double variable that keeps changing in one dialog window, and I want to be able to acces that variable from from the other window.
 
Are they modal dialogs? Can you just have one dialog return it to the other? Or are they supposed to be open at the same time? If the latter then this is a much more complicated issue because it inherently involves multithreading.
 
Either add Set & Get functions or make the other class a friend.
 
Note that without proper locking the above solution could very well lead to a race condition...even if it appears to work most of the time. (As could other similar solutions such as employing a global variable, or pointers to a common object.)

Most likely you can take you pick from code-level solutions like the above as long as you lock appropriately, or else try using something like a named pipe.
 
The dialogs are open at the same time.
How do employ a global variable? I've tried using a common Class but that has not proven to work yet.
Also the variable keeps getting updated once every 20ms.
 
If they are open at the same time then you will definitely have to look into multithreading and locking. Any solution that doesn't address the fact that you're trying to do something that is multithreaded is likely to be fragile.

Not sure what you mean by a common class not working?
Code:
struct Common {
    Common(double init) : _commonMember(init) {}
    double _commonMember;
};

class A {
public:
    A(Common *sharedData) : _sharedData(sharedData) {}
    void incrementCommonMember() {
        ++_sharedData->_commonMember;
	}
    double getCommonMember() const { 
        return _sharedData->_commonMember; 
    }
private:
    Common *_sharedData;
};

class B {
public:
    B(Common *sharedData) : _sharedData(sharedData) {}
    void incrementCommonMember() {
        ++_sharedData->_commonMember;
	}
    double getCommonMember() const { 
        return _sharedData->_commonMember; 
    }
private:
    Common *_sharedData;
};

#include <iostream>

int main() {
    Common *c = new Common(5);
    A a(c);
    B b(c);

    a.incrementCommonMember();
	std::cout << b.getCommonMember() << std::endl;

    return 0;
}

HOWEVER, this is not a proper solution if object a and object b are in separate threads...which I believe they ARE if they are in separate dialogs.

Unfortunately, I do not remember how to do proper threading in the context of an MFC app...but hopefully somebody here can modify the above to clarify...

Also note...this is just a demonstration of a common class...there are plenty of other ways to do it. I seem to remember MFC having concepts of message passing between dialogs...but I also do not remember those details.

Been awhile since I used MFC...
 
Ummm...there should obviously be a
Code:
delete c;
in there before exiting main. I mean...it isn't strictly necessary in this case as it is a toy application and exits immeidately...but still...

*hangs head in shame*
 
WEll - I ended up trying to fit the two functions into one cpp file. I thopught there might be an easy way of switching data, butI guess not.


Thanks for you reply, I appreciate it.
 
o_O

1) It makes no sense that it would work in one CPP file but not in two.

2) That does not get around the potential race-condition issue.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top