ubuntuusers.de

Es bringt den Vorteil, dass man in einer Sprache die OOP von Haus aus unterstützt, eben diese Unterstützung benutzen kann, anstatt diese Unterstützung per Hand simulieren zu müssen. Man braucht sich zum Beispiel nicht zu merken, in welcher "Unterklasse" genau eine "Methode" definiert wurde, weil man in C++ alle Methoden von Unterklassen auf dem Objekt aufrufen kann und nicht den Umweg über die (Unter)Klasse gehen muss.

Der einzige "Umweg" ist, dass ich die Strukturen casten muss.
Das geht aber mit den Makros von GTK+ so komfortabel, dass ich mir wirklich überlegen würde GTK+ zu benutzen.
Aber wie gesagt: Wem beim Benutzen von Klassen einer abgeht, der soll gtkmm nehmen (mal überspitzt ausgedrückt 😉 ).
Ich kann Polymorphie und Vererbung zwar schon was abringen, aber ich denke das is ne Glaubenseinstellung.
Wer auf Performance steht, der nimmt C (bzw. gleich ASM 😉 ).
Und alle die auf Kapselung (Funktionalität vor dem Benutzer verbergen um damit die Benutzung zu vereinfachen) stehen, nehmen eben C++.
Jedem das Seine. ☺

Gruß TheImaginator

Du kannst natürlich gerne GUI-Code in ASM schreiben wenn Dir bei der Geschwindigkeit, die Du damit erreichst einer abgeht. Mal überspitzt ausgedrückt. Dass das totaler Schwachsinn ist, weil der Mensch der die GUI bedient sowieso um Grössenordnungen langsamer ist, als der ach so langsame GUI-Code in C++, der sich wahrscheinlich besser schreiben, verstehen und warten lässt als Assembler (oder eben auch C) ist ja nicht so wichtig.

Übrigens müsstest Du diesen Beweis, dass es wirklich merklich langsamer ist, erst einmal erbringen. Kapselung macht Code nicht automatisch langsam.

Übrigens müsstest Du diesen Beweis, dass es wirklich merklich langsamer ist, erst einmal erbringen. Kapselung macht Code nicht automatisch langsam.

// Ungekapselt
#include <cstdio>
#include <ctime>

using namespace std;
unsigned int GetVar();

unsigned int i = 0;

int main()
{

	while(GetVar() < 400000000)
	{}

	printf("%d\n", clock());
	return 0;
}

unsigned int GetVar()
{
	i++;
	return i;
} 

// Gekapselt
#include <cstdio>
#include <ctime>

using namespace std;

class Test
{
	public:
	Test(unsigned int x);
	unsigned int GetVar();

	private:
	unsigned int i;
};

Test t(0);

int main()
{
	while(t.GetVar() < 400000000)
	{}

	printf("%d\n", clock());
	return 0;
}


Test::Test(unsigned int x):
i(x)
{}

unsigned int Test::GetVar()
{
	i++;
	return i;
} 

Ergebnis des ungekapselten Codes auf meinem 1.4 GHz AMD: ~2600
Ergebnis des gekapselten Codes auf meinem 1.4 GHz AMD: ~3100
Macht ein Unterschied von: 500
Damit wird der Code um etwa: 19% verlangsamt.

OOH ... OOOOHHH ... ICH KOMME!!! 😉

Gruß TheImaginator

PS: Wenn du jetzt noch überladene Operatoren und andere objektorientierte Spielereinen benutzt liegt der Wert bei ungefähr 7300.
Das liegt unter anderem an der Indizierung der Klasse.
Bei einer V-Tabelle (virutelle Methoden → Polymorphie) wird das ganze noch extremer, da bei jedem "virtuellen" Funktionsaufruf diese durchsucht wird.

TheImaginator hat geschrieben:

[...] Ich kann Polymorphie und Vererbung zwar schon was abringen, aber ich denke das is ne Glaubenseinstellung [...]

Wohl kaum.

TheImaginator hat geschrieben:

Wer auf Performance steht, der nimmt C (bzw. gleich ASM 😉 ).
Und alle die auf Kapselung (Funktionalität vor dem Benutzer verbergen um damit die Benutzung zu vereinfachen) stehen, nehmen eben C++.
Jedem das Seine. ☺

Performance in GUI-Anwendungen? Klar... 🙄

Performance in GUI-Anwendungen? Klar...

