Programmiergerüchte
-
Ok. Also ich denke, normalerweise wird es in einem Projekt so ablaufen, jemand stellt mit dem MISRA Checker fest, die Regel so und so "rekursive Funktionen nicht erlaubt" wurde verletzt. Diese Regel hat jemand explizit für dieses Projekt festgelegt. Dieser jemand ist dein Vorgesetzter oder der Kunde...
Dann heißt es entweder, weg mit der Rekursion, oder, Rekursion behalten und die Stelle besonders dokumentieren u.ä.
-
abc.w schrieb:
Ok. Also ich denke, normalerweise wird es in einem Projekt so ablaufen, jemand stellt mit dem MISRA Checker fest, die Regel so und so "rekursive Funktionen nicht erlaubt" wurde verletzt. Diese Regel hat jemand explizit für dieses Projekt festgelegt. Dieser jemand ist dein Vorgesetzter oder der Kunde...
Dann heißt es entweder, weg mit der Rekursion, oder, Rekursion behalten und die Stelle besonders dokumentieren u.ä.Ich widerspreche doch nur deiner Expertise "Niemand kann ja garantieren, dass für die Rekursion genug Stack da ist... hm, ein Gerücht?" und der Folgerung, Rekursion sei grundsätzlich gefährlich.
Und ich sage, daß es keine kluge Vorgehensweise ist, Rekursion generell zu verbieten. Projektweise oder Firmenweise oder MISRA-Branchenweise ist kein Problem. Jeder, wie er mag.
-
volkard schrieb:
...und der Folgerung, Rekursion sei grundsätzlich gefährlich.
rekursion hat auch keinen vorteil, ausser einer will zeigen, was für'n toller programmierer er ist. manche kommen auf die glorreiche idee, irgendwelchen mathematischen firlefanz wie 'ne fakultätsfunktion rekursiv zu proggen, und vergessen dabei, dass die rekursionstiefe linear in die höhe schnellt. in der realität bringt rekursion garnix und ist auch noch langsamer.
-
Falsch. Manchmal ist Rekursion schneller als der iterative Ersatz. Manchmal kriegt man's iterativ gar nicht hin (außer mit simulierter Rekursion durch einen künstlichen Stack, also keinerlei Zugewinn).
-
volkard schrieb:
Beispiel: Es gibt in der SetTopBox 1000 Programmplätze. Man will sie mit Quicksort sortieren (nur als Beispiel). Und man nimmt die von mir oben gesagte Modifikation und hat garantiert nicht mehr als Rekursionstiefe 10.
... im Mittel hast du recht. Im Worst-case kann der normale Quicksort aber Rekursionstiefe O(n) erreichen.
Da nimmt man besser abgewandelte Quicksorts mit besserem Worstcase-Verhalten, heapsort (der zwar im Mittel schlechter, aber im Worst-case besser ist) oder Introsort, der bei Überschreiten der Rekursionstiefe O(log n) auf heapsort "umschaltet".
-
u_ser-l schrieb:
volkard schrieb:
Beispiel: Es gibt in der SetTopBox 1000 Programmplätze. Man will sie mit Quicksort sortieren (nur als Beispiel). Und man nimmt die von mir oben gesagte Modifikation und hat garantiert nicht mehr als Rekursionstiefe 10.
... im Mittel hast du recht. Im Worst-case kann der normale Quicksort aber Rekursionstiefe O(n) erreichen.
Ich habe im worst case recht. Lies doch nochmal genau. Die Modifikation ist ein paar Postings vorher genau beschrieben.
-
ja, mit dem modifizierten Quicksort hast du recht.
-
volkard schrieb:
Ich widerspreche doch nur deiner Expertise "Niemand kann ja garantieren, dass für die Rekursion genug Stack da ist... hm, ein Gerücht?" und der Folgerung, Rekursion sei grundsätzlich gefährlich.
Und ich sage, daß es keine kluge Vorgehensweise ist, Rekursion generell zu verbieten. Projektweise oder Firmenweise oder MISRA-Branchenweise ist kein Problem. Jeder, wie er mag.Also irgendwelche Folgerungen habe ich nicht gezogen. Ist ja auch egal.
Eins muss man vielleicht dazu sagen: MISRA macht keine Verbote. Da haben sich "einfach" einige Spezialisten zusammengesetzt und haben "einfach mal so" die Regeln vorgeschlagen, die wenn man die befolgt, zu besserer Software führen sollen, so nach dem Motto "Software rostet nicht" .
Software rostet nicht - ein weiteres Gerücht?
-
volkard schrieb:
Falsch. Manchmal ist Rekursion schneller als der iterative Ersatz. Manchmal kriegt man's iterativ gar nicht hin (außer mit simulierter Rekursion durch einen künstlichen Stack, also keinerlei Zugewinn)
ok, algos wie den qsort z.b. dann sach ich mal: rekursion nur, wenn's nicht anders geht. zur not mit 'nem selbstgemachten stack, dessen füllstand die rekursive funktion selbst überprüfen kann. das entlastet den prozessor-stack und der aufrufer der funktion braucht sich keine gedanken zu machen, ob sein input zum absturz durch stack overflows führen kann. wer sowas wie fakultät, fibonacci-zahlen, permutationen, towers of hangeul. usw. braucht, der sollte trotzdem auf rekursion verzichten, auch wenn der code mit rekursion schicker und einfacher aussieht. schliesslich sind nicht alle compiler so schlau und machen aus rekursiven formulierungen schleifen.
-
* hier kann man auch nach 5 Seiten beim Thema bleiben
* Wer goto benutzt, bekommt Besuch von einem Velociraptor
-
abc.w schrieb:
MISRA macht keine Verbote. Da haben sich "einfach" einige Spezialisten zusammengesetzt...
aber C spezialisten waren's wohl nicht
79 (req): The value returned by void functions shall not be used
^^was soll den dieser 'value' sein? wie kommt man da ran?
-
zwutz schrieb:
* hier kann man auch nach 5 Seiten beim Thema bleiben
-
* Rechtschreibung wird überbewertet