Flame aus "Projekte": C oder C++ schneller bei Spieleprogrammierung?

[godlikebot]

KXII schrieb:

damit meine ich, daß man alles hinschreiben muss, und der compiler/linker/ide nichts für einen verwaltet, wie z.b. die includes im stile:

#include "com/company/game/core/model/cplayer.h"

sowas sollte man nicht mehr hinschreiben müssen, sondern die ide sollte das für einen verwalten. da aber in c++ "#include's" ein teil der sprache sind (es gehört zum präprozessor, der aber auch zu c/c++ gehört) ist das nicht wirklich möglich.

Warum sollte es nicht möglich sein eine Compiler IDE zu schreiben, bei der man sowas per Mausklicks einstellen kann? Ausserdem wäre es Schwachsinn #include's aus dem Standard zu entfernen (ist das wirklich deine Meinung oder n Missverständniss?); wie sollte man dann sowas machen können?

#if defined BLUBB
  #include "cplayer.h"
#else
  #include "neanderedatei.h"
#endif

Sowas kann dir ne IDE nich (oder nur schwer) abnehmen.

[Gast]

otze schrieb:

was das namensproblem aber auch nur auf eine andere ebene verschiebt, es ist schon immernoch vorhanden. Gegenbeispiel: was ist, wenn 2 libs die selben packagenamen haben? wie willst du dann noch damit zurande kommen?

Nein, wenn man sich wirklich an die Java-Konventionen hält, würde das so aussehen:

net.emuleproject.gui
net.emuleproject.chat
...

und du wirst mir sicher nicht ernsthaft erzählen wollen, dass du mal aus Versehen deine GUI-Lib mal so nennen würdest. Das ist allerdings nicht irgendeine tolle Besonderheit der Sprache Java, die C++ nicht hat, als viel mehr eine Sache dessen, dass im Allgemeinen Java-Programmierer das anders handhaben und diese Vorgehensweise noch ein bisschen gefördert wird.
Beispielsweise wird das anonyme package (der "globale namespace") praktisch nie benutzt, weil es auch noch mit sprachlichen Einschränkungen daherkommt. In Java gibt es keinen Scope-Auflösungsoperator '::' und man kann von einem nicht-anonymen package aus nicht auf Elemente des anonymen packages zugreifen.

[Manuelh87]

Ich seh das genauso wie rapso! Genau so was hab ich gemeint! und gerade bei na Matrix kann man sich überlegen ob die C Variante net gscheiter ist!

Niemand greift die OPP variante an! Ich find das super und verwend wie schon hundert mal gesagt auch gerne klassen, aber halt nur wenns wirklich in eine gehört (meiner Meinung nach) und wenn es zur übersichtlichkeit gut beiträgt! Dann nhm ich auch die Nachteile in Kauf. Nur z.b. ne Klasse für nen Vector würd ich wahrscheinlich ned machen. Wenn ich eh noch viele übergeordnete klassen hab würd ich da eher ne typedef struct machen so aus dem gefühl heraus. Denn hier trägt eine Klasse wirklich nur minimal zu einer großen verbesserung bei. (Wobei das bei dem Beispiel auch von dem code her keinen wirklichen unterschied machen würd, is eher ne geschmackssache)

Also: Wie finden alle oop super und verwenden die auch gerne, ich wollte nur auf mögliche Probleme hinweisen. (und eigentlich ein Team machen; aber dank den Moderatoren ist das jetzt eh ein neuer Thread!; Danke nochmal )

cu Manuelh87

[the_hero99]

Wie wäre es mal, wenn man eine Aufgabe erstellt, die von C Programmieren als auch C++ Programmierern lösen lässt.
Logischerweise gleiche Aufgabebedingungen und ein 'kleines Benchmark' sollten enthalten sein.

Denn können wir mal Vergleiche ziehen, welche Version schneller ist.

[TheTester]

das ergebnis wird da dann wohl am Compiler liegen...

[Manuelh87]

Das kommt zu stark auf die technik und die skills des coders an und ich weiß nicht was du damit beweisen willst und wem du das beweisen willst?
Ich mein für mich is klar das ma mit nem guten c-compiler aufjedenfall ne kleinere datei zamkriegt aber auch das ist stark abhängig von den verwendeten Biliotheken.

Ich fänds besser ein richtiges Projekt zu haben :xmas1: (so wie meins zb wo sich noch keiner gemeldet hat.... )

