La macro __FILE__ mostra il percorso completo

La macro predefinita standard __FILE__disponibile in C mostra il percorso completo del file. C'è un modo per abbreviare il percorso? Intendo invece di

/full/path/to/file.c

Vedo

to/file.c

o

file.c

Provare

#include <string.h>

#define __FILENAME__ (strrchr(__FILE__, '/') ? strrchr(__FILE__, '/') + 1 : __FILE__)

Per Windows usa '\\' invece di '/'.

Ecco un consiglio se stai usando cmake. Da: http://public.kitware.com/pipermail/cmake/2013-January/053117.html

Sto copiando il suggerimento, quindi è tutto su questa pagina:

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -D__FILENAME__='\"$(subst
  ${CMAKE_SOURCE_DIR}/,,$(abspath $<))\"'")

Se stai usando GNU make, non vedo alcun motivo per cui non potresti estenderlo ai tuoi makefile. Ad esempio, potresti avere una linea come questa:

CXX_FLAGS+=-D__FILENAME__='\"$(subst $(SOURCE_PREFIX)/,,$(abspath $<))\"'"

dove si $(SOURCE_PREFIX)trova il prefisso che si desidera rimuovere.

Quindi utilizzare __FILENAME__al posto di __FILE__.

Ho appena pensato a un'ottima soluzione che funziona sia con i file sorgente che con quelli di intestazione, è molto efficiente e funziona in fase di compilazione su tutte le piattaforme senza estensioni specifiche del compilatore. Questa soluzione conserva anche la relativa struttura di directory del progetto, in modo da sapere in quale cartella si trova il file e solo relativamente alla radice del progetto.

L'idea è di ottenere le dimensioni della directory di origine con lo strumento di compilazione e di aggiungerla alla __FILE__macro, rimuovendo completamente la directory e mostrando solo il nome del file a partire dalla directory di origine.

L'esempio seguente è implementato usando CMake, ma non c'è motivo per cui non funzionerebbe con nessun altro strumento di compilazione, perché il trucco è molto semplice.

Nel file CMakeLists.txt, definire una macro che abbia la lunghezza del percorso del progetto su CMake:

# The additional / is important to remove the last character from the path.
# Note that it does not matter if the OS uses / or \, because we are only
# saving the path size.
string(LENGTH "${CMAKE_SOURCE_DIR}/" SOURCE_PATH_SIZE)
add_definitions("-DSOURCE_PATH_SIZE=${SOURCE_PATH_SIZE}")

Sul tuo codice sorgente, definisci una __FILENAME__macro che aggiunge semplicemente la dimensione del percorso di origine alla __FILE__macro:

#define __FILENAME__ (__FILE__ + SOURCE_PATH_SIZE)

Quindi usa questa nuova macro anziché la __FILE__macro. Questo funziona perché il __FILE__percorso inizierà sempre con il percorso della directory dei sorgenti di CMake. Rimuovendolo dalla __FILE__stringa, il preprocessore si occuperà di specificare il nome file corretto e sarà tutto relativo alla radice del progetto CMake.

Se ti preoccupi delle prestazioni, questo è efficiente quanto l'utilizzo __FILE__, perché entrambi __FILE__e SOURCE_PATH_SIZEsono noti costanti di tempo di compilazione, quindi può essere ottimizzato dal compilatore.

L'unico posto in cui ciò fallirebbe se lo si utilizza su file generati e si trovano in una cartella di build off-source. Quindi probabilmente dovrai creare un'altra macro usando la CMAKE_BUILD_DIRvariabile anziché CMAKE_SOURCE_DIR.

Compilare la soluzione del tempo puramente qui. Si basa sul fatto che sizeof()di una stringa letterale restituisce la sua lunghezza + 1.

