Ist es in Ordnung, C++ anzupassen?

Question

Für meine Projekte definiere ich normalerweise eine Menge Aliase für Typen wie unsigned int, char und double sowie std :: string und andere.

ich auch

• wird dies als schlechte Praxis oder in Ordnung zu tun aliased und etc. zu! Zu & &, oder ||, nicht wahr?

Answer 1

Das Definieren von Typen zum Hinzufügen von Kontext in Ihrem Code ist akzeptabel und wird sogar empfohlen. Sich mit Bedienern zu beschäftigen, wird nur die nächste Person ermutigen, die Ihren Code pflegen muss, um eine Waffe in Ihr Haus zu bringen.

Answer 2

Nun, betrachten Sie die Neulinge, die an C++ gewöhnt sind. Sie werden Schwierigkeiten haben, Ihr Projekt zu erhalten.

Beachten Sie, dass es viele Möglichkeiten für das effektivere Aliasing gibt. Ein gutes Beispiel sind komplizierte verschachtelte STL-Container.

Beispiel:

typedef int ClientID; 
typedef double Price; 
typedef map<ClientID, map<Date, Price> > ClientPurchases; 

Statt nun

map<int, map<Date, double> >::iterator it = clientPurchases.find(clientId); 

Sie

ClientPurchases::iterator it = clientPurchases.find(clientId); 

schreiben kann, das scheint klar und lesbar zu sein.

Answer 3

Wenn Sie es nur für sinnlos verwenden umbenennen Sprachfunktionen (im Gegensatz zu dem Beispiel @Vlad gibt), dann ist es die Wrong Thing.

Es macht definitiv den Code weniger lesbar - jemand, der C++ beherrschen wird (x ? y : z) sehen und wissen, dass es ein ternäres conditional operator ist. Obwohl ORLY x YARLY y NOWAI z KTHXkönnte die gleiche Sache sein, wird es den Betrachter verwirren: "Ist das YARLY NOWAI die gleiche Sache wie ? :, umbenannt für die Bequemlichkeit des Autors, oder hat es feine Unterschiede?" Wenn diese "Aliase" mit den Standardsprachelementen identisch sind, verlangsamen sie nur die nächste Person, die Ihren Code verwaltet.

TLDR: Lesen von Code, jeder Code, ist hart genug, ohne Ihre private alternative Syntax die ganze Zeit nachschlagen zu müssen.

Answer 4

Das ist schrecklich. Tu es bitte nicht. Schreibe idiomatisches C++, nicht irgendeine Makro-gespenstische Monstrosität. Im Allgemeinen ist es extrem schlechte Praxis, solche Makros zu definieren, außer in sehr speziellen Fällen (wie dem BOOST_FOREACH Makro).

Das heißt, and, or und not sind eigentlich bereits gültige Aliasnamen für &&, || und ! in C++!

Es ist nur, dass Visual Studio sie nur kennt, wenn Sie zuerst die Standardkopfzeile <ciso646> einschließen. Andere Compiler brauchen das nicht.

Typen sind etwas anderes.Die Verwendung von typedef zum Erstellen von Typaliasnamen je nach Kontext macht Sinn, wenn sie die Aussagekraft des Codes erhöht. Dann ist es ermutigt. Noch besser wäre es jedoch eigene Typen anstelle von Aliasen zu erstellen. Zum Beispiel kann ich mir nicht vorstellen, dass es jemals von Vorteil wäre, einen Alias ​​für std::string zu erstellen - warum nicht einfach std::string direkt verwenden? (Eine Ausnahme sind natürlich generische Datenstrukturen und Algorithmen.)

Answer 5

Wenn jeder C++ - Entwickler mit Ihren Aliasen vertraut war, dann warum nicht, aber Sie sind mit diesen Aliasen im Wesentlichen eine neue Sprache für jeden einführen, der Ihren Code pflegen muss.

Warum fügen Sie diesen zusätzlichen mentalen Schritt, der zum größten Teil fügt keine Klarheit (& & und || sind ziemlich offensichtlich, was sie für jeden C/C++ Programmierer tun, und eine Möglichkeit, in C++ Sie die and verwenden können und or keywords)

Answer 6

• „und“, „oder“, „nicht“ OK ist, weil sie Teil der Sprache sind, aber es ist wahrscheinlich besser, C++ zu schreiben in einem Stil, die anderen C++ Programmierer verwenden, und sehr wenige Leute stören sich, sie zu benutzen. Aliasieren Sie sie nicht selbst: Sie sind reservierte Namen und es ist im Allgemeinen nicht erlaubt, reservierte Namen auch im Präprozessor zu verwenden. Wenn Ihr Compiler sie nicht in seinem Standardmodus (dh es ist nicht standardkonform), Sie könnte sie mit #define fälschen, aber Sie können sich für Probleme in der Zukunft einrichten, wenn Sie den Compiler ändern oder Compiler ändern Optionen.

• typedefs für eingebaute Typen können unter bestimmten Umständen sinnvoll sein. Zum Beispiel gibt es in C99 (aber nicht in C++ 03) erweiterte Integer-Typen wie int32_t, die eine 32-Bit-Ganzzahl angeben, und auf einem bestimmten System, das ein typedef für int sein könnte. Sie kommen von stdint.h (<cstdint> in C++ 0x), und wenn Ihr C++ - Compiler dies nicht als Erweiterung bietet, können Sie im Allgemeinen eine Version von jagen oder schreiben, die für Ihr System funktioniert. Wenn Sie einen bestimmten Zweck haben, für den Sie vielleicht in Zukunft einen anderen Integer-Typ verwenden möchten (vielleicht auf einem anderen System), dann verstecken Sie auf jeden Fall den "echten" Typ hinter einem Namen, der die wichtigen Eigenschaften beschreibt, die der Grund sind Sie haben diesen Typ für diesen Zweck ausgewählt. Wenn du nur denkst, dass "int" unnötig kurz ist und es "ganzzahlig" sein sollte, dann hilfst du niemandem, selbst dir selbst nicht, indem du versuchst, die Sprache so oberflächlich zu verändern. Es ist eine zusätzliche Indirektion für keinen Gewinn, und auf lange Sicht ist es besser, C++ zu lernen, als C++ zu ändern, um "mehr Sinn" für Sie zu machen.

• ich nicht aus einem guten Grund denken kann für string einen anderen Namen zu verwenden, außer in einem Fall, ähnlich wie bei den erweiterten Integer-Typen, wo Sie Ihren Namen vielleicht ein typedef für string auf einige baut sein, und wstring auf Andere.

• Wenn Sie kein englischer Muttersprachler sind und versuchen, C++ in eine andere Sprache zu übersetzen, dann sehe ich Ihren Standpunkt, aber ich denke nicht, dass es eine gute Idee ist. Sogar andere Sprecher Ihrer Sprache werden C++ besser kennen, als sie die Übersetzungen kennen, die Sie zufällig ausgewählt haben. Aber ich bin ein englischer Muttersprachler, also weiß ich nicht wirklich, wie viel Unterschied es macht. Bedenkt man, wie viele C++ Programmierer es in der Welt gibt, die nicht Sprachen übersetzen, ich vermute, es ist keine große Sache mit der Tatsache verglichen, dass alle Unterlagen in englischer Sprache ...