Struct in Vector speichern

volkard

It0101 schrieb:

Echt? Komisch. Die Unterschiede sind ja meist so irrelevant.

Sind sie das? Find ich nicht.
Mit int verbinde ich das Speichern von ganzzahligen Werten.

Das verbinde ich auch mit HugeInt.

It0101 schrieb:

Klassen verwalten bei mir große Datenmengen, schreiben Logfiles, managen ganze Serverstrukturen... Natürlich ist nicht jede Klasse der Verwalter größerer Datenmengen, denn auch ich versuche Klassen nicht zu groß werden zu lassen, aber dennoch sind sie für mich mehr als nur ein int.

Das von der Speichergröße oder den Kopierkosten her fest anzunehmen ist aber ein Fehler. Ich kann auch Klassen haben, die drinnen nur einen int haben und keinen besonderen Kopierkonstruktor, Zuweisungsoperator oder Destruktor.

knivil

weil?

Weil das Uebergabeverhalten was mit der Groesse zu tun hat. Im Gegensatz dazu kann ich grosse und kleine Objekte (Klassen) haben. Beispiel: Wert gekoppelt an physikalische Einheit, damit Geschwindigkeit nicht aus Versehen mit Zeit verglichen wird. Objekt und Uebergabeverhalten sind also nicht korreliert. (Bei Verwendung von smart pointern wuerde man mit deiner greifbaren Definition arg gegen den Baum fahren).

It0101

(Bei Verwendung von smart pointern wuerde man mit deiner greifbaren Definition arg gegen den Baum fahren).

Ich sagte ja auch nicht, dass meine Regel zwangsläufig gilt. Aber im allgemeinen ist eine Instanz einer Klasse größer als ein Pointer ( 8byte ).

Sebastian Pizer

It0101 schrieb:

Ganz ehrlich: mir gehen diese absolut sinnlosen Theorie-Diskussionen auf den Keks...

So sinnlos finde ich die gar nicht. Du kannst ja munter weiter "praktisch" programmieren. Aber ohne gemeinsames Vokabular gibt es eben oft Missverständnisse, wenn man darüber reden will. Das Problem dabei ist, dass die ganze Angelegenheit sehr abstrakt ist (Man kann Typen, Klassen, Objekte nicht anfassen). Ich kenne keine universelle Definition -- nur sprachabhängige. Halbwegs universell -- zumindest bei imperativen Sprachen -- ist vielleicht noch, dass Objekte durch 3 Eigenschaften charakterisiert werden können:
- Identität
- Zustand
- Verhalten
Bezogen auf C++ heißt das:
- Adresse des Objektes
- aktuelle(r) Wert(e)
- Funktionen, die man aufrufen kann. (zB void increment(int&); )
Das schließt allerdings Objekte vom Typ int oder double nicht aus. Wenn der C++ Standard klipp und klar definiert, was Objekte sind und was nicht und man früher oder später doch nicht drum herum kommt, etwas darin nachzugucken, macht es Sinn, sich mit einem solchen Objekt-Begriff anzufreunden.

Diese "Was ist ein Objekt?" Diskussionen sind ja noch harmlos gegenüber "Was ist ein Werttyp?"

It0101 schrieb:

Ich versuche den Dingen Namen zu geben, die sich an der Praxis orientieren, also z.B. an den Unterschieden bzgl. der Anwendung.

Da gibts auch Namen für. Man würde wahrscheinlich "POD" benutzen. In C++0x Neusprech vielleicht auch "trivial kopierbare Typen". Wenn also sizeof(T) schön klein ist und T trivial kopierbar ist, muss man keine Angst vor pass-by-value haben (Beispiel: Viele Iteratoren). Selbst "Objekte", die nicht trivial kopierbar sind, will man manchmal ohne Referenz entgegen nehmen. Siehe Copy-&-Swap:

class Blupp {
  ...
  Blupp(Blupp const&);
  ~Blupp();
  void swap(Blupp &);

  Blupp& operator=(Blupp copy) {
    this->swap(copy);
    return *this;
  }
  ...
};

Gruß,
SP

Nexus

