R: technische fragen

Mann, sind wir hier off-Topic... 😉
Habe ohnehin erst eben gemerkt, daß ich die alte colotris-Version "geprüft" hab. Den neuen Link hast Du ja wohl schon wieder entfernt... 😉
Hilfreich beim Feststellen, welche Libraries eine Applikation benötigt, ist noch immer Depends, welches Du z.B. im Platform-SDK findest.
Die LibCxx ist die "normale" Standard-Library, welche Funktionien wie strcpy und printf usw. abdeckt.
Die MSVCxxx sind, wie der Name schon sagt, die zur jeweiligen VC-Version passenden DLLs, die zusätzliche Funktionen wie z.B. Unicode-Handling beinhalten.
Wie Du schon geschrieben hast, kann man nicht gleichzeitig zu beiden Libraries linken und sollte sich auf die statische LIBCxx beschränken.
Die Debug/Release-Versionen sollten prinzipiell mischbar sein. Die Debug-Version enthält nur zusätzlichen Code, der z.B. bei Funktions-Aufrufen den lokalen Stack-Frame initialisiert oder grundsätzlich einen Frame-Pointer mitführt, auch wenn die Funktion gar keine lokalen Variablen hat.
Wenn Dein Programm nur in der Debug-Variante sauber läuft, hast Du wahrscheinlich irgend etwas nicht initialisiert (z.B. Elemente in Deinen Objekten).
In der Multi-Threaded LibCxx werden einige Symbole anders exportiert, als in der Single-Threaded-Variante. Schau' Dir einmal die Deklaration von errno an... Hier muß sich das Projekt und alle DLLs völlig einig sein.
Ansonsten hat das nur den Sinn, daß die DLLs z.B. den Zugriff auf zentrale Strukturen absichern. Folglich ist die MT-Variante grundsätzlich ein wenig langsamer. Ob Du sie brauchst, hängt nur davon ab, ob in Deinem Programm mehr als ein Thread werkelt (z.B. Sound-Ausgabe).
Wenn Du, so wie ich, die Standard-Library gar nicht verwendest (insbesondere nicht die I/O-Funktionen), kannst Du die Einstellung getrost auf Single-Threaded lassen.
So, jetzt reicht's erstmal...

ok, danke erstmal für deine info's !! vielleicht nehm ich nochmal einen anlauf und versuche mein programm im multithreaded modus (/MT) zu übersetzen. multithreading brauch ich wohl für die soundlib.

ach ja, die neue (defekte beta) und ein paar funktionierende alte betas findest du unter www.andre-krause.net/tetris/beta

Wie gesagt: Solange Deine Threads die Standard-Library (I/O und so weiter) nicht aufrufen, brauchst Du Dir um /MT keine Gedanken zu machen!

