In C / C ++ / Obiettivo C è possibile definire una macro utilizzando i preprocessori del compilatore. Inoltre, puoi includere / escludere alcune parti di codice usando i preprocessori del compilatore.

#ifdef DEBUG
    // Debug-only code
#endif

Esiste una soluzione simile in Swift?

Si, puoi farlo.

In Swift puoi comunque utilizzare le macro del preprocessore "# if / # else / # endif" (anche se più vincolate), secondo i documenti Apple . Ecco un esempio:

#if DEBUG
    let a = 2
#else
    let a = 3
#endif

Ora, però, è necessario impostare il simbolo "DEBUG" altrove. Impostalo nella sezione "Compilatore Swift - Bandiere personalizzate", riga "Altre bandiere Swift". Aggiungi il simbolo DEBUG con la -D DEBUGvoce.

Come al solito, è possibile impostare un valore diverso in Debug o in Release.

L'ho provato in codice reale e funziona; non sembra essere riconosciuto in un parco giochi però.

Puoi leggere il mio post originale qui .

NOTA IMPORTANTE: -DDEBUG=1 non funziona. -D DEBUGFunziona solo . Sembra che il compilatore stia ignorando una bandiera con un valore specifico.

Come indicato in Apple Docs

Il compilatore Swift non include un preprocessore. Invece, sfrutta gli attributi in fase di compilazione, le configurazioni di compilazione e le funzionalità del linguaggio per ottenere la stessa funzionalità. Per questo motivo, le direttive del preprocessore non vengono importate in Swift.

Sono riuscito a ottenere quello che volevo usando Configurazioni di costruzione personalizzate:

1. Vai al tuo progetto / seleziona il tuo obiettivo / Crea impostazioni / cerca bandiere personalizzate
2. Per il bersaglio scelto imposta il tuo flag personalizzato usando il prefisso -D (senza spazi bianchi), sia per il debug che per il rilascio
3. Fai i passaggi sopra indicati per ogni obiettivo che hai

Ecco come si controlla l'obiettivo:

#if BANANA
    print("We have a banana")
#elseif MELONA
    print("Melona")
#else
    print("Kiwi")
#endif

Testato utilizzando Swift 2.2

In molte situazioni, non hai davvero bisogno della compilazione condizionale ; hai solo bisogno di un comportamento condizionale che puoi accendere e spegnere. Per questo, puoi usare una variabile d'ambiente. Questo ha l'enorme vantaggio che in realtà non devi ricompilare.

È possibile impostare la variabile di ambiente e attivarla o disattivarla facilmente nell'editor di schemi:

Puoi recuperare la variabile d'ambiente con NSProcessInfo:

    let dic = NSProcessInfo.processInfo().environment
    if dic["TRIPLE"] != nil {
        // ... do secret stuff here ...
    }

Ecco un esempio di vita reale. La mia app funziona solo sul dispositivo, perché utilizza la libreria musicale, che non esiste sul simulatore. Come, quindi, catturare schermate sul simulatore per dispositivi che non possiedo? Senza quelle schermate, non posso inviare all'App Store.

Ho bisogno di dati falsi e di un modo diverso di elaborarli . Ho due variabili d'ambiente: una che, quando accesa, dice all'app di generare i dati falsi dai dati reali mentre è in esecuzione sul mio dispositivo; l'altro che, quando acceso, utilizza i dati falsi (non la libreria musicale mancante) durante l'esecuzione sul Simulatore. Attivare / disattivare ciascuna di queste modalità speciali è facile grazie alle caselle di controllo delle variabili di ambiente nell'editor Schema. E il vantaggio è che non posso usarli accidentalmente nella build del mio App Store, perché l'archiviazione non ha variabili di ambiente.

Un grande cambiamento di ifdefsostituzione è venuto fuori con Xcode 8. vale a dire l'uso delle condizioni di compilazione attiva .

Fare riferimento a Creazione e collegamento nella nota di rilascio di Xcode 8 .

Nuove impostazioni di build

Nuova impostazione: SWIFT_ACTIVE_COMPILATION_CONDITIONS

“Active Compilation Conditions” is a new build setting for passing conditional compilation flags to the Swift compiler.