It0101 schrieb:

Ich sagte ja auch nicht, dass meine Regel zwangsläufig gilt. Aber im allgemeinen ist eine Instanz einer Klasse größer als ein Pointer ( 8byte ).

Du bist immer noch nicht auf volkards Einwand eingegangen, wieso HugeInt ein Objekt sein soll und int nicht. Dass auch nur "grössere Klassen, mit denen man Sachen machen kann" als Objekte gelten, ist deine eigene Definition. Was ist mit Sprachen, in denen bereits "kleine Dinge" Instanzen von Klassen sind? Sind das zwangsläufig Objekte, lediglich aufgrund der konkreten Implementierung der Programmiersprache? Ist bei dir je nach Kontext was anderes ein Objekt? Wenn du in einem Template Const-Referenzen eingerichtet hast und dieses plötzlich mit int instanziierst, wird int für kurze Zeit auch ein Objekt?

Das scheint mir ehrlich gesagt etwas zu widersprüchlich zu sein. Ich behaupte mal, dass die "gängige", auch ausserhalb von C++ vertretene Auffassung von Objekt viel abstrakter ist und sich nicht auf ein spezifisches Sprachmittel bezieht und sich erst recht nicht anhand des Funktions-Übergabeverhaltens entscheidet.

Im Weiteren gibt es C++-Objekte, die im Sprachstandard eindeutig definiert sind. Sich über diese zu unterhalten, hilft dem Sprachverständnis enorm, da Objektsemantik etwas vom Grundlegendsten ist. Tatsache ist nun mal, mit deiner Objekt-Definition kannst du vielleicht "praktisch" programmieren (inwiefern das ein Vorteil sein soll, ich würds eher als "oberflächlich" bezeichnen), aber verstehst nicht besonders viel von den Hintergründen. Gerade dieses Wissen trägt jedoch stark dazu bei, effizienteren und produktiveren Code zu schreiben. So realitätsfern, wie du vielleicht glaubst, ist diese Thematik gar nicht.

It0101 schrieb:

Ich seh das [...] Objekte sind für mich Instanzen von Klassen... das die ewig gestrigen Theoretiker und Papierprogrammierer das anders sehen und der Standard vielleicht auch, mag so sein, ist mir persönlich aber schnuppe

Ganz ehrlich: mir gehen diese absolut sinnlosen Theorie-Diskussionen auf den Keks... Programmieren ist Praxis. [...]

Entschuldigt meine Ansichten, aber ich hab eine angeborene Abneigung gegenüber Theoretikern...

Es hindert dich niemand daran, dich aus den theoretischen Diskussionen dieses Forums zu enthalten. Wie du siehst, gibt es nicht wenige Leute hier, die interessiert sind und ihre Standpunkte auch begründen. Wenn du das für sinnlos hältst, okay. Wenn du meinst, wir sind deswegen staubige Theoretiker und würden kaum praxisrelevanten Code schreiben, deine Sache.

Aber dann solltest du vielleicht nicht denken, die eigene, willkürliche Definition in den Raum zu stellen, ohne sie rechtfertigen zu können, sei sinnvoller.

Sebastian Pizer

Nexus schrieb:

Du bist immer noch nicht auf volkards Einwand eingegangen, wieso HugeInt ein Objekt sein soll und int nicht.

In bestimmten Kontexten stimmt das sogar nach C++ Regeln:

struct Kla {};

Kla quelle1();
int quelle2();

int main()
{
    Kla k   = quelle1();
//      ^     ^^^^^^^^^
//  Objekt   liefert Objekt

    int i   = quelle2();
//      ^     ^^^^^^^^^
//  Objekt   liefert int-Wert (kein Objekt)
}

In beiden Fällen bezieht sich der Variablenname auf ein Objekt. Allerdings gibt quelle2 kein Objekt zurück, sondern nur einen int-Wert.

C++ Standard, 3.10, Lvalues and Rvalues schrieb:

Every expression is either an lvalue or rvalue.

An lvalue refers to an object or function. Some rvalue expressions -- those of class or cv-qualified class type -- also refer to objects.

Gruß,
SP

