main() als friend

ChrisM

Hi,

kann es sein, dass gerade das nicht geht? Dass sie nicht überladen werden kann und man nicht ihre Adresse speichern kann, weiß ich, aber dass wäre mir neu.

ChrisM

Knuddlbaer

Welchen Sinn würde das denn machen ?

Weißt du überhaupt was 'friend' für eine Aufgabe hat?

und was ist mit virtual ?

ChrisM

Hi,

natürlich, ich habe eine bestimmte Klasse, die nur in main() instantiiert werden soll und sonst nirgends. Deswegen ist der Konstruktor private und main() ist bzw. sollte friend sein.

ChrisM

ChrisM

Hi,

.not schrieb:

und was ist mit virtual ?

da du main() eh nicht aufrufen kannst, würde das sicherlich wenig Sinn machen, zumal main() eh nie in einer Klasse ist

ChrisM

ChrisM

Hi,

hat sich geklärt, die Klasse war in einem Namespace und ich hab' bei der Frienddeklaration vergessen, explizit den globalen Namespace anzugeben.

ChrisM

Knuddlbaer

Mich Interessiert dennoch der Einsatz der friend deklaration einer bestimmten Methode. Warum darf die Klasse nur in Main instanziiert werden ?

(Mensch mensch, auf solche Ideen muss man erst mal kommen ;o)

ChrisM

Hi,

ich zeig einfach mal den Code:

#ifndef SERVERMAIN_INCLUDED
#define SERVERMAIN_INCLUDED

#include <list>

int main(void);

namespace GalacticBlast
{

class AuthMgr;
class CmdDistributor;
class Console;
class Database;
class FileList;
class Log;
class MsgDistributor;
class Timer;
class UDPServer;

class Application
{
public:
	AuthMgr& getAuthMgr(void) const { return *m_pAuthMgr; }
	CmdDistributor& getCmdDistributor(void) const { return *m_pCmdDistributor; }
	Console& getConsole(void) const { return *m_pConsole; }
	Database& getDatabase(void) const { return *m_pDatabase; }
	FileList& getFilelist(void) const { return *m_pFileList; }
    Log& getLog(void) const { return *m_pLog; }
	MsgDistributor& getMsgDistributor(void) const { return *m_pMsgDistributor; }
	Timer& getTimer(void) const { return *m_pTimer; }
	UDPServer& getUDPServer(void) const { return *m_pUDPServer; }

private:
	friend int ::main(void);

	Application();
	~Application(void);

	void init(void);

	bool run(void);

	AuthMgr* m_pAuthMgr;
	CmdDistributor* m_pCmdDistributor;
	Console* m_pConsole;
	Database* m_pDatabase;
	FileList* m_pFileList;
	Log* m_pLog;
	MsgDistributor* m_pMsgDistributor;
	Timer* m_pTimer;
	UDPServer* m_pUDPServer;
};

void handleException(const Exception& exc);

}

#endif

Die Klasse ist halt sozusagen die Applikationsklasse, die normalerweise nur einmal instantiiert wird (später könnte es aber auch Fälle geben, wo in einem Prozess z.B. mehrere Serveranwendungen laufen sollen und dann wird die entsprechend mehrfach instantiiert).

Die Hauptschleife ist dann entsprechend kurz:

int main(void)
{
#ifdef _DEBUG
	_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);
#endif

	try
	{
		// Create application
		g_pApplication = new Application;
		g_pApplication->init();

		// Run
		while (g_pApplication->run());

		// Destroy application object
		delete g_pApplication;
	}
	catch (const Exception &e)
	{
		handleException(e);
	}
	catch (...)
	{
		handleException(Exception("Unknown", "?", 0));
	}

	std::cout << "Press any key to close this window!" << std::endl;
	while (!kbhit());

	return 0;
}

ChrisM

Knuddlbaer

Hätte ja fast gesagt nimm ein Singleton, aber so bist Du abhängig von Main und kannst auch nur da gesehen werden....

Im Moment weiß ich mit der Technik nichts anzufangen, aber mal notieren. Heut lohnt sich Forum lesen richtig thx

ChrisM

Hi,

vor einigen Tagen hab' ich zu dem Thema einen Thread offen gehabt und keiner hat sich pro Singleton geäußert.

Naja, so wie es jetzt ist, geht es und ist auch recht solide, soweit ich das beurteilen kann. Dank meiner tollen Game State-Architektur muss ich da jetzt auch nie wieder was ändern, sondern nur noch neue Game States von GameState ableiten und doTick() implementieren.

ChrisM

Knuddlbaer

ChrisM schrieb:

vor einigen Tagen hab' ich zu dem Thema einen Thread offen gehabt und keiner hat sich pro Singleton geäußert.

Na da hab ich was Übersehen. Wo is der Thread ?

ChrisM

Hi,

hier!

ChrisM