Klasse für Bruchzahlen gesucht

Ingo

Das war mein Fehler. Ich meinte dein Posting auf meine Klasse.

Optimizer schrieb:

Hilfe! m_
Ein klein geschriebener Klassenname.
Wieso ist ggT nicht statisch, wenn es doch die beiden Zahlen kriegt?
Wieso kriegt kuerzen() die beiden Zahlen, wenn es nicht statisch ist?

Du meinst wohl das.

Also erstens finde ich es hässlich und unnötig, Member mit m_ zu kennzeichnen. Es ist eine ziemliche Unsitte, im Variablennamen zu kennzeichnen, was für ein Typ etwas ist, anstatt zu kennzeichnen, wofür das Ding da ist und welche Aufgabe es erfüllt.
Ein einfaches num und denom (als Beispiel) würde völlig reichen.

Desweiteren sollte man Klassennamen IMHO groß schreiben. Ich kann mir jetzt natürlich herausnehmen, zu sagen, meine Konvention sei die einzig wahre, aber in diesem Punkt sind die meisten Leute der Meinung, dass Klassennamen groß geschrieben werden sollten.

Die Funktion ggT() kriegt zähler und nenner geliefert, also kann sie gleich statisch sein, weil sie sich überhaupt nicht auf den eigenen Bruch (this) bezieht.

Das selbe gilt für kürzen(). Wobei ich persönlich beide nicht statisch machen würde, aber dafür auch keine Parameter übernehmen würde. Die Werte können sie dann selber auslesen. Auf jeden Fall ist nicht-statisch und Parameter doppelt gemoppelt.

Außerdem bin ich der Meinung, dass beide Methoden private sein sollten. Ein Bruch kann sich selber kürzen, das muss von außen keiner anschaffen.

Erhard Henkes

Wie findet ihr eigentlich boost::rational ? (so gut wie Standard)

Ingo

Du magst in allen Punkten Recht haben. Hier einige Anmerkungen von mir dazu:

Die Sitte, Member mit m_ zu kennzeichnen, habe ich dem Buch des Seitenbetreibers hier entnommen. Ich finde das nicht schlecht, weil ich damit selbst einen besseren Überblick über private- und public-Variablen habe.

Ich habe den Klassennamen klein geschrieben, weil die Klassen string und vector etc. auch klein geschrieben sind. In das Buch des Seitenbetreibers will ich an dieser Stelle wegen der fortgeschrittenen Stunde nicht gucken, mag aber gut sein, dass er es anders hält

Das mit dem statisch hab ich nicht so ganz geschnallt (Achtung, für dummies langsam sprechen).

ggt und kürzen sind doch private. Oder seh ich den Wald vor lauter Bäumen nicht mehr ...?

Gez geh ich schlafen, gute N8.

FinalBlackout

1. public-Variablen dürftest du eigentlich ÜBERHAUPT keine haben o.O
2. wenn du Funktionen in einer Klasse mit static auszeichest, dann bedeutet das, dass diese Funktion nicht mehr auf den Werten eines bestimmten Objektes operiert. Das heißt, du hast keinen this-Zeiger mehr zur verfügung, weil statische Funktionen an kein Objekt gebunden sind. Guckst du einfach mal in ein Buch, dass kann das bestimtm besser erklären, als ich.

Erhard Henkes

Das läuft wie folgt:
Member mit m_ kommt von MFC. :p
MFC ist schlechtes C++.
m_ ist schlecht für C++.

Zur Zeit ist dataelement_ (nachgestellter Underscore) in.
Argument Herb Sutter: "Since I'm no longer allowed to use leading underscores as my "member variable" tag, I'll now use trailing underscores!" (s.u.)
Auch nicht gerade überzeugend, wie er argumentiert.

Meine Meinung:
Alles ist irgendwie brauchbar und gleichzeitig beknackt.
(Ausnahme: voran gestellter Underscore)
siehe: http://www.gotw.ca/gotw/004.htm

11. Style: Try to avoid names with leading underscores. Yes, I've habitually used them, and yes, popular books like "Design Patterns" (Gamma et al) do use it... but the standard reserves some leading-underscore identifiers for the implementation and the rules are hard enough to remember (for you and for compiler writers!) that you might as well avoid this in new code. (Since I'm no longer allowed to use leading underscores as my "member variable" tag, I'll now use trailing underscores!)

