C++ fstream GPIO Trigger/Interrupt

[alexander_ro]

Der 64 Bit Prozessor arbeitet am schnellsten wenn er 64 Bit Wörter vergleicht. Dafür gibt es auch entsprechende Befehle die auch für String vergleiche taugen. Bei kurzen Strings und einem 32 Bit enum wird der Unterschied daher in der Schnelligkeit nicht so groß sein. Der GCC kann Dir den Assemblercode zugeordnet zu den C++ Sourcecode ausgeben. Da findet man das dann relativ leicht was er daraus macht. Erklärungen zu den Assembler befehlen findet man bei ARM.

Wenn Du bei mir als Logstatus Debug angibst dann wird nur Debug ausgegeben. Wenn Du Debug und Error ausgeben willst musst Du auch beides angeben. Die Log Klasse hat einen Logstatus (was soll ausgegeben werden) die LogMeldung einen Loglevel (Priorität diese Log Meldung). Das soll so sein. Logisch muss man einen if machen den muss man aber bei einem enum auch machen.

Der Linux Debugger macht das nur wenn er entsprechend konfiguriert wurde. Früher konnten die das gar nicht.

Du hast jetzt einfach die Zeit bei dem Kritisch unterschlagen ...
Zeitkritische Programmteile sollten kein Log ausgeben. Jedes Log auch vom syslog ist sehr teuer was Zeit betrifft.

Du hast da sicher recht das die Verwendung eines Strings ein bisschen Zeit kostet. Fast immer wird aber die Log Meldung so nur im Fehlerfall ausgegeben. Sehr oft für der Fehler zum sofortigen Programm Abbruch. Ich war aus Sicherheitsgründen schon immer der Meinung ein Programm sollte im Fehlerfall Infos Sammeln ausgeben und sich möglichst anständig beenden. Wobei ein exit schon problematisch ist weil dann keine Destruktoren mehr aufgerufen werden.

Wie sieht das denn mit dem Callstack bei den anderen aus?
Wenn ich einen brauchte habe ich den gdb bemüht. Des Programm starten zum Beispiel einfach bis zum Absturz laufen lassen. Dann kann man sich einen Callstack ausgeben lassen. In der Ausgabe des strace kann man den verfolgen. Oder wenn man die Erstellung eines Dump einschaltet kann man mit gdb diesen öffnen und ebenfalls den Callstack anzeigen lassen. Im Ideal Fall kann man es aus den Log Meldungen sehen.

[NumberFive]

Sorry aber das man mehr als ein Loglevel angeben muss geht wirklich an allem vorbei was ich so kenne. Normal gebe ich das Max an was ich sehen will.

Um ein Programm bis an den Punkt des Absturtz laufen lassen zu können brauche ich entweder gute User oder ein haufen log. Ich kenne nur immer wieder die Aussage Was hast gemacht als es Abgestürtzt ist ? Nichts ist einfach abgestürzt. Im Job Kontext sind jetzt gerade am Testen das immer Intern das Debug Level an ist aber nur bei Auftreten von einer Warn oder Error eintrag der Speicherbuffer geschrieben wird. Da kostet zwar Ram aber man kann sehen was kurz vor der Warn oder Error Meldung war ohne die ganze Zeit die Platte als Bremse zu haben. Wenn wir davon ausgehen das Logging nicht in eine Datenbank geschrieben wird was sich Natürlich in einfachen Systemen einfach nicht lohnt. Bei größeren Systeme schon aber das habe ich im Job leider noch nicht durch setzten können (im Job).

Bei den Dingen die Ich programmiere ist das Laufen lassen bis zum Crash definitiv nicht möglich weil wie gesagt andere Programme / Hardware die "User" sind und die sind nicht Transportiert bar.

https://tuxthink.blogspot.com/2012/0...log-level.html
https://www.linuxquestions.org/quest...-crond-273547/
https://logging.apache.org/log4cxx/l...1_1_level.html

Loglevel immer Int

[alexander_ro]

Ich habe nie behauptet meine Log Klasse würde sein wie andere wäre sie das wäre es nicht sinnvoll eine neue zu bauen. Mich hat das schon oft genervt das man oft Loglevel einschalten muss die ich nicht haben will nur weil der zwischen den anderen liegt. Also ich will genau das sehen was für den Zweck wichtig ist und sonst nichts. Das macht das Log nur unübersichtlich und das wichtige wird dann übersehen. Da helfen Tools zum Auswerten auch nur bedingt.

Wenn man in Programmen Fehler sucht die andere Testen sollte man einen Speicherdump erzeugen lassen. Dann kann man ganz leicht die Ursache der Problems finden. Hat man seine Hausaufgaben gemacht bei der Fehlerbehandlung ist das aber fast nie nötig weil dann in der Log Meldung steht was wo passiert ist. Das einzige was sich etwas Widerborstig anstellt sind Speicherlecks aber für die Problemfälle unter den Problemfällen gibt es den Dump. Auch die Nutzung der Compiler Makros die einem Programmzeile und Dateiname in eine Log Meldung schreiben können sind von echtem Wert beim Fehlersuchen. Das Programm mit strace starten kann man auch für andere User einrichten und die Ausgabe liefert weitere Infos die helfen können. Sollte ein Programm sich nur Aufhängen und nicht Abstürzen muss man sich zwar zu dem User hin bewegen kann aber dann mit dem gdb auch einen noch laufenden Prozess Debuggen. Das ist immer sehr hilfreich wenn ein Programm hängt und keinerlei Kommentar abgibt was schief läuft. Also Möglichkeiten an Informationen zu kommen gibt es viele da sind die eigen Debug Meldungen nur ein kleiner Teil und oft nicht hilfreich weil die letzten Meldungen vor aufhängen/Absturz so nicht mehr im Log auftauchen.

Ja aber selbst ein int ist schon viel zu groß für die paar Loglevel ...