3. Sinn und Unsinn von Views auf Container

Sinn und Unsinn von Views auf Container

  • S

    Hallo.

    Was haltet ihr davon, dass man Views auf Container anwenden kann.
    zB wenn man eine LinkedList hat, dass man sich dann ein ArrayView drauf holt und dann den op[] hat um auf Elemente zugreifen zu können.

    Natürlich kann man nichts löschen und nichts einfügen, aber werte setzen und lesen.

    Leider sehe ich dieses Konzept fast nirgends, hat es also irgendwelche probleme die ich ihn meiner ignoranz nicht sehe? denn für mich wirkt das View-Konzept absolut genial.

    Wo ist der Nachteil oder warum sieht man solche Views quasi nirgends?

    0
  • A

    Wer sagt denn, das sowas Unsinn ist? 😕

    0
  • V

    Shade Of Mine schrieb:

    Hallo.

    Was haltet ihr davon, dass man Views auf Container anwenden kann.
    zB wenn man eine LinkedList hat, dass man sich dann ein ArrayView drauf holt und dann den op[] hat um auf Elemente zugreifen zu können.

    Natürlich kann man nichts löschen und nichts einfügen, aber werte setzen und lesen.

    Leider sehe ich dieses Konzept fast nirgends, hat es also irgendwelche probleme die ich ihn meiner ignoranz nicht sehe? denn für mich wirkt das View-Konzept absolut genial.

    Wo ist der Nachteil oder warum sieht man solche Views quasi nirgends?

    Einen Nachteil kann ich dir nicht sagen, aber um auf deinen zweiten Teil der
    Frage einzugehen: Vielleicht weil es niemanden bis jetzt in den Sinn gekommen
    ist?

    mfg
    v R

    0
  • G

    Vielleicht weil es niemanden bis jetzt in den Sinn gekommen
    ist?

    In C++ vielleicht nicht. In Java ist das standard! Solche Methoden erkennt man meist an ihrer Namensgebung wie asType, zum Beispiel asList() oder asArray.

    0
  • F

    Vielleicht solltest du noch ein wenig genauer formulieren was du genau mit "Views" meinst.

    Dein Beispiel mit der Liste und der ArrayView hätte ich jetzt spontan eher "InterfaceAdapter" oder "InterfaceErweiterung" oder so genannt.

    Eine "View" wäre für mich eher ganz klassisch eine von (potentiell) mehreren Darstellungsformen oder Konzentration auf bestimmte Aspekte von irgenwelchen Daten.
    Evtl. auch noch so eine Art Proxy, sozusagen ein container als "View" auf die Orginaldaten.

    Shade Of Mine schrieb:

    Leider sehe ich dieses Konzept fast nirgends, hat es also irgendwelche probleme die ich ihn meiner ignoranz nicht sehe? denn für mich wirkt das View-Konzept absolut genial.

    Zu deinem Beispiel:
    Wofür brauchst du op[] bei einer Liste? Zum iterieren ist der Iterator prinzipiell genauso lesbar, wenn nicht noch deutlicher. Und wenn du wirklich so häufig Random Access brauchst wärst du mit einer anderen Datenstruktur vielleicht besser bedient.
    Falls obiges nicht zutrifft bist du mit advance auf jeden Fall besser bedient (außer du cachest die Werte):
    a) du bist genauso schnell, uU gar schneller, denn:
    b) du hast einen Iterator, d.h. du ohne weiteres löschen/einfügen und bekommst wieder einen gültigen iterator zurück
    c) der direkte op[] könnte evtl. den Eindruck eines schnellen Zugriffs erwecken

    (Bezieht sich nur auf das Beispiel, vielleicht solltest du wie eingangs erwähnt noch mal genauer darstellen was dir vorschwebt, oder ein anderes Beispiel bringen.)

    Shade Of Mine schrieb:

    Wo ist der Nachteil oder warum sieht man solche Views quasi nirgends?

    Ohne genau zu wissen was du meinst würde ich fast behaupten solche Konzepte eignen sich eher für konkrete Anwendungsfälle statt für allgemeine Bibliotheken.

    0
  • H

    Hallo,
    die Idee ist nicht neu. Siehe z.B.
    Maciej Sobczak: "STL Sequences & the View Concept" CUJ, April 2004
    oder auch:
    Gary Powell and Martin Weiser: "Views, A New Form of Container Adaptors" CUJ, April 2000

    Boost hat mit der "Multi Index"-Lib mittlerweile etwas ähnliches: http://www.boost.org/libs/multi_index/doc/

    0
  • F

    Griffin schrieb:

    Vielleicht weil es niemanden bis jetzt in den Sinn gekommen
    ist?

    In C++ vielleicht nicht. In Java ist das standard! Solche Methoden erkennt man meist an ihrer Namensgebung wie asType, zum Beispiel asList() oder asArray.

    zu Arrays.asList:
    Die Java Variante macht in C++ glaub ich nicht allzu viel Sinn, oder? In C++ kannst du auch für Arrays Iteratoren angeben und so die Algorithmen nutzen. Darüber hinaus gibt asList keine konkrete Klasse sondern nur List zurück.
    zu Collection.toArray() (meintest du das?):

    vector<T> myvector(mylist.begin(), mylist.end());
    0
  • S

    HumeSikkins schrieb:

    die Idee ist nicht neu.

    Ja. Ich habe hier nichts geniales erfunden, sondern will eigentlich nur wissen, was dagegen spricht... Schliesslich wird es nur sehr selten verwendet...

    und ja, ich meine etwas im Stile von Javas as*
    Nur etwas abstrakter 😉 Mich fasziniert vorallem der Ansatz eines abstrakten Views mit konkreten Subklassen. So dass man jedes View auf jeden Container anwenden kann (sofern es sinn macht, also HashMapView auf Array waere zB nicht sinnvoll, weil es ja keine Keys gibt).

    Warum man das will ist leicht erklaert: die Anwendung eines Containers ist nicht immer die ganze Zeit gleich. zB will ich anfangs vielleicht viel in der Mitte einfuegen und dennoch random access haben? einfache in ArrayView ueber die List legen und fertig. Man will nicht alles kopieren und ein Container ist fast nie perfekt fuer den Job geeignet, normalerweise ist es ein abwegen zwischen verschiedenen faktoren und man nimmt den container der gesamt am besten abschneidet...

    @finix:
    du hast es nicht verstanden, es geht bei einem View darum, nur ein anderes Interface (oder besser: Blickwinkel) auf die selben Daten zu haben. So dass ich nichts kopieren muss. Das View speichert nur eine handvoll Zeiger auf den echten Container.

    0
  • N

    Shade Of Mine schrieb:

    ...nur ein anderes Interface (oder besser: Blickwinkel) auf die selben Daten zu haben. So dass ich nichts kopieren muss. Das View speichert nur eine handvoll Zeiger auf den echten Container.

    du meinst sowas wie ein 'view' in sql

    0
  • F

    Shade Of Mine schrieb:

    @finix:
    du hast es nicht verstanden, es geht bei einem View darum, nur ein anderes Interface (oder besser: Blickwinkel) auf die selben Daten zu haben. So dass ich nichts kopieren muss. Das View speichert nur eine handvoll Zeiger auf den echten Container.

    Deswegen hab ich ja gefragt ob du deine Idee noch mal erläutern könntest. Konnte ja nicht ahnen dass der Begriff "View" so selbsterklärend ist. 🙄
    Dennoch meinte ich genau diesen Ansatz mit

    ein container als "View" auf die Orginaldaten

    Und ich denk mal so selten kommt das gar nicht vor, aber ist denke ich zumeist echt eher auf den konkreten Fall zugeschnitten.

    Für eine Bibliothek ist es zwar sicher auch nicht uninteressant aber schon recht komplex:
    - du z.B. willst werte setzen, der nächste will das ganze vielleicht ohne write-through!?
    - wieso kein einfügen oder löschen?
    - bietest du die Möglichkeit den Orginalcontainer einer View entsprechend zu modifizieren?
    - Views auf Views?
    - Datenkonsistenz?

    0
  • H

    Ergänzung:
    Den Code zu Sobczaks Artikel gibt's hier:

    http://www.msobczak.com/prog/bin/view.zip

    0
Anmelden zum Antworten