#ifdef in C #

116

Ich möchte das Folgende tun, aber in C # anstelle von C ++

#ifdef _DEBUG
bool bypassCheck=TRUE_OR_FALSE;//i will decide depending on what i am debugging
#else
bool bypassCheck = false; //NEVER bypass it
#endif

c#

Überprüfen Sie auch diese hervorragende Antwort . Sie zeigt, wie Sie Debug-Symbole basierend auf Bedingungen über die Projektdatei (.csproj) hinzufügen können.

— Matt

162

#if DEBUG
bool bypassCheck=TRUE_OR_FALSE;//i will decide depending on what i am debugging
#else
bool bypassCheck = false; //NEVER bypass it
#endif

Stellen Sie sicher, dass das Kontrollkästchen zum Definieren von DEBUG in Ihren Build-Eigenschaften aktiviert ist.

— schwer
quelle

51

Ich würde Ihnen empfehlen, das bedingte Attribut zu verwenden !

Update: 3,5 Jahre später

Sie können Folgendes verwenden #if( Beispiel aus MSDN kopiert ):

// preprocessor_if.cs
#define DEBUG
#define VC_V7
using System;
public class MyClass 
{
    static void Main() 
    {
#if (DEBUG && !VC_V7)
        Console.WriteLine("DEBUG is defined");
#elif (!DEBUG && VC_V7)
        Console.WriteLine("VC_V7 is defined");
#elif (DEBUG && VC_V7)
        Console.WriteLine("DEBUG and VC_V7 are defined");
#else
        Console.WriteLine("DEBUG and VC_V7 are not defined");
#endif
    }
}

Nur nützlich, um Teile von Methoden auszuschließen.

Wenn Sie #ifeine Methode von der Kompilierung ausschließen, müssen Sie alle Codeteile, die diese Methode ebenfalls aufrufen, von der Kompilierung ausschließen (manchmal können Sie zur Laufzeit einige Klassen laden und den Aufrufer mit "Alle Referenzen finden" nicht finden). Andernfalls treten Fehler auf.

Wenn Sie andererseits die bedingte Kompilierung verwenden, können Sie dennoch alle Codeteile belassen, die die Methode aufrufen. Alle Parameter werden weiterhin vom Compiler validiert. Die Methode wird zur Laufzeit einfach nicht aufgerufen . Ich denke, dass es viel besser ist, die Methode nur einmal auszublenden und nicht den gesamten Code zu entfernen, der sie ebenfalls aufruft. Sie dürfen das bedingte Attribut nicht für Methoden verwenden, die einen Wert zurückgeben - nur für void-Methoden. Ich denke jedoch nicht, dass dies eine große Einschränkung ist, denn wenn Sie #ifeine Methode verwenden, die einen Wert zurückgibt, müssen Sie alle Codeteile ausblenden, die ihn ebenfalls aufrufen.

Hier ist ein Beispiel:

    // Der Aufruf von Class1.ConditionalMethod () wird zur Laufzeit ignoriert 
    // es sei denn, die DEBUG-Konstante ist definiert


    using System.Diagnostics;
    Klasse Klasse1 
    {
       [Bedingt ("DEBUG")]
       public static void ConditionalMethod () {
          Console.WriteLine ("Executed Class1.ConditionalMethod");
       }}
    }}

Zusammenfassung:

Ich würde #ifdefin C ++ verwenden, aber mit C # / VB würde ich das Conditional-Attribut verwenden. Auf diese Weise können Sie die Methodendefinition ausblenden, ohne die Codeteile ausblenden zu müssen, die sie aufrufen. Der aufrufende Code wird weiterhin vom Compiler kompiliert und validiert, die Methode wird jedoch zur Laufzeit nicht aufgerufen. Möglicherweise möchten Sie verwenden #if, um Abhängigkeiten zu vermeiden, da Ihr Code mit dem Attribut "Bedingt" noch kompiliert wird.

— Pavel Nikolov
quelle

1

+1 Das ist zwar nett, hat aber Einschränkungen, z. B. wenn Sie versuchen, einen Wert von einer bedingten Methode zurückzugeben (so wie ich das verstehe). Ein Inline-Beispiel würde helfen, denke ich.

— Hamish Grubijan

1

Es verhindert auch nicht, dass Code kompiliert wird, es erlaubt diesen Code einfach nicht. Die Unterscheidung ist wichtig, wenn Sie Abhängigkeiten und dergleichen entfernen möchten.

— Lee Louviere

1

C # hat einen Präprozessor. Es funktioniert nur geringfügig anders als das von C ++ und C.

Hier ist ein MSDN-Link - der Abschnitt über alle Präprozessor-Direktiven .

— Karl T.
quelle

11

Es ist ein kleiner Punkt, aber C # hat KEINEN Präprozessor. # Direktiven werden vom Hauptcompiler so verarbeitet, als ob es einen Präprozessor gäbe. Siehe hier: msdn.microsoft.com/en-us/library/ed8yd1ha.aspx Das Hauptergebnis dieser Unterscheidung ist, dass Makros im C / C ++ - Stil nicht funktionieren.

— Simon P Stevens