1. Dashboard
  2. Mitglieder
    1. Letzte Aktivitäten
    2. Benutzer online
    3. Team
    4. Mitgliedersuche
  3. Forenregeln
  4. Forum
    1. Unerledigte Themen
  • Anmelden
  • Registrieren
  • Suche
Alles
  • Alles
  • Artikel
  • Seiten
  • Forum
  • Erweiterte Suche
  1. AutoIt.de - Das deutschsprachige Forum.
  2. Mitglieder
  3. Marthog

Beiträge von Marthog

  • C++ Erklärung der Grundkonzepte

    • Marthog
    • 2. September 2013 um 17:51
    Zitat von YaeroxXO

    Über den Vektoren Teil kann ich nichts sagen, habe ich mir nie richtig angeschaut. Ich

    würde vielleicht den Polymorphismus noch hinzufügen, speziell das überladen von Funktionen und vielleicht die Funktionen „virtual“ sowie die Erklärung von

    „private“ und „public“.

    Ich wollte nicht so speziell darauf eingehen, weil dann viele einfach nur noch Bahnhof verstanden hätten. virtual ist z.B. mit dem Überschreiben von Funktionen

    gemeint. Über die Implementierungsdetails wollte ich nicht erzählen, sondern nur allgemein, damit ein Grundverständnis zu den Begriffen da ist.


    Zitat von TheShadowAE


    1.


    Falsch. Der Konstruktur wird zuerst aufgerufen und dann wird die Methode die mit dem =operator verknüpft ist aufgerufen. Diese speichert erst den Inhalt in sich

    ab.

    Nein, beim Erstellen und gleichzeitigen Zuweisen wird der Konstruktor mit einem passenden Parameter rausgesucht und verwendet. Es kann sein, dass das als
    string text = string(text) compiled wird und erst ein Objekt erzeugt und das dann kopiert wird, sodass man zwei Konstruktoraufrufe auf unterschiedliche Objekte

    hat (1 parameter + copy).
    Der Zuweisungsoperator wird aber nur angewandt, wenn das Objekt bereits besteht und dann zugewiesen wird, wobei manche Implementierungen im

    Konstruktor einfach den Zuweisungsoperator aufrufen, weil man sich so doppelten Code spart.


    Zitat von TheShadowAE


    2.


    und zwar "sich selber". Die Methode initialisiert alles nötige, damit das Objekt, in dem es ist, funktioniert.
    Daher ist das Beispiel auch kein Konstruktor, da es erst ein Object (eine Struct) erzeugt und dann von außen Daten drin speichert.


    Klar, aber so ist ungefähr verständlich, was ein Konstruktor überhaupt macht, denn fast immer läuft Speicherplatzreservierung und Konstruktoraufruf zusammen ab.

  • Programmiersprachen - Diskussion in Hinsicht auf Berufliche Zukunft und Anwendungsfall

    • Marthog
    • 2. September 2013 um 17:24

    http://www.somethingofthatilk.com/comics/135.jpg :rofl: :rofl:

    HTML sollte jeder ansatzweise können, ist aber keine Programmiersprache.

    Es hängt halt alles davon ab, was du machen willst.
    PHP, MySQL, Javascript, flash, Python (Django) sind als Web-Entwickler wichtig.

    Python ist für den Bereich Linux wohl unverzichtbar, weil man von kleinen Skripts bis zu komplexen Programmen alles auf einfache Weise machen kann und einen enormen Umfang an libraries hat.

    C++ hat den Vorteil, dass es verhältnismäßig große Übersichtlichkeit und Wiederverwertbarkeit bei guter Laufzeit und Hardwarenähe hat. Richtiges C++ ist plattformunabhängig. Da nach einer Langen Dürreperiode (seit 1998 kaum Neuerungen) 2011 ein komplett anderer Standard herausgekommen ist, könnten sich in Zukunft wieder mehr Firmen überlegen, für neue Projekte doch wieder C++ zu verwenden.
    C muss man zwar nicht programmieren können, aber es hat große Vorteile, es gut lesen zu können, weil ein Großteil alter Programme und Algorithmen in C geschrieben ist, und C auch der historische Schnittpunkt vieler anderer Programmiersprachen ist.


    Java ist quasi die Standardsprache und es kann nicht schaden, sie zu können. Java ist meistens plattformunabhängig, hat ein GUI-framework, bei Android (leider) die einzige Sprache, die direkt auf das Userinterface zugreifen kann. Dafür ist Java langsam, hat Designfehler (wird nicht umsonst gehasst) und viele Sicherheitslücken.
    Die meisten Studenten lernen Java, aber das kann auch Nachteile haben, z.B. hat sich ein Arbeitskollege meines Vaters (Druckmaschinenbau) mal beschwert, dass alle jungen Leute nur noch Java könnten und es kaum mehr gebe, die sich um die alten Programme, die z.T. auch auf Treiberebene arbeiten müssen, kümmern können.

    C# steht irgendwo zwischen Java und C++. Es läuft hauptsächlich auf Windows, die Algorithmen durch Mono auch woanders, aber GUI und andere Funktionen sind auf die WinAPI zugeschnitten. Es ist einfach zu verwenden, der Benutzer braucht keine Runtime library bzw. diese wird mit Windows geupdatet. Es ist übersichtlich, verhältnismäßig sicher (gegen Memory leaks und Abstürze und auch keine solche Virenschleuder wie Java), aber immernoch annehmbar schnell.
    Gerade Firmen, die Windows als einzige Plattform haben, werden wohl C# vorziehen, allerdings lässt sich die Entwicklung schwer abschätzen, weil Microsoft sich nicht mehr um C# kümmert und jetzt ihren Metro-Modern-UI-rechteck-pseudo-html5-kack abzieht.

    Objective C scheint irgendwo zwischen C++ und C# zu sein, wird aber nur für Apple verwendet.

    Assembler lohnt sich wohl aus beruflicher Seite erstmal nicht.

    Haskell könnte mal interessant werden, aber ist es zur Zeit noch nicht. Es hat ein gänzlich anderes Konzept und wird zur Zeit noch als Akademikersprache belächelt, aber das höhere Abstraktionslevel verringert die Fehlerzahl und überlässt dem Compiler mehr Denkarbeit. Da sich Compiler laufend verbessern, könnte es sein, dass sie irgendwann besseren Code generieren als ein durchschnittlicher C++-Programmierer könnte, so wie es zur Zeit auch mit C/C++ und Assembler ist.


    Das ist aber nur, was ich so einschätze. Was die Firmen wirklich wollen, kann ich nicht sagen, denn ich bin noch nicht berufstätig. Es lässt sich für die Zukunft nur schwer abschätzen, denn während es zwischenzeitlich so aussah, als würde irgendwann außer OS, Treiber und Spiele alles Java sein, nimmt die Zahl zur Zeit eher ab und es gibt doch erstaunlich viele Firmen, die anderes verwenden.

  • C++ Erklärung der Grundkonzepte

    • Marthog
    • 1. September 2013 um 17:24

    Hallo,
    da viele hier im Forum irgendwann anfangen C++ zu lernen, aber ein Großteil der Bücher und Tutorials veraltet oder falsch ist, erkläre ich hier mal die
    Grundprinzipien für sauberes C++.

    • Objektorientierte Programmierung (OOP):
      OOP ist das grundlegende Feature von C++ und heißt, dass Daten in Objekten gekapselt sind.
      Eine Klasse ist der Datentyp eines Objekts.
      Das ist ähnlich wie ein DllStruct, nur kann man neben ein paar anderen Features zusätzlich Methoden definieren, das sind Funktionen, die mit dem Objekt
      verbunden sind. Wenn man daran gewöhnt ist, ist $variable.length() einfacher zu lesen, als StringLength($variable), außerdem kann man die internen Daten
      eines Objekts verstecken, sodass man sie von außen nicht ändern kann, Methoden haben aber immernoch volle Zugriffsrechte darauf.
      Man kann Operatoren (+, &, +=, etc) für eigene Objekte selber definieren und so übersichtlich mit ihnen programmieren, indem man z.B. eine Vektorklasse hat und die normalen
      mathematischen Schreibweisen zulässt.


    • Vererbung:

      Vererbung heißt, man leitet eine Klasse von einer anderen ab. Die abgeleitete übernimmt alle Eigenschaften der Basisklasse, kann aber Methoden überschreiben
      und zusätzliche definieren. Dadurch kann man eine allgemeine Basis haben und die immer weiter spezialisieren. Zum Beispiel kann die Basisklasse Tier nehmen
      und Verhaltensweisen wie Essen und schlafen definieren. Dann leitet man die spezialisierte Klasse Hund ab und fügt Bellen hinzu und leitet als zweites Vogel ab
      und fügt Fliegen hinzu, überschreibt aber das normale Essen mit Körnerpicken.


    • Konstruktor:

      Der Konstruktor ist einfach eine Funktion, die ein Objekt initialisiert.

      [autoit]

      Func createVector($x, $y)
      Local $struct = DllStructCreate("int x; int y;")
      DllStructSetData($struct, "x", $x)
      DllStructSetData($struct, "y", $y)
      return $struct
      EndFunc

      [/autoit]


      wäre quasi ein Konstruktor, aber richtige Konstruktoren sind übersichtlicher und sicherer, weil sie implizit aufgerufen werden:
      Bei

      Code
      string text = "Hello, world!";

      wird automatisch ein Konstruktor aufgerufen, der den String "Hello, world!" in das Objekt kopiert.
      Würde man altes C verwenden, müsste man erst selbst den Speicher reservieren mit

      Code
      char* string = malloc(strlen(anderer_string));


      und dann füllen mit

      Code
      strcpy(string, anderer_string);


    • Destruktor:

      Er ist quasi das Gegenteil des Konstruktors. Wenn das Objekt gelöscht wird, sorgt er dafür, dass alles ausgeräumt wird. Bei einem string sorgt er zum Beispiel dafür, dass der Speicherplatz wieder freigegenben wird. Bei dem anderen Beispiel von C muss man dafür selber sorgen mit
      Code
      free(string);

      und wenn man das irgendwo vergisst, hat man Memory leaks.
      Mehr dazu schreibe ich später.


    • Exceptions:

      Exceptions sind Ausnahmen, die irgendwo bei einem Fehler ausgelöst werden. Sie übernehmen die Aufgabe von @error, aber @error muss nach jedem Schritt überprüft werden, gegenenenfalls die Funktion beendet und @error neu gesetzt werden muss
      [autoit]Func Foo()
      Bar()
      if @error Then Return SetError(@error)
      ; blablabla
      EndFunc[/autoit]
      und das wird von einer Funktion in die nächste weitergegeben, bis es eine ignoriert oder verarbeitet.

      Dagegen beenden Exceptions automatisch alle anderen Funktionen und springen zu einer Stelle, die vorher mit try und catch definiert wurde

      Code
      try
      {
      // ganz gang viele, komplizierte Funktionen
      }
      catch (exception e)
      {
      cout<<e.what();	// das heißt, die Feherbeschreibung wird ausgegeben
      }


      Der Vorteil ist, dass ein Fehler an ganz anderer Stelle bearbeitet werden kann, wenn z.B. beim Einlesen von Dateien ein Fehler auftritt, der Fehler vom Manager aufgefangen und an GUI oder Konsole weitergegeben werden. Dadurch erreicht man eine striktere Trennung von verschiedenen Bereichen und mehr Übersichtlichkeit.


    • Namespaces:

      Namespaces sind wirklich kein großartiges Feature.
      Es erlaubt nur Namensräume, quasi Codeabschnitte mit Namen zu definieren und so zu verhindern, dass sich Namen überschneiden. Zum Beispiel gibt es in der Standard-library (= standard-UDFs) die Klasse string, man hat vielleicht aber auch eine andere Klasse, die genauso heißt. Deswegen schreibt man std::string und bestimmt dadurch, das man die Klasse/Funktion aus std (Standard library) haben will. Bei AutoIt macht man das ähnlich, indem man _WinAPI_... schreibt, aber die namespaces sind da noch etwas mächtiger und übersichtlicher. Wenn man selber eine library schreibt, sollte man namespaces nutzen und wenn man eine nutzt, sollte man sich sehr gut überlegen, ob man den Namespace mittels
      Code
      using namespace

      in den globalen integriert. Leider ist es in Tutorials sehr verbreitet, denn es erspart Tipparbeit, wenn man nur string statt std::string schreibt, aber umso größer und komplexer das Pojekt, umso wahrscheinlicher wird es auch, dass sich Namen überschneiden, Fehler und Probleme bei der Zuordnung auftreten.
      Leider lernen die meisten Anfänger das falsch und gewöhnen sich schnell daran.


    • Templates:

      Templates sind eine Art zusätzlicher Parameter, der beim Compilen bestimmt wird. Im Gegensatz zu anderen Parameter können sie auch Typen enthalten. Sie sind sehr praktisch, wenn man eine allgemeine Funktion oder allgemeines Objekt für verschiedene Datentypen haben will. Eine template-classe ist beispielsweise list, eine verkettete Liste aus der Standard library Mit
      Code
      list<int>

      erzeigt man eine Liste aus integern, mit

      Code
      list<string>

      eine aus Strings und mit

      Code
      list<MeineEigeneKlasse>

      eine für die selbst definierte Klasse. In C musste man noch Funktionen für alle drei Dateintypen selbst definieren und dadurch mehrmals fast den gleichen Code schreiben. Fast alles aus der Standard-library enthält templates, damit man es so allgemein wie möglich halten kann, deswegen spricht man auch von der standard template library, kurz STL.
      Templates selber können noch viel mehr, als nur Typen dynamisch zu machen und für solche Zwecke zwar sehr einfach, aber wenn man den vollen Funktionsumfang nutzen will, sind eines der kompliziertesten Dinge aus C++. Sie haben quasi den Umfang einer kompletten Programmiersprache, die aber während des Compilens umgesetzt wird und so maximale Übersichtlichkeit und Sicherheit bei keinem Geschwindigkeitsverlust bieten.


    • RAII:

      Dieses ist wohl der wichtigste Punkt, denn dieses Konzept ist das grundlegende für sauberes C++, vermeidet fast alle Flüchtigkeitsfehler, die zu Memory Leaks, fehlerhafter Threadsteuerung oder anderen fehlern bei Resourcen führen. Es wurde früher schon eingeführt aber enthielt immer noch Lücken, in C++11 (der neue Standard von 2011) wird es aber konsequent und fast vollständig umgesetzt und mit C++14 noch weiter ausgebaut. Es steht für Resource Acquisition Is Initialization und bedeutet dass alle Daten in Objekte gekapselt werden, die bei der Objekterzeugung zugewiesen und bei Zerstörung der Objekte vom Destruktor automatisch freigegeben wird.
      Zum Beispiel muss man in AutoIt Dateien mit FileOpen öffnen und mit FileClose wieder schließen. Dabei können Fehler auftreten, indem FileClose nicht aufgerufen wird.
      [autoit]Func foo()
      Local $file = FileOpen("Datei.txt")
      If $file=-1 Then Return SetError(1) ; beende mit exit code 1

      Local $string = FileRead($file, 5)
      If StringLen($string)<>5 Then Return SetError(2) ; beende mit exit code 2

      ; anderer code

      FileClose($file)
      EndFunc
      Hat die Datei weniger als 5 Buchstaben, wird frühzeitig mit Return abgebrochen, die Datei bleibt geöffnet und kann von anderen Programmen nicht mehr verwendet werden. Man kann die Datei aber auch nachträglich nicht mehr schließen, weil $file nur lokal ist und deswegen nach Ende der Funktion nicht mehr existiert. Man muss also an jedem möglichen frühzeitigen Ende alle Resourcen aufräumen.
      Bei AutoIt ist es aber harmlos, weil nur durch Return, ExitLoop, ContinueLoop, if-Abfragen, Switch und Select ein FileClose oder ähnliche Funktion ausgelassen wird, wobei nur Return wirklich relevant ist, weil man meistens am Ende der Funktion aufräumt.
      In C++ hingegen gibt es alle diese Fälle auch, aber zusätzlich auch noch goto, longjump (ähnlich wie goto, aber über Funktionsgrenzen hinweg), auf diese beiden sollte man aber meistens verzichten, und Exceptions, die an jeder Stelle des Codes ausgelöst werden können, auch innerhalb von aufgerufenen Funktionen und teilweise unabsehbar. Es kann auch passieren, dass beim Aufruf einer Funktion ein Parameter eine exception auslöst und so die Resource des andere Parameter nicht freigegeben werden kann. In C+ hat (und braucht) man auch deutlich direkteren Zugriff auf den Arbeitsspeicher und kann deswegen sehr leicht memory-leaks auslösen.
      C++ garantiert aber, dass alle Objekte beim Verlassen des Scopes gelöscht und die Destruktoren aufgerufen werden. Deswegen kapselt man die Resourcen in ihnen und egal was passiert (Außnahme Absturz), es ist gesichert, dass alle Resourcen freigegeben werden.
      Für Dateien gibt es fstream, das RAII und andere Vorteile in sich vereint und man sollte sie deswegen nutzen und nicht fopen und fclose. Will man einen container (array, liste, map, hashmap u.v.m.) haben, sollte man sich keine wie in C selbst basteln und mit Funktionen alles selbst verwalten und freigeben, sondern die fertigen nutzen, die neben RAII (auch die Destruktoren des Inhalts werden aufgerufen) auch generisch und damit übersichtlicher sind.
      Wenn ein Objekt länger als der Scope leben soll, dann kann man es dynamisch mit der Funktion new erzeugen und einen Zeiger darauf übergeben, aber dann muss man es auch wieder selbst freigeben mit delete (delete ruft auch den Konstruktor auf), aber ein Zeiger ist nicht RAII, denn wenn er gelöscht wird, bleibt der Speicher erhalten. Deswegen sollte man hierfür smart-pointer nutzen, denn diese existieren als Objekt, das den Speicher im Destruktor unter der Voraussetzung freigibt, dass es nicht vorher kopiert wurde, dann wird nämlich der Zeiger übergeben und das andere Objekt lässt ihn leben.

      [/autoit]

    Ich denke jetzt mal, dass ihr vielleicht nicht viel oder zumindest nicht alles verstanden habt, aber denkt daran, wenn ihr mal C++ lernt, euch hiermit und anderen Artikeln über modernes C++ auseinanderzusetzen, denn ein recht großer Teil der C++-Programmierer hat die Sprache nie wirklich verstanden oder verwendet noch Programmierweisen aus den 80ern, ohne zu beachten, dass sich C++ weiterentwickelt und besser wird. Leider ist ein Teil dieser Programmierer auch noch der Meinung Tutorials oder Bücher schreiben zu müssen und leider gibt es inzwischen sehr viele Bücher/Tutorials, die falsches beibringen.

    Mfg Marthog

  • Opteron - der neue heilige Gral?

    • Marthog
    • 31. August 2013 um 21:50

    Helfen kann ich jetzt nicht, aber brauchst du die denn wirklich? Die sind doch schon sehr teuer und vielleicht wäre es auch besser, zu warten, bis sie billiger sind.

    Und: Was hast du damit vor?

  • [GDI+] Sinus im Einheitskreis

    • Marthog
    • 25. August 2013 um 21:41

    Ein nützlicher Zweck fällt mir jetzt nicht ein, außer zu Lernzwecken.

    Es ist auf jedenfall ein sehr schönes Skript und sehr angenehm und übersichtlich geschrieben.

    $fPi hast du zweimal (einmal lokal und einmal global), außerdem könntest du es und andere Konstanten auch konstant machen.

  • C++ Dll & Autoit

    • Marthog
    • 13. August 2013 um 10:52

    Wenn du Standardkonformes C++ schreibst, sollten auch alle aktuellen Compiler das schaffen.
    Allerdings löst der gcc wesentlich mehr Fehlermeldungen und Warnungen aus, weil der VC++ sehr viel Murks einfach hinnimmt.
    Es kommt auch auf die C++ Version an.
    So unterstützt VC++ afaik noch keine range based for loops (foreach), eine neue gcc-Version kann hingegen fast alle C++11 Features.

    Code::Blocks ist kein Compiler, sondern nur die IDE, die Dateieditor und Compilersteuerung in einem ist. Als Compiler kann man eigentlich jeden nehmen (auch den Visual Studio Compiler), allerdings bietet sich für deine Zwecke gcc (genauer MinGW-w64) an.

  • C++ Dll & Autoit

    • Marthog
    • 13. August 2013 um 00:24

    Ich habe sehr lange die IDE, die zu Visual Studio gehört, benutzt.
    Allerdings wollte ich C++11 nutzen und das war nur ansatzweise umgesetzt. Ich bin dann zu Code::Blocks und MinGW gewechselt, die IDE ist zwar nicht so gut, aber dafür kann man jeden beliebigen Compiler dahinterpacken.

  • C++ Dll & Autoit

    • Marthog
    • 12. August 2013 um 21:48
    Zitat von PuReIroNie

    Meine Frage währ aber jetzt wie man sein (dll) Script in c++ als x64 compillieren kann?

    Das hängt vom Compiler ab. Soweit ich weiß kann man bei Visual Studio nur mit der kostenpflichtigen Version 64 bit compilen, dann kann man das aber ganz einfach umstellen.

    Beim gcc kann man das mit dem Commandlineparameter -m64 bzw. -m32 festlegen, vorausgesetzt man hat die richtige Version, bei Windows braucht man z.B. die hier. Die Projektdateien der IDE muss man natürlich entsprechend selber konfigurieren.

    Bei anderen compilern kenn ich mich nicht so genau aus, aber z.B. Clang und der Intel compiler (kostenpflichtig und extrem teuer) können das auch.


    Man sagt bei C++ übrigens nicht Skript.

  • C++ Dll & Autoit

    • Marthog
    • 12. August 2013 um 16:35

    Kompatibel geht gar nicht oder zumindest macht man das nie. Üblicherweise ist entweder dein Programm mit allen DLLs 64 bit oder alles ist 32 bit.
    Du musst halt zwei DLLs haben, eine für 32 und eine für 64 bit, oder dich auf eines beschränken.

  • C++ Dll & Autoit

    • Marthog
    • 12. August 2013 um 12:37

    Hast du auch für die richtige Plattform compiled bzw. ausgeführt? Vielleicht führst du automatisch mit 64 bit aus und die dll hat 32. Andersherum ist es eher unwahrscheinlich.

  • Irrlicht.dll - DLL Call

    • Marthog
    • 6. August 2013 um 16:35

    Keine Ahnung, aber tatsächlich schreibt der C++-Standard nichts vor.
    Man kann oft die Dlls nicht zwischen verschiedenen Compilern austauschen, also z.B. Irrlicht von Visual Studio mit einem gcc Programm verwenden.

  • Irrlicht.dll - DLL Call

    • Marthog
    • 6. August 2013 um 12:01

    Das simmt noch nicht ganz, denn wenn die Funktion auf Elemente des Objekts zugreift, dann muss sie wissen, welches Object sie gerade vor sich hat. Dazu muss der this-pointer (zeigt auf aktuelles Objekt) als zusätzlicher Parameter übergeben werden und zwar im ECX Register. Zusätzlich muss man noch die Calling convention beachten und gegebenenfalls als fastcall (Parameter liegen in Registern) aufrufen.
    Es ist auch nicht festgelegt, wie die vtable und die calling conventions genau aufgebaut sind und das kann sich bei jedem Compiler unterscheiden und nach anderen Versionen ändern.

    Die letzten Probleme kann man aber umgehen, indem man einfach eine DLL mit den Standardeinstellungen mit Microsoft Visual C++ 2010 compiled und diese behält.

  • Autoit zu C++ konverter

    • Marthog
    • 27. Juli 2013 um 23:30

    In C kann man Funktionen ohne Rückgabewert haben, in AutoIt gibt es immer einen Rückgabewert und wenn keiner gesetzt wurde, dann ist das 0.

    Alle Funktionen in AutoItC haben den Rückgabetyp Variant (kann verschiedene andere Typen annehmen) und für den Fall, dass noch nichts zurückgegeben wurde, muss hier eben die 0 zurückgegeben werden.

  • Autoit zu C++ konverter

    • Marthog
    • 26. Juli 2013 um 11:56

    Ja, aber es gibt noch viele Probleme, also eigentlich ist das Programm noch nicht brauchbar.
    Siehe hier

  • ObjT

    • Marthog
    • 22. Juli 2013 um 20:00
    Zitat von alpines

    Desweiteren würde ein ObjT2Assembler Interpreter nur auf einem emulierten Mikroprozessor in Windows funktionieren ansonsten muss man das auf einer Diskette haben und die booten.


    Ähh, nein. C++ wird doch auch zu Assembler und dann zu Maschinencode kompiliert und geht dann unter Windows.

    Zitat von alpines

    Soweit ich weiß ist doch Assembler prozesserabhängig und ist auf jeder CPU verschieden?


    Dann nimmt man halt LLVM. Das ist assemblerähnlich und wird in einem letzten Schritt in richtigen Assembler bzw. Maschinencode umgewandelt.

  • n-Body Simulation -> 64-Bit-Assembler + MultiThread + AssembleIt2() Update Benchmark

    • Marthog
    • 7. Juli 2013 um 21:55

    Dafür dass der PC schon fast 5 Jahre alt ist und die früher nach dieser Zeit hoffnungslos veraltet waren, ist mein Prozessor im Vergleich erstaunlich gut:

    Code
    Benchmark n-Body-Simulation
    
    
    Number Particles:		30000
    Processor:		Intel(R) Core(TM)2 Quad  CPU   Q8200  @ 2.33GHz
    Number Processors(Cores):	4
    Number Threads:		4
    Overall Time:		95.27 Seconds
    Number Loops benchmarked:	207
    
    
    Average Interacts/sec:	8.34e+009
    Maximum Interacts/sec:	9.71e+009
    
    
    Average Ticks/Interact:	15.87    CAUTION! Depends on real Clockticks!
    Minimum Ticks/Interact:	15.25    CAUTION! Depends on real Clockticks!
    
    
    Average Clockticks[Mhz]:	2333    CAUTION! Clockticks may NOT match if over/underclocked! Please insert the real Clockticks!
    Maximum Clockticks[Mhz]:	2333    CAUTION! Clockticks may NOT match if over/underclocked! Please insert the real Clockticks!
    
    
    Average Looptime:		444.39 Milliseconds
    Fastest Looptime:		370.72 Milliseconds
    Alles anzeigen
  • Dafür verwendet man "Dim"!

    • Marthog
    • 7. Juli 2013 um 11:43

    Das Problem bei Dim ist, dass man nicht weiß, ob man eine neue Variable anlegt oder eine alte ändert.
    Deine Funktion kann man auch so schreiben. In diesem Fall ist sehr übersichtlich, dass man ein neues Array erzeugt und dann das alte damit überschreibt.

    [autoit]

    Func _ArrayTest(ByRef $_aArray)
    Local $_aNewArray[2] = ["Hello", "World"]
    $_aArray = $_aNewArray
    EndFunc

    [/autoit]
  • n-Body Simulation -> 64-Bit-Assembler + MultiThread + AssembleIt2() Update Benchmark

    • Marthog
    • 6. Juli 2013 um 12:54

    Bei mir stürzt das Programm beim Starten sofort ab. Ich hatte erst den Verdacht, dass da irgendwo ein Befehl verwendet wird, der zu neu für meinen Prozessor (Intel Core 2 Quad Q8200) ist, aber ich habe keinen gefunden.


    Zitat von Andy


    Um bei den heute vorhandenen Multi-Cores das letzte an Power rauszuholen, habe ich auch noch Multithreading integriert. Das war wesentlich einfacher, als ich gedacht hatte... 8o


    Multithreading ist für solche Berechnungen auch sehr einfach und effektiv. Wirklich kompliziert wird es aber, wenn man mehrere Threads mit unterschiedlichen Aufgaben hat. Zur Zeit machst du es auch so, dass du jeden Frame neue Threads erstellst, dabei geht natürlich auch Zeit verloren. Dann kannst du in der Schleife, die wartet, bis alle Threads beendet haben, auch noch Sleep(0) einbauen, denn dadurch gibst du anderen Threads die Chance zur Ausführung.

  • Audi Fan aus Köln

    • Marthog
    • 5. Juni 2013 um 15:00

    Trooooololololo :party::party::party::party:

  • Audi Fan aus Köln

    • Marthog
    • 4. Juni 2013 um 14:35

    :rofl::rofl::rofl::rofl::rofl::rofl:

Spenden

Jeder Euro hilft uns, Euch zu helfen.

Download

AutoIt Tutorial
AutoIt Buch
Onlinehilfe
AutoIt Entwickler
  1. Datenschutzerklärung
  2. Impressum
  3. Shoutbox-Archiv
Community-Software: WoltLab Suite™