Es will mir nicht in den Kopf, warum private Member überhaupt gekennzeichnet werden müssen?!

Erhard Henkes

Man möchte oft den gleichen Namen für die Membervariable wie auch eine als Parameter übergebene Variable benutzen (z.B. in einer Initialisierungsliste). Man kann zur Unterscheidung den Zeiger this vorstellen, aber elegant ist das wirklich nicht.

Hier ein kleiner Ausschnitt aus einer Klasse MyString:

class MyString
{
public:
  MyString(char* pText=NULL);                  // ctor 
  MyString(const MyString& str);               // Copy-Konstruktor
  MyString& operator=(const MyString& str);    // Zuweisungsoperator
  ~MyString();                                 // dtor 
//...

private:
  char* pText_;
};

MyString::MyString(char* pText)
{
  if (pText)
  {
    pText_ = new char[ strlen(pText+1) ];
    strcpy(pText_, pText);
  }
  else
  {
    pText_ = new char[1];
    *pText_='\0';
  }
}

Man hat die Membervariable pText_ und einen Parameter pText. Man kann sich hier streiten, ob m_pText und pText nicht eine klarer erkennbarere Unterscheidung bringen. Geschmacksache.

Ich finde this-> eigentlich ziemlich elegant, vor allem, weil man es sehr selten braucht. Meistens kann man das wunderbar über die Initialisierungsliste lösen.

Foo::Foo(int foo) : foo(foo) {}

Erhard Henkes

Foo::Foo(int foo) : foo_(foo) {}

... gefällt mir zur Unterscheidung doch noch besser.
In dem MyString-Beispiel würdest du also lieber this->pText und pText einsetzen?
Falsch ist dies nicht, nur unüblich. Das Thema wurde bereits oft diskutiert, auch ob man get und set vorstellen oder weglassen sollte. Da muss jeder seinen eigenen Weg finden. Wichtig ist allerdings, dass man diesen dann auch durchhält.

get und set schreib ich sowieso, wobei ich versuche, statt setColor() färbe() oder sowas anzubieten. Im CTor schreib ich halt manchmal this. find ich besser als _.
Ich verstehe diese Hässlichkeit eh nicht. Da ist es ja noch schöner, itsAge, oder myAge zu schreiben.

Erhard Henkes

Dir scheint der Underscore in Bezeichnungen nicht zu gefallen, das ist o.k., aber irgendwie unterscheiden sollte man, um nicht verschiedene Namen für das Gleiche verwenden zu müssen. Das ist aber nur meine Meinung. Bei Scott Meyers findet man z.B. folgende Klasse:

// a poorly designed String class
class String {
public:
  String(const char *value);
  ~String();
  ...                           // no copy ctor or operator=
private:
  char *data;
};

String::String(const char *value)
{
  if (value) 
  {
    data = new char[strlen(value) + 1];
    strcpy(data, value);
  }
  else 
  {
    data = new char[1];
    *data = '\0';
  }
}

Er bevorzugt data und value (also 2 Bezeichnungen) und mag hier auch kein p zur Kennzeichnung eines Zeigers.

Du hast die freie Auswahl!

Ja gut, das ist natürlich immer die eleganteste Lösung, zwei gleiche Namen zu vermeiden.

EDIT: Achso, das gefällt dir ja gerade nicht. Na was solls.

Erhard Henkes

Wie gesagt, du musst es durchhalten. Deshalb solltest du dir klar werden, was dir oder deinem Team wichtig ist. Ein allgemeines Vorbild gibt es selbst bei den Gurus nicht. Da prägt wahrscheinlich jeder bewusst seinen eigenen Stil.

volkard

Optimizer schrieb:

Ich verstehe diese Hässlichkeit eh nicht. Da ist es ja noch schöner, itsAge, oder myAge zu schreiben.

aber ich. es liegt an "nur bittere medicin ist gut".
schüler lernen nur dann gut, wenn sie leiden.
und stil ist nur dann gut, wenn man drunter leidet.

ist zwar unfug, geht aber aus den hirnen der hirnies nicht raus. also litten wir sinnloserweise unter un und struktogrammen und leiden sinnloserweise unter unterstrichen und uml und werden auch für alle zeiten immer wieder etwas finden, worunter wir leiden können.