It0101

Es hindert dich niemand daran, dich aus den theoretischen Diskussionen dieses Forums zu enthalten.

Wenn die Diskussion denn wenigstens Sinn machen würde... Wir diskutieren hier nur Bezeichnungen. Das macht nicht ein einziges Stückchen Code performanter, schöner oder eleganter. Ich bin durchaus gern geneigt mich von euch beraten zu lassen, aber nicht in solchen massiv sinnlosen Diskussion.

Wir diskutieren hier praktisch, ob wir den Affen nicht lieber als Tiger, oder doch als Affen bezeichnen sollten. Das macht den Affen weder zum Tiger, noch den Tiger zum Affen.

Was ich damit sagen will: Es ist doch total wurst, ob man int als Objekt oder nicht als Objekt bezeichnet.

volkard

It0101 schrieb:

Es hindert dich niemand daran, dich aus den theoretischen Diskussionen dieses Forums zu enthalten.

Wenn die Diskussion denn wenigstens Sinn machen würde... Wir diskutieren hier nur Bezeichnungen. Das macht nicht ein einziges Stückchen Code performanter, schöner oder eleganter. Ich bin durchaus gern geneigt mich von euch beraten zu lassen, aber nicht in solchen massiv sinnlosen Diskussion.

Wir diskutieren hier praktisch, ob wir den Affen nicht lieber als Tiger, oder doch als Affen bezeichnen sollten. Das macht den Affen weder zum Tiger, noch den Tiger zum Affen.

Was ich damit sagen will: Es ist doch total wurst, ob man int als Objekt oder nicht als Objekt bezeichnet.

Aber aufgetaucht ist das Problem doch bei einem total hilfreichen Rat, wo empfohlen wurde, dem Tiger Zucker zu geben. Grausam, wenn man dabei Affen und Tiger sprachlich nicht trennt. Der Tierpfleger davon wird nicht schlechter, wenn er Wechsel verwortet. Aber vielleicht sollte man davon absehen, daß er seinen Nachfolger einarbeitet.

camper

Sind Arrays auch Objekte und hängt das evtl. davon ab, ob die Elemente Instanzen einer Klasses, eines Basis-Datentyps oder eines Array-Typs sind?

Nexus

It0101 schrieb:

Wenn die Diskussion denn wenigstens Sinn machen würde... Wir diskutieren hier nur Bezeichnungen. Das macht nicht ein einziges Stückchen Code performanter, schöner oder eleganter.

Die Diskussion selbst nicht, wie auch. Aber Erkenntnisse daraus können das sehr wohl tun.

It0101 schrieb:

Ich bin durchaus gern geneigt mich von euch beraten zu lassen, aber nicht in solchen massiv sinnlosen Diskussion.

Du musst dich nicht beraten lassen, wenn du nicht willst oder eine Diskussion für sinnlos hältst. Aber wenn du schon mitdiskutierst, solltest du wenigstens ein bisschen versuchen, andere Standpunkte nachzuvollziehen, anstatt von Grund auf völlig stur zu bleiben.

It0101 schrieb:

Was ich damit sagen will: Es ist doch total wurst, ob man int als Objekt oder nicht als Objekt bezeichnet.

Sobald man die eigene Definition nicht mehr rechtfertigen kann, ist das Ganze plötzlich egal... Okay. Und selbst wenn es dir nun gleichgültig ist, liefert das keinen Anlass, deine Sichtweise erneut als allgemeingültig zu erklären.

Aber das hier hat keinen grossen Sinn, solange du dich nur wiederholst und nicht auf unsere Argumente eingehst. Ich habe oben einiges gesagt, das du scheinbar nicht wahrhaben willst und/oder zu dem du keine Gegenargumente findest.

asc

Nexus schrieb:

Sobald man die eigene Definition nicht mehr rechtfertigen kann, ist das Ganze plötzlich egal... Okay. Und selbst wenn es dir nun gleichgültig ist, liefert das keinen Anlass, deine Sichtweise erneut als allgemeingültig zu erklären.

