Funktion ohne Wertübergabe aufrufen

[Adrian E. (ahsd)]

Hallo,
ich habe ein paar Fragen zur Wertübergabe in C.

- Wenn ich eine Funktion, die Werte erwartet, ohne Wertübergabe aufrufe, 
nimmt die Funktion für die Werte dann 0 an?

- Kann ich an eine Funktion auch nur einen bestimmten Wert übergeben, 
zum Beispiel den 2. ?

z.B.:

void funktion(uint8_t v1, uint8_t v2){

}

int main(void){

    funktion( /* möchte nur v2 übergeben */)

return 0;
}

[Bitflüsterer (Gast)]

Nein. Alle Parameter die deklariert sind, müssen auch übergeben werden. 
Andernfalls wird das Programm garnicht compiliert.

Falls Du etwas mehr Variabilität mit den Parametern möchtest, 
inbesondere optionale Parameter, dann such mal nach "vargs", "varargs", 
bzw. "variable Parameterlisten".

[Max H. (hartl192)]

Adrian E. schrieb:
> - Wenn ich eine Funktion, die Werte erwartet, ohne Wertübergabe aufrufe,
> nimmt die Funktion für die Werte dann 0 an?
Nein, "error: too few arguments" oder Ähnliches

> - Kann ich an eine Funktion auch nur einen bestimmten Wert übergeben,
> zum Beispiel den 2. ?
Man könnten für den Ersten einfach null übergeben

funktion(0,wert_fuer_v2);

[Adrian E. (ahsd)]

Alles klar, danke!

Es geht bei mir gerade um eine Funktion, die ein LED Display multiplext. 
Diese Funktion wird einerseits aufgerufen um die anzuzeigenden Zeichen 
zu übergeben, andererseits von der main() zum eigentlichen Multiplexen. 
Dann könnte ich sie vielleicht von der main() mit

Display(0,0,0,0);

aufrufen und eine Unterscheidung in die Funktion einbauen, damit das 
nicht das Display Löscht.

[Frank K. (fchk)]

Wenn Du statt C C++ verwenden kannst, hast Du die Möglichkeit, 
Default-Argumente zu verwenden.

int func(int a, int b=0);

Hier kannst Du optional den 2 Parameter weglassen - der Compiler setzt 
dann den Defaultwert ein. Weglassen kannst Du immer nur von hinten - der 
Compiler muss ja die Argumente zuordnen können.

fchk

[Rufus Τ. F. (rufus)]

Adrian E. schrieb:
> Diese Funktion wird einerseits aufgerufen um die anzuzeigenden Zeichen
> zu übergeben, andererseits von der main() zum eigentlichen Multiplexen.

Ist das ein geschicktes Design?

[Markus F. (mfro)]

Rufus Τ. Firefly schrieb:
>
> Ist das ein geschicktes Design?

Ist das eine rhetorische Frage?

[Udo S. (urschmitt)]

Markus F. schrieb:
> Rufus Τ. Firefly schrieb:
>>
>> Ist das ein geschicktes Design?
>
> Ist das eine rhetorische Frage?

Nein eher ein dezenter Hinweis darauf, daß eine Funktion eigentlich 
genau EINE Sache machen sollte.
Für 2 verschiedene Dinge nimmt man 2 verschiedene Funktionen, machen 
diese beiden zum Teil das Gleiche lagert man genau das GLEICHE in eine 
Unterfunktion aus.

Um zu wissen was im Falle des TOs sinnvoll wäre müsste man mehr über 
seinen Code wissen.

[Karl H. (kbuchegg)]

Udo Schmitt schrieb:
> Markus F. schrieb:
>> Rufus Τ. Firefly schrieb:
>>>
>>> Ist das ein geschicktes Design?
>>
>> Ist das eine rhetorische Frage?
>
> Nein eher ein dezenter Hinweis darauf, daß eine Funktion eigentlich
> genau EINE Sache machen sollte.

So könnte man das sehen.
Man könnte es allerdings auch so sehen, dass die Kombination aus 'main' 
und 'multiplexing' schon mal ein kräftiger Hinweis darauf ist, dass das 
Design schon mal grundsätzlich völlig daneben ist.
In einem vernünftig designtem Programm, welches einen Multiplex betreibt 
(egal ob 7-Segment, oder LED-Matrix oder der allseits so beliebte Cube), 
stellt sich die Frage nämlich gar nicht.

