Beiträge von Marthog

Zitat von Friesel

Meiner Meinung nach ist in dem konkreten Beispiel oben und auch bei meinem Programm mit FileInstall der Vorteil, dass man nach dem Return nur den Code hinzufügen muß, der neu ist und nicht wie bei Switch/Case jedesmal den gesamten Code wiederholen muß.

Ich würde auch lieber das mit if und return nehmen. Switch ist nur bei entweder-oder Auswahlen wirklich sinnvoll, bei aufeinanderfolgenden Abfragen wird if verwendet.
Mit Switch könnte man das auch so lösen: (unübersichtlich)

Zitat von Friesel

Hast du das gemessen oder weiß man sowas einfach?

Bei den if-abfragen muss jedes Mal der Wert der Variable neu ausgelesen werden und dafür muss in der Liste aller Variablen nachgeschlagen werden, welcher Wert dazu gehört steht.
Bei Switch wird der Wert einmal bestimmt und dann nur noch verglichen.

EDIT:

Zitat von chesstiger

Letztendlich ist jede Konstruktion eigentlich nur JMP/GOTO.^^

Ja klar, aber letztendlich ist goto/jmp unübersichtlich, weil man nicht sofort weiß, wann und warum gesprungen wird.
Hat man hingegen While da stehen, weiß man, dass man eine Schleife hat, die solange gilt, wie die Bedingung zutrifft.
Bei goto kann als Schleife, if-Abfrage, Exception und möglicherweise sogar als Funktionsaufruf bzw. -rücksprung fungieren, man sieht aber nicht sofort, was es sein soll und wann es auftritt.

Das Ändern ist nicht möglich. GUIs sind zum möglichst übersichtlichen und angenehmen Benutzen da und dieses sollte in jeder Windows Version bleiben. Wenn du wirklich einen eigenen Stil setzen willst, musst du eigene Libraries verwenden. Mit der Uxtheme.dll kann man nur auf Windows 95 "resetten".

Die Fenster sehen alle so aus, wie es sich für das Betriebssystem gehört, man kann aber für diese den Windows 95-Modus erzwingen.

64-bit Systeme können Programme im 32-bit Modus ausführen und dann auch alle Dlls normal verwenden.

Wenn man es kompliziert genug macht wird man auch irgendwann Grenzen erreichen, an denen man Unterschiede finden, aber normalerweise braucht man das nicht.

Ich denke mal, deine Skripte gehen von der Komplexität nicht weit über von GUIs, Dateien und Netwerke hinaus, dabei brauchst du noch nicht wirklich auch das Betriebssystem achten.

Zitat von minx

Käntenglättung gäbe es nur durch Verwendung von GDI+ . Mal sehen ob ich mich dazu überreden lasse

Postprocessing? Man rendert erst in einen Buffer und diesen dann noch einmal mit entsprechenden Effekten in einen zweiten.

Bei der Irrlichtengine sind zwei Softwarerenderer dabei, wobei Burningsvideo echt gut ist und der andere sehr einfach. Unter Umständen kannst du da ein paar Tricks abschauen (Texturen etc).

Ich wäre da aber immer vorsichtig. Die verbreiteten Lizenzen wie GPL, FreeBSD und MIT wurden von Juristen kontrolliert und verbessert und haben teilweise auch schon Gerichtsverfahren hinter sich. Ich denke, dass in deiner Lizenz bestimmt irgendwo Stellen sind, die juristisch unklar sind und deswegen Streitereien verursachen könnten.

Viel sinnvoller als eine neue Lizenz finde ich eine Auflistung vieler bisheriger Open-Source Lizenzen, sodass man sich dann einfach und schnell welche aussuchen kann.

Du könntest versuchen die Dll zu laden und gegebenenfalls auf Fehler reagieren.

Local $bits
$dll = DllOpen("Dll.dll")
If $dll=-1 Then
$bits = 64-32*@AutoItX64
Else
DllClose($dll)
$bits = 32+32*@AutoItX64
EndIf

Alternativ kannst du auch mit

StringFormat("%.3f", 2.5)

die Zahl in einen String umwandeln und dabei festlegen, dass genau 3 Nachkommastellen angezeigt werden sollen.

