Was ist toll an size_t?

Shade Of Mine

EnERgYzEr schrieb:

- Während des codens weiß ich, was für ein Typ die Variable hat und
kann so besser programmieren. Bei vielen Variablen und längeren Funktionen
macht das IMHO Sinn

Du hast aber weder viele Variable noch laengere Funktionen, wenn du schoen OO programmierst

bzw. wenn du soetwas hast, dann hast du die Variablen alle schoen lokal - du solltest also die Deklaration sehen koennen.

- Ich kann Membervariablen von Funktionsparametern unterscheiden

warum ist das wichtig?

- Mir gefällt ein m_sName = sName besser als this->Name = Name

mir gefaellt name am besten. Na und?

- Der Vorschlag, dass der Compiler schon merkt, wenn eine Typzuweisung falsch
ist, sehe ich als genauso theoretisch an - Nicht jedes Projekt lässt
sich in 10 Sekunden compilieren - In meiner Firma sitzen wir schon mal
10 Minuten rum, weil das MS VC mal wieder nicht gerallt hat, dass nur
eine Datei geändert wurde

Schonmal was von pimpl gehoert?
Naja, trotzdem. Da helfen die Praefixe auch nix - denn du hast ja nicht nur Primitive Typen - und du wirst ja nicht allen ernstes fuer jeden Typen ein Praefix erfinden, oder? Da du das nicht tun wirst, beschraenkst du dich mit den Praefixen auf die paar Builtins? Und das lohnt sich? Was machst du, wenn du statt einem int mal ein Int128 hast? Das ist momentan noch eine Klasse, aber auf einer anderen Plattform ist das aufeinmal nur ein typedef. Sehr verwirrend... zumindest fuer mich. Ich wuerde den Code dann nicht so klar finden.

- Das Mit-Der-Maus-Rüberfahren ist beim MS VC.NET buggy und fumktioniert nicht
immer - vor allem im Debug Modus (Ironie?) - Wann kommt endlich ein Service
Pack, um diese ganzen s****** Bugs zu entfernen

Na, das sind ja mal Probleme (und vorallem ein super Grund)

Mich hat der Typ einer Variable bisher nur dann interessiert, wenn der Compiler einen Fehler gemeldet hat (und dann war es meistens ein const Problem).

Deine Argumente sind loechrig.

Erklaer lieber mal _warum_ du den Typen wissen musst. zB wie machst du das bei Templates??

Genau mein Reden.... Das Verhalten ist das eines int - also kann ich das auch
dazu schreiben, oder? Schließlich kann nicht jeder wissen, dass
fjdfdjkTOLLE_ZAHLffdjk ein typedef auf ein int sein soll..

Wieso interessiert dich, dass der Typ "fjdfdjkTOLLE_ZAHLffdjk" ist? Vielleicht ist es ja kein typedef auf int, sondern eine hoch komplexe Klasse? Wuerdest du dann immer noch i als Praefix nehmen?

Wenn i einfach nur Zahl bedeutet, dann ist das Problem doch: wenn du iNumber sagst, dann bringt das i nicht wirklich etwas. Und ein iName wird es nicht geben. Somit sagt iNumber kein bisschen mehr als number.
Und zB s als string-Praefix. Was fuer ein string ist es denn? CString? std::string? char*? wchar_t*? oder vielleicht flex_string? Und wenn flex_string - mit welchen Policies?

Der Sinn von OOP ist ja, dass der Typ uninteressant ist. Das Verhalten zaehlt. Und du kannst das genaue Verhalten nicht mit ein paar Buchstaben sinnvoll beschreiben.

zB statt Zeiger hast du oft smart pointer - wie macht man da Praefixe? Prinzipiell sind es Zeiger (lassen sich ja auch genauso verwenden) - aber ein p als Praefix ist dennoch nicht richtig (weil es ja eben _doch_ unterschiede gibt - nur sind diese Unterschiede in 99% der Faelle uninteressant).

Du bindest mit einem Praefix eine Variable an einen Typen - das geht aber nicht. Denn du koenntest ja uU mal polymorphe Objekte (ein super Beispiel, warum der Typ nicht wichtig) - wie willst du mit denen umgehen?

Ungarische Notation passt einfach nicht in eine OO Sprache.

EnERgYzEr schrieb:

Optimizer schrieb:
Mir gefällt eigentlich am besten die Initialisierliste:
Person:Person(const string& name, int age)  :
    name(name), age(age)        {}
Haha, toller Witz ... Es gibt auch ein SetName(string sName)

Echt? Bei mir nicht, weil eine Person in der Regel ihren Namen für das ganze Leben behält.

net 0

Optimizer schrieb:

Jo, das ist ja auch sinnvoll. Sonst weiss ich ja nicht, ob Math.sqrt() jetzt eine statische Methode ist, oder ich eine Instanz mit dem Namen Math hab und die Methode nicht statisch ist. Hat aber auch nichts mit ungarischer Notation zu tun.