#define STRIPPATH(s)\
    (sizeof(s) > 2 && (s)[sizeof(s)-2] == '/' ? (s) + sizeof(s) - 1 : \
    sizeof(s) > 3 && (s)[sizeof(s)-3] == '/' ? (s) + sizeof(s) - 2 : \
    sizeof(s) > 4 && (s)[sizeof(s)-4] == '/' ? (s) + sizeof(s) - 3 : \
    sizeof(s) > 5 && (s)[sizeof(s)-5] == '/' ? (s) + sizeof(s) - 4 : \
    sizeof(s) > 6 && (s)[sizeof(s)-6] == '/' ? (s) + sizeof(s) - 5 : \
    sizeof(s) > 7 && (s)[sizeof(s)-7] == '/' ? (s) + sizeof(s) - 6 : \
    sizeof(s) > 8 && (s)[sizeof(s)-8] == '/' ? (s) + sizeof(s) - 7 : \
    sizeof(s) > 9 && (s)[sizeof(s)-9] == '/' ? (s) + sizeof(s) - 8 : \
    sizeof(s) > 10 && (s)[sizeof(s)-10] == '/' ? (s) + sizeof(s) - 9 : \
    sizeof(s) > 11 && (s)[sizeof(s)-11] == '/' ? (s) + sizeof(s) - 10 : (s))

#define __JUSTFILE__ STRIPPATH(__FILE__)

Sentiti libero di estendere la cascata dell'operatore condizionale al nome file massimo sensibile nel progetto. La lunghezza del percorso non ha importanza, purché controlli abbastanza lontano dalla fine della stringa.

Vedrò se riesco a ottenere una macro simile senza lunghezza hardcoded con ricorsione macro ...

Almeno per gcc, il valore di __FILE__è il percorso del file come specificato nella riga di comando del compilatore . Se compili in file.cquesto modo:

gcc -c /full/path/to/file.c

la __FILE__si espanderà per "/full/path/to/file.c". Se invece lo fai:

cd /full/path/to
gcc -c file.c

quindi __FILE__si espanderà a solo "file.c".

Questo può o meno essere pratico.

Lo standard C non richiede questo comportamento. Tutto ciò che dice __FILE__è che si espande in "Il presunto nome del file sorgente corrente (una stringa di caratteri letterale)".

Un'alternativa è usare la #linedirettiva. Sostituisce il numero di riga corrente e, facoltativamente, il nome del file di origine. Se si desidera sovrascrivere il nome del file ma lasciare solo il numero di riga, utilizzare la __LINE__macro.

Ad esempio, puoi aggiungerlo nella parte superiore di file.c:

#line __LINE__ "file.c"

L'unico problema è che assegna il numero di riga specificato alla riga seguente e il primo argomento #linedeve essere una sequenza di cifre, quindi non puoi fare qualcosa di simile

#line (__LINE__-1) "file.c"  // This is invalid

Garantire che il nome del file nella #linedirettiva corrisponda al nome effettivo del file viene lasciato come esercizio.

Almeno per gcc, questo influenzerà anche il nome del file riportato nei messaggi diagnostici.

Un po 'in ritardo per la festa, ma per GCC dai un'occhiata -ffile-prefix-map=old=newall'opzione:

Quando si compilano file che risiedono nella directory precedente , registrare tutti i riferimenti ad essi nel risultato della compilazione come se fossero invece i file nella directory nuova . Specificare questa opzione equivale a specificare tutte le singole -f*-prefix-mapopzioni. Questo può essere usato per creare build riproducibili indipendenti dalla posizione. Vedi anche -fmacro-prefix-mape -fdebug-prefix-map.

Quindi per le mie build Jenkins aggiungerò -ffile-prefix-map=${WORKSPACE}/=/e un altro per rimuovere il prefisso di installazione del pacchetto di sviluppo locale.

NOTA Sfortunatamente l' -ffile-prefix-mapopzione è disponibile solo in GCC 8 in poi, così come -fmacro-prefix-map, credo , fa la __FILE__parte. Ad esempio, per GCC 5, abbiamo solo quelli -fdebug-prefix-mapche non sembrano (sembrano) influenzare __FILE__.

• C ++ 11

• msvc2015u3, gcc5.4, clang3.8.0

  template <typename T, size_t S>
  inline constexpr size_t get_file_name_offset(const T (& str)[S], size_t i = S - 1)
  {
      return (str[i] == '/' || str[i] == '\\') ? i + 1 : (i > 0 ? get_file_name_offset(str, i - 1) : 0);
  }
  
  template <typename T>
  inline constexpr size_t get_file_name_offset(T (& str)[1])
  {
      return 0;
  }

  '

  int main()
  {
       printf("%s\n", &__FILE__[get_file_name_offset(__FILE__)]);
  }

Il codice genera un offset di tempo di compilazione quando:

• gcc: almeno gcc6.1 + -O1