Ich glaube nicht, dass EmptyWorkingSet da großartig hilft.
Entweder das Programm ist sauber und dann kommt es auch ohne klar, oder es ist nicht sauber, dann verzögert EmptyWorkingSet nur die Probleme, aber behebt sie nicht.
Es nützt nicht viel, nur die Symptome zu bekämpfen, man muss die Ursache beheben.

Wie man eine Resource freigibt, hängt von der Art ab. Dateien und FileSearches schließt man mit FileClose, manche WinAPI-Handles schließt man mit _WinAPI_DeleteObject.
Andere Resourcen werden vielleicht auch von eigenen Dlls geladen und müssen durch diese auch wieder freigegeben werden.
Man sollte nach Möglichkeit jede Resource ab dem Zeitpunkt wieder freigeben, ab dem man sie nicht mehr braucht.

Zitat von Freeman

Gibt es allgemeine Tipps zum Thema Arbeitsspeicher? Was kann man machen damit man nicht in meine Lage kommt?

Ja. Sauber programmieren und jede Resource wieder freigegen, wenn sie nicht mehr gebraucht wird.

Ich habe ja schon einmal erzählt, dass ich an einem AutoIt-Compiler arbeite, der AutoIt-scripte nach C++ übersetzt. Das Projekt habe ich deswegen AutoItC genannt.
Es besteht aus zwei Teilen, einem Converter und einer runtime library. In der runtime library sind alle Funktionen enthalten und diese werden dann mit dem compilierten Skript verknüpft.

Es gibt eine neue Version von AutoItC. Im Gegensatz zur alten wird nicht nur einfach eins zu eins umgewandelt, sondern ein abstrakter Syntaxbaum aufgebaut. Das erlaubt neben dem Beheben einiger Probleme der alten Version auch eine Reihe an Optimierungen.
Außerdem funktioniert das Variablensystem jetzt vernünftig, auch wenn ich dafür auf Geschwindigkeit verzichten musste.

Der Converter funktioniert mit Ausnahme von Kleinigkeiten schon, aber von den ganzen Funktionen sind noch kaum welche implementiert. AutoItC ist noch nicht für den Einsatz vorgesehen, denn neben fehlenden Features ist das ganze System auf Tests und nicht auf angenehme Benutzung ausgelegt.

Es gibt dazu auch ein Sourceforge Projekt und ich freue mich, wenn mir jemand dabei hilft.

In C++ ist multithreading auch schwer zu realisieren, weil große Teile der Standardlibrary nicht für gleichzeitignen Zugriff ausgelegt sind.

Hallo, Midakox
Die erste Programmiersprache sollte leicht sein. Das ist mit AutoIt gegeben.
Zudem hat man auch noch einen weit größeres Erfolgserlebnis. Während es bei anderen Programmiersprachen fast immer anfängt, die Grundkonzepte zu erklären und man langweilige Ausgaben in die Konsole hat, hat man bei AutoIt schon gleich eine MessageBox und kann davon Text, Titel und Icon ändern.

Für die Anfänge kann ich auch Lua empfehlen. Die Sprache ist wesentlich sauberer designed als AutoIt und hat auch einige andere Vorteile, aber gerade das mit dem Erfolgserlebnis fehlt zu großen Teilen.

Es gibt auch Leute, die sagen, man solle erst ausführlich die Grundlagen lernen und später dann zu praktischen und einfachen Sprachen wechseln, aber meine Erfahrung ist, dass Motivation das wichtigste ist du die dann am höchsten ist, wenn man sichtbare Ergebnisse hat und man die auch anderen zeigen kann.

Informatik und später auf Neuroinformatik spezialisieren

Ich werde nächstes Jahr anfangen zu studieren und denke, dass ein Tablet viele Vorteile hat, weil es übersichtlicher ist als eine Zettelsammlung und man trotzdem immer noch schnell und einfach Zeichnungen und ordentlich aufgeschriebene, mathematische Formeln einfügen kann. Das Tablet sollte schon in der Preisklasse von 500 Euro liegen, eine Tastatur haben bzw. damit erweiterbar sein.
Ich habe mich mal umgeschaut und das Google Nexus 10 macht einiges her, ich müsste es nur noch mit einem Keyboard-case kombinieren. Hat von euch jemand Erfahrungen damit und kann dazu raten, es zu kaufen oder nicht zu kaufen?