D.h. hier in der Anfrage verbergen sich eigentlich 2 Fragestellungen.
Die eine Fragestellung ist die, die tatsächlich gefragt wurde.
Die andere Fragestellung lautet: Warum stellt sich die erste Frage 
überhaupt? Die taucht nämlich in einem ordentlich gemachten Multiplexing 
überhaupt nicht auf und ist ein Hinweis darauf, dass da etwas 
grundsätzlich falsch angegangen wurde.

Ist ein bischen so, wie die Frage, wie man Papier-Aufkleber wasserdicht 
kriegt. Kann man natürlich fragen. Wenn sich dann aber rausstellt, dass 
der Aufkleber Roststellen im Kotflügel eines PKW abdichten soll, dann 
ist das schon mal die grundsätzlich falsche Vorgehensweise und die 
Frage, wie man den Aufkleber wasserdicht kriegt löst sich in Luft auf.

[Bitflüsterer (Gast)]

Alles soweit nicht unplausibel.

Nur wird die Frage ohnehin erst wieder als, "LEDs zu dunkel", oder 
"Interrupts stören serielle Übertragung" oder "Komischer Fehler in 
Hex-Werten" reinkarnieren, weil die bei den Profis so beliebten 
Nachfragen "wozu, warum, weshalb" als "unverschämte Einmischung - ich 
weiss schon was ich tue" oder "ihr wollt nur die Anfänger entmutigen" 
bei den TOs ankommen.

Aber gut. Wenn so bekannte Namen wie "Karl-Heinz B." oder "Einstein" das 
sagen, kommen vielleicht sogar Antworten darauf. Das die Bedeutung der 
Fragen "Warum, wie und weshalb" unabhängig vom Fragesteller ist, wird im 
Jahre 2054 eine kulturelle Revolution auslösen. Die wird zeitlich mit 
der kommerziellen Verfügbarkeit von RNA-Pillen zusammenfallen, so das 
sie nur so ungefähr die Zeit für den Gang zum Automaten übersteht. Neben 
"Spiegeleier selbstgemacht" auch "Kamasutra allein" oder "was ist und 
was sollen Argumente".


OK. Ich bin heut' irgendwie pessimistisch. :-)

[Peter D. (peda)]

Multiplexen lebt davon, daß die Leuchtzeiten exakt gleich sind, 
ansonsten flackert es.
Da die Mainloop je nach Aufgabe unterschiedlich lange braucht, ist das 
der schlechteste Platz.
Da ein Timerinterrupt spielend leicht gleiche Zeitintervalle erzeugen 
kann (dazu wurde er ja gemacht), ist er der ideale Platz zum 
Multiplexen.

[Adrian E. (ahsd)]

Peter Dannegger schrieb:
> Multiplexen lebt davon, daß die Leuchtzeiten exakt gleich sind,
> ansonsten flackert es.
> Da die Mainloop je nach Aufgabe unterschiedlich lange braucht, ist das
> der schlechteste Platz.
> Da ein Timerinterrupt spielend leicht gleiche Zeitintervalle erzeugen
> kann (dazu wurde er ja gemacht), ist er der ideale Platz zum
> Multiplexen.

Ich hatte den Thread nicht mehr gesehen nachdem die eigentliche Frage 
beantwortet war. Die Hinweise nehme ich gerne auf, ich werde kein 
Multiplexing vom main() loop aufrufen lassen, sondern es mit einem Timer 
lösen.

Dennoch, denke ich dass die Lösung mit main() ausreichend ist, wenn man 
bislang nur an der Ansteuerung des Display selbst arbeitet und sich 
wenige anderen Aufgaben in main() befinden.

LG,
Adrian.

PS: Es geht übrigens um HDSP2003 LED Displays. Und ja, ich weiß, dass es 
diesen Thread dazu gibt, allerdings wollte ich es mal selbst versuchen. 
Habe mich allerdings zugegebenermaßen etwas übernommen. Sprich: läuft 
noch nicht. Ich wollte den Code allerdings so noch nicht posten, sondern 
noch etwas drüber brüten. Ar enthält sicher einige Denkfehler...

Beitrag "HDSP2000 an Atmega48 einfaches Bsp."

[Peter D. (peda)]

Adrian E. schrieb:
> Dennoch, denke ich dass die Lösung mit main() ausreichend ist

Das heißt dann aber, sich doppelte Arbeit zu machen.

Die Interruptlösung arbeitet nämlich völlig anders. Sie gibt nur einen 
Bereich des SRAM (Bildspeicher) aus.
Die Umwandlung von Variablen in Zeichen und in das Pixelmuster macht 
dann das Main in aller Ruhe und nur, wenn sich der Wert auch ändert.