C+ statt C++

nman

Äh...
Ja, ganze 8 Zeichen (private:) schwieriger. :p

// struct mit privaten Membervariablen:
struct foo
{
private:
    T bar;
};

// aequivalente Klasse:
class foo
{
    T bar;
};

Im Ernst: structs SIND tatsächlich äquivalent zu Klassen, mal von dieser Kleinigkeit mit private/ public abgesehen.

Artchi

struct und class sind das gleich... wird auch beim compilieren gleich behandelt. Es gibt also theoretisch keinen Unterschied. Allerdings macht man bei einem struct deutlich "Hey, hier handelt es sich um eine reine Datenstruktur, der ich gerne nur public-Members zur Verfügung stellen will!" Wenn ich keine reine Datenstruktr haben will, nehme ich ein class.

Es ist eine reine Design-Frage und was ich damit "Aussagen" will.

@nman
also das die gleich sind wage ich zu bezweifeln bis ich nicht ASM code von den beiden beispielen gesehen habe
Erst ab dann kann man sagen sie seien "äquivalent"

Bashar

*** schrieb:

also das die gleich sind wage ich zu bezweifeln bis ich nicht ASM code von den beiden beispielen gesehen habe
Erst ab dann kann man sagen sie seien "äquivalent"

Du wirst nicht den Assemblercode davon zu sehen bekommen, weil es den nicht gibt. Die beiden Konstrukte sind äquivalent, weil der C++ Standard das so definiert, Punkt. Wenn irgendein Compiler dafür unterschiedlichen Code generiert, ist das sein Problem.

Shlo

gh0st124 schrieb:

Shlo schrieb:

gh0st124 schrieb:

Klassen sind wie Strukturen, können aber einiges mehr...

zum Beispiel?

o Methoden aufnehmen;
o Einzelne Elemente verstecken (Zugriffsspezifikationen a la private - public - protected;

ich würde dir ganz dringend raten ein gutes C++ Buch zur Hand zu nehmen und es auch zu lesen

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.

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.