cu Manuelh87 :xmas1:

[rapso]

mathik schrieb:

rapso schrieb:

und naja, alles auf einen compiler zu schieben find ich suboptimal, denn ein wirklich guter compiler würde meiner meinung nach erkennen, dass ich nen bubblesort implementiert habe und ihn durch nen quicksort ersetzen.

das sind genau solche sachen, die ein compiler niemals optimieren können wird!

was ein compiler können wird hängt von dessen programmierern ab, früher behauptete man auch, dass ein compiler bzw eine umgebung einem die speicherverwaltung nicht abnehmen könnte... niemals nie und man müsse mit den 640kb so gut wie es nur geht um gehen. heute gibt es java und das macht die speicherverwaltung für dich.

mathik schrieb:

rapso schrieb:

es ändert aber nichts daran, dass in c++ temporere objecte erstellt werden und es nichtmal ein keyword gibt um das ändern zu können und man hofft oft umsonst auf den compiler, auf der anderen seite kann man gut optimierende compiler öfter mal durch irre konstrukte dazu bringen falsche optimierungen zu machen, z.b. in einem fall in dem eine tempvar nötig wird, sie wegoptimiert wird und man ewig dran hängt den fehler herauszufinden.

rapso->greets();

was spricht gegen objektorientierung, dem typen Matrix eine operation zu verpassen, die zwei matrizen als parameter bekommt, wenn es bei der multiplikation von 3 matrizen tatsächlich einen ausgeklügelteren algorithmus gibt, und dieser auch häufig verwendet wird?

der menschenverstand, einen defizit einer sprache ausglecihen zu wollen indem man die kombinatorik durchführt die sie eigentlich hätte für einen übernehmen müssen ist dem, was die ganze zeitersparnis bringen soll wie du hier im anschluss sagst.

mathik schrieb:

worum es mir geht:
es ist falsch zu sagen, dass mit der OOP programme langsammer werden! Ich würde sogar behaupten, dass bei großen projekten diese sogar schneller und stabiler sind, da man aufgrund der höheren übersichtlichkeit besser optimieren kann. es liegt am programmierer oder am schlechten entwurf, falls das nicht der fall sein sollte. und an einem evtl. schlechten compiler... :xmas1:

Gruß mathik

ich spreche ja auch nicht von OOP programmen an sich, sondern von den defiziten von c++ die total unnötig sind, wieso kann man bei der deklaration von rückgabetypen nicht mit angeben, dass man direkt in eine var schreiben könnte ohne tempvar und copyconstructor? schliesslich kann man auch parameter als referenz bekommen.

rapso->greets();

[rüdiger]

oh man, du hast so absolut keine Ahnung von dem Thema und scheinst dir zu viel Blödsinn angehört zu haben.

und gerade bei na Matrix kann man sich überlegen ob die C Variante net gscheiter ist!

??

Ich mein für mich is klar das ma mit nem guten c-compiler aufjedenfall ne kleinere datei zamkriegt aber auch das ist stark abhängig von den verwendeten Biliotheken.

aber beweisen kannst du es nicht?

Bring lieber Fakten, als so ein Geschwafel!

[Gast]

rapso schrieb:

ich spreche ja auch nicht von OOP programmen an sich, sondern von den defiziten von c++ die total unnötig sind, wieso kann man bei der deklaration von rückgabetypen nicht mit angeben, dass man direkt in eine var schreiben könnte ohne tempvar und copyconstructor? schliesslich kann man auch parameter als referenz bekommen.

Sollte ich mich täuschen? Sowas machen C++ Compiler doch schon lange? Mich persönlich stört diese sprachliche Einschränkung nicht, wenn es der Compiler trotzdem richtig macht. :xmas1:
Dass es auf Sprachebene nicht möglich ist, ist leider klar. Die Rückgabe muss per Wert erfolgen, weil der aktuelle Frame ja abgebaut wird. Lösen könnte man das z.B. über Referenzsemantik, also return new Bla();

Aber das ist für C++ auch wieder nicht Recht, weil da ergibt sich dann kein zeitlicher Gewinn mehr. (Und noch ein paar Probleme mit Speicherverwaltung )

[rüdiger]

@rapso
das Operator-Konzept ist wirklich nicht sinnvoll, wenn man intern SIMD Optimierungen bauen will. In dem Fall nimmt man dann eben keine Operatoren. Man muss aber auch den C Code entsprechend anpassen. Hat wieder nichts mit der Sprache zu tun.

