C-Frage zur Ermittlung Takt Cortex-M3

[Oha! (Gast)]

Hallo,

als Anfänger habe ich mir nun schon etwas C angetan und mache 
Trockenübungen mit der LPCXpresso-IDE (Super teil).
Ich hüpfe mit F3 so durch die ganzen LPCOpen-Deklarationen und verstehe 
folgendes nicht:

/* Return main clock rate */
uint32_t Chip_Clock_GetMainClockRate(void)
{
  uint32_t clkRate;

  if (Chip_Clock_GetMain_B_ClockSource() == SYSCTL_MAIN_B_CLKSRC_MAINCLKSELA) {
    /* Return main A clock rate */
    clkRate = Chip_Clock_GetMain_A_ClockRate();
  }
  else {
    /* Return main B clock rate */
    clkRate = Chip_Clock_GetMain_B_ClockRate();
  }

  return clkRate;
}

Nach dieser Funktion ist die Variable clkRate doch nicht mehr existent?
Warum wird sie dann angelegt, ihr ein Wert zugewiesen und dieser am Ende 
zurückgegeben? Es wäre doch kürzer und schneller einfach zu schreiben
return Chip_Clock_GetMain_A_ClockRate();
else
return Chip_Clock_GetMain_B_ClockRate();
Und sollten durch Aufruf von z.B. Chip_Clock_GetMain_A_ClockRate(); 
irgendwelche anderen Effekte erreicht werden, müßte es doch mit einem 
direkten return auch funktionieren?

[B. S. (bestucki)]

Ist eine Stilfrage. Manche mögen keine mehrfachen returns.

Die Variable clkRate existiert wahrscheinlich gar nie, der Compiler wird 
das optimieren.

[chris (Gast)]

Oha! schrieb:
> Es wäre doch kürzer und schneller einfach zu schreiben

Der Compiler optimiert die Variable sowieso weg.
Aber es ist wesentlich übersichtlicher, wenn es nur ein return am Ende 
der Funktion gibt, anstatt unzählige returns über die ganze Funktion zu 
verteilen.
--> Eine Frage des Programmierstils und der Übersichtlichkeit.

[Philipp (Gast)]

Beide Wege sind sind richtig und funktionieren. Das sind idr. 
Designentscheidungen und jeder machts wies ihm am besten gefällt.

[Frank K. (fchk)]

Wenn Du einen Debugger benutzt, kannst Du beim Debug Build einen 
Breakpoint vor dem return machen und Dir den Inhalt von clkRate 
anschauen.

fchk

[Oha! (Gast)]

Alles klar; Danke!