2010-05-24 16 views
5

Um Konstanten zu definieren, was ist der üblichere und korrekte Weg? Wie hoch sind die Kosten für die Definition, Konstanten, Verlinkung usw. von #define? Es ist ein anderer Weg weniger teuer?Was kostet ein #define?

+0

Wählen Sie eine Sprache, eine Sprache? –

+1

@Kyle: Siehe Tags. – Cam

+1

C# lässt nicht zu, dass '# define' verwendet wird, um Konstanten zu definieren. Du kannst '#define DEBUG', aber nicht' #define DEBUG 1' definieren. http://msdn.microsoft.com/en-us/library/yt3yck0x.aspx –

Antwort

14

Der beste Weg, um jede const zu definieren ist

const int m = 7; 
const float pi = 3.1415926f; 
const char x = 'F'; 

Mit #define a ++ schlecht c Stil zu schreiben. Es ist unmöglich, #define im Namensraumbereich zu verstecken.

Vergleich

#define pi 3.1415926 

mit

namespace myscope { 
const float pi = 3.1415926f; 
} 

zweitem Weg ist natürlich besser.

+2

+1 '# define' ist auch schlechter Stil, weil es keine explizite Typ Informationen zum Compiler gibt. – GrahamS

+2

Dies fasst die Stilempfehlungen treffend zusammen, beantwortet aber die Frage nicht. Konstanten, die im richtigen C++ - Stil deklariert sind, haben Kosten, die #defines nicht haben. –

+1

@Dan Olson: Aah aber #defines haben auch eine Kosten in Bezug auf die Code-Größe, als (abhängig von Compiler-Smarts) können Sie am Ende viele Literale einzuführen, wo eine einzige const getan hätte. @Espuz: keine der Kosten ist es wert, sich Gedanken darüber zu machen (es sei denn, du machst sehr Low-Level-Mikroprozessor Zeug), also geh mit dem besseren Stil, der 'const' wo möglich ist. – GrahamS

2

Die Kosten sind nur für den Präprozessor, wenn #defines aufgelöst werden (die zusätzlichen Debugging-Kosten des Umgangs mit einem Projekt mit #defines für Konstanten natürlich ignorierend).

0

#define ist String-Ersatz. Wenn Sie also Fehler in den Makros machen, werden sie später als Fehler angezeigt. Meistens sind falsche Typen oder falsche Ausdrücke üblich.

Für die bedingte Kompilierung funktionieren Preprozessor-Makros am besten. Für andere Konstanten, die in der Berechnung verwendet werden, funktioniert const gut.

1

#define Makros werden vom Preprozessor verarbeitet, sie sind für den Compiler nicht sichtbar. Und da sie für den Compiler als Symbol nicht sichtbar sind, ist es schwierig etwas zu debuggen, das ein Makro beinhaltet.

Die bevorzugte Methode zum Definieren von Konstanten besteht in der Verwendung des Schlüsselwortes const und der richtigen Typinformation.

const unsigned int ArraySize = 100; 

Noch besser ist

static const unsigned int ArraySize = 100; 

wenn die Konstante nur in einer einzigen Datei verwendet wird.

1

#define wird Compilation Zeit zu erhöhen, aber es wird schneller in der Ausführung ...

im Allgemeinen in der bedingten Kompilierung #define verwendet wird ...

wo const im allgemeinen Berechnung von Zahlen verwendet wird

Die Auswahl hängt von Ihrer Anforderung ab ...

+1

Im besten Fall wird die Geschwindigkeitserhöhung mit #define marginal sein. Wenn der Compiler die Konflikte optimiert, wird es keinen Vorteil geben und Sie verlieren alle Vorteile von const. – JeremyP

+0

ja ... #define ist praktisch in Conditional Compilation (in Cross-Plattform-Anwendung ...) Es ist der einzige Vorteil, der in Betracht gezogen werden kann ... –

5

Der Compiler selbst sieht nie eine #define. Der Präprozessor erweitert alle Makros, bevor sie an den Compiler übergeben werden. Eine der Nebenwirkungen ist jedoch, dass die Werte wiederholt werden ... und zwei identische Zeichenfolgen sind nicht unbedingt die exakt gleiche Zeichenfolge. Wenn Sie sagen,

#define SOME_STRING "Just an example" 

es ist vollkommen legal für die Compiler eine Kopie des Strings in die Ausgabedatei jedes Mal hinzufügen die Zeichenfolge sieht. Ein guter Compiler wird wahrscheinlich doppelte Literale eliminieren, aber das ist zusätzliche Arbeit. Wenn Sie stattdessen const verwenden, muss sich der Compiler nicht so viele Sorgen machen.

0

CPU-Zeit ist nicht wirklich die Kosten für die Verwendung von #define oder Makros. Die "Kosten" als Entwickler ist wie folgt:

  • Wenn es einen Fehler in Ihrem Makro gibt, wird der Compiler es dort markieren, wo Sie das Makro referenziert haben, nicht wo Sie es definiert haben.
  • Sie verlieren die Typensicherheit und das Scoping für Ihr Makro.
  • Debugging-Tools kennen den Wert des Makros nicht.
  • Diese Dinge können nicht CPU-Zyklen brennen, aber sie können Entwicklerzyklen brennen.

    Für Konstanten ist die Deklaration von const Variablen vorzuziehen, und für kleine typunabhängige Funktionen sind Inline-Funktionen und Templates vorzuziehen.