3. Wie viel in main() und wie viel in Application...

Wie viel in main() und wie viel in Application...

  • M

    Hi,

    Application ist die Hauptklasse, das übernehme ich gerade von Leuten, die sich besser auskennen.

    #include <iostream>
using namespace std;

int main(int argv, char* argc[])
{
Application app;
app.Main(argv,argc);
return 0;
}

    Also der Code ist natürlich nicht gut, aber mir geht es jetzt darum, ob ich argv in main() oder Application::Main(...) untersuchen soll?
    Die Parameteranzahl ist hier nämlich festgelegt, soll ich das in Main oder main machen lassen?

    MfG Eisflamme

    0
  • ?

    in Main, nebebei würd ich sowas eher machen:

    int main (int argc, char* argv[])
{
    return (CMain::getInstance()->init (argc, argv));
}

    sieht übersichtlicher aus.

    0
  • M

    Hi,

    ok, deinen Code werde ich allerdings nicht übernehmen, da ich Exceptions noch einbaue.
    Aber das konntest du ja nicht wissen, danke...

    MfG Eisflamme

    0
  • ?

    /me benutzt ebenfalls exceptions:
    Code aus anderem Programm von mir

    #ifdef _WIN32
int CMain::init (HINSTANCE__ *instance, char *command, int show)
#else
int CMain::init (int argc, char* argv[])
{ 
	this->m_app.setName ("Vega-Engine: Testversion für Texturen");

#ifdef _WIN32
	if (!(this->m_app.createWindow (CMain::WindowProc, instance, show, 640, 480, NULL)))
#else
	if (!(this->m_app.createWindow (640,480);
#endif
	{
		return 1;
	}

	return gameLoop();
}

int CMain::gameLoop (void)
{
	MSG             msg;

	try
	{
		VIDEO.init (this->m_app.getHwnd(), 640, 480, 16, x);

		while (true)
		{
#ifdef _WIN32
			if (::PeekMessage (&msg, NULL, 0, 0, PM_REMOVE))
			{
				if (msg.message == WM_QUIT)
				{
					break;
				}

				::TranslateMessage (&msg);
				::DispatchMessage (&msg);
			}
#else
			if (::RunMessage (&msg))
			{
				if (msg.message == WM_QUIT)
				{
					break;
				}
			}
#endif

			// Process game here, if active
			if (this->m_app.isActive ())
			{ 
				// Do something
			}
		} 
	}
	catch (CException &ex)
	{
#ifdef _WIN32
		::MessageBoxA (NULL, ex.getText().c_str(), "Error!", MB_ICONEXCLAMATION | MB_OK);
#else
		std::cout << "Error!  " << ex.getText().c_str() << std::endl;
#endif
	}
	catch (...)
	{
#ifdef _WIN32
		::MessageBoxA (NULL, "Unknown Exception", "Error!", MB_ICONEXCLAMATION | MB_OK);
#else
		std::cout << "Error!  " <<  "Unknown Exception" << std::endl;
#endif
	}

#ifdef _WIN32
	return ((int)msg.wParam);
#else
	return 0;
#endif
}
    0
  • S

    @nix da:

    und das findest du lesbar?

    zuviele this, excessives #if innerhalb von Funktionen, C vor dem Klassennamen,...

    naja, jedem das seine...

    0
  • ?

    ich habe relativ wenig probleme das zu lesen, wie denn auch wenn ich so seit Jahren code um meine Programme portabel zu bekommen für andere Plattformen 😉

    0
  • S

    @nix da du verwendest C++ und löst etwas in C-Style statt Polymorphie zu verwenden,
    wieso erstellst du nicht 2Klassen die von ner Basisklasse, oder nen Interface
    abgeleitet wurden und sämtliche Ausgaben übernehmen, je nachdem ob es ne Konsolenanwendung
    oder ne win32 Anwendung ist.
    So bräuchtest du nur 1mal den Präprozessor für die Erstellung des Objektes

    Basisklasse *p;
#ifdef _WIN32
p = new Win32;
#else
p = new Konsole;
#endif
    0
  • ?

    @SirLant:
    das hab ich mir auch durch den Kopf gehen lassen wurde auch umgesetzt, doch dies wurde nur als beispiel benutzt 🙂 Der Code ist über 5 Jahre alt und ich fand ihn hier relativ gut am Platze als Beispiel wie mans nicht machen sollte 😉 Heute benutze ich natürlich auch Interfaces 🙂

    0
  • S

    SirLant schrieb:

    @nix da du verwendest C++ und löst etwas in C-Style statt Polymorphie zu verwenden,

    Naja, wobei Polymorphie da garnicht nötig ist:

    #ifdef WIN32
typedef Win32::Application Application:
#elif defined(LINUX)
typedef Linux::Application Application;
.
.
.
#endif

    Da hat man dann 0 overhead 🙂

    Ich finde das mit separaten namespaces, usw. sehr fein gelöst - denn dann kann ich proxy include files machen, die dann entweder win32/foo.hpp oder linux/foo.hpp inkludieren. So kann ich die unterliegende Architektur besser nutzen als bei nix das Ansatz - denn ich kann wirklich die Implementierung 100% verschieden machen und das hinzufügen von neuen Plattformen ist problemlos möglich.

    SirLants Polymorphie Lösung ist natürlich auch OK - nur würde ich halt hier keine virtuellen Methoden in Kauf nehmen (denn das heisst: keine templates) - ich kenne ja zur Compiletime die passende Plattform, ich brauche daher keine Laufzeitpolymorphie.

    0
  • S

    Shade Of Mine schrieb:

    SirLant schrieb:

    @nix da du verwendest C++ und löst etwas in C-Style statt Polymorphie zu verwenden,

    Naja, wobei Polymorphie da garnicht nötig ist:

    #ifdef WIN32
typedef Win32::Application Application:
#elif defined(LINUX)
typedef Linux::Application Application;
.
.
.
#endif

    Da hat man dann 0 overhead 🙂

    Ich finde das mit separaten namespaces, usw. sehr fein gelöst - denn dann kann ich proxy include files machen, die dann entweder win32/foo.hpp oder linux/foo.hpp inkludieren. So kann ich die unterliegende Architektur besser nutzen als bei nix das Ansatz - denn ich kann wirklich die Implementierung 100% verschieden machen und das hinzufügen von neuen Plattformen ist problemlos möglich.

    SirLants Polymorphie Lösung ist natürlich auch OK - nur würde ich halt hier keine virtuellen Methoden in Kauf nehmen (denn das heisst: keine templates) - ich kenne ja zur Compiletime die passende Plattform, ich brauche daher keine Laufzeitpolymorphie.

    Stimmt so ist das natürlich sogar noch besser, mir fiel selbst nur keine bessere
    Lösung ein 🤡

    0
Anmelden zum Antworten