3. Struct in Vector speichern

Struct in Vector speichern

  • V

    drakon schrieb:

    volkard schrieb:

    drakon schrieb:

    Generik

    Neues Wort?

    Öhh, nö?
    http://de.wikipedia.org/wiki/Generik

    Öhm doch!
    http://de.wikipedia.org/w/index.php?title=Generizität&redirect=no
    (Ist doch nur Wikipedia und kein Lexikon)

    0
  • D

    Ich weiss jetzt nicht genau, was du mir damit sagen willst, aber lies doch mal den Artikel:

    Die Implementierung erfolgt bei einigen Programmiersprachen durch das Konzept generischer Typen bzw. Templates – so gestalten sich dynamische Programmiersprachen, bei denen sich der Typ einer Variable zur Laufzeit ändern darf, durch ihre verallgemeinerte Polymorphie generisch. Von Sprachen, die solche Mechanismen bieten, sagt man auch, dass sie Generik erlauben.

    Das Wort ist weder von mir erfunden, noch äusserst unbekannt.

    0
  • V

    Verstehe, Generik für sie Sprache, Generizität für die Funktionen. Das geht.

    0

  • asc schrieb:

    Sebastian Pizer schrieb:

    Ich will nur erwähnen, dass Du scheinbar unter "Objekt" etwas anderes verstehst als der C++ Standard...

    Die Kritik nehme ich an, wenn auch nicht Kritiklos: Noch kein einziger in meiner gesamten Berufslaufbahn (überwiegend C++, bei mehr als 10 Jahre Berufserfahrung) hat den Begriff Objekt, in den Gebrauch des C++ Standards, sondern eher bezogen auf die Objektorientierte Programmierung (Instanz einer Klasse) verwendet. Es gibt bei mir eine Grenze bei der mir der Standard abgeht: Und zwar wenn der Sprachgebrauch im Programmierbereich in 90%+ der Fälle etwas anderes besagt. Vielleicht liegt es auch daran das ich nicht im Lehrbereich tätig bin...

    Ich seh das genauso wie du. 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. Man kann 30 Seiten drüber schreiben, was man genau als Objekt betrachtet, oder man geht hin und baut einfach eins und benutzt es auf die schmutzigste und versauteste Art und Weise! Benutz mich, du Sau! 😛

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

    0
  • V

    It0101 schrieb:

    Ich seh das genauso wie du. 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 😉

    Also ein Objekt ist ein Ding, mit dem ich Sachen machen kann, egal ob das Ding nun ein HugeInteger oder ein int ist, egal, ob char oder string.

    It0101 schrieb:

    Ganz ehrlich: mir gehen diese absolut sinnlosen Theorie-Diskussionen auf den Keks... Programmieren ist Praxis. Man kann 30 Seiten drüber schreiben, was man genau als Objekt betrachtet, oder man geht hin und baut einfach eins und benutzt es auf die schmutzigste und versauteste Art und Weise! Benutz mich, du Sau! 😛

    Ganz ehrlich: Du beziehst Deine "Objekt"-Definition von solchen Sprachen, wo alle Klassen von der Zauberklasse "Object" erben. Aber das ist in C++ doch gar nicht angemessen. Einfach falscher Kontext. Wir haben die Object-Klasse nicht.
    Das ist töricht und widerspricht genau Deiner Benutz-Mich-Theorie. In C++ nimmt man sich einfach ein Objekt und benutzt es und muß gar nicht drüber nachdenken, aus welcher Klasse es kommt oder ob es überhaupt Instanz einer Klasse ist. Einfach nur benutzen.
    Und es schadet nicht, sich dessen im Klaren zu sein. Programmieren könnt ihr auch so. Jahrelang. Aber in Diskussionen werden ihr immer auffallen, wenn ihr regionales Vokabular pflegt. Man wird vielleicht denken, daß ihr nicht regelmäßig C++-Bücher lest und das wollen wir doch nicht.

    0
  • A

    volkard schrieb:

    ...Aber in Diskussionen werden ihr immer auffallen, wenn ihr regionales Vokabular pflegt...

    Stimmt, sehr regionales Vokabular (Hessen, Bayern, NRW...). Und in der Praxis kenne ich nur wenige Firmen mit mehr als 10 Entwicklern die nur C++ verwenden, und selbst in reinen C++ Firmen entsprach bisher der Wortschatz nicht dem aus dem C++ Standard. Mag vielleicht sein das sich der Sprachgebrauch teilweise vor dem Standard entwickelt hat.

    volkard schrieb:

    Ganz ehrlich: Du beziehst Deine "Objekt"-Definition von solchen Sprachen, wo alle Klassen von der Zauberklasse "Object" erben.

    Merkwürdig, das ich diese "Interpretation" schon aus Zeiten kenne, wo ich noch nicht mit reinen OO-Sprachen zu tun hatte (C++ kam bei mir deutlich vor Java, C# und Co - und auch noch vor dem Standard). Und mag sein das alle bisherigen Firmen zufälligerweise den gleichen (unabhängig vom Bundesland) "regionalen" Sprachgebrauch hatten.

    0

  • Also ein Objekt ist ein Ding, mit dem ich Sachen machen kann, egal ob das Ding nun ein HugeInteger oder ein int ist, egal, ob char oder string.

    Also zwischen int und std::string ist bzgl. der "Sachen machen" ein riesiger Unterschied... aber prinzipiell gebe ich dir insofern recht, dass man mit allen diesen Dingen etwas tun kann. Wenn das deine Definition von einem Objekt ist, ist sie berechtigt. Ich definiere sie anders, weil ich int und char und co. nicht als Objekt sehe... Für mich sind das Basis-datentypen ( also float, double, int, long, char, short, etc. ).

    Diese unterscheiden sich aus meiner Sicht genau dadurch von Instanzen von Klassen, dass man sie bei der Übergabe in Funktionen nicht mit const-Referenz übergibt, sondern normal. Zumindest mach ich sowas nicht:

    void Foobar( const int &IntegerWert )
{
...
}

    Mit std::string mach ich das allerdings schon:

    void Foobar( const std::string &StringObjekt )
{
...
}

    so jetzt habt ihr ne greifbare Definition von Objekten 😉

    0
  • V

    Also ein Objekt ist ein Ding, mit dem ich Sachen machen kann, egal ob das Ding nun ein HugeInteger oder ein int ist, egal, ob char oder string .
    (Hinweis: int und char sind keine Klassen, HugeInteger und string sind Klassen.)

    0
  • V

    It0101 schrieb:

    so jetzt habt ihr ne greifbare Definition von Objekten 😉

    Die war schon klar.

    It0101 schrieb:

    Diese unterscheiden sich aus meiner Sicht genau dadurch von Instanzen von Klassen, dass man sie bei der Übergabe in Funktionen nicht mit const-Referenz übergibt, sondern normal.

    Erstens: Und was machst Du mit bekanntermaßen kleinen Sachen wie std::pair<char,char>? Oder mit Digit (erst im Handbuch nachschlagen, ob's ein enum, typedef auf nicht-klassen-instanz oder struct/class ist)?

    It0101 schrieb:

    Diese unterscheiden sich aus meiner Sicht genau dadurch von Instanzen von Klassen, dass man sie bei der Übergabe in Funktionen nicht mit const-Referenz übergibt, sondern normal.

    Zweitens: Ja, benutz einfach Instanzen von Klassen statt Objekten, wenn Du Instanzen von Klassen meinst, und alles ist ok.

    0

  • volkard schrieb:

    Also ein Objekt ist ein Ding, mit dem ich Sachen machen kann, egal ob das Ding nun ein HugeInteger oder ein int ist, egal, ob char oder string .
    (Hinweis: int und char sind keine Klassen, HugeInteger und string sind Klassen.)

    das erwähntest du bereits.

    sag mir doch mal, lieber Volkard:

    Übergibst du int und float als Const-Referenz?
    Behandelst du sie genauso wie Instanzen von Klassen?

    Wenn ja, warum?
    Wenn nein, warum?

    ich behandele sie nicht gleich, weil sie nicht das gleiche sind.

    0
  • K

    Diese unterscheiden sich aus meiner Sicht genau dadurch von Instanzen von Klassen, dass man sie bei der Übergabe in Funktionen nicht mit const-Referenz übergibt, sondern normal. Zumindest mach ich sowas nicht: ... so jetzt habt ihr ne greifbare Definition von Objekten

    Eine ziemlich bescheuerte Definition, das am Uebergabeverhalten festzumachen.

    Übergibst du int und float als Const-Referenz?

    Manchmal sogar ohne das Const. Aber mal ehrlich: Alles was klein ist, darf kein Objekt sein, nur weil ich es nicht als Const-Referenz uebergebe?

    0
  • V

    It0101 schrieb:

    Übergibst du int und float als Const-Referenz?

    Natürlich, nämlich gelegentlich in Templates.

    It0101 schrieb:

    Behandelst du sie genauso wie Instanzen von Klassen?

    Umgekehrt! Ich baue Klassen, daß sie sich wie int und double anfühlen.

    It0101 schrieb:

    Wenn ja, warum?

    Weniger Handbuchnotwendigkeit. Jeder kennt ints und jeder erwartet Klassen, die wie int gehen.

    It0101 schrieb:

    ich behandele sie nicht gleich, weil sie nicht das gleiche sind.

    Echt? Komisch. Die Unterschiede sind ja meist so irrelevant. Bei der Übergabe mal ein const& oder roh. Aber wenn ich diese Objekte in einen vector stopfen will, wo ist der Unterschied hin? Sie haben die richtige Kopiersemantik dazu also kann ich sie in den vector stopfen.

    0

  • knivil schrieb:

    Diese unterscheiden sich aus meiner Sicht genau dadurch von Instanzen von Klassen, dass man sie bei der Übergabe in Funktionen nicht mit const-Referenz übergibt, sondern normal. Zumindest mach ich sowas nicht: ... so jetzt habt ihr ne greifbare Definition von Objekten

    Eine ziemlich bescheuerte Definition, dass am Uebergabeverhalten festzumachen.

    weil?

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

    Ich halte doch keinen davon ab, weiterhin die Theorie im Standard anzubeten.

    0

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

    Sind sie das? Find ich nicht.

    Mit int verbinde ich das Speichern von ganzzahligen Werten.

    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.

    0
  • V

    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.

    0
  • K

    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).

    0

  • (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 ).

    0
  • S

    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

    0
  • N

    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.

    0
  • S

    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

    0
Anmelden zum Antworten