• msvc: inserisci il risultato nella variabile constexpr:

    constexpr auto file = &__FILE__[get_file_name_offset(__FILE__)];
    printf("%s\n", file);

• clang: persiste nella non valutazione del tempo di compilazione

C'è un trucco per forzare tutti e 3 i compilatori a compilare la valutazione del tempo anche nella configurazione di debug con ottimizzazione disabilitata:

    namespace utility {

        template <typename T, T v>
        struct const_expr_value
        {
            static constexpr const T value = v;
        };

    }

    #define UTILITY_CONST_EXPR_VALUE(exp) ::utility::const_expr_value<decltype(exp), exp>::value

    int main()
    {
         printf("%s\n", &__FILE__[UTILITY_CONST_EXPR_VALUE(get_file_name_offset(__FILE__))]);
    }

https://godbolt.org/z/u6s8j3

In VC, durante l'utilizzo /FC, si __FILE__espande al percorso completo, senza l' /FCopzione __FILE__espande il nome del file. ref: qui

Non esiste un modo per compilare il tempo per farlo. Ovviamente puoi farlo in fase di runtime usando il runtime C, come hanno dimostrato alcune delle altre risposte, ma in fase di compilazione, quando il pre-procuratore entra, sei sfortunato.

Usa la funzione basename () o, se sei su Windows, _splitpath () .

#include <libgen.h>

#define PRINTFILE() { char buf[] = __FILE__; printf("Filename:  %s\n", basename(buf)); }

Prova anche man 3 basenamein una shell.

Se si utilizza CMAKEcon il compilatore GNU, la globaldefinizione funziona correttamente:

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -D__MY_FILE__='\"$(notdir $(abspath $<))\"'")

Ho usato la stessa soluzione con la risposta di @Patrick per anni.

Ha un piccolo problema quando il percorso completo contiene un collegamento simbolico.

Soluzione migliore.

set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wno-builtin-macro-redefined -D'__FILE__=\"$(subst $(realpath ${CMAKE_SOURCE_DIR})/,,$(abspath $<))\"'")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-builtin-macro-redefined -D'__FILE__=\"$(subst $(realpath ${CMAKE_SOURCE_DIR})/,,$(abspath $<))\"'")

Perché dovrebbe usare questo?

• -Wno-builtin-macro-redefinedper silenziare gli avvisi del compilatore per la ridefinizione della __FILE__macro.

  Per quei compilatori che non supportano questo, fare riferimento al modo Robusto di seguito.

• Spogliare il percorso del progetto dal percorso del file è il vero requisito. Non ti piacerebbe perdere tempo per scoprire dove si trova un header.hfile src/foo/header.ho src/bar/header.h.

• Dovremmo eliminare la __FILE__macrocmake file di configurazione.

  Questa macro viene utilizzata nella maggior parte dei codici esistenti. Basta ridefinire può liberarti.

  I compilatori come gccpredefiniscono questa macro dagli argomenti della riga di comando. E il percorso completo è scritto in makefiles generato da cmake.

• CMAKE_*_FLAGSÈ richiesto il codice di accesso .

  Esistono alcuni comandi per aggiungere opzioni o definizioni del compilatore in alcune versioni più recenti, come add_definitions()e add_compile_definitions(). Questi comandi analizzeranno le funzioni make come substprima di applicarle ai file sorgente. Non è quello che vogliamo.

Modo robusto per -Wno-builtin-macro-redefined.

include(CheckCCompilerFlag)
check_c_compiler_flag(-Wno-builtin-macro-redefined SUPPORT_C_WNO_BUILTIN_MACRO_REDEFINED)
if (SUPPORT_C_WNO_BUILTIN_MACRO_REDEFINED)
    set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wno-builtin-macro-redefined")
endif (SUPPORT_C_WNO_BUILTIN_MACRO_REDEFINED)
include(CheckCXXCompilerFlag)
check_cxx_compiler_flag(-Wno-builtin-macro-redefined SUPPORT_CXX_WNO_BUILTIN_MACRO_REDEFINED)
if (SUPPORT_CXX_WNO_BUILTIN_MACRO_REDEFINED)
    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-builtin-macro-redefined")
endif (SUPPORT_CXX_WNO_BUILTIN_MACRO_REDEFINED)

Ricorda di rimuovere questa opzione del compilatore dalla set(*_FLAGS ... -D__FILE__=...)riga.

