Also, ich habe mit Hilfe von FPCUnit herausgefunden, dass eine Funktion mist ausspuckt. Also wollte ich mal nachschauen, was eigentlich nicht stimmt. Es ist mir gelungen, die Werte mit dem Debugger zu bekommen, allerdings überspringt mir der Debugger sämtliche relevante funktionen (in den Funktionen gesetzte Haltepunkte werden auch ignoriert). Und zwar betrifft das alle Funktionen, die den Fehler enthalten könnten, und nicht in assembler implementiert sind. Zuerst habe ich gedacht, es liegt am inline, aber dann hab ich oben eingefügt kein inline mehr, und ich kann nachwievor nicht debuggen.

Hier noch der Code, der nicht funktioniert (ctype wird zu TComplexf (komplexe Zahl mit einfacher genauigkeit) bzw TComplexd (das gleiche mit doppelter Genauigkeit), ftype wird zu single bzw double): Wie gesagt, das eigentliche Problem ist nicht, dass der code nicht funktioniert, sondern dass ich nicht debuggen kann

Geh doch mal logisch an die Sache. Du kannst es nicht debuggen, da inline an ist. Denke ist verständlich warum das nicht geht. Dann deaktivierst du inline, was auch sinnvoll ist, aber du kannst es dennoch nicht debuggen. Kann also nur heißen, dass Inline immernoch aktiviert sein muss.

In Delphi ist es im übrigen egal ob du hinter einem Definenamen noch etwas schreibst. Wenn du anstelle des Semikolons einen Buchstaben genommen hättest, dann wäre der Name des Defines ein anderer und er würde was anderes aktivieren. Allerdings Leerzeichen/Trennzeichen plus sonstwas führen nicht dazu, dass der Definename verändert werden. In Delphi mache ich gerne so etwas {.$define Blah} zu mindest in Delphi ist das Define dann nicht gesetzt. Um ganz sicher zu gehen ob das Define auch deaktiviert ist solltest du testweise darauf prüfen. Also {$ifdef inline}schlöff{$endif}. Wenn es aktiv ist bekommst du einen Fehler. Sinn dahinter. Du kannst defines auch global setzen lassen. Dann würde nur ein {$undef inline} helfen es wirklich zu deaktivieren. Oder aber du kannst nicht die Methode direkt debuggen sondern musst die Stelle debuggen an der du die Methode benutzt. Denn irgendwo muss der Code ja stecken.

Wenn ich das Semikolon weglasse, dann schreit er, weil da nach der Funktionsdeklaration ein Semicolon zu viel kommt.

ähm, der Sinn von dem define ist nicht, inline zu aktivieren, sondern dafür zu sorgen, dass er es ignoriert (also "inline;" durch ein Leerzeichen ersetzt). Übrigens hilft es auch nix, wenn ich inline manuel entferne (also einfch auskommentiere).

Ja, weil das dann ein Kommentar ist. Ist in FPC genauso.

Hilft anscheinend auch nicht. Also jedenfalls funktioniert das debuggen nicht besser als vorher.

Wirft keinen Fehler. Also ganz egal, ob vorher {$undef inline} steht oder nicht.

Ja, das ist ja gerade das Problem. Dabei bekomme ich dann das Ergebnis, aber ich weiß nicht, wo der Fehler passiert. Und klar gäbe es bei meinem momentanen Problem wohl noch andere Wege, den Fehler zu beheben, weil so viele Zeilen sinds nicht, allerdings hab ich ehrlich gesagt (wenn ich jemals so weit komme ) schon noch vor, sachen zu implementieren, die nicht 1:1 so auf Wikipedia stehen, dass ich die Formeln nur noch nach Pascal übersetzen muss. Und dann wäre es doch ganz Hilfreich, einen funktionierenden Debugger zu haben.

fallt mir grad so ein: kann das Problem sein, dass der code in einer .inc Datei steht? Ähm, schwachsinn, dann könnte er den asm Teil ja auch nicht debuggen...

Define: Da muss ich gestehen verstehe ich dann den Sinn hinter dem define überhaupt nicht. Im Zweifel solltest du dann mal schauen ob es ein globales Flag gibt was inlining reguliert. Bzw auch mal alle Binarys löschen und komplett neu Erzeugen lassen.

