Was ist toll an size_t?
-
Jo. size wär ein bisschen nervig, weil jede zweite size_t Variable size heißt
-
SideWinder schrieb:
1. Doch ich schreibe "unsigned long int" und nicht "unsigned long"
Naja, deinen Programmierstil kann man sowieso nicht ernstnehmen. Du klammerst das return-Argument obwohl es sich bei return nicht um eine Funktion handelt, du verwendest const Value-Parameter, du schreibst unsigned long int usw.
Btw:
<: ist ein Digraph. Wenn du also einen Vector von ::std::irgendwas anlegen willst, musst du ein Leerzeichen zwischen der spitzen Klammer und dem ersten Doppelpunkt machen.
-
Bashar schrieb:
Jo. size wär ein bisschen nervig, weil jede zweite size_t Variable size heißt
Das Problem sehe ich nicht. Man hat ja auch kein string_t oder so, obwohl es hier wohl ein ähnliches Problem gibt.
-
@Hume: const value mach ich nicht mehr. Was ist so schlimm an return in Klammern? Und was ist daran so schlimm wenn ich mich klar und deutlich mit unsigend long int ausdrücke?
MfG SideWinder
-
@Gregor die Entscheidung _t als Postfix zu nehmen wurde in C getroffen, da gab es keine Namespaces und C++ hat das dann eben übernommen.
Aber wie gesagt, um die Namensproblematik zu vermeiden, gibt es ja viele Lösungen (so wie Klassennamen am Anfang groß schreiben etc.)
@SideWinder nichts, aber es ist nicht üblich. Übrigens ist unsigned und unsigned long genauso eindeutig
-
Aber wie gesagt, um die Namensproblematik zu vermeiden, gibt es ja viele Lösungen (so wie Klassennamen am Anfang groß schreiben etc.)
Der Struppi gebraucht die shift-Taste leider nur zum Unterstrich eingeben.
-
@kingruedi:
HumeSikkins schrieb:
Naja, deinen Programmierstil kann man sowieso nicht ernstnehmen.
Darunter verstehe ich nicht "unüblich" sondern "zu dumm". Da ist es schonmal Stilsache, und dann kann man bestimmte Stile erst gar nicht ernstnehmen
MfG SideWinder
-
Soweit ich das überblickt habe, benutzt Marc++us in seinem Buch auch nicht immer stringent size_t.
-
SideWinder schrieb:
Darunter verstehe ich nicht "unüblich" sondern "zu dumm". Da ist es schonmal Stilsache, und dann kann man bestimmte Stile erst gar nicht ernstnehmen
naja, ungarische Notation kann man ja auch nicht ernst nehmen. Oder ein C vor dem Klassennamen. Oder ein unsigned long int. Macht alles keinen Sinn.
Wobei ein
const unsigned short int twice(const unsigned short int param) { return(param*2); }irgendwie lustig ist.
Ungarische Notation wäre zB nur traurig.Es ist schön wenn du dich konsequent an einen Stil hältst - aber warum schreibst du denn gerne soviel? Und andererseits ist dir size_t wieder zu umständlich zu schreiben...
-
Shade Of Mine schrieb:
Ungarische Notation wäre zB nur traurig.
meinste? ich verwende es zwar auch nicht aber ganz sinnlos ist das nicht. die variablen haben im extremfall dann zwar blöde namen (z.b. rgrgrgszDerName) aber was solls.
-
aber was solls
Soll das der Grund sein, warum sie doch nicht schlecht ist`? :p
-
rófl. was für ne tolle aussage von net.
-
net schrieb:
Shade Of Mine schrieb:
Ungarische Notation wäre zB nur traurig.
meinste?
Jo, mein ich.
Wenn man OO Programmiert, dann macht ungarisch einfach keinen Sinn.
-
Shade Of Mine schrieb:
Wenn man OO Programmiert, dann macht ungarisch einfach keinen Sinn.
Warum wird hier so oft OOP angeführt, wo ihr doch alle von C++ kommt, was eine Multiparadigmensprache ist. Spielen andere Programmierparadigmen auch in C++ nur eine sehr untergeordnete Rolle?
(das soll natürlich keine Verteidigung der ungarischen Notation sein)
-
Shade Of Mine schrieb:
net schrieb:
Shade Of Mine schrieb:
Ungarische Notation wäre zB nur traurig.
meinste?
Jo, mein ich.
Wenn man OO Programmiert, dann macht ungarisch einfach keinen Sinn.das versteh ich nicht. in vielen oo-programmen taucht auch mal ein primitiver datentyp auf. ausserdem kann man den objekten mit 'erweiterter' ungarischer notation ja auch schicke namen geben z.b. man hat autos und fernseher dann könnte man die objekte 'carFerrari' und 'tvSony' nennen. ist doch cool eh?
-
Nein, ist es nicht.
-
Klasseninstanzen sollen einen Namen haben, der ihre Bedeutung im Programm erklärt und nicht erklärt, von was für einem Typ sie sind.
-
Optimizer schrieb:
Klasseninstanzen sollen einen Namen haben, der ihre Bedeutung im Programm erklärt und nicht erklärt, von was für einem Typ sie sind.
tja, da sieht man's mal - ich bin halt nur ein einfacher c-coder und hab' mit oop nicht so viel am hut
-
Aber net hat Recht, was die primitiven Datentypen angeht. Ich sehe keinen
Vorteil darin, mir den Code unübersichtlicher zu machen.Wo ist der Nachteil von:
int iObjectID??
Für eine Zahl muss ich keine Klasse ObjectID entwerfen - das wäre theoretischer
Bullshit. Hier muss die Praxisrelevanz vorgehen. Schließlich enthält C++ ja
auch noch die Standarddatentypen, oder? Und diese sind auch nicht (wie in
anderen Sprachen) als Klassen designt.Und bei primitiven Datentypen macht die ungarische Notation Sinn.
Wer _vernünftige_ Argumente hat, darf mich einen besseren belehren.
Bobby Womack - California Dreamin' hören tu *ggg* - Was kanns schöneres am
Abend geben// Edit: Präfixe für Klassen sind Müll, da stimme ich mit euch überein - man denke
an das "C" aus der MFC... Dadurch meint jeder Anfänger seine Klasse CFoo nennen
zu müssen
// Edit2: auch das m_ macht IMHO Sinn
-
EnERgYzEr schrieb:
Und bei primitiven Datentypen macht die ungarische Notation Sinn.
Begründung?? Komm erstmal du mit vernünftigen Argumenten.
Mir ist es lieber, wenn ich eine Variable sehe und anhand des Namens erkenne, "aha die Variable ist dafür da, das heisst sie enthält den Wert, den ich für des und des brauche." Mich interessiert das NULL, von welchem Typ sie ist.
Dann ist sie halt vom Typ int. Wenn ich die Programmlogik gerade verstehen will, ist mir das egal. Wird schon seinen Grund haben, warum es nicht double ist. Das wichtigste ist erstmal, dass ich weiss wofür diese Variable überhaupt gut ist. Wenn ich mir danach unbedingt einbilde, den Typ wissen zu müssen, dann fahre ich mit der Maus darüber.