hat aber die gleiche wirkung. man steckt (teilweise) typinformationen o.ä. in die namen und wenn sich am typ, spezifizierer oder so irgendwas ändert sind alle namen für die katz.

Gregor

BTW: Gibt es eigentlich für C++ Code-Konventionen, die von einem Großteil der C++ Programmierer zu großen Teilen eingehalten werden? Das ist bei Java ja mit den von Sun herausgegebenen Code Conventions der Fall. Wo finde ich für C++ so ein Dokument, das von einem Großteil der Gemeinschaft beachtet wird?

energyzer

Optimizer schrieb:

EnERgYzEr schrieb:
Optimizer schrieb:
Mir gefällt eigentlich am besten die Initialisierliste:
Person:Person(const string& name, int age)  :
    name(name), age(age)        {}
Haha, toller Witz ... Es gibt auch ein SetName(string sName)
Echt? Bei mir nicht, weil eine Person in der Regel ihren Namen für das ganze Leben behält.

Noch besserer Witz

Anti-Witz: SetGamerName(string sName)

Leute...hört bitte mit der Diskussion auf.

Das hatten wir schon sehr oft besprochen. Und es kommt immer das gleiche bei rum.

Habt ihr zuviel Zeit?

Shade Of Mine

net schrieb:

hat aber die gleiche wirkung. man steckt (teilweise) typinformationen o.ä. in die namen und wenn sich am typ, spezifizierer oder so irgendwas ändert sind alle namen für die katz.

*lol*

Das ist etwas Grundlegend anderes.

Ob ich jetzt eine Katze, einen Hund oder einen Vogel habe - ich mache
tier.fuettern(); und das tier fuettert sich selbst. OK, doofes Beispiel - aber es ist ja wohl klar was ich meine, oder?

Aber ob ich einen Typen oder eine Variable habe - das ist ja sehr wohl wichtig. Vorallem weil sich das ja nicht aendern _kann_. Tier wird immer eine Klasse bleiben und kann sich niemals in eine Variable umwandeln.

Weiters:

Foo Bar(Foobar);

ist das eine Funktionsdeklaration oder eine Variablendefinition?

unmoeglich zu sagen, aber vital zu wissen.

ein
Foo bar(foobar);
ist dagegen eindeutig.

Geil, nicht?

energyzer

Ok, aber im Großen und Ganzen muss ich euren Argumenten recht geben. Man
ist halt doch sehr stark an seine Schreibweise gewöhnt.

Nur solltet ihr bedenken, dass in der Praxis nicht unbedingt der schönste
OO-Code gewinnt. Es gibt nun mal auch lange Methoden, weil nicht jeder die
Zeit hat hunderte von Klassen/Methoden zu entwerfen, die diese eine Methode
aufsplitten.

net 0

???????? schrieb:

Leute...hört bitte mit der Diskussion auf.

also mir gefällt's hier. ihr seid wenigstens nicht solche vollidioten wie 90% der user bei developia --> http://www.softgames.de/forum/

Gregor schrieb:

BTW: Gibt es eigentlich für C++ Code-Konventionen, die von einem Großteil der C++ Programmierer zu großen Teilen eingehalten werden? Das ist bei Java ja mit den von Sun herausgegebenen Code Conventions der Fall. Wo finde ich für C++ so ein Dokument, das von einem Großteil der Gemeinschaft beachtet wird?

Nicht so wirklich, glaube ich. Man könnte sich an der stdlib orientieren, aber das würde ich nur machen, wenn man mir ne Knarre an den Kopf hält.

net schrieb:

Optimizer schrieb:

Jo, das ist ja auch sinnvoll. Sonst weiss ich ja nicht, ob Math.sqrt() jetzt eine statische Methode ist, oder ich eine Instanz mit dem Namen Math hab und die Methode nicht statisch ist. Hat aber auch nichts mit ungarischer Notation zu tun.

hat aber die gleiche wirkung. man steckt (teilweise) typinformationen o.ä. in die namen und wenn sich am typ, spezifizierer oder so irgendwas ändert sind alle namen für die katz.

Ne, eben nicht. Unter Typinformation verstehst du ja wohl genauso wie ich die Information, von welchem Typ ein Objekt ist. Wenn ich Math groß schreibe, dann ist Math ein Typ und nicht hat den Typ .... Hat also mit Typinformation nach dem Motto "iMyCounter ist ein int" gar nichts zu tun.
EDIT: ach, da war ja shade schon schneller.

Shade Of Mine

EnERgYzEr schrieb:

Nur solltet ihr bedenken, dass in der Praxis nicht unbedingt der schönste
OO-Code gewinnt. Es gibt nun mal auch lange Methoden, weil nicht jeder die
Zeit hat hunderte von Klassen/Methoden zu entwerfen, die diese eine Methode
aufsplitten.

