Eine kleine Umfrage: C/C++ the OOP way?

[Bashar]

Ist sowieso ein Troll, zu was soll dass denn führen, ausser dass sich ab Seite 3 ausgewählte Vertreter der "Lager" gegenseitig beharken?

[volkard]

Wan-Hi schrieb:

• Möglicht objekt-orientiert? (Also mit möglichst vielen Klassen, wie es Sinn macht, einem stark strukturiertem Programm Design und strikten Sichtbarkeitstrennungen.)
• Viele "globalen" Funktionen (C Style) und eine bunte Mischung aus structs, unions und Klassen?

ich verfolge:
-viel oo, aber nicht so blind und bedingungslos oo, wie java (mit sqrt in Math, damit es in ner klasse ist).
-viel strukturiert, aber nicht so blind und bedingungslos, wie die pascaller (mit forderungen wie sinke-entry/single-exit).
-sichtbarkeitstrennung? was ist das? also makros und globale variablen nehme ich ungern. meinste das?
-ganz wenige globale funktionen. auf 1000 klassen kommen cirka 50 globale funktionen (eigentlich immer nur, wenn die doofe lib moch dazu zwingt) (mal operatoren ausgenommen) (unter "global" vertehe ich auch die in namespaces aber außerhalb von klassen)
-structs nur als private structs innerhalb von klassen. beispiel am ende.
-unions eigentlich nie (evtl mal für ip-adressen).

class List{
   private:
   struct Node{
      ...
   };
   public:
   ...
};

[C++ Forumbot]

Dieser Thread wurde von Moderator/in HumeSikkins aus dem Forum C++ in das Forum Rund um die Programmierung verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

[volkard]

elise schrieb:

irgendwie gehört die frage nicht in das c++ forum, sondern nach rund um die programmierung, denn es ist eine viel allgemeinere frage.

klingt nach: prozedural versus oop.
hat für mich auch nichts mit c-style oder c++ style zu tun.

nein. im kontext des c++-forums ist es ne andere frage als im globalen kontext.

global fragte er damit "wie isses mit oo"?

lokal fragte er "wie isses mit oo in c++"?

und mit oo isses in c++ ganz anders als in perl, python, java, php und pascal. ganz anders.
die sprache steuert den stil, der sich zu entwickeln hat, um die sprache optimal zu benutzen. für c++ muß man zum beispiel sagen, daß

class Sqrt{
   double calc(double x){
      //some mathemagical code
      return result;
   }
}

schwachsinnig ist. der user würde eh antworten mit

#define SQRT(x) Sqrt().calc(x)

und in java kann er nicht antwoten, sondern muß glauben. in php und perl isses ne speed-frage.

[volkard]

Bashar schrieb:

Ist sowieso ein Troll, zu was soll dass denn führen, ausser dass sich ab Seite 3 ausgewählte Vertreter der "Lager" gegenseitig beharken?

hast du nie programmieren gelernt? als nube fragt man sich doch solche sachen. vor allem fragt man sich, wohin der eigene stil sich entwickeln sollte. wie stark sollte man nach oo gehen?
mal angenommen, es enstspänne sich ne diskussion (beharkung mit zwischengeworfenen argumenten, fakten, schlüssen, beweisen, statistiken oder anderen glaubhaftmachungen), könnte der nube doch daraus lernen, oder? also mir wäre damals sowas ne riesige hilfe gewesen.

[Blue-Tiger]

im Allgemeinen steckt bei mir (fast) alles in Klassen. Oft passierts mir z. B., dass 3 oder 4 Funktionen auf die gleichen Variablen zugreifen muessen, das endet dann meist in einer Klasse mit den Variablen als Membern und den Funktionen als Methoden

Absolut 100%ig globale Funktionen gibts nur ganz, ganz wenige. Namespaces verwende ich hoechstens zu Uebungszwecken, da meine Projekte bisher immer sehr klein waren, da seh ich das eher als Umstaendlich als Sinnvoll an

[Wan-Hi]

nix da schrieb:

Wan-Hi
Wenn Du was drauf haben willst, machst Du am Besten Dein eigenes Ding und läufst nicht der Mehrheit blind, wie ein reudiger Hund hinterher.

