C+ statt C++

Shade Of Mine

Helium schrieb:

Die Reihenfolge innerhalb eines Sichtbarkeitsbereiches (public, private, protected) schon.

Hat das eigentlich irgend einen tieferen Sinn?

Ich nehme an, es kommt von den C structs, denn dort war es ja wichtig...
Um ehrlich zu sein, sehe ich aber, ausser bei den C structs den Sinn auch nicht.

Bashar

Wo ist denn bei C-structs der tiefere Sinn?

also ich muss ja mal sagen: wer stucts wie klassen benutzt ist pervers !
natürlich kann man structs wie klassen verwenden. man kann alle möglichen sachen missbrauchen, aber es geht nun einmal um die grundlegende eigenschaft der programmkapslung.

rüdiger

warum pervers? Das ist eben deine Vorstellung von structs. Aber ich sehe keinen logischen Grund darin. ich mach das immer so, dass ich structs nehme, wenn ich erst public Member einrichten musst (zB. enum-Konstanten). Warum sollte ich dann erst class schreiben um dann ein public einzufügen?

klassen sind nunmal klassen und structs sind structs und das sollten sie auch bleiben. wenn jemand deine programme liest und sieht, dass du structs benutzt, wird er zunächst davon ausgehen, dass es ein struct im C-sinn ist. ich versteh eh nicht warum man structs so "aufgemotzt" hat.

es gibt aber notationen an die man sich auch halbwegs halten sollte. ich habe (viel) früher auch mal unterstriche und für andere scheinbar sinnlose regeln benutzt um meine funktionen, variablen & co zu benennen und habe es als "meinen programmierstil" bezeichnet, aber solche einzelaktionen helfen im endeffekt niemandem.

Knuddlbaer

Das hängt davon ab ob dieser Programmierer viel C gemacht hat. Er könnte auch mit C++ groß geworden sein oder von einer anderen Sprache her kommen.

Structs sind eine feine sache wenns um Ansammlung von Variablen geht (wie in C) oder um Funktoren etc. zu schreiben.
Also kleine,einfache Funktionalitäten abbilden.

rüdiger

komischer kautz schrieb:

klassen sind nunmal klassen und structs sind structs und das sollten sie auch bleiben. wenn jemand deine programme liest und sieht, dass du structs benutzt, wird er zunächst davon ausgehen, dass es ein struct im C-sinn ist. ich versteh eh nicht warum man structs so "aufgemotzt" hat.

Einige Leute neigen dazu die eigenen Eindrücke auf andere Menschen zu übertragen. Wie ich bereits sagte, dir gefällt es nicht und du hast damit wohl Probleme. Aber deswegen muss man keine allgemein gültige Moral darauf aufbauen.

Jester

Können wir uns also darauf einigen, daß das benutzen zweier verschiedener Schlüsselwörter für denselben Zwecke(Klasse definieren) und unter der Voraussetzung, daß die beiden für gewöhnlich eine unterschiedliche Absicht Wiederspiegeln(struct - POD, class - Klasse) irreführend und damit bescheuert ist?

MfG Jester

Jester schrieb:

Können wir uns also darauf einigen, daß das benutzen zweier verschiedener Schlüsselwörter für denselben Zwecke [...] irreführend und damit bescheuert ist?

JAAAAAAAAA !!!

@kingruedi:

ich programmiere nun schon lange genug um damit keine probleme zu haben, aber anderen geht das bestimmt so. und es ist nunmal eine allgemeingültige moral, die habe ich nicht erfunden, aber es gibt sie und man sollte sich weitgehend daran halten.

Helium

Cool, ein Streit über den PErsönlichen Geschmack. Das wir wieder interessant.

Ich verwende struct eigentlich nur für PODs und Functoren.

Jester

Ich denke nicht, daß das eine Frage des Geschmacks ist, sondern eher eine Frage des guten Stils.

Okay, wer schlechten Stil mag... aber dem ist eh nicht zu helfen.

rüdiger

Der Stil ist aber subjektiv, genauso wie gut und böse subjektiv sind :p

(deswegen finde ich Programmier-Stil Diskussionen immer so dämlich, weil man nicht wirklich auf eine rational begründete Lösung kommt)

Jester

naja, weiter oben habe ich einen (meiner Ansicht nach guten) Grund genannt, die beiden nicht zu mischen.

Shade Of Mine

Jester schrieb:

naja, weiter oben habe ich einen (meiner Ansicht nach guten)
Grund genannt, die beiden nicht zu mischen.

weil du nicht genau liest!

Niemand würde

struct string;

schreiben, denn string ist eine 'echte' Klasse.
Aber zB

struct NoInherit {};

struct DoInherit
{
  virtual void foo()=0;
};

Hier wäre es bei NoInherit egal ob ich class oder struct schreibe, aber bei DoInherit gibt es keine private Member. Wozu also class?