Klar - aber hast du dann auch jedesmal Zeit refactoring zu betreiben wenn du short in int aenderst, oder statt double eine Klasse mit groesserer Genauigkeit nimmst?

Ganz ehrlich: wenn ich unter Zeitdruck arbeite, dann waeren solche Anpassung wohl das erste, was ich nicht machen wuerde

Aber vielleicht sehe ich das alles auch anders, weil ich beruflich PHP Programmiere - da gibt es nur dynamische Typen - der Typ einer Variablen ist somit nahezu immer vollstaendig uninteressant.

Gregor

Optimizer schrieb:

Man könnte sich an der stdlib orientieren, aber das würde ich nur machen, wenn man mir ne Knarre an den Kopf hält.

Ich würde das für das natürlichste halten, wenn man sonst keine Anhaltspunkte hat. Damit sorgt man immerhin für eine gewisse Konsistenz im Programm. Was spricht dagegen?

Sie ist mega-potthässlich.

- alles wird klein geschrieben, sogar Klassen
- Wortteile werden mit Unterstrich getrennt (my_vector.push_back())
- Parameter haben ein _ als Präfix
- getter heißen einfach z.B. size()
- Exceptions haben behinderte Namen (bad_alloc, logic_error)

Nene, da musst du mir sogar ne große Knarre an den Schädel halten, eine sehr große.

net 0

Shade Of Mine schrieb:

Aber ob ich einen Typen oder eine Variable habe - das ist ja sehr wohl wichtig. Vorallem weil sich das ja nicht aendern _kann_. Tier wird immer eine Klasse bleiben und kann sich niemals in eine Variable umwandeln.

ach ja? und was ist wenn es keine klasse 'Tier' gibt und man eine variable anlegt, die 'Tier' heisst? dann steht da: Tier.fuettern()
ist es nun ein aufruf einer statischen methode oder wird 'fuettern()' einer instanz aufgerufen?
also eine gewisser informationsgehalt in den namen und typen ist ok, aber eben nicht so exakt wie's bei der ungarischen notation gemacht wird.

Gregor

net schrieb:

und man eine variable anlegt, die 'Tier' heisst?

Wenn du die Code Conventions gelesen hättest, dann wüßtest du, dass Variablen in Java klein geschrieben werden.

Wir haben ja vorhin festgestellt, dass es zweckmäßig ist, Typen und Instanzen zu unterscheiden, z.B. durch Klassennamen mit großen Anfangsbuchstaben.

Außerdem hast du es immer noch nicht begriffen, wenn du eine Variable "Tier" oder "tier" nennst. Das erklärt null und absolut gar nicht, was für eine Aufgabe dieses Viech im Programm hat.
Namen wie "leittier", wobei die Variable ein Zeiger auf des momentane Leittier der Herde ist, wären ok.

net 0

Optimizer schrieb:

Namen wie "leittier", wobei die Variable ein Zeiger auf des momentane Leittier der Herde ist, wären ok.

ja, aber 'leittier' und nicht 'Leittier'
ich hab' das schon begriffen. wollte nur darauf hinweisen, dass es eine gewisse übereinstimmung mit der ungarischen notation gibt. eben dieses 'kennzeichnen' von variablennamen etc.

Nein, gibt es nicht. In der ungarischen Notation gibst du an, von welchem Typ deine Variable (deine Instanz!!) ist.
Das machst du hier nirgendwo. Das leittier kann vom Typ Elefant, Giraffe oder Zebra sein. Du weisst es nicht und es interessiert dich auch nicht.

Gregor

net schrieb:

ich hab' das schon begriffen. wollte nur darauf hinweisen, dass es eine gewisse übereinstimmung mit der ungarischen notation gibt. eben dieses 'kennzeichnen' von variablennamen etc.

Nein, es ist etwas anders. Es wird nicht gekennzeichnet, von welchem Typ eine Variable ist, sondern nur, dass es überhaupt eine Variable ist. Das ist im Vergleich zur ungarischen Notation auf einer vollkommen anderen Ebene.

net 0

Optimizer schrieb:

Nein, gibt es nicht. In der ungarischen Notation gibst du an, von welchem Typ deine Variable (deine Instanz!!) ist.
Das machst du hier nirgendwo. Das leittier kann vom Typ Elefant, Giraffe oder Zebra sein. Du weisst es nicht und es interessiert dich auch nicht.

Gregor schrieb:

Nein, es ist etwas anders. Es wird nicht gekennzeichnet, von welchem Typ eine Variable ist, sondern nur, dass es überhaupt eine Variable ist. Das ist im Vergleich zur ungarischen Notation auf einer vollkommen anderen Ebene.

naja, die kennzeichnung ist nur unschärfer
also:
ungarische notation -> exakter typ
java coding conventions -> klasse, objekt, konstante etc.

ich hoffe ihr versteht mich jetzt...