[otze]

und gerade bei na Matrix kann man sich überlegen ob die C Variante net gscheiter ist!

in c++ kannst du das ganze genauso abhandeln, perfekt geinlined und so schnell wie in c

stichwort: expression templates

zwar nicht ganz einfach zu programmieren, aber gut erweiterbar, wenn mans richtig macht.

sinn des ganzen ist es, dass der compiler aus

Matrix1=Matrix2*Matrix3

ein
TrinaerOp<Matrix,Matrix,Matrix,AssignMul>(Matrix1,Matrix2,Matrix3) macht.

innerhalb des ganzen würde dann AssignMul(Matrix1,Matrix2,Matrix3) ausgerechnet werden, und der TrinaerOp kram hinterher rausoptimiert.

sodass am ende aus

Matrix1=Matrix2*Matrix3

ein

AssignMul(Matrix1,Matrix2,Matrix3)

wird,was wiederum dem mul(&M1,&M2,&m3) entspricht.

[groovemaster]

rapso schrieb:

ich spreche ja auch nicht von OOP programmen an sich, sondern von den defiziten von c++ die total unnötig sind, wieso kann man bei der deklaration von rückgabetypen nicht mit angeben, dass man direkt in eine var schreiben könnte ohne tempvar und copyconstructor?

Ich dachte eigentlich, dass genau das mit RVO und NRVO gemacht wird.

[DEvent]

Manuelh87 schrieb:

Nur z.b. ne Klasse für nen Vector würd ich wahrscheinlich ned machen.

ich bezweifle irgendwie, dass es irgendeinen geschwindigkeitsvorteil bringt, statt einer vector-klasse ein typedef struct zu machen.
( ich nehme an, du meinst einen mathematischen vektor und kein array )

[Manuelh87]

kingruedi schrieb:

oh man, du hast so absolut keine Ahnung von dem Thema und scheinst dir zu viel Blödsinn angehört zu haben.

und gerade bei na Matrix kann man sich überlegen ob die C Variante net gscheiter ist!

??

Ich mein für mich is klar das ma mit nem guten c-compiler aufjedenfall ne kleinere datei zamkriegt aber auch das ist stark abhängig von den verwendeten Biliotheken.

aber beweisen kannst du es nicht?

Bring lieber Fakten, als so ein Geschwafel!

Und das beziehst du auf ???
Weil ich ne Matrix als typedef struct anlegen würd? das ist auch staark ne Stilfrage und ich find dass das nur Daten sind und da keine Klasse hingehört. Und wenn der restliche code dadurch nicht zu stark aufgebläht wird dann würd ich das auf jeden fall als typedef struct anlegen.

so das war das und das andere:
Du bist ja anscheined die totale elite in Person den du kannst mich ja genau einschätzen von oben.

Aber erklär mir jetzt bitte von was genau ich keine Ahnung hab und wie das alles wirklich ist. Da bin ich jetzt echt gespannt. Denn andere ohne genaue Angaben einfach mal global abzustufen ist recht einfach.

Da bin ich jetzt gespannt drauf!
Manuelh87

[DEvent]

Manuelh87 schrieb:

und gerade bei na Matrix kann man sich überlegen ob die C Variante net gscheiter ist!

wieso sollte das gescheiter sein? grade bei einer matrix gehts meist darum die determinante auszurechnen oder die eigenwerte /-vektoren zu berechnen. und da sind nur die algos entscheident, die dies tun. ob du dann einen copy-ctor brauchst, um auf die matrix zugreifen zu können ist dann auch egal. oder ob der compiler erst ein tmp-var erstellt für den wert der determinate ist wirklich vollkommen latte.

edit: @Manuelh87:
wie gesagt, eine matrix kannste auch als ein array speichern. aber was nützt? wozu brauch man den eine matrix? um damit zu rechnen. und da ist es sinnvoller die operatoren in der matrix zu haben, statt sie irgendwo umherschwiren zu lassen.

[Walli]

Manuelh87: Deine ganzen Posts lassen doch auch darauf schließen, dass du wenig fundiertes Wissen über C++ besitzt. Gerade solche Sachen, die u.a. im Bereich der Spieleprogrammierung auftauchen, wie Matrizen kann man doch in C++ verdammt performant mit einem Klassentemplate implementieren und hat auch noch den Vorteil einer hohen Wiederverwendbarkeit.

