Programmiergerüchte
-
* TGGC
-
* OOP ist erstrebenswert.
-
* es gibt programmiergerüchte
-
* "es gibt Programmiergerüchte" ist ein Programmiergerücht.
-
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...