Ich denke da an nen schnellen Bildbetrachter (also nicht GIMP 😉 ).
Es gibt ne Menge GUI-Anwendungen, die Performance vertragen könnten.

Gruß TheImaginator

TheImaginator hat geschrieben:

Ergebnis des ungekapselten Codes auf meinem 1.4 GHz AMD: ~2600
Ergebnis des gekapselten Codes auf meinem 1.4 GHz AMD: ~3100
Macht ein Unterschied von: 500

500 was? Nuessen?

Dein Test ist ziemlich Praxis untauglich.
Ein Test in dem du 400 Millionen mal einfach nur eine Methode aufrufst im Gegensatz zu einer Funktion die lediglich den Rückgabewert liefert hat so gut wie keine Aussage.

Üblicherweise ist es so das du in Funktionen etwas mehr machst, Rechenintensive Sachen etc.
Genau solche Sachen werden hauptsächlich Rechenzeit in Anspruch nehmen. Du wirst in keinem Programm so viele Werte abrufen müssen.

Zwar mag etwas overhead entstehen. Aber wenn dies in der Praxis nur 10 Aufrufe sind, wirst du nicht viel davon Mercken ob der Aufruf jetzt 10ms oder 12ms gebraucht hat, den das was in der Methode Berechnet wird, braucht sehr viel länger. So das die reine Aufrufzeit wieder richtung 0 tendiert.

Auf Kapselung oder das OOP langsamer ist daran sollte man niht all zu viel verdanken verwenden. Viel wichtiger sind andere Dinge. Nämlich das sich leichter in Teams entwickeln lässt. Man keinen Redunten Code besitzt. Man veränderungen oder erweiterungen leichter realisieren kann. Soetwas istwichtiger als die Reine ausführzeit. Wäre die Reine Ausführzeit immer noch das wichtigste, würden wir Heute immer noch in Assembler Programmieren. Und Sachen wie Java, Perl, Python, Ruby, ... würden wohl nie benutzt werden.

TheImaginator hat geschrieben:

Performance in GUI-Anwendungen? Klar...

Ich denke da an nen schnellen Bildbetrachter/-bearbeiter (also nicht GIMP 😉 ).
Es gibt ne Menge GUI-Anwendungen, die Performance vertragen könnten.

Gruß TheImaginator

Ist es die GUI, die die Performance schluckt? Anders gefragt: Womit verbringt eine GUI-Anwendung die meiste Zeit?

@Sid Burn:
Gut gut, du hast mich überzeugt.
Naja, mich kitzelt eben Geschwindigkeitsoptimierung und Ähnliches.
Ich versuche meinen Code zwar dabei trotzdem so lesbar wie möglich zu halten, hatte aber noch nie das Vergnügen in einem Team zu arbeiten. Deswegen denke ich über solche Aspekte auch selten nach.

Und jetzt mal zu Appollon:

500 was? Nuessen?

Dir ist anscheinend nicht klar was clock() tut ...

Ist es die GUI, die die Performance schluckt? Anders gefragt: Womit verbringt eine GUI-Anwendung die meiste Zeit?

Die meiste Zeit wartet eine GUI auf die Eingabe des Benutzers.
Wenn du aber nur ein bisschen nachdenken würdest, wäre dir klar, dass die Zeit, die beim "Warten" verstreicht, bei OOP-Libraries exakt gleich ist wie bei "normalen" Libraries.
Folglich geht es um die Verarbeitung, die nach einer Eingabe erfolgt (erst dann wird dem Programm Prozessorzeit zugeteilt; hier kann also Optimierung erfolgen).

TheImaginator hat geschrieben:

Und jetzt mal zu Appollon:

500 was? Nuessen?

Dir ist anscheinend nicht klar was clock() tut ...

Ist es die GUI, die die Performance schluckt? Anders gefragt: Womit verbringt eine GUI-Anwendung die meiste Zeit?

Die meiste Zeit wartet eine GUI auf die Eingabe des Benutzers.
Wenn du aber nur ein bisschen nachdenken würdest, wäre dir klar, dass die Zeit, die beim "Warten" verstreicht, bei OOP-Libraries exakt gleich ist wie bei "normalen" Libraries.
Folglich geht es um die Verarbeitung, die nach einer Eingabe erfolgt (erst dann wird dem Programm Prozessorzeit zugeteilt; hier kann also Optimierung erfolgen).

Guter Mann! Warum also die GUI in C schreiben?