In precedenza, dovevamo dichiarare i flag di compilazione condizionale in OTHER_SWIFT_FLAGS, ricordando di anteporre "-D" all'impostazione. Ad esempio, per compilare in modo condizionale con un valore MYFLAG:

#if MYFLAG1
    // stuff 1
#elseif MYFLAG2
    // stuff 2
#else
    // stuff 3
#endif

Il valore da aggiungere all'impostazione -DMYFLAG

Ora dobbiamo solo passare il valore MYFLAG alla nuova impostazione. È ora di spostare tutti quei valori di compilazione condizionale!

Fai riferimento al link seguente per ulteriori funzionalità di Swift Build Settings in Xcode 8: http://www.miqu.me/blog/2016/07/31/xcode-8-new-build-settings-and-analyzer-improvements/

A partire da Swift 4.1, se tutto ciò che serve è solo verificare se il codice è stato creato con la configurazione di debug o di rilascio, è possibile utilizzare le funzioni integrate:

• _isDebugAssertConfiguration()(vero quando l'ottimizzazione è impostata su -Onone)
• _isReleaseAssertConfiguration()(vero quando l'ottimizzazione è impostata su -O) (non disponibile su Swift 3+)
• _isFastAssertConfiguration()(vero quando l'ottimizzazione è impostata su -Ounchecked)

per esempio

func obtain() -> AbstractThing {
    if _isDebugAssertConfiguration() {
        return DecoratedThingWithDebugInformation(Thing())
    } else {
        return Thing()
    }
}

Rispetto alle macro del preprocessore,

• ✓ Non è necessario definire un -D DEBUGflag personalizzato per usarlo
• ~ In realtà è definito in termini di impostazioni di ottimizzazione, non di configurazione build Xcode

• ✗ Non documentato, il che significa che la funzione può essere rimossa in qualsiasi aggiornamento (ma dovrebbe essere protetta da AppStore poiché l'ottimizzatore li trasformerà in costanti)

  • questi una volta rimossi , ma riportati al pubblico per mancanza di @testableattributo , destino incerto sul futuro Swift.

• ✗ L'uso di in if / else genererà sempre un avviso "Non verrà mai eseguito".

Xcode 8 e versioni successive

Usa l' impostazione Condizioni di compilazione attive in Impostazioni di compilazione / Compilatore rapido - Flag personalizzati .

• Questa è la nuova impostazione di generazione per il passaggio dei flag di compilazione condizionale al compilatore Swift.
• Bandiere aggiuntivi semplice come questo: ALPHA, BETAetc.

Quindi verificalo con condizioni di compilazione come questa:

#if ALPHA
    //
#elseif BETA
    //
#else
    //
#endif

Suggerimento: è anche possibile utilizzare #if !ALPHAecc.

Non esiste un preprocessore Swift. (Per prima cosa, la sostituzione arbitraria del codice rompe la sicurezza di tipo e memoria.)

Swift include opzioni di configurazione in fase di creazione, tuttavia, in modo da poter includere in modo condizionale il codice per determinate piattaforme o stili di costruzione o in risposta ai flag definiti con gli -Dargomenti del compilatore. A differenza di C, tuttavia, una sezione del codice compilata in modo condizionale deve essere sintatticamente completa. C'è una sezione su questo nell'uso di Swift With Cocoa e Objective-C .

Per esempio:

#if os(iOS)
    let color = UIColor.redColor()
#else
    let color = NSColor.redColor()
#endif

I miei due centesimi per Xcode 8:

a) Un flag personalizzato che utilizza il -Dprefisso funziona bene, ma ...

b) Uso più semplice:

In Xcode 8 è presente una nuova sezione: "Condizioni di compilazione attive", già con due righe, per il debug e il rilascio.

Aggiungi semplicemente la tua definizione SENZA -D.

Costante isDebug basata su condizioni di compilazione attive

Un'altra soluzione, forse più semplice, che si traduce ancora in un valore booleano che puoi passare a funzioni senza peppering #ifcondizionali in tutta la tua base di codice è definire DEBUGcome uno dei tuoi target di costruzione del progetto Active Compilation Conditionse includere quanto segue (lo definisco una costante globale):

#if DEBUG
    let isDebug = true
#else
    let isDebug = false
#endif

Costante isDebug basata sulle impostazioni di ottimizzazione del compilatore

Questo concetto si basa sulla risposta di kennytm

Il vantaggio principale rispetto a kennytm è che non si basa su metodi privati ​​o non documentati.

In Swift 4 :

let isDebug: Bool = {
    var isDebug = false
    // function with a side effect and Bool return value that we can pass into assert()
    func set(debug: Bool) -> Bool {
        isDebug = debug
        return isDebug
    }
    // assert:
    // "Condition is only evaluated in playgrounds and -Onone builds."
    // so isDebug is never changed to true in Release builds
    assert(set(debug: true))
    return isDebug
}()

Rispetto alle macro del preprocessore e alla risposta di kennytm ,

• ✓ Non è necessario definire un -D DEBUGflag personalizzato per usarlo
• ~ In realtà è definito in termini di impostazioni di ottimizzazione, non di configurazione build Xcode

• ✓ Documentato , il che significa che la funzione seguirà i normali schemi di rilascio / deprecazione dell'API.

• ✓ L'uso di in if / else non genererà un avviso "Non verrà mai eseguito".

La risposta di Moignans qui funziona bene. Ecco un'altra informazione in caso di aiuto,

#if DEBUG
    let a = 2
#else
    let a = 3
#endif

Puoi annullare le macro come di seguito,

#if !RELEASE
    let a = 2
#else
    let a = 3
#endif

Nei progetti Swift creati con Xcode versione 9.4.1, Swift 4.1

#if DEBUG
#endif

funziona di default perché nei macro del preprocessore DEBUG = 1 è già stato impostato da Xcode.

Quindi puoi usare #if DEBUG "out of box".

A proposito, come utilizzare i blocchi di compilazione delle condizioni in generale è scritto nel libro Apple Swift Programming Language 4.1 (la sezione Dichiarazioni sul controllo del compilatore) e come scrivere i flag di compilazione e ciò che è la controparte delle macro C in Swift è scritto in un altro libro di Apple che utilizza Swift con Cocoa e Objective C (nella sezione Direttive del preprocessore)

Spero che in futuro Apple scriva i contenuti più dettagliati e gli indici per i loro libri.

XCODE 9 E SOPRA

#if DEVELOP
    //
#elseif PRODCTN
    //
#else
    //
#endif

Dopo aver impostato DEBUG=1le GCC_PREPROCESSOR_DEFINITIONSImpostazioni build, preferisco utilizzare una funzione per effettuare queste chiamate:

func executeInProduction(_ block: () -> Void)
{
    #if !DEBUG
        block()
    #endif
}

E poi racchiudi in questa funzione qualsiasi blocco che voglio omesso nelle build di debug:

executeInProduction {
    Fabric.with([Crashlytics.self]) // Compiler checks this line even in Debug
}

Il vantaggio rispetto a:

#if !DEBUG
    Fabric.with([Crashlytics.self]) // This is not checked, may not compile in non-Debug builds
#endif

È che il compilatore controlla la sintassi del mio codice, quindi sono sicuro che la sua sintassi sia corretta e build.

! [In Xcode 8 e versioni successive vai a build setting -> cerca flag personalizzati] 1

Nel codice

 #if Live
    print("Live")
    #else
    print("debug")
    #endif

func inDebugBuilds(_ code: () -> Void) {
    assert({ code(); return true }())
}

fonte

Questo si basa sulla risposta di Jon Willis che si basa sull'affermazione , che viene eseguita solo nelle compilation di debug:

func Log(_ str: String) { 
    assert(DebugLog(str)) 
}
func DebugLog(_ str: String) -> Bool { 
    print(str) 
    return true
}

Il mio caso d'uso è per la registrazione delle dichiarazioni di stampa. Ecco un benchmark per la versione di rilascio su iPhone X:

let iterations = 100_000_000
let time1 = CFAbsoluteTimeGetCurrent()
for i in 0 ..< iterations {
    Log ("⧉ unarchiveArray:\(fileName) memoryTime:\(memoryTime) count:\(array.count)")
}
var time2 = CFAbsoluteTimeGetCurrent()
print ("Log: \(time2-time1)" )

stampe:

Log: 0.0

Sembra che Swift 4 elimini completamente la chiamata di funzione.