Una leggera variazione su ciò che @ red1ynx proposto sarebbe creare la seguente macro:

#define SET_THIS_FILE_NAME() \
    static const char* const THIS_FILE_NAME = \
        strrchr(__FILE__, '/') ? strrchr(__FILE__, '/') + 1 : __FILE__;

In ciascuno dei tuoi file .c (pp) aggiungi:

SET_THIS_FILE_NAME();

Quindi puoi fare riferimento THIS_FILE_NAMEinvece di __FILE__:

printf("%s\n", THIS_FILE_NAME);

Ciò significa che la costruzione viene eseguita una volta per file .c (pp) anziché ogni volta che viene fatto riferimento alla macro.

È limitato all'uso solo da file .c (pp) e sarebbe inutilizzabile da file di intestazione.

Ho fatto una macro __FILENAME__ che evita di tagliare ogni volta il percorso completo. Il problema è mantenere il nome del file risultante in una variabile cpp-local.

Può essere fatto facilmente definendo una variabile globale statica nel file .h . Questa definizione fornisce variabili separate e indipendenti in ciascun file .cpp che include .h . Per essere a prova di multithreading vale la pena rendere anche le variabili thread locali (TLS).

Una variabile memorizza il nome del file (ridotto). Un altro contiene il valore non tagliato che ha __FILE__dato. Il file h:

static __declspec( thread ) const char* fileAndThreadLocal_strFilePath = NULL;
static __declspec( thread ) const char* fileAndThreadLocal_strFileName = NULL;

La macro stessa chiama il metodo con tutta la logica:

#define __FILENAME__ \
    GetSourceFileName(__FILE__, fileAndThreadLocal_strFilePath, fileAndThreadLocal_strFileName)

E la funzione è implementata in questo modo:

const char* GetSourceFileName(const char* strFilePath, 
                              const char*& rstrFilePathHolder, 
                              const char*& rstrFileNameHolder)
{
    if(strFilePath != rstrFilePathHolder)
    {
        // 
        // This if works in 2 cases: 
        // - when first time called in the cpp (ordinary case) or
        // - when the macro __FILENAME__ is used in both h and cpp files 
        //   and so the method is consequentially called 
        //     once with strFilePath == "UserPath/HeaderFileThatUsesMyMACRO.h" and 
        //     once with strFilePath == "UserPath/CPPFileThatUsesMyMACRO.cpp"
        //
        rstrFileNameHolder = removePath(strFilePath);
        rstrFilePathHolder = strFilePath;
    }
    return rstrFileNameHolder;
}

RemovePath () può essere implementato in diversi modi, ma il veloce e semplice sembra essere con strrchr:

const char* removePath(const char* path)
{
    const char* pDelimeter = strrchr (path, '\\');
    if (pDelimeter)
        path = pDelimeter+1;

    pDelimeter = strrchr (path, '/');
    if (pDelimeter)
        path = pDelimeter+1;

    return path;
}

Il compilatore Clang recente ha una __FILE_NAME__macro (vedi qui ).

spero solo di migliorare un po 'la macro FILE:

#define FILE (strrchr(__FILE__, '/') ? strrchr(__FILE__, '/') + 1 : strrchr(__FILE__, '\\') ? strrchr(__FILE__, '\\') + 1 : __FILE__)

questo cattura / e \, come richiesto da Czarek Tomczak, e funziona benissimo nel mio ambiente misto.

Provare

#pragma push_macro("__FILE__")
#define __FILE__ "foobar.c"

dopo le istruzioni include nel file sorgente e aggiungi

#pragma pop_macro("__FILE__")

alla fine del file sorgente.

