First off, thank you both for your input
I should have mentioned I’d like to be able to access m_pD3D just as “m_pD3D” as if it were a normal data member of classB. Truthfully, this is mostly just for cosmetic reasons, I guess... mainly so I don’t get confused! Heh.
Hum, Phrased like that a #define macro comes to mind to simplify a singleton::get() methodology. Hum, that might be the best approach.
AP:
Very true indeed, thank you.
ToohrVyk:
quote:Original post by ToohrVyk
First, the friend operator only works if you have a pointer to such a class. It has been done to access private and protected members just like you would access public members of that class. In your case, it''s not of a great use since you don''t seem to have instances of these classes available, and you''re not accessing private members anyway (I think).
Ok, from what you have mentioned the documentation made more sense this time
Lets see if I understand this right:
class classB{ classB(); virtual ~classB(); DoSomething() { m_pD3D->GetAdapterCount(); // <-- This is what I want to // acomplish; using m_pD3D as if it // were property of classB... }}class classA{ friend class classB; // ADDED: We like classB, share private // and protected members. classA() { } virtual ~classA();private: LPDIRECT3D8 m_pD3D; // The main D3D object}
This should give classB access to the private and protected members of classA, so classB::m_pD3D is valid and would be (in effect) a private data member. (for classB only of course, as friendship is not inherited.)
I thought I tried this once and discarded the idea for some reason... Heh, probably that `friendship is not inherited` part... I believe I was trying to make the abstract base class for the appstate class a friend of the application class. (i.e. classC derives from classB but does not have access to m_pD3D, et al. which was a problem.)
Ok, great! An an if that does not work in the actual mess of code for some reason I’ll go with singleton’s and `Get` member functions
Thank you both!
quote:Original post by ToohrVyk
Second, many of thse classes seem to have only a single instance in the whole game. That is, there will be only one StateMenu, only one Activestate, etc. This can be achieved by using static variables.
Aye, indeed. Many such classes (all the states, logger, etc.) are good singleton candidates.
Thank you both for your time, thoughts and replies!
Feral