Effektive C++-Begriffe (dritte Ausgabe – übersetzt von Hou Jie)

Punkt 1: Behandeln Sie C++ als Sprachföderation

        [Die Richtlinien für eine effiziente C++-Programmierung variieren je nach Situation, je nachdem, welchen Teil von C++ Sie verwenden]

Klausel 2: Versuchen Sie, #define durch const, enum, inline zu ersetzen

        [Bei einfachen Variablen ist es am besten, #defines durch const-Objekte oder Aufzählungen zu ersetzen]

        [Für Makros, die wie Funktionen aussehen, ist es am besten, Inline-Funktionen anstelle von #define zu verwenden]

Punkt 3: Verwenden Sie nach Möglichkeit const

        [etwas als „const“ zu deklarieren, kann dem Compiler helfen, falsche Verwendung zu erkennen. „const“ kann auf Objekte, Funktionsparameter, Funktionsrückgabetypen und Member-Funktionskörper in jedem Bereich angewendet werden]

        [Der Compiler erzwingt bitweise Konstanz (Bitkonstante), Sie sollten jedoch beim Schreiben von Programmen „konzeptionelle Konstanz“ verwenden.]

        [Wenn konstante und nicht konstante Mitgliedsfunktionen im Wesentlichen äquivalente Implementierungen haben, kann Codeduplizierung vermieden werden, wenn die nicht konstante Version die konstante Version aufruft.]

Punkt 4: Stellen Sie sicher, dass Objekte initialisiert werden, bevor sie verwendet werden

        [Manuelle Initialisierung für integrierte Objekte, da C++ ihre Initialisierung nicht garantiert]

        [Für den Konstruktor ist es besser, die Anfangswertspalte des Mitglieds zu verwenden, anstatt die Zuweisungsoperation im Konstruktorkörper zu verwenden. Die in der Anfangswertspalte aufgelisteten Mitgliedsvariablen sollten in derselben Reihenfolge sortiert werden, in der sie in der Klasse deklariert werden.]

        [Um das Problem der „Initialisierungsreihenfolge über Kompilierungseinheiten hinweg“ zu vermeiden, ersetzen Sie bitte nicht-lokale statische Objekte (globale statische Variablen) durch lokale statische Objekte (lokale statische Variablen).]

Punkt 5: Wissen Sie, welche Funktionen C++ stillschweigend schreibt und aufruft

        [Compiler können heimlich Standardkonstruktoren, Standardkopierfunktionen, Standardoperatoren und Destruktoren für Klassen erstellen]

Punkt 6: Wenn Sie die vom Compiler automatisch generierten Funktionen nicht nutzen möchten, sollten Sie dies ausdrücklich ablehnen

        [Um die vom Compiler automatisch bereitgestellten Funktionen abzulehnen, können Sie die entsprechenden Mitgliedsfunktionen als privat deklarieren und nicht implementieren, oder nicht kopierbare Basisklassen verwenden, was ebenfalls üblich ist]

Punkt 7: Akkumulieren Sie virtuelle Destruktoren für den Polymorphismus

        [Die Basisklasse mit polymorpher Natur sollte einen virtuellen Destruktor deklarieren. Wenn die Klasse eine virtuelle Funktion hat, sollte sie einen virtuellen Destruktor haben]

        [Wenn der Entwurfszweck von Klassen nicht darin besteht, als Basisklasse verwendet zu werden oder keinen Polymorphismus zu haben, sollte der virtuelle Destruktor nicht deklariert werden]

Punkt 8: Lassen Sie nicht zu, dass Ausnahmen Destruktoren entgehen

        [Der Destruktor sollte niemals Ausnahmen ausspucken. Wenn eine vom Destruktor aufgerufene Funktion eine Ausnahme auslösen könnte, sollte der Destruktor alle Ausnahmen abfangen und sie verschlucken oder das Programm beenden.]

        [Wenn der Client auf eine während der Ausführung einer Operationsfunktion ausgelöste Ausnahme reagieren muss, sollte die Klasse eine gemeinsame Funktion zum Ausführen der Operation bereitstellen]

Punkt 9: Rufen Sie niemals virtuelle Funktionen während der Konstruktion und Zerstörung auf

        [Rufen Sie während der Konstruktion und Zerstörung keine virtuellen Funktionen auf, da solche Aufrufe nicht auf abgeleitete Klassen absteigen.]

Punkt 10: Operator= soll einen Verweis auf *this zurückgeben

        [Lassen Sie den Zuweisungsoperator einen Verweis auf *this zurückgeben]

Punkt 11: Umgang mit „Selbstzuweisung“ in „operator=“.

        [Stellen Sie sicher, dass sich „operator=“ gut verhält, wenn sich das Objekt selbst zuweist. Zu den Techniken gehören unter anderem der Vergleich der Adressen von „Quellobjekt“ und „Zielobjekt“, eine sorgfältige und durchdachte Sprachreihenfolge sowie Kopieren und
        Austauschen dasselbe Objekt, sein Verhalten ist immer noch korrekt]

Punkt 12: Vergessen Sie beim Duplizieren von Objekten nicht jede Komponente

        [Die Kopierfunktion sollte sicherstellen, dass „alle Mitgliedsvariablen im Objekt“ und alle Basisklassenkomponenten kopiert werden]

        [Versuchen Sie nicht, eine andere Kopierfunktion mit einer Zuweisungsfunktion zu implementieren. Sie sollten die gemeinsame Funktion in eine dritte Funktion einfügen und sie gemeinsam von den beiden Kopierfunktionen aufrufen.]

Punkt 13: Ressourcen mit Objekten verwalten

        [Um Ressourcenlecks zu verhindern, verwenden Sie bitte RALL-Objekte. Sie erhalten Ressourcen im Konstruktor und geben Ressourcen im Destruktor frei.]

        [Die beiden häufig verwendeten RALL-Klassen sind trl::shared_ptr und auto_shared. Ersteres ist normalerweise die bessere Wahl, da sein Kopierverhalten intuitiver ist. Wenn auto_ptr, wird es durch die Kopieraktion auf NULL zeigen]

Punkt 14: Seien Sie vorsichtig beim Kopierverhalten in Ressourcenverwaltungsklassen

        [Beim Kopieren eines RALL-Objekts müssen auch die von ihm verwalteten Ressourcen kopiert werden, sodass das Kopierverhalten von Ressourcen das Kopierverhalten von RALL-Objekten bestimmt.]

        [Universelle und gängige RALL-ähnliche Replikationsverhalten sind: Replikation unterdrücken, Referenzzählung implementieren, aber auch andere Verhaltensweisen können implementiert werden]

Punkt 15: Bereitstellung des Zugriffs auf Rohressourcen in Ressourcenverwaltungsklassen

        [APIs erfordern oft Zugriff auf Rohressourcen, daher sollte jede RALL-Klasse eine Methode zum „Abrufen der von ihr verwalteten Ressourcen“ bereitstellen]

        [Der Zugriff auf Originalressourcen kann durch explizite Konvertierung oder implizite Konvertierung erfolgen. Im Allgemeinen ist die explizite Konvertierung sicherer, die implizite Konvertierung ist jedoch für Benutzer bequemer.]

Punkt 16: Neu koppeln und löschen in derselben Form

       【Wenn Sie [] in new verwenden, müssen Sie auch [] im entsprechenden Löschausdruck verwenden. Wenn Sie [] nicht im neuen Ausdruck verwenden, dürfen Sie [] nicht im entsprechenden Löschausdruck verwenden.]

Punkt 17: Fügen Sie das neue Objekt in einer separaten Anweisung in den Smart Pointer ein

        [Speichern Sie das neue Objekt mit einer unabhängigen Anweisung im Smart Pointer. Wenn Sie dies nicht tun, kann es nach dem Auslösen einer Ausnahme zu einem nicht wahrnehmbaren Ressourcenleck kommen.]

Punkt 18: Stellen Sie sicher, dass Schnittstellen einfach und korrekt zu verwenden sind und dass sie nicht missbraucht werden können

        [Eine gute Schnittstelle lässt sich leicht richtig verwenden und nicht leicht missbrauchen. Sie sollten danach streben, diese Eigenschaften in allen Ihren Schnittstellen zu erreichen]

        [Zu den Mitteln zur „Förderung der korrekten Verwendung“ gehören Schnittstellenkonsistenz und Verhaltenskompatibilität mit integrierten Typen.]

        [Zu den Maßnahmen zur „Verhinderung von Missbrauch“ gehören das Erstellen neuer Typen, das Einschränken von Operationen an Typen, das Binden von Objektwerten und das Entfernen der Verantwortung für die Ressourcenverwaltung von Clients.]

        [trl:shared_ptr unterstützt einen benutzerdefinierten Löscher, der DLL-Probleme verhindern und zum automatischen Freigeben des Mutex-Wartens verwendet werden kann]

Punkt 19: Entwerfen Sie Klassen wie Sie, die Typen entwerfen

        [Der Entwurf einer Klasse ist der Entwurf eines Typs. Bevor Sie einen neuen Typ definieren, stellen Sie bitte sicher, dass Sie die in diesem Artikel behandelten Diskussionsthemen berücksichtigt haben.]

Punkt 20: Ersetzen Sie lieber den Pass-by-Wert durch den Pass-by-Referenz-zu-Konstanten

        [Versuchen Sie, pass-byvalue durch pass-byreference-to-const zu ersetzen. Ersteres ist normalerweise effizienter und vermeidet das Slicing-Problem. ]
        [Die oben genannten Regeln gelten nicht für integrierte Typen sowie STL-Iteratoren und Western Digital-Objekte. Für sie ist die Wertübergabe oft besser geeignet]

Punkt 21: Wenn Sie ein Objekt zurückgeben müssen, versuchen Sie nicht, seine Referenz zurückzugeben

        [Geben Sie niemals einen Zeiger oder eine Referenz zurück, um auf ein lokales Stapelobjekt zu zeigen, oder geben Sie eine Referenz auf ein Heap-zugewiesenes Objekt zurück, oder geben Sie einen Zeiger oder eine Referenz auf ein lokales statisches Objekt zurück, und Sie benötigen möglicherweise mehrere solcher Objekte gleichzeitig.
Punkt 4 bietet bereits ein Designbeispiel für die „vernünftige Rückgabe eines Verweises auf ein lokales statisches Objekt in einer Single-Threaded-Umgebung “.

Punkt 22: Mitgliedsvariablen als privat deklarieren

        [Denken Sie daran, die Mitgliedsvariable als privat zu deklarieren. Dies kann Kunden die Konsistenz des Zugriffs auf Daten ermöglichen, für die Abgrenzung der Zugriffskontrolle sind jedoch Versprechenseinschränkungen garantiert. Und bieten Sie Kursautoren volle Flexibilität]

        [geschützt ist nicht stärker gekapselt als öffentlich]

Punkt 23: Ning ersetzt Mitgliedsfunktionen durch Nicht-Mitglied und Nicht-Freund

        [Es ist besser, die Mitgliedsfunktion durch Nicht-Mitglied und Nicht-Freund zu ersetzen, was die Kapselung, Verpackungsflexibilität und funktionale Skalierbarkeit verbessern kann]

Punkt 24: Wenn alle Parameter eine Typkonvertierung erfordern, verwenden Sie hierfür Nicht-Member-Funktionen

        [Wenn Sie eine Typkonvertierung für alle Parameter einer Funktion durchführen müssen (einschließlich des metaphorischen Parameters, auf den dieser Zeiger zeigt), muss diese Funktion kein Mitglied sein]

Punkt 25: Erwägen Sie das Schreiben einer Swap-Funktion, die nicht auslöst

        [Wenn std::swap für Ihren Typ nicht effizient ist, stellen Sie eine Swap-Member-Funktion bereit und stellen Sie sicher, dass diese Funktion
keine Ausnahme auslöst.]
        [Wenn Sie einen Member-Swap bereitstellen, sollten Sie auch einen Nicht-Member-Swap zum Aufrufen bereitstellen das erstere. Gegnerklassen (keine Vorlagen), bitte spezialisieren Sie sich auch auf std::swap]
        [Wenn Sie swap aufrufen, sollten Sie die using-Anweisung für std!:swap verwenden und dann swap ohne jede „Namespace-Qualifikationsänderung“ aufrufen] [
        Für „user Es ist Es ist gut, „stdtempltes“ vollständig zu spezialisieren, aber versuchen Sie niemals, etwas völlig Neues zu „std“ in „std“ hinzuzufügen.

Punkt 26: Variablendefinitionen so lange wie möglich verzögern

        [Verzögern Sie das Erscheinen von Variablendefinitionen so weit wie möglich, was die Klarheit des Programms erhöhen und die Effizienz des Programms verbessern kann]

Artikel 27: Machen Sie so wenig Transformation wie möglich

        [Vermeiden Sie Umwandlungen, wenn möglich, insbesondere dynamische_ Umwandlungen in effizienzorientiertem Code.
Wenn es ein Design gibt, das Umwandlungsaktionen erfordert, versuchen Sie, alternative Designs zu entwickeln, die keine Umwandlungen erfordern.] [
        Wenn Umwandlungen notwendig sind, versuchen Sie, sie irgendwo dahinter zu verstecken eine Funktion. Clients können diese Funktion dann aufrufen, ohne die Transformation in ihren eigenen Code einzufügen.]
        [Verwenden Sie lieber eine Transformation im C+T-Stil (neuen Stil) anstelle einer Transformation im alten Stil. Ersteres ist leicht zu identifizieren und hat auch geheimere Aufgaben.]

Punkt 28: Vermeiden Sie die Rückgabe von Handles an objektinterne Komponenten

       [Vermeiden Sie es, Handles so zurückzugeben, dass sie auf das Innere des Objekts zeigen. Die Einhaltung dieser Klausel kann die Kapselung erhöhen, dazu beitragen, dass sich Cosnt-Memberfunktionen wie const verhalten, und die Möglichkeit „virtuell hängender Nummernschilder“ minimieren.]

Punkt 29: Das Streben nach „Ausnahmesicherheit“ lohnt sich

      [Ausnahmesichere Funktionen (ausnahmesichere Funktionen) lassen keine Ressourcen verloren und ermöglichen keine Beschädigung von Datenstrukturen, selbst wenn eine Ausnahme auftritt.
        Solche Funktionen werden in drei mögliche Garantien unterteilt: Basistyp, starker Typ und Ausnahmetyp hat praktische Bedeutung]
        [Die von einer Funktion bereitgestellte „Ausnahmesicherheitsgarantie“ entspricht normalerweise nur der schwächsten der „Ausnahmesicherheitsgarantien“ der von ihr aufgerufenen Funktionen]

Punkt 30: Verstehen Sie die Besonderheiten des Inlinings gründlich

        [Beschränken Sie die meisten Inlining-Funktionen auf kleine, häufig aufgerufene Funktionen, die den Debugging-Prozess und das Binär-Upgrade in Zukunft vereinfachen können, außerdem potenzielle Probleme bei der Codeerweiterung minimieren und die Geschwindigkeit des Programms maximieren können.

        [Funktionsvorlagen nicht als Inline deklarieren, nur weil sie in der Header-Datei erscheinen]

Punkt 31: Minimieren Sie die Abhängigkeiten bei der Dateikompilierung

        [Die allgemeine Idee, die die „Minimierung von Kompilierungsabhängigkeiten“ unterstützt, lautet: Abhängig von Deklarationen, nicht von Definitionen. Die beiden auf dieser Idee basierenden Methoden sind Handle-Klasse und Interface-Klasse]

        [Bibliotheks-Header-Dateien sollten in einer „vollständig und nur deklarativen“ Form vorliegen, die unabhängig davon gilt, ob die Vorlage entworfen wurde]

Punkt 32: Stellen Sie sicher, dass Ihr öffentliches Erbe eine Ist-Beziehung formt

        [Öffentliche Vererbung bedeutet is-a, alles, was für die Basisklasse gilt, muss auch für die abgeleitete Klasse gelten, da jedes abgeleitete Klassenobjekt auch ein Basisklassenobjekt ist]

Punkt 33: Vermeiden Sie es, geerbte Namen zu verschleiern

        [Der Name der abgeleiteten Klasse deckt den Namen der Basisklasse ab, und das hat bei öffentlicher Vererbung niemand erwartet]

        [Um den maskierten Namen wieder ans Tageslicht zu bringen, können Sie die using-Anweisung oder die Transferfunktion verwenden]

Punkt 34: Unterscheiden Sie zwischen Schnittstellenvererbung und Implementierungsvererbung

        [Die Schnittstellenvererbung unterscheidet sich von der Implementierungsvererbung. Bei der öffentlichen Vererbung erben abgeleitete Klassen immer die Schnittstelle der Basisklasse.]

        [Reine virtuelle Funktionen geben nur die Schnittstellenvererbung an]

        [Einfache virtuelle Funktion spezifiziert die Schnittstellenvererbung und die Standardimplementierungsvererbung]

        [Nicht-virtuelle Funktionen spezifizieren die Schnittstellenvererbung und die obligatorische Implementierungsvererbung]

Punkt 35: Erwägen Sie Alternativen zu virtuellen Funktionen

        [Alternativen zu virtuellen Funktionen umfassen NVI-Techniken und verschiedene Formen des Strategieentwurfsmusters. Die NVI-Methode
selbst ist eine spezielle Form des Entwurfsmusters für Vorlagenmethoden.]
        [Das Verschieben der Funktion von Mitgliedsnummern in klassenexterne Funktionen bringt den Nachteil mit sich, dass Nicht-Mitgliedsfunktionen nicht auf die nicht öffentlichen Mitglieder der Klasse zugreifen können] [ tr1:
        function Das Objekt verhält sich wie ein normaler Funktionszeiger. Ein solches Objekt akzeptiert alle aufrufbaren Entitäten, die „mit der angegebenen Zielsignatur kompatibel“ sind.]

Punkt 36: Definieren Sie niemals eine geerbte nicht virtuelle Funktion neu

        [Nicht-virtuelle Funktionen auf keinen Fall neu definieren]

Punkt 37: Definieren Sie niemals geerbte Standardparameterwerte neu

        [Definieren Sie niemals einen geerbten Standardparameterwert neu. Weil Standardparameterwerte statisch gebunden sind und virtuelle Funktionen – das Einzige, was Sie überschreiben sollten – tatsächlich dynamisch gebunden sind]

Punkt 38: „Hat-a“ oder „Erreicht durch etwas“

        [Zusammengesetzte Bedeutung unterscheidet sich völlig von öffentlicher Vererbung]

        [Im Anwendungsbereich bedeutet zusammengesetztes „hat-a“, im Implementierungsbereich bedeutet zusammengesetztes „is-implemented-terms-of]“

Punkt 39: Nutzen Sie das private Erbe klug und umsichtig

        [Private Vererbung bedeutet „is-implemented-in-ters of“ (implementiert gemäß etwas). Es hat normalerweise ein niedrigeres Niveau als Komposit. Wenn die abgeleitete Klasse jedoch auf die Mitglieder der geschützten Basisklasse zugreifen oder den virtuellen Wert von Lechenger neu definieren muss, ist dieses Design sinnvoll.] 【Im Gegensatz zur Komposition (Komposition) kann die private Vererbung zur Optimierung der leeren Basis führen
        . Dies kann für Bibliotheksentwickler wichtig sein, die an der „Minimierung der Objektgröße“ arbeiten.]

Punkt 40: Nutzen Sie die Mehrfachvererbung mit Bedacht und Bedacht

        [Mehrfachvererbung ist komplizierter als Einzelvererbung. Es kann zu neuen Unklarheiten und der Notwendigkeit einer virtuellen Vererbung führen.

        [Virtuelle Vererbung erhöht die Kosten für Größe, Geschwindigkeit, Komplexität der Initialisierung (und Zuweisung) usw. Wenn die virtuelle Basisklasse keine Daten enthält, ist dies die praktischste Situation.] [Mehrfachvererbung hat legitime Verwendungszwecke
        . Eines der Szenarios beinhaltet eine zweiphasige Kombination aus „öffentlichen erbt von einer Interface-Klasse“ und „privaten erbt von einer Klasse, die die Implementierung erleichtert“]

Punkt 41: Implizite Schnittstellen und Polymorphismus zur Kompilierungszeit verstehen

        [Sowohl Klassen als auch Vorlagen unterstützen Iterfaces und Polymorphismus]
        [Bei Klassen sind Schnittstellen explizit und konzentrieren sich auf Funktionssignaturen. Polymorphismus tritt
zur Laufzeit durch virtuelle Funktionen auf]
        [Für den Vorlagenparameter ist die Schnittstelle implizit (implizit) und basiert auf einem gültigen Ausdruck. Polymorphismus tritt zur Kompilierzeit durch Vorlageninstanziierung und Funktionsüberladungsauflösung auf.]

Punkt 42: Verstehen Sie die Doppelbedeutung von Typname

        [Bei der Deklaration von Vorlagenparametern können die Präfixschlüsselwörter class und typename vertauscht werden]

        [Bitte verwenden Sie das Schlüsselwort typename, um den Namen des verschachtelten untergeordneten Typs zu identifizieren. Es kann jedoch nicht als Basisklassenmodifikator in der Basisklassenspalte oder der Elementanfangswertspalte verwendet werden.]

Punkt 43: Lernen Sie, mit Namen in Basisklassen mit Vorlagen umzugehen

        [Dies kann durch Verweis auf den Mitgliedsnamen in der Basisklassenvorlage durch „this->“ in der abgeleiteten Vorlage oder durch einen klar formulierten „Basisklassenqualifikationsmodifikator“ vervollständigt werden.]

Punkt 44: Parameterunabhängigen Code aus Vorlagen extrahieren

        [Vorlagen generieren mehrere Klassen und mehrere Funktionen, daher sollte kein Teraplate-Code
eine Abhängigkeitsbeziehung zu einem Vorlagenparameter haben, die zu einer Aufblähung führt]
        [Code-Aufblähung durch nicht typisierte Vorlagenparameter (nicht typisierte Vorlagenparameter) Konten können häufig durch eliminiert werden Ersetzen von Vorlagenparametern durch Funktionsparameter oder Klassenmitgliedsvariablen]
        [Die durch Typparameter (Typparameter) verursachte Codeerweiterung kann häufig reduziert werden, indem gemeinsamer Implementierungscode für Instanziierungstypen erstellt wird.]

Punkt 45: Verwenden Sie Member-Funktionsvorlagen, die alle kompatiblen Typen akzeptieren

        [Bitte verwenden Sie Member-Funktionsvorlagen, um Funktionen zu generieren, die „alle kompatiblen Typen akzeptieren“]

        [Wenn Sie eine Mitgliedsvorlage für „generalisierte Kopierkonstruktion oder =-Operator“ deklarieren, benötigen Sie weiterhin den normalen Kopierkonstruktor und den =-Operator]

Punkt 46: Definieren Sie Nicht-Member-Funktionen für Vorlagen, wenn eine Typkonvertierung erforderlich ist

        [Wenn wir eine Klassenvorlage schreiben und die von ihr bereitgestellten Funktionen, die sich auf diese Vorlage beziehen, die implizite Typkonvertierung aller Parameter unterstützen, definieren Sie diese Funktionen bitte als Friend-Funktionen innerhalb der Klassenvorlage.]

Punkt 47: Verwenden Sie Merkmalsklassen, um Typinformationen darzustellen

        [Traitsklassen stellen „typbezogene Informationen“ zur Kompilierzeit zur Verfügung und werden mit Vorlagen und „Vorlagenspezialisierung“ implementiert]

        [Nach der Integration der Überladungstechnologie ist es für Merkmalsklassen möglich, zur Kompilierungszeit if-else-Tests für Typen durchzuführen.]

Punkt 48: Vorlagen-Metaprogrammierung verstehen

        [Template-Metaprogrammierung (TMP, Template-Metaprogrammierung, kann die Arbeit von der Laufzeit zur Kompilierungszeit verlagern und ermöglicht so eine frühzeitige Fehlererkennung und eine höhere Ausführungseffizienz] [TMP kann verwendet werden, um „basierend auf Richtlinienauswahlkombinationen“ (basierend auf Kombinationen von Richtlinienauswahlen) zu generieren
        . , kann auch verwendet werden, um die Generierung von Code zu vermeiden, der für einige spezielle Typen nicht geeignet ist]

Punkt 49: Verhalten neuer Handler verstehen

        [set_new_handler ermöglicht es Kunden, eine Funktion anzugeben, die aufgerufen werden soll, wenn die Speicherzuweisung nicht erfüllt werden kann]

        [Nothrow new ist ein eher eingeschränktes Tool, da es nur für die Speicherzuweisung gilt. Denken Sie daran, dass Konstruktoraufrufe dennoch Ausnahmen auslösen können.]

Punkt 50: Wissen Sie, wann Sie neue ersetzen und löschen müssen

        [Es gibt viele Gründe, ein benutzerdefiniertes neues und gelöschtes Dokument zu schreiben, darunter die Verbesserung der Leistung, das Debuggen von Heap-Anwendungsfehlern und Informationen zu mobilen Heap-Aufrufen.]

Punkt 51: Halten Sie sich beim Schreiben von Neu und Löschen an Konventionen

        [Operator new sollte eine Endlosschleife enthalten, in der er versucht, Speicher zuzuweisen, und wenn er die Speicheranforderungen nicht erfüllen kann, sollte er new-handler aufrufen. Es sollte auch in der Lage sein, 0-Byte-Anfragen zu verarbeiten. Die klassenspezifische Version sollte auch „eine größere (Fehler-)Anwendung als die richtige Größe“ verarbeiten]
        [Operator delete sollte nichts tun, wenn er einen Nullzeiger empfängt. Die klassenspezifische Version sollte auch „eine größere (falsche) Anwendung als die richtige Größe“ verarbeiten.]

Punkt 52: Platzierung schreiben, löschen, nachdem Platzierung neu geschrieben wurde

        [Wenn Sie einen Platzierungsoperator neu schreiben, stellen Sie bitte sicher, dass Sie auch den richtigen Platzierungsoperator löschen schreiben.
        Wenn Sie dies nicht tun, kann es in Ihrem Programm zu subtilen und zeitweise auftretenden Speicherlecks kommen.

Punkt 53: Compiler-Warnungen nicht ignorieren

        [Nehmen Sie die vom Compiler ausgegebenen Warnmeldungen ernst und streben Sie nach der Ehre „keine Warnungen“ auf der höchsten Warnstufe Ihres Compilers]

        [Verlassen Sie sich nicht zu sehr auf die Warnfunktion des Compilers, da verschiedene Compiler unterschiedliche Einstellungen zu den Dingen haben. Nach der Portierung auf einen anderen Compiler können die Warninformationen, auf die Sie sich ursprünglich verlassen haben, verloren gehen.]

Punkt 54: Machen Sie sich mit der Standardbibliothek einschließlich TR1 vertraut

        [Die Hauptfunktionen der C++-Standardbibliothek bestehen aus STL, iostreams und 1ocales. Und enthält die C99-Standardbibliothek
]
        [TRI fügt intelligente Zeiger (z. B. tr1:: shared ptr), verallgemeinerte Funktionszeiger (tr1:: function), Hash-basierte Container, reguläre Ausdrücke (reguläre Ausdrücke) und 10 weitere unterstützte Komponenten hinzu]
        [ TRI selbst ist nur eine Spezifikation. Um die Vorteile von TR1 nutzen zu können, benötigen Sie eine physische Kopie. Eine gute
Quelle in Form von Sachleistungen ist Boost]

Punkt 55: Machen Sie sich mit Boost vertraut

        [Boost ist eine Community und eine Website, die sich der kostenlosen Entwicklung von Quellcode und der Entwicklung von peer-reviewten C++-Bibliotheken widmet. Boost spielt eine einflussreiche Rolle im C++-Standardisierungsprozess]

        [Boost bietet viele TR1-Komponentenimplementierungen sowie viele andere Bibliotheken]

        

      

Supongo que te gusta

Origin blog.csdn.net/pan_1214_/article/details/127735641
Recomendado
Clasificación