Ich nehme struct eigentlich immer wenn es keine privaten Member gibt. Was soll daran schlechter Stil sein? Solange ich es immer so mache, gibt es auch keine zweideutigkeiten oder verwirrende Situationen.

Shade Of Mine schrieb:

Ich nehme struct eigentlich immer wenn es keine privaten Member gibt. Was soll daran schlechter Stil sein? Solange ich es immer so mache, gibt es auch keine zweideutigkeiten oder verwirrende Situationen.

es ist schlechter stil, weil stucts nicht dafür gemacht wurden. natürlich ist konsistenz im code auch wichtig, aber allgemeine notationen sind wichtiger. wieso sollte man an ein auto flügel bauen, wenn's nicht schon flugzeuge gibt? wo ist denn da das problem, für 'echte' klassen (und das ist nunmal alles, was über die funktionalität eines structs (im c-sinn) hinausgeht) auch class zu benutzen? klingt doch logisch, oder ?

Die Diskussion um struct und class ist kindisch.

Hier noch mal ein konkretes Beispiel für "virtual":

#include <iostream>
using namespace std;

class Person
{
  public:
    /*virtual*/ void geldueberweisung(float geld){ cout << geld << " an Person " << endl; };
};

class Mitarbeiter : public Person
{
  public:
    void geldueberweisung(float geld){ cout << geld << " an Mitarbeiter " << endl; };
};

class Kunde : public Person
{
  public:
    void geldueberweisung(float geld){ cout << geld << " an Kunde " << endl; };
};

class Lieferant : public Person
{
  public:
    void geldueberweisung(float geld){ cout << geld << " an Lieferant " << endl;};
};

void zahlung(Person * x, float Summe)
{
    x->geldueberweisung(Summe);
}

int main()
{
    Lieferant a;
    Kunde b;
    Mitarbeiter c,d;

    zahlung( &a, 500 );
    zahlung( &b, 300 );
    zahlung( &c, 250 );
    zahlung( &d, 170 );
}

Marc++us

Ich sehe das genauso wie der komische kautz - warum in alles in der Welt benutzt man das Schlüsselwort "struct", wenn man eine Klasse (engl.: class) meint? Kann ich nicht nachvollziehen.

Das Argument mit der Ersparnis einiger Zeichen ist irrelevant, wir (damit meine ich die Programmierergemeinde) haben uns schließlich doch inzwischen darauf geeinigt, daß Lesbarkeit vor Kürze geht. Tippfaulheit ist niemals ein Argument für eine Schreibung, sonst können wir die Variablen gleich wieder a,b,c,d nennen - ist doch kürzer.

Und genau da kommt meine Abneigung gegen structs mit "Klassenverhalten" - es verletzt die Erwartungskonformität des Lesers. Auch wenn struct und class austauschbar sind, so assoziiert man struct eher mit POD und class mit Klassen. 98% der C++-Programmierer wissen wahrscheinlich nicht mal, daß es diese Gemeinsamkeit gibt. Warum in alles in der Welt soll man also hier zusätzliche Verwirrung beim Leser erzeugen? Der einzige bewirkte Effekt ist, daß man damit zeigt den Standard besser zu kennen als andere Code-Leser.

Shade Of Mine

Marc++us schrieb:

Und genau da kommt meine Abneigung gegen structs mit "Klassenverhalten" - es verletzt die Erwartungskonformität des Lesers. Auch wenn struct und class austauschbar sind, so assoziiert man struct eher mit POD und class mit Klassen.

meine structs haben kein Klassenverhalten im eigentlichen Sinne - denn man kann sie allesamt nicht instanziieren, bzw. sind es leere Klassen.

Ich habe schon oft gesehen dass Leute struct für functoren verwenden - weil sie eben keine Klassen darstellen. Und ein interface ist IMHO auch keine Klasse - dies drücke ich durch struct aus.

vielleicht wäre ein #define interface struct passender

Sobald man es wie eine Klasse verwendet, also intanziiert, Methoden aufruft,... ist es auch bei mir eine class.

Nur wo liegt euer Problem? Solange es konsistent verwendet wird kann man ja auch Ungarische Notation verwenden Ich meine damit: wenn der Stil logisch aufgebaut ist und konsequent durchgezogen wird, spricht doch nichts dagegen, oder?

Jester

@Shade: Inwiefern lese ich nicht genau?

Ansonsten denke ich wir sind uns da einig, Du nimmst das Schlüsselwort je nachdem welches Verhalten Du modellierst. Ehrlich gesagt hatte ich solche Interface-Klassen nicht bedacht, da würde ich wirklich sagen es handelt sich um eine Geschmacksfrage, wobei das mit dem #define interface struct keine schlechte Idee ist.
Aber kingruedi sagt er nimmt das je nachdem ob er erst was privates oder was öffentliches deklariert struct oder class. Und das ist meiner Meinung nach ein sehr schlechtes Kriterium.

MfG Jester

@shade:

ich geb's auf.