Nochmal: Ungarische Notation

Shade Of Mine

Jover schrieb:

Naja ich dachte, dass im Konstruktor this nicht verwendet werden kann.
Foo::Foo(float value)
{
    this->value = value;
}
geht das?

Klar geht das.

Was du uU meinst ist, dass man this nicht in der Initialisierungsliste verwenden sollte.

bzw, geht das?

Foo::Foo(float value)
: value(value) {}

Klar geht das.
einzig ein bisschen doof ist folgendes:

Foo::Foo(float val)
: value(value) {}

@Mis2com:
nein welch große Erkenntnis und Idee. Lamesfaktor: 10

Welche Idiot benutzt denn Bitte this-> im Constructor??? Das wird wenn schon im Funktionsheader reingeschrieben des Konstruktors:

Foo::Foo (void) : m_value (0.0f) { }

bzw.:

Foo::Foo (float value) : m_value (value) { }

Die drei Einzigsten nützlichen Präfixe aus der Ungarischen Notation sind: C (bzw. I) sowie m_ für Member variablen (denn this->value finde ich persönlich Scheisse!) sowie g_. Den Rest aus dieser Notation kannste knicken.

Shade Of Mine

nix da schrieb:

Welche Idiot benutzt denn Bitte this-> im Constructor??? Das wird wenn schon im Funktionsheader reingeschrieben des Konstruktors:

Geil, du hattest noch nie Code in einem Ctor?

Jover

@Shade: Danke, für die Korrektur. Man lernt eben nie aus.

Mis2com

@nix_da:
Schön, dass du den Rest des Threads gelesen hast, sodass du dich in keinem Punkt wiederholt hast.

OK, _ als Suffix bzw. m_ als Präfix ist ok, C bei Klassen ist ja anscheinend auch unsinnig, außer bei Einheit in z.B. MFC, was sagt ihr zu I bei Schnittstellen?

Noch Fragen:

Tja, äh, aber dann wären Zeiger-Präfixe doch auch Quatsch, weil man das mit dem Zeiger auch schnell nachlesen kann?
Ich sehe darin allerdings insofern Sinn, als dass es nicht ein Hund ist, sondern nur ein Zeiger auf den Hund...
Frage ist jetzt natürlich, ob durch das * dieses Zeiger auf direkt mit zum Namen gehört, hm.
Ist es eigentlich schlechter Stil Monsterfunktionen zu machen, statt vielen vereinzelten, wenn man jeden Teil der Funktion ohnehin nur einmal benötigt, einzelne Abschnitte kommentiert und Variablen auch erst dann definiert, wenn sie nötig sind?
In meinem aktuellen Projekt habe ich so eine Funktion, es handelt sich direkt um main, also ich sehe da kein sonderlich großes Problem drin, aber es ist ja allgemein nicht besonders schön, oder?

Danke jedenfalls, die ungarische Notation werde ich in Zukunft wohl kaum noch verwenden.

Nochwas, Prädikate werden ja auch nicht mit prd präfixiert, wie kann man ein Prädikat denn dann bennenen, damit es klar wird?
Also paar Beispielbezeichnungen wäre nett.

Danke für die Hilfen bisher,

MfG Eisflamme

Shade Of Mine

Mis2com schrieb:

was sagt ihr zu I bei Schnittstellen?

Wozu?

Tja, äh, aber dann wären Zeiger-Präfixe doch auch Quatsch, weil man das mit dem Zeiger auch schnell nachlesen kann?
Ich sehe darin allerdings insofern Sinn, als dass es nicht ein Hund ist, sondern nur ein Zeiger auf den Hund...
Frage ist jetzt natürlich, ob durch das * dieses Zeiger auf direkt mit zum Namen gehört, hm.

Ist es nicht egal ob du einen Hund, oder einen Zeiger auf einen Hund hast?

Ist es eigentlich schlechter Stil Monsterfunktionen zu machen, statt vielen vereinzelten, wenn man jeden Teil der Funktion ohnehin nur einmal benötigt, einzelne Abschnitte kommentiert und Variablen auch erst dann definiert, wenn sie nötig sind?

Ja

In meinem aktuellen Projekt habe ich so eine Funktion, es handelt sich direkt um main, also ich sehe da kein sonderlich großes Problem drin, aber es ist ja allgemein nicht besonders schön, oder?

Mein main sieht in etwa so aus:

int main()
{
  try
  {
     Application app;
     app.run();
  }
  catch(...) //bzw. andere exceptions
  {
     cout<<"unbekannter Fehler\n";
  }
}

Was hast du da viel mehr drinnen stehen?
selbst app.run() ist nicht sonderlich lang...

Naja, manchmal habe ich auch längere Funktionen - nämlich dann wenn man eine hässliche C API ewig lang initialisieren muss - aber sowas kommt selten vor.

Nochwas, Prädikate werden ja auch nicht mit prd präfixiert, wie kann man ein Prädikat denn dann bennenen, damit es klar wird?
Also paar Beispielbezeichnungen wäre nett.

