Dummy-Variablen

[SBond]

Hallo Leute,

wisst ihr, ob man Dummy-Variablen erzeugen kann? Ich habe folgenden Fall:

Code: Alles auswählen

Macro _Mein_Makro (Prozedur, Prozedur_ergebnis)
	Prozedur_ergebnis = Prozedur
EndMacro


Procedure Tu_etwas()
	ProcedureReturn Random(100)
EndProcedure


Procedure Irgendetwas()
	Protected Dummy.i
	; ... Code...
	_Mein_Makro(Tu_etwas(), Dummy)
	; ... Code...
EndProcedure

Im Beispiel wird der Rückgabewert der Tu_etwas()-Prozedur durch das Makro in die Variable "Dummy" geschrieben. Meine Frage: gibt es eine Möglichkeit, den Rückgabewert ins Leere laufen zu lassen? Ich möchte, dass der zweite Makro-Parameter optional ist.

Um es genauer darzustellen:

Code: Alles auswählen

????? = meineProzedur()

wenn ????? eine Variable ist, dann ist es ja kein Problem. Der Rückgabewert wird dann in die Variable geschrieben. Aber wie könnte man ????? ersetzen, wenn keine Variable existiert? Ich weiß nicht ob man mit Compiler-Direktiven muss oder ob es einfacher geht. Bin da etwas ratlos

[SBond]

Code: Alles auswählen