Debugging: Lass mich meine Aussage präzisieren. Inline sorgt ja dafür, dass ein Aufruf einer Methode durch den Code direkt ersetzt wird. An der Stelle wo du die Methode normal aufrufen würdest befindet sich dann direkt der Code. Allerdings nicht im High Level Debugger. Dort sieht man ja nur den Quellcode. In Delphi ist es möglich in die CPU Ansicht zu wechseln und sich direkt durch die CPU Befehle zu steppen. Damit kannst du die Funktionsweise von Inlinecode debuggen ohne inlining zu entfernen. Keine Ahnung ob FPC so was unterstützt.

FPC/Lazarus: Tja. Wenn alles fehl schlägt ist entweder der Debugger/Compiler fehlerhaft oder unnötig kompliziert aufgebaut. In einem Projekt von mir hatte ich schon mal das Problem, dass ich alles debuggen konnte außer die Unit um die es mir tatsächlich ging. Aber dann konnte ich die komplette Unit nicht debuggen und nicht nur Teile davon. Habe es dann irgendwann auch aufgegeben, weil mir das entschieden zu blöd war.

Ist eigentlich ganz einfach ersetzt jedes x durch y (ich schätz mal nur die, die ein kompletter Bezeichner sind, und nicht die, die mitten irgendwo drin stehen, habs aber nicht überprüft). Normalerweise benutzt man das zB um Funktionen für verschiedene Typen, die aber irgendwas gemeinsam haben nur ein mal implementieren zu müssen. (also ich hab zB TComplexf und TComplexd, die sich nur in ihrer Genauigkeit unterscheiden, aber ansonsten genau gleich funktionieren. Im Interface abschnitt deklariere ich die Funktionen für beide Seperat, in der Implementation (in einer eigenen Datei) wird es dann aber nur einmal implementiert, und dort bezeichne ich die komplexen Zahlen zB als ctype, und das ersetze ich dann mit $define durch den gewünschten Typen, und mit {$i implement.inc} sag ich dann, er soll die Funktionen bitte für die definierten Typen implementieren)

Allerdings kann man das (glaube ich) auch benutzen, eben um zB das inline zu entfernen, ohne es händisch auskommentieren zu müssen. Das Inline scheint aber sowieso nicht der (einzige) übeltäter zu sein, weil ohne kann ich genauso wenig debuggen.

In Lazarus soweit ich weiß auch. allerdings verstehe ich nicht allzuviel vom AT&T assembler code, oder wie der heißt. (bzw, wahrscheinlich würde ich sogar bissel was verstehen, wenn ich´s mir mal genauer anschaun würde, aber assembler zu debuggen ist allgemein nicht so lustig, besonders wenn man den Code nicht in asm geschrieben hat)

Das ist, was ich tue, wenn debugging nicht so will wie ich. Das {$define inline;:=} ist nicht sicher, weil der Compiler inlining auch und vorallem von sich aus aktivieren wird.

@Lossy: Ja, Lazarus kann auch asm und registerinhalte anzeigen. Prinzipiell ist das für die meisten aber eher weniger hilfreich.

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

ok, kann jetzt debuggen. Den Fehler in meinem code hab ich zwar noch nicht gefudnden, aber... wenigstens kann ich jetzt anfangen zu suchen

thx

edit: Fehler im code auch behoben

Ist es das? Also für jemanden der überwiegend nur Delphi entwickelt liegt die Funktion solcher defines nicht ganz auf der Hand. Von daher bin ich davon ausgegangen, dass du das Define inline setzen möchtest und nicht eine kompiler Codeersetzung ansteuerst.

CPU-Ansicht: Keine Ahnung wie es in Lazarus ist. Delphi zeigt aber praktischerweise die Hochspachen Codezeile immer mit an. Dadurch sind die Assemblerbefehle gruppiert und alles um ein vielfaches einfacher. Und ich weiß, dass das in der Regel nicht interessant ist. Aber zum Schauen was der Kompiler macht ist das okay. Oder falls man so überhaupt nicht debuggen kann als letzter Ausweg.

Hmmja, die Hochsprachenzeilen werden auch angezeigt. Aber wenn ich wissen will, was der Compiler macht, rufe ich den mit -al auf und lasse mir das lieber in eine Datei geben, und schaue mir das mit ordentlichem Syntaxhighlighting an. Für den Notfall, wenn der Debugger garnicht mehr will ists aber dennoch hilfreich…

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Tja. Jeder hat andere Preferenzen.