Programmiergerüchte
-
Bashar schrieb:
* OOP ist erstrebenswert.
:p
-
* ""es gibt Programmiergerüchte" ist ein Programmiergerücht" ist ein Programmiergerücht.
* Programmiergerüchte sind keine Programmiergerüchte
-
dust schrieb:
* ""es gibt Programmiergerüchte" ist ein Programmiergerücht" ist ein Programmiergerücht.
Endlich was Witziges.
-
dust schrieb:
* ""es gibt Programmiergerüchte" ist ein Programmiergerücht" ist ein Programmiergerücht.
* Programmiergerüchte sind keine Programmiergerüchte
Unwitzig
-
* Dies ist ein Programmiergerücht.
-
- ein programmiergerücht ist kein programmiergerücht.
~(ok, jetzt wirds albern)~
-
* Unregs lesen bevor sie schreiben
* Unregs werden ernst genommen
-
* Registrierte denken Internet sei serious business
-
* Unregs denken "Registrierte denken Internet sei serious business" sei kein Gerücht
-
_mngbd schrieb:
* rekursiv geht schief (in MISRA verboten?)
Ja:
Functions shall not call themselves, either directly or indirectly
Niemand kann ja garantieren, dass für die Rekursion genug Stack da ist... hm, ein Gerücht?
MISRA ist ein Fluch?
-
abc.w schrieb:
Niemand kann ja garantieren, dass für die Rekursion genug Stack da ist... hm, ein Gerücht?
Aber man sollte durchaus logarithmisch beschränkte Rekursion zulassen. Oder welche, die unabhängig von den Eingangsdaten nicht mehr als 1k benötigt. Bei Quicksort wird das zum Beispiel leicht erreicht, indem man immer die kleinere "Hälfte" rekursiv aufruft und die größere "Hälfte" die in eine Schleife umgewandelte Endrekursion machen läßt.
-
volkard schrieb:
Aber man sollte durchaus logarithmisch beschränkte Rekursion zulassen. Oder welche, die unabhängig von den Eingangsdaten nicht mehr als 1k benötigt. Bei Quicksort wird das zum Beispiel leicht erreicht, indem man immer die kleinere "Hälfte" rekursiv aufruft und die größere "Hälfte" die in eine Schleife umgewandelte Endrekursion machen läßt.
Ich kann mir gut vorstellen, es gibt dann jemanden, der sagt: "Herr volkard, alles schön und gut, aber stellen Sie sich vor, ein Auto muss bremsen und ABS fällt aus, weil es in der ABS Software eine schöne rekursive Funktion gibt, die aus unerklärlichen Gründen einen Stacküberlauf verursacht hat. Das Auto wird auf die Gegenfahrbahn geschleudert und es kommt zum Frontalzusammenstoß mit dem entgegenkommenden Auto..." usw.
-
Mit dem gleichen Argument kannst Du JEDEN Funktionsaufruf als gefährlich ansehen, denn vielleicht klappt er nicht, weil der Stackspeicher alle ist. Oder jede Funktion mit mehr als fünf lokalen Variablen. Oder jede Funktion mit mehr als 1k lokalen Variablen. Wo ist die Grenze?
Auf PCs sind 1k sicherlich null problemo. Auf Schwachrechnern mag man die Grenze auf 64 Bytes legen, wasauchimmer.
Aber Rekursion als solche zu verteufeln, ist nicht sehr gut.
-
außerdem könnte man jeder rekursiven Funktion ein zusätzliches Argument mitgeben, das die Rekursionstiefe mitzählt und bei Überschreitung weitere Selbstaufrufe verhindert.
-
volkard schrieb:
Aber Rekursion als solche zu verteufeln, ist nicht sehr gut.
MISRA-regeln sind zum grossen teil vorbeugende massnahmen. die gehen einfach davon aus, dass nicht jeder 100%ig weiss, wie tief seine funktionen rekursieren können, also verbieten sie's 'per default'. ist genau so bescheuert wie rote ampeln: auch wenn der nächste verkehrsteilnehmer 1km entfernt ist, losfahren darfste bei rot trotzdem nicht.
-
volkard schrieb:
Mit dem gleichen Argument kannst Du JEDEN Funktionsaufruf als gefährlich ansehen, denn vielleicht klappt er nicht, weil der Stackspeicher alle ist. Oder jede Funktion mit mehr als fünf lokalen Variablen. Oder jede Funktion mit mehr als 1k lokalen Variablen. Wo ist die Grenze?
Auf PCs sind 1k sicherlich null problemo. Auf Schwachrechnern mag man die Grenze auf 64 Bytes legen, wasauchimmer.
Aber Rekursion als solche zu verteufeln, ist nicht sehr gut.Ja, jeder Funktionsaufruf kann einen Stacküberlauf verursachen, aber es gibt z.B. Regeln oder Vorgaben in einem Projekt, wie viele Parameter eine Funktion maximal haben darf, wie viele maximal ausführbare Zeilen, wie viele maximal lokale Variablen... Ich bin nicht in diesem Bereich tätig (komme aus dem "car infotainment" Bereich, wo es mit MISRA und QAC++ Regeln lockerer ist) und weiss nicht genau, wie man es mit dem Stack genau garantieren kann. Ein Paar mal durfte ich mit den Green Hills Tools für V850 Mikrocontroller arbeiten und nach dem Kompilieren gab es eine Textdatei, in der Funktionen und alle Pfade und deren Stackverbrauch aufgelistet waren. Damit könnte man ja schon den Stackverbrauch eines Tasks recht genau abschätzen. Dann kann man das System laufen lassen, anhalten und sich mit dem Debugger die Stacks anschauen (so ungefähr mache ich das), Pi mal Daumen, 30% des Stacks müssen noch da sein (z.B).
Bei rekursiven Funktionen weiss man ja aber nicht, wie viel Stack vor dem rekursiven Funktionsaufruf noch frei sind. Es könnte ja sein, 30% sind frei, und dann wird die rekursive Funktion aufgerufen. Auch wenn diese Funktion einen Zähler zum Abruch o.ä. zur Absicherung hat, weiss man ja trotzdem nicht, ob die 30% ausreichen...
-
abc.w schrieb:
Bei rekursiven Funktionen weiss man ja aber nicht, wie viel Stack vor dem rekursiven Funktionsaufruf noch frei sind.
Ich gehe nur von rekursiven Funktionen aus, die ich beherrschen kann, zum Beispiel garantieren kann, daß die Tiefe nicht größer als 10 wird und pro Aufruf ausgemessen 20 Bytes draufgehen, macht nicht mehr als 200 Bytes.
Warum sollte man da weniger wissen, als bei normalen Funktionen?
-
volkard schrieb:
Ich gehe nur von rekursiven Funktionen aus, die ich beherrschen kann, zum Beispiel garantieren kann, daß die Tiefe nicht größer als 10 wird und pro Aufruf ausgemessen 20 Bytes draufgehen, macht nicht mehr als 200 Bytes.
Warum sollte man da weniger wissen, als bei normalen Funktionen?Es wird schwierig wenn die Rekursiontiefe von Funktionsargumenten abhängt was oft der Fall ist. Dann müßte die Funktieon alle Argumente ablehnen die eine bestimmte Tiefe verlangen
-
general bacardi schrieb:
Es wird schwierig wenn die Rekursiontiefe von Funktionsargumenten abhängt was oft der Fall ist. Dann müßte die Funktieon alle Argumente ablehnen die eine bestimmte Tiefe verlangen
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.
Oder auf PCs: Selbst bei 4GB Daten hat man nicht mehr als Rekursionstiefe 32.
-
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.ä.