Jump to content
  • Advertisement
Sign in to follow this  
VanillaSnake21

only one function as friend

This topic is 3584 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Advertisement
AFAIK it isn't possible to restrict the export to a single function by using the friend keyword. The only way I see is to export an intermediate object especially for accessing the funtion of interest. However, I doubt that it is worth the effort (but perhaps it is; the OP hasn't told about the reasoning of wanting to do so).

Share this post


Link to post
Share on other sites
This could do:

int function1(void);

class a{
public:
class{
private:
friend int function1(void);
int operator(int c);
}function2;
private:
int function3(void);
};

int function1(void){
static a instance;
return instance.function2(77);
}



Share this post


Link to post
Share on other sites
@ville-v
That look like a good solution but it's way too tangled. Anyways it looks like theres no clean way of doing this. I'll just declare the whole class as a friend and save myself the trouble of sifting through spaghetti code later on. Thanks for the help )

Share this post


Link to post
Share on other sites
Quote:
Original post by VanillaSnake21
Anyways it looks like theres no clean way of doing this. I'll just declare the whole class as a friend and save myself the trouble of sifting through spaghetti code later on. Thanks for the help )
Why does this class need to access a function that isn't part of the other class' public interface? In general, that sounds like a problem with your design.

Share this post


Link to post
Share on other sites
Every once and a while I have something like this happen. I've had a couple methods that only one other class should call.
I usually just make the entire class a friend. If a class knows enough about another class to be friends with one of its methods, then it knows enough to be a friend with the entire class.

Share this post


Link to post
Share on other sites
Quote:
Original post by swiftcoder
Why does this class need to access a function that isn't part of the other class' public interface? In general, that sounds like a problem with your design.


One class is called Engine the other class is called Time.
Time class can be owned by any of the Engine subsystems and what it does is it keeps the time since the engine was started (so I can sync all the subsystems). Time class has a functino CallOnCreation(), that should be called in the Engines's constructor. But I don't want that function to be called by any other subsystem (since it will offset the time) So I made the function private and made the Engine class a friend of time class. It's not really a big deal, I'm just trying to be overprotective. BTW If anyone has any suggestions on how I can improve this design let me know.

To be more precise here's a simplified example,


class Time
{
public:
long GetTimeSinceCreation() { return timeGetTime() - m_CreationTime; }
private:
void CallOnCreation() { m_CreationTime = timeGetTime(); }

static long m_CreationTime;

friend class Engine;
};

Engine
{
public:
Engine() { m_EngineTime.CallOnCreation(); }

private:
Time m_EngineTime;
Subsystem WindowManager;
Subsystem Input;
// more subsystems
};

class WindowManager
{
private:
Time m_EngineTime;
};

class Input
{
private:
Time m_EngineTime;
};


Share this post


Link to post
Share on other sites
What you have here is basically a monostate, and monostates are basically globals hiding under another name. That is not to say they are always a bad thing, but they should be treated with care.

In your particular case, why are all the subsystems running on global time? What happens if you need to pause the game at a menu, but animate menu transitions? Or if you want to perform slow-motion/bullet-time effects? Things like these would be much easier if subsystems could be allocated different timers...

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!