4. (überflüssige) Demo

(überflüssige) Demo

  • C

    @Headhunter ...
    I wollte das eigentlich nicht in eine grosse Diskussion ausweiten ...
    Aber wenn du den Source noch nicht gesehen hast kannst du nicht sagen das das nichts bringt.

    Ich weiss was der Vorteil einer Litse und eines Vectors ist. Und der "Nachteil" des Vectors ist das er indizierten Zugriff erlaubt. Normalerweise ein Vorteil, aber im Renderer eigentlich unnötig, da hier nur linear, also in einer For-Schleife durch den Renderer gegangen wird
    Also jedesmal:

    for(int i = 0; i<vec.size();++i)
vec[i]:=bla;

    Da ist der indizierte Zugriff völlig Schwachsinnig, da jedes Element dran kommt. Und das spricht nunmal 100% für eine Liste.

    for(list<obj>::iterator i = l.begin();i!=l.end(); ++i)
(*i):=bla;

    Macht was ihr wollt,, ich will ja nicht streiten, aber sagt nichts darüber wenn ihr noch net den Source gelesen habt. Nur weil TGGC ansonsten echt Klasse Spiele und Demo's macht kann auch er sich ja mal irren.

    0

  • A)

    Original erstellt von ChaosAngel:
    **```cpp
    for(int i = 0; i<vec.size();++i)
    vec[i]:=bla;

    😎

    Original erstellt von ChaosAngel:
    **```cpp
    for(list<obj>::iterator i = l.begin();i!=l.end(); ++i)
    (*i):=bla;

    Nochmal für mich zum mitmeisseln, warum kann B schneller als A sein?

    0
  • C

    Weil der op[] in einem vector mehr kostet als der lineare Zugriff über iteratoren.

    Ne Liste ist also nicht nur schneller (keine Ahnung wie viel) sondern auch intuitiver, da du ja nunmal linear durch den Container gehst ...

    Am schnellsten wäre ein konstantes Array, da da über PointerArhytmetik zugegriffen wird und der ProzessorCache den Speicher nicht so oft nachladen muss. Aber nen Array ist ja nicht dynamisch.

    0
  • H

    ChaosAngel :
    Warum ist der op [] langsamer ? Damit wird doch direkt ein Element *direkt* returned, ohne irgendwelche Größenchecks oder so.

    Ich würde den operator [] so definierien :

    template <class T>