Nach meiner Ansicht kann auch er seine Definition rechtfertigen, ebenso wie ich: Einfach weil wir die Umgangssprache in unserem Berufsumfeld verwenden (die definitiv nicht nur regional ist, auch wenn es durchaus Unterschiede je nach Firmen/Projekten geben kann). Ich verstehe auch durchaus den Wortlaut des C++ Standards, aber so diesen habe ich noch in keiner Firma als allgemeingültig kennen gelernt.

pumuckl

gehts hier noch um den ursprünglichen Topic? Falls nicht, fühlt euch ermutigt, die Diskussion in einem neuen Thread, evtl. sogar im RudP-Forum fortzusetzen

It0101

asc schrieb:

Ich verstehe auch durchaus den Wortlaut des C++ Standards, aber so diesen habe ich noch in keiner Firma als allgemeingültig kennen gelernt.

Geht mir ganz genauso. Ich arbeite in einem Bereich wo vor allem Server & Frontends für den Finanzbereich entwickelt werden.

Wir reden von vielen Millionen Telegrammen, die täglich auf jeden unserer Server einprasseln.
Bei uns gilt das Gesetz: Alles für die Performance, selbst wenn die Wartbarkeit des Codes bisweilen darunter leidet. D.h. wenn eine ANSI-C-Lösung performanter ist, als die entsprechende STL/C++-Lösung, dann wird auf die STL geschissen. So einfach ist das. Der Code mag nicht so schick aussehen, wie das was ich bisweilen zu Hause programmiere, aber die Performance rechtfertigt das Vorgehen aus meiner Sicht. Die Kunden sind nämlich sehr traurig, wenn sie ihre Kurse nicht RealTime bekommen. D.h. wir reden hier von Millisekunden.
Und wir haben schlicht und ergreifend auch keine Zeit über solche Formalitäten wie hier in diesem Thread zu diskutieren... Daher find ich es manchmal einfach nur peinlich wie hier der Standard und/oder die STL runtergebetet wird...

Nexus

pumuckl schrieb:

gehts hier noch um den ursprünglichen Topic? Falls nicht, fühlt euch ermutigt, die Diskussion in einem neuen Thread, evtl. sogar im RudP-Forum fortzusetzen

Der Threadersteller hat sich zumindest nicht mehr gemeldet. Und RudP halte ich für eine ganz schlechte Idee.

asc schrieb:

Nach meiner Ansicht kann auch er seine Definition rechtfertigen, ebenso wie ich: Einfach weil wir die Umgangssprache in unserem Berufsumfeld verwenden

Ja, das habe ich schon verstanden. Aber It0101 ist darüber hinaus kaum auf Gegenargumente eingegangen, sondern hat immer wieder seine Ansicht klargestellt und versucht, andere Meinungen als lächerlich/praxisfern/irrelevant darzustellen. Nicht gerade das, was ich unter Rechtfertigung verstehe.

It0101 schrieb:

Bei uns gilt das Gesetz: Alles für die Performance, selbst wenn die Wartbarkeit des Codes bisweilen darunter leidet.
[...]
Und wir haben schlicht und ergreifend auch keine Zeit über solche Formalitäten wie hier in diesem Thread zu diskutieren... Daher find ich es manchmal einfach nur peinlich wie hier der Standard und/oder die STL runtergebetet wird...

Ist ja schön, dass ihr solchen Code schreiben dürft. Was mich jedoch stört, ist dein abschätziges Verhalten und die Intoleranz gegenüber den Leuten, welche eben mehr Wert auf Codestil und die Kenntnis der Programmiersprache legen. Deren Motive scheinst du nach wie vor nicht nachvollziehen zu können.

Wie gesagt: Ich verstehe durchaus, dass du dich um gewisse C++-bezogene Themen nicht kümmerst. Das ist auch völlig okay. Aber sei doch wenigstens so tolerant und akzeptiere die Meinung anderer Menschen. Denn Andersdenkende als realitätsferne Theoretiker und deren Diskussionen als lächerlich zu bezeichnen finde ich ehrlich gesagt etwas anmassend.

Ich hoffe, du kannst dir unter meinem Anliegen etwas vorstellen.