C++ Kenntnisse für Spieleprogrammierung!

Helium

also ich schreib meine variablen in deutsch hin, ich seh gar nich ein wieso ich das nicht tun sollte die sources bekommt eh kein englisch sprechender zu lesen

Das heißt nicht, das das bei allen so ist.

Zeig mal ein Beispiel für deine Variablenbenennung. Vielleicht finde ich die ja hässlich.

Und das verwenden von Operatoren ist natürlich vorteilhaft. Das letzte mal habe ich aber vor etwa drei Jahren Spiele programmiert. Ich hab überhaupt keine Ahnung mehr von meinem eigenen Code. Natürlich ließ sich das Punktprodukt auch mit Operatoren berechnen. * konnte auch gleichzeitig fürs Skalarprodukt verwendet werden. % war das Kreuzprodukt. Langsam erinnere ich mich. Ich müsste erstmal wieder reinkommen. Eigentlich ging mit meiner kleinen Minibibliothek alles, was man so in dem Bereich brauchte. Multiplizieren mit Matrizen zum rotieren, transformieren, ... , umrechnen von Quaternionen in Matrizen und umgekehrt, ... . Was weiß ich vielleicht sollte ichs mir nochmal angucken, bevor ich irgendwas schreibe.

rapso schrieb:

und wieso ist es sinnvoll das erste Nomen klein und die restlichen gross zu schreiben? wäre eine einheitlicherere Konvention nicht besser?

rapso->greets();

Das ist doch einheitlich

int eineLangeVariable;

class MeineLangeKlasse
{
};

oft bestehen ja Klassennamen nicht aus mehreren Wörtern (bei mir zumindest nicht).
Auf jeden Fall erkennt man so Variablen immer am kleinen Anfangsbuchstaben und Klassennamen am großen.
Den Unterstrich zu verwenden finde ich außerordentlich hässlich und anangenehm zu schreiben.
Mein Vorschlag für

float temp_dist_x;

wäre also

float distanceX; // Wozu das temp

Ach und wenn wir schon dabei sind...
Die Namen von Funktionen und Methoden schreibe ich immer Groß:

class MeineKlasse
{
[...]
};

MeineKlasse meineInstanz;

meineInstanz.BerechneZeitpunktsDesUrknalls();
meineInstanz.SetBla(4);

Get- und Set Methoden sollten auch immer mit Get oder Set beginnen -.-
man sieht hier übrigens ganz schön (anhand der Groß/Kleinschreibung!) dass MeineKlasse eine Klasse ist und meineInstanz ein Objekt.

So, jetzt wisst ihr alles über mich.

rapso

Optimizer schrieb:

Das ist doch einheitlich

int eineLangeVariable;

int EineLangeVariable; // das wäre einheitlicher

class CMeineLangeKlasse
{
};
class IMeineLangeKlasse
{
};
struct SMeineLangeKlasse
{
};

wenn du nur gross und kleinschreibung hast zu differenzierung, dann hast du viele variablen die "int","class" und "float" heißen

nein, aber mal das beispiel da, Jedes Nomen gross anfangen lassen, das finde ich besser als ne "unnütze" ausnahme einzubauen.

ein interface mit I anfangen lassen, denn es kann sein, dass man ein plugin schreibt, dann leitet man von einem interface ab, da weiß man gleich, dass das eine abstract class ist und man kommt nicht auf die versuchung IMeineKlasse& ... zu schreiben.

und S für kleine structuren für die es sich nicht lohnt eine gekapselte klasse zu erstellen mit accessorfunktionen.

bsp:

struct SLookUpTable
{
     int         m_Hash;
     float       m_SquareRoot;
}

desweiteren finde ich es sehr angenehm m_ zu schreiben für member variabeln, dann kann man auch

void CBla::Bla(float Position)
{
    m_Position  = Position;
}

schreiben, ohne sich für die eigentlich eindeutige benennung der Position etwas ausdenken zu müssen...was schreibt man statt Position?

rapso->greets();

wenn du nur gross und kleinschreibung hast zu differenzierung, dann hast du viele variablen die "int","class" und "float" heißen

hmmm versteh ich jetzt nicht so ganz was du meinst.

desweiteren finde ich es sehr angenehm m_ zu schreiben für member variabeln, dann kann man auch

void CBla::Bla(float Position)
{
m_Position = Position;
}

schreiben, ohne sich für die eigentlich eindeutige benennung der Position etwas ausdenken zu müssen...was schreibt man statt Position?

mein Vorschlag:

void Bla::Bla(float startPosition)   // Konstruktor, also wie wärs mit startPosition?
{
    position = startPosition;        // Das position ein Member ist, ist eigentlich offensichtlich.
// Davon abgesehen sollte man seine eigene Klasse schon kennen  ;)
}

Wie auch immer, es ist alles Geschmackssache (bis auf Unterstriche )
Das wichtigste ist, dass man seine Konvention konsequent durchhält.

Helium

ein interface mit I anfangen lassen, denn es kann sein, dass man ein plugin schreibt, dann leitet man von einem interface ab, da weiß man gleich, dass das eine abstract class ist und man kommt nicht auf die versuchung IMeineKlasse& ... zu schreiben.

MeineKlasse_adapter adapter;

IMeineKlasse & referenz = adapter;

Mist doch in die Versuchung gekommen.

und S für kleine structuren für die es sich nicht lohnt eine gekapselte klasse zu erstellen mit accessorfunktionen.

Was du sagen willst du verwendest S für PODs.

Konventionen hat jeder. Meine sind folgende: Wörter werden mit einem Unterstrich getrennt. Variablen und funktionen beginnen mit einem Kleinbuchstaben, Typen, egal ob Klassen Aufzählungen oder typedefs mit einem Großbuchstaben. Makros werden komplett groß geschreiben. Member werden durch ein m_ als Präfix markiert. Abstrakte Klassen beginnen mit einem I. für PODs gibts keine gesonderete Kennung, da Sie bei mir nur als verschachtelte Klasse vorkommen. Sicherlich habe ich noch irgendwas vergessen, aber das ist jetzt nicht sowichtig.

float distanceX; // Wozu das temp

Ganz einfach, weil es eine temporäre Variable ist, die nur kurz existiert (siehe den Kleinen Sie umgebenden Block) und nach Möglichkeit nach der nächsten Refaktorisierung verschwindet.

eine_lange_Variable kann ich wesentlich besser lesen als eineLangeVariable. Und außerdem werden bei dir Adjektive plötzlich groß geschrieben.

Zitat:
float distanceX; // Wozu das temp

Ganz einfach, weil es eine temporäre Variable ist, die nur kurz existiert (siehe den Kleinen Sie umgebenden Block) und nach Möglichkeit nach der nächsten Refaktorisierung verschwindet.

eine_lange_Variable kann ich wesentlich besser lesen als eineLangeVariable. Und außerdem werden bei dir Adjektive plötzlich groß geschrieben.

Wow, es ist eine Variable, die nur kurz existiert. Respekt. Das ist eine Erkenntnis, für die ich kein temp brauche, um sie innerhalb einer halben Millisekunde zu machen. Vor allem, wenn die Variable in einer Funktion definiert ist, die 5 Zeilen lang ist.
Und unwichtig ist es obendrein noch.