Vorallem würde ich so eine Frage nicht stellen, wenn Du so am Anfang bist mit dem Coding (siehe anderen Topic von Dir mit cout).

Nebenbei: Total falsches Forum

Ich will nicht der Mehrheit blind folgen. Es spricht aber einiges dafür, so früh wie möglich sich bestimmte Gewohnheiten anzueignen, wenn es später darum geht in einem Team zu arbeiten.

Zum Beispiel bin ich es von Java gewöhnt, alles nur Denkbare erst einmal fein zu modellieren und in Klassen zu stecken. Um Klassen kommt man in der Sprache ja eh nicht herum. Doch C/C++ ist da ja sehr viel freier. Wenn ich mich jetzt z.B. darauf einstelle, dem gleichen Trend mit der Modellierung von Klassen in C++ zu folgen, und später merke, daß es sehr viele Nachteile hat oder von allen zukünftigen Mitarbeitern als Ballast angesehen wird, wäre das sehr unbefriedigend, da ich gegen meinen Brauch gezwungen wäre, einem anderen Stil zu folgen. Daher auch die frühe Fragestellung.

Ob es im falschen Forum ist, darüber läßt sich streiten. Ich finde es schon sehr C++ spezifisch, weil ich hier doch speziell auf die Freiheiten von C++ eingehe.

[Helium]

Mal so am Rande: Neben oo und prozedural gibt es auch noch funktional und logisch, wobei ich von letzterem Paradigma gar keine Ahnung habe.

Globale Funktion findest du bei mir viele. Ich habe viele kleine Helferfunktionen. Und wenn es meiner Meinug nach nicht sinnvoll die Helferfunktion als Methode zu implementieren, wird es ne globale jedoch modullokale Funktion.

Allerdins experimentiere ich gerade viel mit funktionalen Dingen in C++. Ist nicht immer ganz einfach, aber manchmal lustig, was man mit freakigen Template- und Makro-Rumgetrickse alles halbwegs bequem hinbekommt. (Bit bequem ist die spätere Anwendung gemeint, nicht das Implementieren der Hilfsmittel).

[elise]

@volkard

für mich erklang die frage eher nach einer abstrakten, relativ unabhängig von c++ und c (beides waren nur beispiele..), aber das waren vielleicht auch nur meine ohren

[Helium]

Ich will nicht der Mehrheit blind folgen. Es spricht aber einiges dafür, so früh wie möglich sich bestimmte Gewohnheiten anzueignen, wenn es später darum geht in einem Team zu arbeiten.

Das sehen verschiedene Teams verschieden.

Zum Beispiel bin ich es von Java gewöhnt, alles nur Denkbare erst einmal fein zu modellieren und in Klassen zu stecken. Um Klassen kommt man in der Sprache ja eh nicht herum. Doch C/C++ ist da ja sehr viel freier.

Für Problemfälle, die sich gut OO modelieren lassen, kannst du weiterhin deine Java-artige Ansätze verfolgen. Reine Algorithmen, (einfaches Beispiel: Sortieren) lassen sich nicht gut modelieren. Es sind Vorgehensweisen, die recht unabhängig von konkreten Objekten sind. Die Objekte, die Sortiert werden sollen, müssen ordbar sein, aber das Sortieren an sich kann man schlecht als Objekt manifestieren.
Hier ist ein Prozeduraler oder funktionaler Ansatz sicherlich sinnvoller.

[Wan-Hi]

volkard schrieb:

...

class Sqrt{
   double calc(double x){
      //some mathemagical code
      return result;
   }
}

...

#define SQRT(x) Sqrt().calc(x)

...

Also, ich hätte intuitiv eher auf einen direkten Zugriff einer Klassenfunktion nach dem ersten Muster zurückgegriffen, als auf ein Makro per define. Defines empfinde ich eher als Verwässerung der Syntax, konstante Werte einmal ausgeschlossen, da sie eigentlich doch nur eine Anweisung an den Preprozessor darstellen, die verkürzte Schreibweise mit dem richtigen Inhalt auszuwechseln. Oder habe ich was verrafft? :p