Was machst Du mit OLE? Bei mir fliegt er mit einem eindeutigen NULL-Pointer-Zugriff in OLE32 raus. (nach dem Laden von "fname:data/wav/voice_well_done.wav idx:2663324"
Du kannst Dir ja 'mal meine AutoDbg-DLL auf meiner Tools-Seite (http://www.tofahrn.de/tools) anschauen. Die listet Dir den ganzen Call-Stack auch bei einer Release-Version (mit den richtigen Compiler-Optionen, versteht sich).

@andreas: ja, ich komme wohl nicht drumherum, mir endlich mal die bedeutung der verschiedenen laufzeitbibliotheken klar zu machen und deine debug-dll werde ich auch probieren. denn so geht es nicht weiter *entnervt*. habe mich bisher sehr erfolgreich um solche probleme drumherumgemogelt, aber ab einer gewissen projektkomplexität geht es nicht mehr ohne vernünftiges debuggen. vielleicht war es auch ein fehler, so schnell auf visual studio .net 2003 beta(!!) upzugraden.. aber ich denke der fehler liegt wohl viel eher bei mir. hoffentlich kann ich vc6 noch parallel wieder dazuinstallieren..
OLE benutze ich überhaupt nicht - wirklich sehr komisch - ich wüsste auch nicht, welche lib davon abhängt. fltk-windowstoolkit jedenfalls bietet kein ole.
übrigens muss ich jetzt bei meinem uni-projekt eine weitere "lustige" erfahrung machen: mein programm stürzt im release-modus gestartet mit strg+f5 ab, aber im debugger läuft es problemlos. wie kann sowas sein? initialisiert mir der debugger etwa variablen / zeiger mit null, die sonst zufällig belegt wären? merkwürdig.

Quote:

---

OLE benutze ich überhaupt nicht

---

Hatte ich mir schon gedacht. Es lebe .net ...

Quote:

---

übrigens muss ich jetzt bei meinem uni-projekt eine weitere "lustige" erfahrung machen: mein programm stürzt im release-modus gestartet mit strg+f5 ab, aber im debugger läuft es problemlos. wie kann sowas sein? initialisiert mir der debugger etwa variablen / zeiger mit null, die sonst zufällig belegt wären? merkwürdig.

---

Die wesentliche Laufzeit-Änderung im Debug-Modus ist, daß jeder Stack-Frame initialisiert und mit einer Guard-Area versehen wird. Die Guard-Area hat den Sinn, übergelaufene Puffer festzustellen, was in der Regel recht zuverlässig funktioniert.
Die Initialisierung wird allerdings nicht mit 0 sondern mit CCh (INT3, Breakpoint-Code) durchgeführt. Damit sind garantiert alle Pointer auch bei Lesezugriffen ungültig (0xCCCCCCCC liegt in der Kernel-Area).
Bei numerischen Werten hängt die Wirkung natürlich stark von deren Bedeutung ab. Integer-Werte sind z.B. negativ, unsigned Variablen ziemlich groß.
Natürlich kostet das Füllen (beim Funktionseintritt) und das Testen (beim Verlassen der Funktion) entsprechend Zeit. Ob Du da ein Problem hast, kannst Du natürlich leicht feststellen, wenn Du in der Debug-Build die entsprechenden Optionen abschaltest. Näheres dazu habe ich Dir per Mail zukommen lassen (Du solltest auf Deiner Web-Site ggf. einen Mail-Link anbringen, und fehlendes Impressum/Kontakt/Urheber kann heutzutage auch teuer werden...).
In der Release-Build wird der Stack-Frame nicht initialisiert, sodaß die Variablen mit ziemlich zufälligen Werten gefüllt sind.
Beides hat natürlich einen unterhaltsamen Einfluß auf Bitfelder. In der Debug-Build haben diese logischerweise immer einen definierten Zustand.
Solange Du nur C verwendest, meckert der Compiler normalerweise ziemlich zuverlässig an, wenn Du auf eine lokale Variable lesend zugreifst, bevor diese initialisiert wurde (Ausnahme sind natürlich lokale Arrays, die über Zeiger verarbeitet werden).
Wenn Du C++-Objekte auf dem Stack liegen hast, wird hingegen keinerlei Warnung ausgespuckt, und die Fehler treten in der Regel erst viel später auf. Diese Dinger liebe ich ganz besonders, da man sie nur ziemlich schwierig findet...

Wo ich das hier so lese...
Anscheinend gibt es ja noch mehr Programiertechnisch begabte Leute in der Robot-Community (kann man das eigentlich schon so nennen? 😃
autofahrn, wie stehst du der Idee gegenüber aus Robot V ein open Source Projekt zu machen?
Wenn ich das richtig verstanden habe bist du im moment allein was Robot angeht.
Ich hab leider keinen Schimmer vom Programmieren (bekomme ja nichtmal die dämlichen Robot I Gatter in die richtige Reinfolge *g) aber mit anderen interessierten gemeinsam müsste es doch machbar sein, wenn man sich ein wenig abspricht, ein neues Projekt zu starten?
Was ins Officelle Tom Productions Release reinkäme und was nicht, müsstest du natürlich immernoch selbst entscheiden, aber zeichen und programmierarbeit aufteilen und gemeinsam Konzepte erarbeiten, anstelle sich von tausend Anfragen nerven zu lassen, wann es denn soweit ist, und was drin ist und warum du nicht dieses oderjenes Feature eingebaut hast, stelle ich mir besser vor...
Nur 'ne Idee 😃

So gut ich die Idee einer konzertierten Aktion ja auch finde, aber was von meiner Seite absolut dagegen spricht ist der Zeitaufwand.
An einem Spiel wie Robot III haben wir zu dritt ein knappes Jahr vollzeitmäßig beschäftigt. Wenn man da ein abendliches Freizeitvergnügen draus macht, wird das ein ewiges Unterfangen. Vom Aufwand der notwendigen Koordination einmal ganz abgesehen.
Wenn es irgendwann ein Robot V gibt, dann eines basierend auf dem Skript, das schon ewig hier rumliegt und mit Christian zusammen. Sonst wäre es nicht TOM Productions und wahrscheinlich auch kein Robot.
Und mit den ständigen Anfragen zu einem Robot V habe ich in den letzten 10 Jahren gut umgehen gelernt... 😉

@andreas: ich missbrauche mal wieder diesen thread 😉
also ich habe es nach 1 woche ständigem neucompilieren diverser opensource-libs endlich geschafft, mein tetris im multitreaded modus zu compilieren, also brauche ich jetzt tatsächlich nicht mehr die beiden runtime-dll's dazupacken. nur eine einzige exe-datei - kein installieren, kein deinstallieren 🙂
was mich eine woche aufgehalten hat: eine mit der soundlib sdl_mixer wurde eine statische ogg-vorbis lib mitgeliefert, die zur sdl_mixer lib hinzugelinkt wurde. die war aber anscheinend im single-threaded-modus compiliert. diese eine lib war wohl für die ganzen nicht aufzulösenden referenzen und anscheinend auch seltsame bugs verantwortlich.

Ach, das bestätigt mich 'mal wieder, nur die Standard-Schnittstellen vom System zu verwenden und alles andere ggf. selber neu zu schreiben. Kostet zwar auch immer ein wenig Zeit, aber wenigstens behält man den vollen Überblick...

Von welcher Programmiersprache sprechen wir hier eigentlich?
Mich nervt das nämlich auch, dass man zumindest bei Visual Basic jede Menge DLL-Dateien benötigt, um das kompilierte Programm dann auszuführen. So müssen auf jedem Rechner entweder die Visual Basic Runtime-Files (oder gar Visual Basic an sich) installiert sein oder ich muss ein Setup erstellen.

Was mich betrifft, so ist alles OK, wo ein C drin vorkommt. Also C, C++, Objective C (Mac). Aber auch A ist OK, so wie in Assembler.
Gilt also offensichtlich nicht für VisualBähsik... 😉 Nix gegen die Sprache an sich, vor allem für GUI-basierte Applikationen hat VB einige Vorteile. Aber bei mir geht's irgendwie immer um Performance oder Kompaktheit. Schonmal einen kompletten Logik-Simulator mit Library-Editor für Win32 in entpackten 460kB gesehen? Liegt auf meiner Web-Site (www.tofahrn.de) bei den Tools.

Für einige Sachen nehm ich auch lieber Turbo Pascal. Manche Sachen enden in VB manchmal in zu viel Fummelarbeit, vor allem, wenn man mal nur kurz was bestimmtes probieren wollte und nicht vor hatte, gleich ein komplettes Layout für das Programm mitzuerstellen.

@andreas: Auch C# ? 😀
---
Robert Schwortschik, Webmaster Game-of-Robot.de

Ist in ZehSharp etwa ein C ???
Nunja, zumindest einmal reingeschnuppert habe ich. Solange das aber eine proprietäre Plattform bleibt, ist das noch keine Option für mich.
Da wäre Java für mich sicher noch eher einarbeitungswürdig...

ich benutze visual c++
es wurde übrigens schon ein nachfolger von c++ angedacht, die programmiersprache "D"
(www.digitalmars.com)

Genau, da war doch was. Hab's mir eben nochmal angeschaut, die beschriebene Funktionalität ist schon beeindruckend. Bin mir aber nicht sicher ob sich die genannten Features nicht wieder negativ auf das Laufzeitverhalten auswirken.
Dynamische Arrays und Garbage-Collection. Das klingt schon wieder nach viel Code, den man nicht sieht. Davon gibt's schon bei C++ genug, vor allem wenn man fremde Klassen einsetzt.
Ich erinnere mich da an einen dicken Multiprozessor Sun-Application-Server, auf dem eine dicke Java-Applikation lief. Ging alles super, bis man ihn unter Last gesetzt hat. Alle CPUs haben fleissig Daten produziert, nur war das zu viel für den Garbage-Collection-Thread, welcher an eine CPU gebunden und damit viel zu langsam war. Ist schon schick, wenn ab einigen 100 Connects das Teil zuverlässig Core-Dumpt...
Zumindest vervollständigt das mein Sprach-Alphabet:
Assembler
Basic
Cobol, C, C++, C#
D (bischen langweilig..)
Eiffel
Fortran
g++ (Gnu C++-Compiler)
HcRtf (Microsoft Help-Compiler)
Wie geht's weiter?

HcRtf? Gibts den als Demo irgendwo zum Download?
--
www.windowsclone.de.vu
- games & progs for casio cfx-calculators
- some old games coded in QBasic
--

www.windowsclone.de.vu
- games & progs for casio cfx-calculators
- some old games coded in QBasic

Hmm, 'ne Demo habe ich davon noch nicht gesehen, allerdings ist das ohnehin frei verfügbar über den Help Workshop. Einfach 'mal nach "Help Workshop" googeln...