T& operator [] (int n)
{
       return m_array[n];
}

    Viel schneller geht das doch nicht, oder 😉 ?

    0
  • C

    Na sicher ...
    Bei nem statischen Container kann man das auch so tun, und da greift auch der ProzessorCache.
    Aber std::vector ist nunmal dynamisch ! Das heisst es muss nicht in so einem Array gespeichert sein ! Ein dynamisches Array sieht nunmal anders aus (implementierungsabhängig)

    Gibts hier nicht irgendwo nen FAQ wann benutze ich Listen und wann Vectoren ?
    Dann könnte man das da nachlesen ...

    0

  • Original erstellt von ChaosAngel:
    Gibts hier nicht irgendwo nen FAQ wann benutze ich Listen und wann Vectoren ?
    Dann könnte man das da nachlesen ...

    Worauf ich dich dann verweisen würde...

    Ok, hat sich erledigt, das war ja dann ein Schlag ins Wasser. Hat evtl. noch jemand nützliche Vorschläge?

    Bye, TGGC

    0
  • C

    Ich glaube nicht das ich dieses Faq brauche ...
    Aber ich will schliesslich niemanden zwingen.
    Viel Spass noch ...

    0
  • ?

    oh mann TGGC
    du besserst dich nie
    schrecklich
    nach deiner meinung ist doch eh schon alles perfekt
    wenn jemand einen vorschlag macht, machst du ihn nieder. wenn jemand argumente bringt, startest du einen kleinkrieg und hälst dich mit lächerlichen kleinigkeiten auf um zu verdecken daß der andere recht hat.
    furchtbar
    !!!

    0
  • ?

    Ich glaube hinter std::vector steckt auch ein ganz normales Array, was super schnelle Zugriffzeiten erlaubt. Es wird halt, wenn das Array zu klein wird, ein neues, größeres Array erstellt, umkopiert und das alte Array gelöscht.

    0
  • H

    Hallo,
    also ich habe keine Ahnung von Spieleprogrammierung, aber eins kann ich euch garantieren: Sofern es sich bei Vektor um einen std::vector handelt, ist dessen op[] keinesfalls langsamer als der Zugriff auf das Folgeelemt einer Liste.

    Auch ist es *garantiert* (zwar erst durch einen Defect Report, aber immerhin), dass std::vector seine Elemente *am Stück* speichert und das der op[] eine constant-time-operation ist (ein simpler Indexzugriff, wie beim "normalen" Array auch).

    Zwischen Vektoren und Listen zu entscheiden, macht Sinn bei Einfügeoperationen, bei Random-Access-Operationen, bei der Betrachtung der Gültigkeit von Referenz bzw. Iteratoren in den Container, beim Sortieren und wenn es um Exceptionsicherheit und Transaktionssemantik geht (irgendwas habe ich bestimmt wieder vergessen).

    Nicht aber, beim einfachen Durchlaufen.

    So, jetzt könnt ihr euch weiter die Köppe einschlagen 🙂

    0
  • C

    Danke erstmal für die Aufklärung

    bei Random-Access-Operationen

    Nunja, der []op ist doch random access, oder ?
    Also folgerte ich logischerweise das ein Zugriff damit langsamer ist als der lineare Zugriff in der Liste.

    Wenn dem nun nicht so ist, nunja ...

    Trotzdem ist die Liste in diesem Beispiel intuitiver ! Aber Geschmackssache ...

    Mal wieder was gelernt

    0
  • H

    Nunja, der []op ist doch random access, oder ?

    Richtig. In der Regel schon. Werden random-access-Zugriffe benötigt, eignet sich ein Vektor besser, da ein solcher Zugriff bei diesem Container in konstanter Zeit abläuft. Bei einer Liste aber in O(n). Ist also dort abhängig von der Anzahl der Elemente in der Liste.

    Also folgerte ich logischerweise das ein Zugriff damit langsamer ist als der lineare Zugriff in der Liste

    Nein. Der Zugriff auf eine beliebige Stelle in einem Vektor ist *schneller* als bei einer Liste. Der schrittweise Zugriff auf jedes einzelne Element dürfte für Vektoren und Listen aber gleich schnell sein. Im zweifelsfall mit einem leicht besseren Ergebnis für Vektor.

    Trotzdem ist die Liste in diesem Beispiel intuitiver !

    Ich habe mir das Beispiel nicht angeschaut. Es kann auch sein, dass die Liste nicht nur intuitiver sonder auch performanter ist. Das kann ich nicht beurteilen.
    Allein die beiden Schleifen lassen darüber aber keine Aussage zu.

    Ich würde allerdings auch beim Vektor die Iteratorschreibweise verwenden.

    [ Dieser Beitrag wurde am 25.01.2003 um 01:00 Uhr von HumeSikkins editiert. ]

    0

  • Original erstellt von HumeSikkins:
    So, jetzt könnt ihr euch weiter die Köppe einschlagen 🙂

    Habe ich nicht vor. Warte nur auf die Vorschläge, die zu Threadbeginn angekündigt wurden ;).

    0

  • So, hab nun auch Source für Linux hochgeladen, hoffe mal der funzt. (Nochmal danke an nman für den Aufwand!)

    Bye, TGGC

    0

  • Evtl. hier noch wer?
    2D Renderer

    0
  • H

    Hi !

    Ich kann den Sourcecode nicht compilen (gcc 3.2.1)
    Hier der Output :

    [code]
    jojo@jojo ~/ZweiD_linux/ZweiD $ make;bell
    g++ -o ZweiD -Wall -O4 ZweiD.cpp stdafx.cpp Renderer/CCircle.cpp Renderer/CFastCircle.cpp Renderer/CFastRender.cpp Renderer/CIObject.cpp Renderer/CLine.cpp Renderer/CObjectList.cpp Renderer/CRender.cpp Renderer/CRenderTarget.cpp Util/CFWraw.cpp Util/CFWtga.cpp
    Renderer/CCircle.cpp:18:7: warning: extra tokens at end of #else directive
    Renderer/CFastCircle.cpp:18:7: warning: extra tokens at end of #else directive
    Renderer/CFastRender.cpp:18:7: warning: extra tokens at end of #else directive
    Renderer/CIObject.cpp:18:7: warning: extra tokens at end of #else directive
    Renderer/CLine.cpp:18:7: warning: extra tokens at end of #else directive
    Renderer/CObjectList.cpp:18:7: warning: extra tokens at end of #else directive
    Renderer/CRender.cpp:18:7: warning: extra tokens at end of #else directive
    Renderer/CRenderTarget.cpp:17:7: warning: extra tokens at end of #else directive
    Renderer/CRenderTarget.h: In constructor CRenderTarget::CRenderTarget(int, int, float)': Renderer/CRenderTarget.h:60: warning: member initializers forint
    CRenderTarget::m_siWidth'
    Renderer/CRenderTarget.h:59: warning: and int CRenderTarget::m_siHeight' Renderer/CRenderTarget.cpp:36: warning: will be re-ordered to match declaration order Util/CFWraw.cpp:16:20: stdafx.h: Datei oder Verzeichnis nicht gefunden In file included from Util/CFWraw.cpp:18: Util/CFWraw.h:30: parse error before{' token
    Util/CFWraw.cpp:28: `string' undeclared in namespace `std'
    Util/CFWraw.cpp:28: parse error before ,' token Util/CFWraw.cpp:29: invalid use of undefined typeclass CFWraw'
    Util/CFWraw.h:29: forward declaration of class CFWraw' Util/CFWraw.cpp: In member functionbool CFWraw::Save(...)':
    Util/CFWraw.cpp:30: strName' undeclared (first use this function) Util/CFWraw.cpp:30: (Each undeclared identifier is reported only once for each function it appears in.) Util/CFWraw.cpp:32: \ofstream' undeclared in namespace `std'
    Util/CFWraw.cpp:32: parse error before (' token Util/CFWraw.cpp:34:ofs' undeclared (first use this function)
    Util/CFWraw.cpp:43: `prt' undeclared (first use this function)
    Util/CFWtga.cpp:18:7: warning: extra tokens at end of #else directive
    make: *** [ZweiD] Fehler 1[/code]

    0
  • N

    Also bei mir compiled die Version auch nicht, bist Du sicher dass das die Version ist die ich dir geschickt habe, TGGC?

    Ich kann Dir gegebenfalls meinen letzten Port schicken oder irgendwo hochladen, der funktioniert ganz sicher.

    0

  • Original erstellt von nman:
    Also bei mir compiled die Version auch nicht, bist Du sicher dass das die Version ist die ich dir geschickt habe, TGGC?

    Du hattest nichts geschickt(!?), das hatte ich von der Adresse oben runtergeladen. Ausprobieren konnte ich es leider nicht, wusste daher nicht, ob es geht.

    0
  • ?

    Original erstellt von TGGC:
    Ihr seid alle kläglich und dumm.

    Das musst Du gerade sagen, Du arroganter selbstverliebter Kerl!!!!!

    0
  • N

    Äh ich meinte ja auch "hochgeladen" - das ist aber sicher nicht die letzte Version, denn diese lässt sich bei mir ohne irgendwelche Probleme kompilieren und ausführen!

    Lade jetzt mal runter - ich hab Headhunter zuliebe sogar noch ein halbwegs vernünftiges Makefile dazugepackt... 😉

    0
Anmelden zum Antworten