[Shade Of Mine]

Blue-Tiger schrieb:

im Allgemeinen steckt bei mir (fast) alles in Klassen. Oft passierts mir z. B., dass 3 oder 4 Funktionen auf die gleichen Variablen zugreifen muessen, das endet dann meist in einer Klasse mit den Variablen als Membern und den Funktionen als Methoden

halte ich für fragwürdig.

denn ergibt das dann auch ein Objekt?
oder ist es dann sowas:

Hash h;
h.do_hash("abc");
return h.value();

[rüdiger]

Ich benutze sehr viele Klassen und arbeite sehr OO. Aber ich habe auch einige kleinere Hilfsfunktionen.

[operator void]

"One class - one responsibility" ist IMHO schon mal ein sehr guter Anfang.
Ich habe z.B. eine Bitmap-Klasse, die wirklich nur setPixel, getPixel, width, height, resize und zwei Hilfsfunktionen (fill und replace) anbietet. Die Zugriffe auf die internen Daten sind damit auf ein Minimum eingedämmt. Alles weitere (drawText, loadFromBMP, saveToPNG usw. etc.) sind freie Funktionen. Das finden manche Ruby-Coder dann zwar total anti-OO, weil man beim Aufrufen keinen .-Operator braucht, aber IMHO gehört zu guter OO nicht nur die schicke Syntax, sondern auch Kapselung und klare Aufgabenverteilung. (Anderes Beispiel dafür wären die STL-Container und -Algorithmen.)

Ich bin also dafür, sich klar zu machen, dass freie Funktionen nicht beißen

[Shade Of Mine]

operator void schrieb:

Alles weitere (drawText, loadFromBMP, saveToPNG usw. etc.) sind freie Funktionen. Das finden manche Ruby-Coder dann zwar total anti-OO, weil man beim Aufrufen keinen .-Operator braucht, aber IMHO gehört zu guter OO nicht nur die schicke Syntax, sondern auch Kapselung und klare Aufgabenverteilung. (Anderes Beispiel dafür wären die STL-Container und -Algorithmen.)

Ich bin also dafür, sich klar zu machen, dass freie Funktionen nicht beißen

Full ACK

[volkard]

operator void schrieb:

"One class - one responsibility" ist IMHO schon mal ein sehr guter Anfang.

jo.

Ich habe z.B. eine Bitmap-Klasse, die wirklich nur setPixel, getPixel, width, height, resize und zwei Hilfsfunktionen (fill und replace) anbietet. Die Zugriffe auf die internen Daten sind damit auf ein Minimum eingedämmt.

sehr fein. das machen die wenigsten und kommen dann mit klassen an, die niemals zu kapieren sind (und niemals zu heilen, falls sich doch ein designfehler eingeschlichen hat, was man nie wirklich vermeiden kann).

Alles weitere (drawText, loadFromBMP, saveToPNG usw. etc.) sind freie Funktionen.

überhaupt gar kein ack. loadFromBMP klingt für mich stark danach, als sollte das ein ctor sein. ich zeige mal ein paar fehlerhafte implementierungen (weiß ja nicht, welche du gewählt hast):

//mit leerem default-ctor
Bitmap b;//uninitialisiert, dangerous
loadFromBmp(b,"test.bmp");//referenz zweckentfremdet
//by throw in laodFromBotmap ein abkacker, weil b nicht löschbar

der leere default-ctor ist einfach zu gefährlich. sagen wir mal, der verbietet sich.

//mit default-ctor, der objekt löschbar macht
Bitmap b;//zeitverschwendung
loadFromBmp(&b,"test.bmp");//ok

die zeitverschwendung, b erst löschbar zu machen und dann doch was anderes reinzumachen, ist doch doof. sagen wir mal, die verbietet sich, weil wir auch sehr schnellen code haben wollen (deshalb verbieten sich für mich ja auch pimpl und rimpl).

Bitmap *b=loadFromBmp("test.bmp");//zeitverschwendung

offensichtlich passiert ein new in loadBitmap, aber das ist ein new, das ich nicht brauche.

ich frage mich, wie du es irgendwie performant und halbwegs ehrenhaft hinkriegen magst mit deinen globalen funktionen.