Kleines Beispiel:

template<std::size_t N, std::size_t M, typename T = float>
class Matrix {
  T matrix[N][M];
  //... usw.
}

template<std::size_t X, std::size_t N, std::size_t M, typename T>
Matrix<N, M, T> operator*(const Matrix<N, X, T>& a, const Matrix<X, M, T>& b)
{
  // ...
}

typedef Matrix<3, 1> Vector3;

// Anwendung
Matrix<3, 3> m;
Vector3 v1, v2;
// ...
v2 = m * v1;

Der Compiler kann nun, wenn er es für sinnvoll hält, Schleifen auflösen und inlinen... Will man etwas vergleichbares in C machen, dann sieht der Code meist häßlich aus.

[Manuelh87]

DEvent schrieb:

Manuelh87 schrieb:

Nur z.b. ne Klasse für nen Vector würd ich wahrscheinlich ned machen.

ich bezweifle irgendwie, dass es irgendeinen geschwindigkeitsvorteil bringt, statt einer vector-klasse ein typedef struct zu machen.
( ich nehme an, du meinst einen mathematischen vektor und kein array )

ne net deshalb sondern wegen weniger Konstruktor Destruktor und so und operatoren nicht zu vergessen !

[otze]

ich blick grad nicht, was der unterschied zwischen

vector a(5,4,3)

und

vectorS a;//S für struct zur verdeutlichung
a.x=5;
a.y=4;
a.z=3;

ist(ausser natürlich, dass das erste lesbarer ist).
beides ergibt genau denselben code.

und zwischen

vector a;

und

vectorS a;

besteht auch kein unterschied.
und da der dtor in beiden fällen nichts macht, da wir keinen dynamischen speicher anfordern, ist sogar da der asm code komplett gleich.

Ui.

achja, vector*vector macht erstmal keinen unterschied zu mul(vector,vector)

erst funktionen die operatoren/operatorkombinationen mit mehr als 2 operanden darstellen, können manchmal einen geschwindigkeitsunterschied machen. aber wie gesagt kann man das über expression templates genausogut darstellen. halt nur lesbarer.

[DEvent]

Manuelh87 schrieb:

DEvent schrieb:

Manuelh87 schrieb:

Nur z.b. ne Klasse für nen Vector würd ich wahrscheinlich ned machen.

ich bezweifle irgendwie, dass es irgendeinen geschwindigkeitsvorteil bringt, statt einer vector-klasse ein typedef struct zu machen.
( ich nehme an, du meinst einen mathematischen vektor und kein array )

ne net deshalb sondern wegen weniger Konstruktor Destruktor und so und operatoren nicht zu vergessen !

das war jetzt spass oder ?

class Vector
{
    public:
        float x, y;
};

typedef struct VectorS
{
    float x, y;
} VectorS;

Vector v1; v1.x = 5; v1.y = 5;
VectorS vs1; vs1.x = 5; v1s.y = 5;

was ist bitte schneller ?
und einen copy-ctor hast du bestimmt nicht in einer schleife die 1.000.000 wiederholt wird.
und seit wann machen operatoren den zugriff auf die elemene einer klasse langsamer ?

edit: hm da war einer schneller...

[Manuelh87]

MaSTaH schrieb:

Manuelh87: Deine ganzen Posts lassen doch auch darauf schließen, dass du wenig fundiertes Wissen über C++ besitzt. Gerade solche Sachen, die u.a. im Bereich der Spieleprogrammierung auftauchen, wie Matrizen kann man doch in C++ verdammt performant mit einem Klassentemplate implementieren und hat auch noch den Vorteil einer hohen Wiederverwendbarkeit.

Und das hab ich in C als typedef ned? Das musst jetzt aber erklären.

Was gibts viel fundiertes Wissen über c++? Na soviel gibts ja da ned, sorry aber ich find c++ ist ned allzu kompliziert. Mir daugt halt mehr cpu näheres coden und nicht so highlevel. deshalb find ich z.b. casts von long* auf void* blöde!

Kannst bitte ein Beispiel für das fehlende fundierte Wissen geben? da bin ich dann auch gepannt drauf. Ich hab jetzt echt schon erklärt warum ich auch c code und weiß ned warums ihr euch so angegriffen fühlts.