Wozu willst du das? Wir wollen doch keine präfixe und ähnliches. Also nur einen passenden Namen oder Schnickschnack.

zB
IpCompare um IP Adresse zu vergleichen

Mis2com

Hi,

ok.
Ich habe jetzt keine Klasse Main in diesem Sinne gehabt, wusste nicht, dass man das so tun soll, auch wenn es natürlich logisch ist, werde das ändern.
Dann bieten sich auch mehrere Funktionen eher an, weil ich mit mehreren globalen Funktionen meinem Geschmack nach zu sehr C programmiert hätte.
main so vollzustopfen ist aber ebenfalls eher C, das war mir nur nicht ganz bewusst, danke.

I für Interface-Präfix, z.B.:

IServer

Finde ich praktisch, weil man es so von einem StandardServer unterscheiden kann, weil ein StandardServer auch gerne den Namen Server hat.
...Compare also... ok, das leuchtet mir natürlich ebenfalls ein.

Gute Nacht, danke nochmal

Warum wollt ihr denn die Variablen immer so technisch benennen? Ist das wichtig, ob es ein Hund ist oder ein Zeiger auf einen Hund? Viel wichtiger ist doch, dass es der Hund ist, der die Passanten auf Drogen beschnuppert, der Wachhund, oder der Hund, der einfach nur faul rumliegt oder eine andere Aufgabe hat.
Beschreibt halt, was der Hund für ne Funktion und für einen Sinn in dem Programm hat und nicht, dass es ein globaler const-Zeiger auf ein Hund-Objekt ist. Das kann ich mit minimalen Aufwand nochmal nachschauen, wenn es mir entfallen ist.
(Das betrifft jetzt die Benennung von Instanzen.)

SirLant

Also ein p als prefix für Zeiger kann ich verstehen, so sieht man sofort wo man
den . und wo den -> benutzen muss, es sei denn man hat ne IDE die das automatisch
korrgiert

Also das mit dem p hab ich mir inzwischen auch angewohnt, bei mir sieht ne Variable
im schlimmsten Fall so aus: g_pHund
Globale Objekte benutze ich höchst selten (wenn Konstanten), wodurch es ein _pHund
ist und wenn die Variable öffentlich zugänglich ist (die MFC versaut einem den Stil ), dann nur
ein pHund, es sei denn es ist nen MFC Projekt dann m_pHund

Christoph

SirLant schrieb:

Würde normale gerne ein C vor den Klassennamen weglassen, aber damit es einheitlich ist schreibe ich ein C davor [...]

Womit einheitlich?

SirLant

Steht doch im Satz darüber, mit der MFC, da diese immer ein C davor schreibt.

Christoph

Dazu gabs mal einen schönen Link. Leider kann ich ihn nicht mehr finden, aber vielleicht kennt jemand die Seite, auf der etwa folgendes steht:

Die Compilerhersteller bieten Klassenbibliotheken an, wie z.B. MS mit seiner MFC. Wenn die nun aber eine Klasse Window anbieten, besteht eine recht hohe Kollisionsgefahr (in normalem Code ist eine eigene Window-Klasse gar nicht mal so unwahrscheinlich).
Deswegen haben die von MS sich gedacht: Verwenden wir ein Präfix! Denn damit kann es nicht mehr zu Kollisionen kommen. (Namespaces gabs damals noch nicht).
Dummerweise ging dieser Schuss ziemlich nach hinten los, weil viele Programmierer gedacht haben: "Microsoft setzt ein C vor die Klassennamen. Für irgendwas wird das wohl gut sein, denn sonst hätten die das nicht gemacht. Also machen wir das auch."
Damit ist das eigentliche Ziel, nämlich die Vermeidung von Kollisionen, total untergegangen.

Konsequenterweise dürftest du das C also nur benutzen, wenn du die MFC programmierst. Denn normale Klassen (non-MFC) haben kein Prefix.
Mit (non-MFC) meine ich alle Klassen, die ein normaler Programmierer selbst schreibt, folglich nicht aus der MFC stammen.

Cool, wenn ich Dienste der MFC nutze, dann muss natürlich mein ganzes Programm im MFC-Stil geschrieben sein.

Oh shit, aber manchmal benutz ich auch noch die STL.

Deswegen haben die von MS sich gedacht: Verwenden wir ein Präfix! Denn damit kann es nicht mehr zu Kollisionen kommen. (Namespaces gabs damals noch nicht).

Naja die MFC ist doch für C++ geschrieben. Oder gabs da die namespaces auch nicht von Anfang an?

SirLant

Ne gab es nicht Optimizer.

Ich benutze in MFC Programmen das C, ganz einfach weil die Klassen großteils, naja
eigentlich alle, bis auf sehr wenige die ich selber schreiben, von Klassen aus der
MFC abgeleitet sind und somit zu einem Teil der MFC werden.
Sonstige Klassen haben kein C im Namen, da sie unabhängig sind, es sei denn sie
verwenden natürlich intern die MFC.

Christoph