Bitmap b("test.bmp");//bitmap kann zu viel, sonst aber perfekt.

FileBitmap b("test.bmp");//ok, thema ist durch

Das finden manche Ruby-Coder dann zwar total anti-OO, weil man beim Aufrufen keinen .-Operator braucht, aber IMHO gehört zu guter OO nicht nur die schicke Syntax, sondern auch Kapselung und klare Aufgabenverteilung. (Anderes Beispiel dafür wären die STL-Container und -Algorithmen.)

ja, es ist ne gute einsicht, wenn man kapiert, daß fopen, fclose fget und die ganzen c-sachen, die ein FILE-objekt benutzen, sauber und gut oo sind.
die stl-algos sind es weniger, aber algos rufen auch nicht immer danach, oo zu sein.

Ich bin also dafür, sich klar zu machen, dass freie Funktionen nicht beißen

freie konstruktoren beißen aber. ätsch.

[otze]

pimpl? rimpl? hör ich heute zum 1. mal...is das pointer implement und reference implement?

"One class - one responsibility" ist IMHO schon mal ein sehr guter Anfang.

mit anderen worten: versuch nie eine Klasse zu schaffen, die objekte effizient verwaltet, und gleichzeitig spezielle funktionen für diese objekte bietet?

[volkard]

otze schrieb:

pimpl? rimpl? hör ich heute zum 1. mal...is das pointer implement und reference implement?

pointer to implemetation. jo.
"pimpl-idiom" oder "pimpl" ist eines von herb sutters lieblingsworten. siehe lektion 26ff aus exceptions c++". rimpl gibts nur während der laufzeit dieses threads, hofe ich.

mit anderen worten: versuch nie eine Klasse zu schaffen, die objekte effizient verwaltet, und gleichzeitig spezielle funktionen für diese objekte bietet?

unter anderem auch das. eigentlich eher "versuch nie eine Klasse zu schaffen, die effizente objektverwaltung implementiert , und gleichzeitig spezielle funktionen für diese objekte implementiert"
natürlich kann die eine klasse das eine implemetieren, die andere klasse das andere und dazu das eine benutzen. und sogar manchmal das eine öffentlich zur verfügung stellen. dann kann die klasse das eine und das andere. zum beispiel effizient objekte verwalten und spezielle funktionen anbieten.

[otze]

volkard schrieb:

otze schrieb:

pimpl? rimpl? hör ich heute zum 1. mal...is das pointer implement und reference implement?

pointer to implemetation. jo.
"pimpl-idiom" oder "pimpl" ist eines von herb sutters lieblingsworten. siehe lektion 26ff aus exceptions c++". rimpl gibts nur während der laufzeit dieses threads, hofe ich.

kann man sich das buch legal downloaden, oder muss das wie der struppi und der standard auch auf meine liste der lesenswerten Bücher? [exceptions c++=exceptional c++?]

mit anderen worten: versuch nie eine Klasse zu schaffen, die objekte effizient verwaltet, und gleichzeitig spezielle funktionen für diese objekte bietet?

unter anderem auch das. eigentlich eher "versuch nie eine Klasse zu schaffen, die effizente objektverwaltung implementiert , und gleichzeitig spezielle funktionen für diese objekte implementiert"
natürlich kann die eine klasse das eine implemetieren, die andere klasse das andere und dazu das eine benutzen. und sogar manchmal das eine öffentlich zur verfügung stellen. dann kann die klasse das eine und das andere. zum beispiel effizient objekte verwalten und spezielle funktionen anbieten.

1.wieder was gelernt
2. jetzt weis ich, wieso ich mit meiner letzten schandtat nich zufrieden bin^^

[rüdiger]

kann man sich das buch legal downloaden, oder muss das wie der struppi und der standard auch auf meine liste der lesenswerten Bücher? [exceptions c++=exceptional c++?]

ne, musst du kaufen. Aber lohnt sich definitiv.

btw. den Standard lesen, lohnt sich nicht wirklich. Den kannst du zum nachschlagen benutzen, wenn du mal im C++ Forum oder im Usenet den Obermaker raushängen lassen willst