Ecco una funzione portatile che funziona sia per Linux (percorso '/') che per Windows (mix di '\' e '/').
Compila con gcc, clang e vs.

#include <string.h>
#include <stdio.h>

const char* GetFileName(const char *path)
{
    const char *name = NULL, *tmp = NULL;
    if (path && *path) {
        name = strrchr(path, '/');
        tmp = strrchr(path, '\\');
        if (tmp) {
             return name && name > tmp ? name + 1 : tmp + 1;
        }
    }
    return name ? name + 1 : path;
}

int main() {
    const char *name = NULL, *path = NULL;

    path = __FILE__;
    name = GetFileName(path);
    printf("path: %s, filename: %s\n", path, name);

    path ="/tmp/device.log";
    name = GetFileName(path);
    printf("path: %s, filename: %s\n", path, name);

    path = "C:\\Downloads\\crisis.avi";
    name = GetFileName(path);
    printf("path: %s, filename: %s\n", path, name);

    path = "C:\\Downloads/nda.pdf";
    name = GetFileName(path);
    printf("path: %s, filename: %s\n", path, name);

    path = "C:/Downloads\\word.doc";
    name = GetFileName(path);
    printf("path: %s, filename: %s\n", path, name);

    path = NULL;
    name = GetFileName(NULL);
    printf("path: %s, filename: %s\n", path, name);

    path = "";
    name = GetFileName("");
    printf("path: %s, filename: %s\n", path, name);

    return 0;
}

Uscita standard:

path: test.c, filename: test.c
path: /tmp/device.log, filename: device.log
path: C:\Downloads\crisis.avi, filename: crisis.avi
path: C:\Downloads/nda.pdf, filename: nda.pdf
path: C:/Downloads\word.doc, filename: word.doc
path: (null), filename: (null)
path: , filename: 

Ecco la soluzione che utilizza il calcolo in fase di compilazione:

constexpr auto* getFileName(const char* const path)
{
    const auto* startPosition = path;
    for (const auto* currentCharacter = path;*currentCharacter != '\0'; ++currentCharacter)
    {
        if (*currentCharacter == '\\' || *currentCharacter == '/')
        {
            startPosition = currentCharacter;
        }
    }

    if (startPosition != path)
    {
        ++startPosition;
    }

    return startPosition;
}

std::cout << getFileName(__FILE__);

Se sei finito in questa pagina alla ricerca di un modo per rimuovere il percorso di origine assoluto che punta a una brutta posizione di costruzione dal binario che stai spedendo, di seguito potrebbe soddisfare le tue esigenze.

Sebbene questo non produca esattamente la risposta che l'autore ha espresso il suo desiderio poiché presume l'uso di CMake , si avvicina piuttosto. È un peccato che non sia stato menzionato prima da nessuno in quanto mi avrebbe risparmiato un sacco di tempo.

OPTION(CMAKE_USE_RELATIVE_PATHS "If true, cmake will use relative paths" ON)

L'impostazione della variabile sopra su ONgenererà il comando build nel formato:

cd /ugly/absolute/path/to/project/build/src && 
    gcc <.. other flags ..> -c ../../src/path/to/source.c

Di conseguenza, la __FILE__macro verrà risolta in../../src/path/to/source.c

Documentazione CMake

Fai attenzione all'avvertimento nella pagina della documentazione:

Usa percorsi relativi (potrebbe non funzionare!).

Non è garantito per funzionare in tutti i casi, ma ha funzionato nel mio - CMake 3.13 + gcc 4.5

Dal momento che si sta utilizzando GCC, è possibile usufruire di

__BASE_FILE__Questa macro si espande nel nome del file di input principale, sotto forma di costante di stringa C. Questo è il file di origine che è stato specificato nella riga di comando del preprocessore o del compilatore C.

e quindi controllare come si desidera visualizzare il nome file modificando la rappresentazione del file di origine (percorso completo / percorso relativo / nome base) al momento della compilazione.

Ecco una soluzione che funziona per ambienti che non dispongono della libreria di stringhe (kernel Linux, sistemi integrati, ecc.):

#define FILENAME ({ \
    const char* filename_start = __FILE__; \
    const char* filename = filename_start; \
    while(*filename != '\0') \
        filename++; \
    while((filename != filename_start) && (*(filename - 1) != '/')) \
        filename--; \
    filename; })

Ora basta usare FILENAMEinvece di __FILENAME__. Sì, è ancora una cosa runtime ma funziona.

#include <algorithm>
#include <string>
using namespace std;
string f( __FILE__ );
f = string( (find(f.rbegin(), f.rend(), '/')+1).base() + 1, f.end() );

// searches for the '/' from the back, transfers the reverse iterator 
// into a forward iterator and constructs a new sting with both

Una risposta breve e funzionante sia per Windows che per * nix:

#define __FILENAME__ std::max<const char*>(__FILE__,\
    std::max(strrchr(__FILE__, '\\')+1, strrchr(__FILE__, '/')+1))