Pro-Tipp: printf
-Debugging funktioniert auch im Release-Modus. 😇
Oder wie Brian Kernighan sagen würde:
The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.
Anmeldungsdatum: Beiträge: 229 |
Pro-Tipp: Oder wie Brian Kernighan sagen würde:
|
||
(Themenstarter)
Anmeldungsdatum: Beiträge: 6339 Wohnort: Hamburg |
Ja, davon habe ich auch noch viele drin. Wenn eine Dateiliste abgearbeitet wird, ist das oft die schnellste Methode um festzustellen, dass die 4711-te der Übeltäter ist. Bisher lasse ich den Debug-Code meisten drin damit ich nach einem Programmabsturz im Coredump/Traceback einen Hinweis auf die Absturzstelle bekomme. Von Unit-Tests habe ich natürlich auch schon gehört, aber als Nicht-Profi habe ich wenig Ahnung wie man so etwas umsetzt. Ich bin nur Funkamateur und Software-Bastler. Das bringt es dann mit sich, dass ich mich gelegentlich auch mal in der digitalen Signalverarbeitung versuche. Mein Code für ein IIR Filter sieht z.B. so aus:
Da will ich definitiv keine Smartpointer oder std::deque dabei haben. Im mikrocontroller Forum hat das mal jemand gemacht; also in Java einen gleitenden Mittelwert (ist auch nur ein Filter) mit einer deque realisiert. Also immer die artig die neuen Werte vorne reingeschoben und die alten hinten gelöscht. Viel umständlicher geht es nicht. Normal macht man das mit einem Ringpuffer. |
||
Ehemalige
Anmeldungsdatum: Beiträge: 4563 Wohnort: Berlin |
@Dakuan: Ich finde Du denkst viel zu ”mikrooptimiert”. Man will Smartpointer und Container aus der Standardbibliothek (oder anderen Bibliotheken) verwenden. Es gibt nur sehr wenige Fälle wo man das nicht will. Du willst aber anscheinend eine GUI-Anwendung wie einen Mikrokontroller programmieren oder wie Code der tatsächlich richtig gut auf Laufzeit optimiert werden muss. Es ist aber wichtiger das Code läuft und korrekt ist. Und da schreibt man halt ein gleitendes Fenster auch mal mit einer deque. Und wenn das läuft und schnell genug ist, dann ist das völlig egal ob das deutlich umständlicher ist als ein Ringpuffer. An der Geschichte mit dem sortieren in einem anderen Thema von Dir sieht man IMHO ganz gut das Du Kämpfe an völlig falschen Fronten austrägst. Den Compiler zum inlinen zwingen zu wollen obwohl der Standard sehr deutlich sagt, dass das nicht geht, um 3 von 20 Sekunden oder so einzusparen, statt einen anderen Algorithmus/Datenstrukturen zu verwenden, die keine so horrende Laufzeitkomplexität haben und so schnell arbeiten das man die kleine Verzögerung kaum merkt. Über einen Debugger den generierten Maschinencode anzuschauen ist das allerletzte was man macht wenn man etwas optimieren will. Das habe ich bei normalen Systemen und den üblichen Problemen die man so hat, schon eeeewig nicht mehr gemacht. Das habe ich unter DOS gemacht, teils um Assembler zu lernen, teils weil die Compiler da regelmässig Code generiert haben, den man von Hand besser machen konnte. Die Zeiten sind vorbei. Es braucht heute schon spezielle und recht kleine Teilprobleme, bei denen es sich tatsächlich lohnt sich auf diese Ebene herunter zu begeben. Beim schreiben sollte man auf die Laufzeitkomplexität achten (Big-O-Notation) und da keine Böcke schiessen, und ansonsten erst einmal Wert auf eine saubere, verständliche, und fehlerfreie Implementierung legen. Bevor man anfängt zu optimieren erst einmal messen wo überhaupt die Flaschenhälse liegen, und wo es sich lohnt Programmierzeit in die Optimierung zu investieren. |