Adjektive werden großgeschrieben? Super, was hat Grammatik beim Programmieren verloren ;((
Sag bloß, du schreibst Substantive konsequent groß und Adjektive konsequent klein. Das ist auch mal ne nette Konvention.

class meine_kleine_Klasse_fuer_Wegpunkte

Gruß
Optimizer

EDIT:
Ja, du kannst eineLangeVariable schlechter lesen. Aber das liegt an der Schriftart...

int eineLangeVariable

Und es ist wesentlich angenehmer zu schreiben.

Helium

Wow, es ist eine Variable, die nur kurz existiert. Respekt. Das ist eine Erkenntnis, für die ich kein temp brauche, um sie innerhalb einer halben Millisekunde zu machen. Vor allem, wenn die Variable in einer Funktion definiert ist, die 5 Zeilen lang ist.
Und unwichtig ist es obendrein noch.

Hallo, die Variable existiert bei mir sowieso nicht; wieso also über den Namen steriten?

Adjektive werden großgeschrieben? Super, was hat Grammatik beim Programmieren verloren ;((
Sag bloß, du schreibst Substantive konsequent groß und Adjektive konsequent klein. Das ist auch mal ne nette Konvention.

class meine_kleine_Klasse_fuer_Wegpunkte

Bist auf das erste Wort in einem Bezeichner (siehe vorheriges Post) ist das tatsächlich so.

Ja, du kannst eineLangeVariable schlechter lesen. Aber das liegt an der Schriftart...
Und es ist wesentlich angenehmer zu schreiben.

Das ist Gewöhnungssache.

Aber wir sollten entweder wieder zum Thema zurückkommen oder den Thread endlich beenden.

rapso

Helium schrieb:

ein interface mit I anfangen lassen, denn es kann sein, dass man ein plugin schreibt, dann leitet man von einem interface ab, da weiß man gleich, dass das eine abstract class ist und man kommt nicht auf die versuchung IMeineKlasse& ... zu schreiben.
MeineKlasse_adapter adapter;

IMeineKlasse & referenz = adapter;
Mist doch in die Versuchung gekommen.

da interfaces nie objekte sondern nur pointer sein können und du dementprechend pointer auf eine referenz legen möchtest, verstößt du gegen die konvetion, dass referenzen nicht NULL sein dürfen, was beim Interfacepointer durchaus passieren kann. (es gibt ja kein interface objekt, sonst wäre es ja kein interface mehr, sondern eine ganz normale class, das objekt definiert durch die class).

das referenzen nicht NULL sein dürfen hab ich mir nicht ausgedacht, c++ standard ist schuld

rapso->greets();

rapso

Optimizer schrieb:

wenn du nur gross und kleinschreibung hast zu differenzierung, dann hast du viele variablen die "int","class" und "float" heißen

hmmm versteh ich jetzt nicht so ganz was du meinst.

desweiteren finde ich es sehr angenehm m_ zu schreiben für member variabeln, dann kann man auch

void CBla::Bla(float Position)
{
m_Position = Position;
}

schreiben, ohne sich für die eigentlich eindeutige benennung der Position etwas ausdenken zu müssen...was schreibt man statt Position?

mein Vorschlag:
void Bla::Bla(float startPosition)   // Konstruktor, also wie wärs mit startPosition?
{
    position = startPosition;        // Das position ein Member ist, ist eigentlich offensichtlich.
// Davon abgesehen sollte man seine eigene Klasse schon kennen  ;) 
}
// Davon abgesehen sollte man seine eigene Klasse schon kennen <--- wie meinen?

Wie auch immer, es ist alles Geschmackssache (bis auf Unterstriche )
Das wichtigste ist, dass man seine Konvention konsequent durchhält.

das position ein member ist, ist offensichtlich, aber in einem längerem code könnte es schon passieren dass man sich startPosition und position mal verwechselt, deswegen ist es für fehlerfreieren code gut, wenn man temp variablen und members unterscheiden kann, schliesslich könnte die klass ja auch startPosition als member enthalten und position als parameter übergeben bekommen, oder muss man dann "absolutStartPosition" schreiben?

Außerdem gibt es nicht nur den konstruktor und deswegen immer "actualPosition" "justSetPosition" oder sowat zu schreiben finde ich komisch, schliesslich sollten variablen einen nützlichen namen haben und über eine accessor funktion, die den memberwert ändert, setz man natürlich die aktuelle position, im konstruktor auch die start bzw initPosition, sonst müßte man ja code akzeptieren wie:

float xAddToYMulBySizeX = x + y*SizeX; //anstatt Position

deswegen finde ich es komisch bei einer variable etwas eindeutiges nochmal reinzschreiben, sogar anfängerbücher für c/c++ sind gegen überflüssige benennungen die man aus dem kontext eh erkennt. (gibt aber bestimmt schwarze schafe darunter )

rapso->greets();

Helium

da interfaces nie objekte sondern nur pointer sein können und du dementprechend pointer auf eine referenz legen möchtest, verstößt du gegen die konvetion, dass referenzen nicht NULL sein dürfen, was beim Interfacepointer durchaus passieren kann. (es gibt ja kein interface objekt, sonst wäre es ja kein interface mehr, sondern eine ganz normale class, das objekt definiert durch die class).

Was willst du mir damit sagen? Eine Referenz ist völlig legal.
Schnittstellen können nicht instanziiert werden, Referenzen sind aber keine Instanzen, genauswenig, wie Zeiger. Und in dem Text, den ich von dir Zitiert habe stand eindeutig IMeineKlasse**&**.

das referenzen nicht NULL sein dürfen hab ich mir nicht ausgedacht, c++ standard ist schuld

Wieder verstehe ich nicht, was du willst:

IMeineKlasse & referenz = *new MeineKlasse_adapter;
...
delete & referenz;

Das ist doch legitim, auch wenns kaum einer machen würde. referenz kann in diesem beispielnicht auf NULL verweisen. Entweder habe ich noch Speicher frei und bekomme das Objekt, das ich will, oder ich habe keinen mehr frei un bekommen ein std::bad_alloc um die Ohren gehauen. Ich kann nichts dafür, das das so ist. Das ist der C++-Standard schuld.

Allerdings könnte ich sowas machen:

int & x = reinterpret_cast<int&>(NULL);

Dann habe ich eine NULL-Referenz, deren Gebrauch undefiniertes Verhalten zur folge hätte.