Statt Eval kann man auch eine andere Funktion verwenden, z.B. diese:

Func _($x)
Return $x
EndFunc

4 Byte für ein Integer ist doch nichts, aber wenn man immer wieder die Buchstaben zählen muss, dann dauert das doch ganz schön lange und vor allem kann man dann auch keine 0-Bytes im String haben.

So, ich kündige dann mal an, dass ich wohl demnächst eine Alpha-Version des Konverters herausbringen werde.
Zur Zeit fehlen von den wichtigen Sprachelementen nur noch Arrays.

Da es noch Alpha ist, sind Funktionen natürlich nur begrenzt vorhanden, also hauptsächlich mathematische und Stringfunktionen, sowie Ausgabe für Tests (MsgBox, ConsoleWrite, IniWrite).

Für alle, die es interessiert, stelle ich hier mal das Konzept vor:
Das AutoIt-skript wird vom Konverter eingelesen und alle AutoIt-Elemente werden in C++-Elemente umgewandelt. Vieles kann dabei so stehen bleiben, z.B. wird die Codezeile

($a+$b)*$c

genauso übersetzt.
Das konvertierte Script wird dann mit einem ganzen Satz von Header-files compiliert. Diese Header sind sozusagen die UDFs von C++. Darin ist der Typ definiert, den die AutoIt-Variablen haben, also ein Typ, der je nach Situation Integer, String, Float, etc. sein kann und darin sind auch die Standard-Funktionen von AutoIt.
Da das Compilen etliche Minuten dauern würde, sind in den Headern nur jeweils die Prototypen, aber was die Funktion genau macht, wird woanders definiert, nämlich in einer statischen Bibliothek. In dieser wurden die Funktionen schon alle compiled und müssen dann nur noch mit dem gerade konvertierten Skript zu einer Exe-Datei verbunden werden.

Ich denke, das wird so nichts. In ganz Irrlicht gibt es nämlich nur zwei normal exportierte Funktionen (createDevice und createDeviceEx), die man von außerhalb verwenden sollte.
Diese Funktionen erzeugen beide eine IrrlichtDevice, das ist ein Interface, also ein Pointer auf eine abstrakte Klasse.
Als Datentyp kannst du einfach einen pointer nehmen, aber den kannst du nicht einfach weiterverwenden.

Man kann das mit inline-assembler machen, das habe ich auch schon einmal ausprobiert (geht nur mit dlls, die mit VC++ compiled wurden):
Der Pointer zeigt auf einen Speicherblock. Darin sind alle Membervariablen, also alle lokalen Variablen des Objekts enthalten, man sollte aber nicht direkt darauf zugreifen, sondern nur über Methoden (Memberfunktionen). Dafür ist das erst DWORD wichtig, das ist nämlich ein pointer auf die sogenannte vtable. In der vtable sind die Addressen aller Funktionen aufgelistet, einfach der Reihe nach.
Das sind aber details, die man normalerweise nur beim Compilerbau beachten sollte, denn wenn z.B. in einer neuen Compilerversion oder Irrlichtversion die Reihenfolge der Methoden geändert wird, dann wiord auf die falschen zugegriffen.

EDIT: Ich denke, ich sollte auch mal auf die eigentliche Frage antworten. E_DRIVER_TYPE ist ein enum, also einfach ein 32 bit integer, dimension2d<u32> besteht auf zwei 32 bit unsigned integer (ulong), u32 ist ein 32-bit integer (ulong), IEventReceiver ein pointer auf eine Klasse, der aber optional ist (auch 0 sein kann).

$x = Random(0, 100)
If $x<80 Then
; case 0
ElseIf $x<90 Then
; case 1
Else
; case 3
EndIf
; case 2 fällt weg, da 0 Prozent

Wie viel hast du davon schon gemacht?
Da ich an dem AutoIt to C++-Compiler arbeite, kann ich sagen, dass es extrem viel Mühe ist, einen Parser zu schreiben und dabei alle Besonderheiten von AutoIt zu beachten. Die Implementierung der Funktionen ist ja später einfach nur Fleißarbeit, aber der Parser ist echt schwer.