Macro _Mein_Makro (Prozedur, Prozedur_ergebnis = Makro_Dummy)
	CompilerIf Defined(Prozedur_ergebnis, #PB_Variable)
		Prozedur_ergebnis = Prozedur
	CompilerEndIf
EndMacro

...ich denke so scheint es zu gehen. Ob das eine gute Entscheidung ist, werde ich dann noch sehen.

viele Grüße,
SBond

[_sivizius]

für was soll das sinnvoll sein?
ich meine, was spricht dagegen:

Code: Alles auswählen

DieVariable = ProzedurErgenisAnVariable()
ProzedurErgenisAnVoid()

Ansonsten

Code: Alles auswählen

Macro DQoute
  "
EndMacro
Macro move(func, retn=)
  CompilerIf DQuote#retn#DQuote = "" : func : CompilerElse : retn = func : CompilerEndIf
EndMacro

[SBond]

...hatte bisher noch nie wirklich mit Makros gearbeitet. Ich wollte ein Makro erstellen, das die laufende Prozedur abbricht, wenn eine aufgerufene Prozedur einen Fehler meldet. Dabei sollte ein Parameter optional sein und zwar der Rückgabewert der aufgerufenen Prozedur.

das Ergebnis sieht so aus:

Code: Alles auswählen

	Macro __Prozedur_bei_Fehler_beenden (Rueckgabewert, iFehlercode, Prozedur, Prozedur_ergebnis = _Makro_Var_Dummy_)
		
		CompilerIf Defined(Prozedur_ergebnis, #PB_Variable)
			Prozedur_ergebnis = Prozedur
		CompilerElse
			Prozedur
		CompilerEndIf
		
		; ermöglicht rekursive Fehlersuche
		If (_gebe_Modul_Statuscode() = #FC__Fehler)	
			_setze_Modul_Status (#FC__Fehler, iFehlercode, #PB_Compiler_FilePath, #PB_Compiler_Filename, #PB_Compiler_Module, #PB_Compiler_Procedure, #PB_Compiler_Line)
			ProcedureReturn Rueckgabewert
		EndIf
		
	EndMacro

Es funktioniert auch prima, aber es ist bestimmt noch verbesserungswürdig. ...naja, das ist einer meiner ersten Makros in PB


Eingebaut in einer Prozedur, sieht es so aus:

Code: Alles auswählen

	Procedure.i _gebe_Anzahl_der_Messpunkte (iTimer_ID.i)
		
		Protected iTimer_Index.i	= 0
		Protected iMesspunkte.i		= 0
		
		; Timer-Index ermitteln
		__Prozedur_bei_Fehler_beenden(0, #FC__Timer_existiert_nicht, _gebe_Timer_Index (@iTimer_Index, iTimer_ID))
		
		; Timer auswählen
		SelectElement(Timer\Timer(), iTimer_Index)
		
		; Anzahl der Messpunkte ermitteln
		iMesspunkte = ListSize(Timer\Timer()\Messwerte())
		
		; Prozedur beenden
		__Prozedur_beenden(iMesspunkte, #FC__Erfolgreich, 0)
		
	EndProcedure

[_sivizius]

warum machst du dir das so schwer und arbeitest nicht einfach mit

Code: Alles auswählen

  ProcedureReturn #PB_Compiler_Line

bzw. ich verstehe noch nicht den Sinn des Ganzen :-/

[SBond]

warum machst du dir das so schwer und arbeitest nicht einfach mit

Code: Alles auswählen

  ProcedureReturn #PB_Compiler_Line

immer die Programmzeile zurückzugeben bringt ja nichts .
Aber es ist auch gut möglich, dass du es nicht genau nachvollziehen kannst. Ich arbeite jetzt schon länger an meiner Software, die im finalen Zustand vorraussichtlich >80K Programmzeilen haben wird. Dementsprechend habe ich auch viele Module und Prozeduren, die untereinander Daten austauschen und irgendwelche Vorgänge ausführen. Um einen möglichst reibungsfreien Ablauf zu gewährleisten, ist es nötig die Vorgänge zu protokolieren, um bei möglichen Problemen oder Abstürzen die Ursache zu finden. Die reine OnError-Funktion zeigt zwar wo es knallt, allerdings lässt sich der Fehler nicht bis zur Ursache zurückverfolgen (denke ich mal). Ich bin daher dabei alle Prozeduren dahingehend zu erweitern, dass diese Meldungen über den Verarbeitungsstatus ausgeben. Würde ich es jedesmal als Returncode realisieren, dann ist es immer schwierig andere Daten zurückzugeben. Aus diesem Grund habe ich Makros geschrieben, die wie im Beispiel eine Prozedur ausführen, den Status speichern, einen Rückgabewert liefern und bei bedarf den ganzen Vorgang abbrechen, wenn ein Fehler auftrat. Würde ich das ohne Makro machen, dann würde ich mich ja totschreiben

Natürlich kommt es auch öfters vor, dass ich eine Prozedur aufrufe, ohne dass ich einen Rückgabewert benötige. In diesem Fall möchte ich ja nicht immer eine Variable deklarieren, in der sowieso nichts geschrieben wird. Aus diesem Grund brauchte ich eine Art Dummy-Variable, die in diesem Fall mögliche Rückgabewerte ins Leere schiebt.

aber es geht ja jetzt alles

viele Grüße,
SBond

[NicTheQuick]

Aber für sowas gibt es doch eigentlich den Debugger. Einfach an Stellen, wo es nicht knallen sollte, 'CallDebugger' aufrufen und dann mit der Prozeduren-Aufrufverfolgung, der Variablenliste, der Programmanalyse usw. durchs Programm steppen und schauen, woher der Aufruf kam.

[SBond]

während der Entwicklung stellt das kein Problem dar
Aber so kann auch im kompilierten Programm ausführliche Logdaten erstellen (je nach Parametrierung). Ein Absturz an sich sollte ja in der Regel nie auftreten, aber ich kenne mich ja (Div/0)

Naja, ich werde ja sehen wo ich mit meinem Vorhaben ende

[STARGÅTE]

Mich wundert es, dass du immer wieder Division durch Null ansprichst.

Ein Absturz passiert ja wirklich nur dann, wenn du eine Integer durch eine Integer 0 dividieren willst.
Bei Floats/Doubles bekommst du ja das Ergebnis + oder - Unendlich.

Hast du wirklich so viele male Divisionen mit Integers?

[SBond]

Hast du wirklich so viele male Divisionen mit Integers?

...jain, meistens dann, wenn ich z.B. Positionen o.ä. in Grafiken (in meinem Fall Oszillogramme) berechne. Sind ja ganze Pixel .
Paradebeispiel dafür war mein erstes größeres Programm mit PureBasic (http://www.purebasic.fr/german/viewtopi ... =8&t=26795). Zu der Zeit war ich aber auch absoluter Programmieranfänger und kannte PB erst knapp eine Woche.

Mittlerweile hat Häufigkeit dieser Fehler schon stark abgenommen, da ich in der Regel solche Fälle überprüfe. Aber je größer die Software wird, desto wahrscheinlicher ist es, dass sich irgendwelche dummen Fehler einschleichen.