BTW: Wieso schreibt jeder meinen Nick falsch?

Und mal ganz nebenbei: inwiefern hat clock was mit der Antwortzeit zu tun?

Wie gesagt.
Mich reizt es ein Programm so performant wie möglich zu schreiben..

Und mal ganz nebenbei: inwiefern hat clock was mit der Ausfuehrungszeit zu tun?

The clock() function returns the processor time since the program started, or -1 if that information is unavailable. To convert the return value to seconds, divide it by CLOCKS_PER_SEC. (Note: if your compiler is POSIX compliant, then CLOCKS_PER_SEC is always defined as 1000000.)
Ein Zitat von: www.cppreference.com

BTW: Wieso schreibt jeder meinen Nick falsch?

Sry, meinte natürlich "Apollon"

TheImaginator hat geschrieben:

BTW: Wieso schreibt jeder meinen Nick falsch?

Sry, meinte natürlich "Apollon"

Ist Ok. 😉

Du bist nicht auf die Kernfrage eingegangen. Die lautet: Warum GUIs in C schreiben, wenn die Antwortzeit von C-GUIs "exakt gleich" mit den C++-GUIs ist?
Und: wer garantiert dir, dass die Ticks/OP auf allen Platformen gleich sind?

TheImaginator hat geschrieben:

Übrigens müsstest Du diesen Beweis, dass es wirklich merklich langsamer ist, erst einmal erbringen. Kapselung macht Code nicht automatisch langsam.

Ergebnis des ungekapselten Codes auf meinem 1.4 GHz AMD: ~2600
Ergebnis des gekapselten Codes auf meinem 1.4 GHz AMD: ~3100
Macht ein Unterschied von: 500
Damit wird der Code um etwa: 19% verlangsamt.

Was genau sind die Zahlen nochmal? Und ja, ich weiss was clock() macht.

PS: Wenn du jetzt noch überladene Operatoren und andere objektorientierte Spielereinen benutzt liegt der Wert bei ungefähr 7300.
Das liegt unter anderem an der Indizierung der Klasse.
Bei einer V-Tabelle (virutelle Methoden → Polymorphie) wird das ganze noch extremer, da bei jedem "virtuellen" Funktionsaufruf diese durchsucht wird.

Klar, man kann es auch absichtlich langsamer machen als es sein müsste. Man kann aus t in der Objektvariante auch eine lokale Variable von main() machen, oder so eine einfache Methode in die Klassendefinition schreiben, damit sie inline übersetzt wird, oder man kann beides kombinieren:

marc@s8n:~/tmp/kapseln$ ./a # Original ohne Objekt.
1280000
marc@s8n:~/tmp/kapseln$ ./b # Original mit Objekt.
1430000
marc@s8n:~/tmp/kapseln$ ./c # `t` lokal in `main()`.
850000
marc@s8n:~/tmp/kapseln$ ./d # `GetVar()` inline.
840000
marc@s8n:~/tmp/kapseln$ ./e # `c` und `d` kombiniert.
1270000

Wobei die Zeiten von c und d natürlich nichts aussagen. Das liegt einfach an dem Code der im Grunde keine wirkliche Arbeit leistet und das halt vom Compiler bemerkt wird.

Gerade bei GUIs sind die Möglichkeiten und Vorteile von Objektorientierung sehr deutlich. Ich will auch keine furchtbar langsamen Programme schreiben, aber Zeit die man für Optimierungen aufwendet, ohne das ein Programm wirklich zu langsam ist, halte ich für verschwendete Zeit. Vor allem wenn man an Stellen optimiert, wie bei der GUI, wo im Grunde schon von vornherein klar ist, dass diese bestimmt nicht den Flaschenhals in der Anwendung darstellen werden.

Wenn man leistungsfähige, robuste und wartbare Programme schreiben will, wählt man am Anfang gute Algorithmen und Datenstrukturen aus, implementiert das Programm möglichst sauber und dokumentiert. Wenn es danach zu langsam erscheint, wird erst einmal der Profiler angeworfen um zu schauen an welchen Stellen man den meisten Gewinn herausholen kann. Wenn die heissen Stellen identifiziert sind, kann man unter Umständen auch über andere Algorithmen oder Datenstrukturen nachdenken, oder eben an diesen Stellen Optimierungen am Code vornehmen.

Um auf das eigentliche Thema einzugehen: Da besteht bei Linux und Windows kein Unterschied.