Forward Declarations

Offen
  • Stimmt etwas nicht?
#89 1 Kommentar 2 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
35/100
Issue-Typ
Dokumentation
Klarheit
Größtenteils klar
Aktivitätsstatus
Veraltet
Tech-Stack
cpp
Bereich
documentation

Rechercherichtung

Beginnen Sie damit, den Dokumentationsabschnitt mit dem Titel "Forward Declare When Possible" zu finden und die ihn umgebenden Hinweise sowie alle verlinkten Referenzen zu lesen. Aktualisieren Sie die Empfehlung, um die im issue angesprochenen Bedenken hinsichtlich forward declarations widerzuspiegeln, und stellen Sie anschließend sicher, dass der Abschnitt in sich konsistent ist und die bevorzugte Vorgehensweise klar angibt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Regarding "Forward Declare When Possible", I think you should (almost) never forward declare for the following reasons:

  1. It makes backward compatible refactorings more complicated and prone to breakage. This is the reason that the the C++ Standard Library and abseil forbid forward declarations. In C++ you can often refactor a function into a lambda or function object or into a template and keep backward compatibility with uses of the function. However, the signature will have changed.

  2. It is dangerous. Forward declarations are an easy way to get hard to diagnose errors like ODR violations. In addition, if something changed in a header you were depending on, forward declarations postpone the error to link-time or to compile time.

  3. It is a short term optimization. Hopefully modules in C++ will come soon and make this better. But even without modules, such techniques as pre-compiled headers are safer and work in more scenarios.

Based on these, I think better advice would be to avoid forward declarations.

Vorherrschende Sprache
Keine Sprachdaten
Sterne
8.9k
Forks
903
Keine gemergten PRs in 30 T.

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus cpp-best-practices/cppbestpractices

Alle Issues in cpp-best-practices/cppbestpractices

Ähnliche Issues

Weitere Issues zu Documentation

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.