2012-09-21 20 views
5

Ciao Sto compilando ffmpeg usando xcode, che credo usi clang per la compilazione. In ffmpeg c'è una struct con una variabile membro chiamata 'class' Credo che questo sia perfettamente in C ma clang sta cercando di analizzarlo come parola chiave. Qualche idea su come sistemare? Fondamentalmente ciò che segue in un file cpp causerà l'errore:Clang C Compilatore parola chiave 'class' riservata?

extern C { 
    typedef struct { 
     int class; 
    } SomeStruct; 
} 

Prova a interpretare la classe come parola chiave.

FYI il file che genera l'errore in ffmpeg è libavcodec/mpegvideo.h e ho bisogno di includerlo per avere accesso alla struttura MpegEncContext per estrarre informazioni sulla mappa del movimento.

EDIT

L'esempio di codice di cui sopra è stato solo per dimostrare l'errore. Ma forse è risolvibile in un altro modo. Nel mio codice vero e proprio che ho in questo modo:

#ifdef __cplusplus 
extern "C" { 
#endif 

    #include "libavcodec/mpegvideo.h" 
    #include "libavformat/avformat.h" 

#if __cplusplus 
} //Extern C 
#endif 

Come potrei ottenere che per includere i due file come file C e non C++?

Grazie

+0

e la tua domanda Xcode- (ffmpeg) relativo è: –

+3

hehe: 'COBOL extern {AGGIUNGI A a B DARE C}' – pmg

+0

mia Xcode ffmpeg domanda relativa è, come faccio a includere tale intestazione in un c lima ++ e compilarlo in Xcode? – user1689196

risposta

4

È tutto a posto in C. Quando lo si costruisce come C++, si verifica un errore perché class è una parola chiave C++.

Per quanto riguarda il suo fissaggio, normalmente si sceglie un identificatore diverso da class. Tuttavia, gli sviluppatori di ffmpeg potrebbero non essere così gradevoli con questo cambiamento. Pertanto, potrebbe essere necessario uno:

  • limitare la visibilità di quel colpo di testa C traduzioni
  • o modificare la propria copia al fine di utilizzarlo in C traduzioni ++

Fortunatamente, vi sono anche usando un compilatore C che ha un buon supporto delle funzionalità C99 in questo caso. I compilatori C che non supportano bene C99 sono particolarmente fastidiosi con le fonti ffmpeg (perché si compilerebbe quindi l'intero programma come C++ per le funzionalità C99, e il conteggio dei conflitti sarebbe molto più alto).

(ci sono altri trucchi sporchi si potrebbe fare per cercare di risolvere il problema, ma io non li parlare)

+0

Puoi spiegare un po 'di più come posso limitare la visibilità di quelle intestazioni alle traduzioni C? Suppongo che potrei spostare qualsiasi codice che usa quel file in un file .c invece. Ma dovrei comunque includere quel file .c da un file C++ a un certo punto, credo. – user1689196

+0

Suppongo che potrei semplicemente rinominare la variabile di classe in qualsiasi altra cosa poiché usa solo il file di intestazione come riferimento (ffmpeg è già compilato in una libreria), ma non mi piace scherzare con i file di origine se non devo, rende l'aggiornamento un po 'più difficile. – user1689196

+1

@ user1689196 sicuro. sei sulla strada giusta; avresti bisogno di creare o un sottile strato wrapper (in C) che puoi chiamare da C++ per interagire con 'SomeStruct', o semplicemente gestire quell'aspetto del programma che include' SomeStruct' esclusivamente in un'implementazione C più ampia. – justin

4

Basically the following in a cpp file will cause the error

file cpp sono trattati come file C++, non C, e class è una parola riservata in C++.

+0

ma non dovrebbe forzare l'extern C a utilizzare il compilatore C? – user1689196

+5

@ user1689196, assolutamente no. Ciò cambierà semplicemente il collegamento dei simboli per fermare il nome di mangling. Puoi forzare la lingua usando il flag -x. –

+0

No, 'extern C' cambia solo il modo in cui il mangling dei nomi funziona. Per compilare come C, utilizzare .c – Joe

1

Se non si dispone di una scelta di rinominare nulla in quei file di intestazione, si può solo sostituire il class token qualcos'altro

#ifdef __cplusplus 
extern "C" { 
# define class videoClass 
#endif 

    #include "libavcodec/mpegvideo.h" 
    #include "libavformat/avformat.h" 

#if __cplusplus 
# undef class 
} //Extern C 
#endif 

Questo è piuttosto un trucco sporco, ma per tale codice male interfacciato non avere molta scelta. La vera soluzione sarebbe quella di avere tutti i membri di struct in questi file con i nomi che noi abbiamo una sorta di prefisso o così, come è fatto nel codice del livello di rete. Tutti i membri hanno alcuni prefissi come ss_ o sa_ e tali problemi sono molto improbabili.

+0

questo è il trucco sporco principale che avevo in mente quando ho scritto di trucchi sporchi nella mia risposta :) * (non preoccuparti, non farò downvote perché in realtà hai passato la briga di indicare e spiegando il problema e chiarito che è sporco) * – justin

Problemi correlati