ClangFormat, ClangTidy basierend auf Google C++ Style Guide
-
Hallo zusammen,
ich hätte eine Frage. Kann mir jemand sagen, ob ClangFormat oder ClangTidy die Programmierrichtlinie "Exceptions" : (https://google.github.io/styleguide/cppguide.html#Exceptions)
aus dem Google C++ Style Guide überprüfen können ? Und wenn ja mit welcher Style Option?Vielen Dank vorab!
VG
Lisa
-
Benutze Exceptions!
-
Sieht nicht so aus. Google selbst sagt ja, dass die die Regel nur wegen Problemen in altem Code haben.
Es gibt in clang-tidy den Check
google-objc-avoid-throwing-exception
für Objective C, habe aber für C++ nichts gefunden.So habe ich gesucht:
$ clang-tidy-10 --list-checks --checks=\* | grep exception bugprone-exception-escape google-objc-avoid-throwing-exception hicpp-exception-baseclass modernize-use-uncaught-exceptions openmp-exception-escape
-
wob vielen Dank für deine Antwort.
Was meinst du mit, dass sie die Regel nur wegen Problemen im alten Code haben?Kann die Regel "Exceptions" überhaupt von einem Tool geprüft werden. Von cpplint wird sie nämlich auch nicht geprüft.
Und wie kann ich ermitteln ob ClangTidy oder ClangFormat diese Guideline überprüfen? https://google.github.io/styleguide/cppguide.html#Other_Features
VG
Lisa
-
@LisaMueller sagte in ClangFormat, ClangTidy basierend auf Google C++ Style Guide:
Kann mir jemand sagen, ob ClangFormat oder ClangTidy die Programmierrichtlinie "Exceptions" aus dem Google C++ Style Guide überprüfen können ? Und wenn ja mit welcher Style Option?
clang-format
ist nur für Code-Formatierung zuständig, dem ist es egal ob du mit oder ohne Exceptions programmierst.Ob
clang-tidy
das explizit überprüfen kann, weiss ich nicht. Ich würde vermuten, dass dir das Tool eher sagt, wo es in deinem Code Probleme mit der Exception Safety gibt. Nicht-exception-sicheren Code zu schreiben ist nämlich keine grosse Kunst.Im Zweifelsfall kompiliere dein Programm einfach mit dem
g++
/clang++
-Compiler-Flag-fno-exceptions
, dann bekommst du eine Fehlermeldung, wenn du irgendwo in deinem Codethrow
odertry
/catch
stehen hast. Dafür muss man nichtclang-tidy
bemühen.Ich empfehle dir allerdings nachdrücklich (!) immer exception-sicheren Code zu schreiben. Das geschieht bei konsequeter Anwendung von RAII und der Rule of 0/3/5 nahezu automatisch (lediglich bei der Implementierung eigener Container-Klassen kann es schonmal ein wenig komplizierter werden). Das schöne an exception-sicherem Code ist nämlich, dass er auch dann noch korrekt funktioniert, wenn keine Exceptions geworfen werden.
Google hat das offenbar in der Vergangenheit nicht befolgt, was ich für den Hauptgrund halte, dass es diese Regel gibt: Altlasten.
Mein Tip: Schreibe neuen Code stets so, dass er auch mit Exceptions korrekt funktioniert, egal ob du ihn für ein
-fno-exceptions
-Programm schreibst oder nicht. Dann kannst du die Frage, ob du letztendlich mit Exceptions arbeitest, vom jeweiligen Einsatzgebiet abhängig machen (es kann gute Gründe für beides geben), anstatt es dir (wie Google) von altem Code aufzwingen zu lassen.
-
@LisaMueller sagte in ClangFormat, ClangTidy basierend auf Google C++ Style Guide:
wob vielen Dank für deine Antwort.
Was meinst du mit, dass sie die Regel nur wegen Problemen im alten Code haben?Das steht doch in dem von dir verlinkten Dokument unter "Decision".
Zitat:On their face, the benefits of using exceptions outweigh the costs, especially in new projects. (...) Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions.
Die sagen, dass sie viel Code haben, der nicht mit Exceptions klarkommt und es deswegen für Google schwierig ist, den existierenden Code mit Code mit Exceptions zu verheiraten.
Kann die Regel "Exceptions" überhaupt von einem Tool geprüft werden. Von cpplint wird sie nämlich auch nicht geprüft.
Du könntest die ein Plugin für clang-tidy schreiben. Es gibt ja schon Plugins wie
hicpp-exception-baseclass
, welches checkt, ob alle Exceptions auch einestd::exception
(oder davon abgeleitete Klasse) werfen und warnt, wenn du was anderes wie z.B. einenint
oder einenstd::string
wirfst. Sollte nicht schwierig sein, das so anzupassen, dass du bei allen Exceptions eine Warnung bekommst. (wenn du das denn wirklich willst).