Dass eine Klasse MFC-Elemente enthält, sollte wirklich kein Grund sein diese Klasse als "Teil der MFC" anzusehen und ihr ein C zu verpassen.
Auch von der MFC abgeleitete Klassen dürften konsequenterweise kein C erhalten, denn sie sind definitiv nicht "Teil der MFC".
Zur MFC gehören nur die Klassen, die in der MSDN unter "MFC" dokumentiert sind.
Ein normaler Programmierer kann von diesen Klassen zwar ableiten oder sie einbinden, die MFC dadurch aber nicht erweitern.
Genausowenig kann man eigene STL-Klassen schreiben. Die STL-Implementation STLPort enthält z.B. die Klasse hash_set. Diese Klasse ist dennoch nicht "Teil der STL".

SirLant

@cd9000, doch es ist ein Grund, denn man soll in einem Projekt Konsistenz in der
Namensgebung halten und wenn ich ein MFC Projekt erstelle, erstellt mir der
Assistent automatisch Klassen mit dem C im Namen, wenn ich eine neue Klasse
hinzufügen möchte und gebe als ersten Buchstaben C ein, so werden die Felder mit
den Dateinamen nicht ausgefüllt, erst mit den anderen Buchstaben (CFoo, wird dann Foo.h und Foo.cpp).

Die MFC zwingt mich also dazu um Konsistenz zu wahren.

TheBigW

@SirLant

Nicht die MFC, sondern die IDE.
Deshalb erstelle ich meine Klassen mittels "Datei neu" und schreibe dann "von Hand".

@Optimizer

Warum wollt ihr denn die Variablen immer so technisch benennen? Ist das wichtig, ob es ein Hund ist oder ein Zeiger auf einen Hund? Viel wichtiger ist doch, dass es der Hund ist, der die Passanten auf Drogen beschnuppert, der Wachhund, oder der Hund, der einfach nur faul rumliegt oder eine andere Aufgabe hat.
Beschreibt halt, was der Hund für ne Funktion und für einen Sinn in dem Programm hat und nicht, dass es ein globaler const-Zeiger auf ein Hund-Objekt ist. Das kann ich mit minimalen Aufwand nochmal nachschauen, wenn es mir entfallen ist.

An sich vom Entwicklungsstandpunkt und der nötigen Abstraktion richtig. Es spricht ja aber nichts dagegen beides zu tun -> Name bezeichnet die Art des Hundes und Prä- bzw. Suffix den technischen Kontext.
Ich sehe es hier wirklich aus der Sicht von jemandem, der relativ häufig in kurzer Zeit Fremdtools nutzen und verstehen muß und da selbst kurzes Nachsauen als lästig empfindet.

Shade Of Mine

TheBigW schrieb:

Nicht die MFC, sondern die IDE.
Deshalb erstelle ich meine Klassen mittels "Datei neu" und schreibe dann "von Hand".

Makro schreiben, dass die Arbeit übernimmt
Gibt da genug freies.

An sich vom Entwicklungsstandpunkt und der nötigen Abstraktion richtig. Es spricht ja aber nichts dagegen beides zu tun -> Name bezeichnet die Art des Hundes und Prä- bzw. Suffix den technischen Kontext.

Lies mal die FAQ von Run um - dann wirst du auch Humes Beispiel sehen und erkennen warum zuviel Information böse ist.

Ich sehe es hier wirklich aus der Sicht von jemandem, der relativ häufig in kurzer Zeit Fremdtools nutzen und verstehen muß und da selbst kurzes Nachsauen als lästig empfindet.

Und da ist es wichtig ob du einen float oder double vor dir hast?
Ich habe dann immer Probleme rauszufinden wie die Funktion jetzt heisst und ob sie das richtige macht.
Ich hatte noch nie Probleme mit dem Typen einer Variablen - zumal es bei mir sowieso fast nur Klassen gibt (und da hast du doch nicht wirklich auch prefixe, oder?)

Christoph

SirLant schrieb:

[...] wenn ich ein MFC Projekt erstelle, erstellt mir der
Assistent automatisch Klassen mit dem C im Namen, wenn ich eine neue Klasse
hinzufügen möchte und gebe als ersten Buchstaben C ein, so werden die Felder mit
den Dateinamen nicht ausgefüllt, erst mit den anderen Buchstaben (CFoo, wird dann Foo.h und Foo.cpp).

Du kannst doch trotzdem Klassen ohne C-Präfix erstellen?
Wenn der Klassenname zufällig mit einem C beginnt und die IDE meint da ruminterpretieren zu müssen, setzt du die Dateinamen eben manuell. In dem genannten Dialog gibt es eine Schaltfläche dafür.

Helium

Programmiert doch mal in einer nicht zur Compilezeit Typisierten Sprache.

|foo|

foo := 5.
foo := Apfelbaum new.
foo := 'Hallo' reverse.

Sicherlich kein sinnvolles Beispiel und sowas würde auch keiner machen, aber es lenkt das Denken in die richtige Richtung.