C+ statt C++

tobidope

Optimizer schrieb:

Es gibt sowieso keinen Assembler-Code für "Strukturen" oder "Klassen", weil das Ganze eine reine Vorstellungssache ist.
Soweit ich weiss, ist lediglich vorgeschrieben, wie die Elemente im Speicher zu liegen haben und mehr nicht. Die Methoden haben genau genommen nach dem Compilieren auch nichts mehr mit den Daten selber zu tun, bzw. gehören nicht zu den Daten, wie es so schön dargestellt wird.

Es ist sogar noch nicht mal vorgeschrieben, wie die Elememnte im Speicher vorliegen. Stichwort alignment!

Shade Of Mine

tobidope schrieb:

Es ist sogar noch nicht mal vorgeschrieben, wie die Elememnte im Speicher vorliegen. Stichwort alignment!

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

Helium

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

Hat das eigentlich irgend einen tieferen Sinn?

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.