A macro __FILE__ mostra o caminho completo

A macro predefinida padrão __FILE__disponível em C mostra o caminho completo para o arquivo. Existe alguma maneira de diminuir o caminho? Quero dizer em vez de

/full/path/to/file.c

Entendo

to/file.c

ou

file.c

Experimentar

#include <string.h>

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

Para Windows, use '\\' em vez de '/'.

Aqui está uma dica se você estiver usando o cmake. De: http://public.kitware.com/pipermail/cmake/2013-January/053117.html

Estou copiando a dica, então está tudo nesta página:

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

Se você estiver usando o GNU make, não vejo razão para que você não possa estender isso para seus próprios makefiles. Por exemplo, você pode ter uma linha como esta:

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

onde $(SOURCE_PREFIX)é o prefixo que você deseja remover.

Em seguida, use __FILENAME__no lugar de __FILE__.

Acabei de pensar em uma ótima solução para isso, que funciona com os arquivos de origem e de cabeçalho, é muito eficiente e funciona em tempo de compilação em todas as plataformas sem extensões específicas do compilador. Essa solução também preserva a estrutura de diretórios relativa do seu projeto, para que você saiba em qual pasta o arquivo está e apenas em relação à raiz do seu projeto.

A idéia é obter o tamanho do diretório de origem com sua ferramenta de construção e apenas adicioná-lo à __FILE__macro, removendo o diretório completamente e mostrando apenas o nome do arquivo começando no diretório de origem.

O exemplo a seguir é implementado usando o CMake, mas não há razão para que ele não funcione com outras ferramentas de construção, porque o truque é muito simples.

No arquivo CMakeLists.txt, defina uma macro que tenha o comprimento do caminho para o seu projeto no 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}")

No seu código-fonte, defina uma __FILENAME__macro que apenas adicione o tamanho do caminho de origem à __FILE__macro:

#define __FILENAME__ (__FILE__ + SOURCE_PATH_SIZE)

Em seguida, basta usar essa nova macro em vez da __FILE__macro. Isso funciona porque o __FILE__caminho sempre começa com o caminho para o diretório de origem do CMake. Ao removê-lo da __FILE__string, o pré-processador se encarregará de especificar o nome correto do arquivo e tudo será relativo à raiz do seu projeto CMake.

Se você se preocupa com o desempenho, este é tão eficiente quanto usar __FILE__, porque ambos __FILE__e SOURCE_PATH_SIZEsão conhecidos constantes de tempo de compilação, para que possa ser otimizado afastado pelo compilador.

O único lugar em que isso falharia é se você estiver usando isso em arquivos gerados e eles estiverem em uma pasta de compilação externa. Então você provavelmente terá que criar outra macro usando a CMAKE_BUILD_DIRvariável em vez de CMAKE_SOURCE_DIR.

Compile a solução de tempo aqui. É baseado no fato de que sizeof()uma string literal retorna seu comprimento + 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__)

Sinta-se à vontade para estender a cascata condicional do operador até o nome máximo de arquivo sensível no projeto. O comprimento do caminho não importa, desde que você verifique o suficiente a partir do final da string.

Vou ver se consigo obter uma macro semelhante sem comprimento codificado com recursão de macro ...

Pelo menos para gcc, o valor de __FILE__é o caminho do arquivo, conforme especificado na linha de comando do compilador . Se você compilar file.cassim:

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

a __FILE__ expandirá para "/full/path/to/file.c". Se você fizer isso:

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

então __FILE__será expandido para apenas "file.c".

Isso pode ou não ser prático.

O padrão C não requer esse comportamento. Tudo o que diz sobre__FILE__ é que ele se expande para "O nome presumido do arquivo de origem atual (uma literal de cadeia de caracteres)".

Uma alternativa é usar o #line diretiva. Ele substitui o número da linha atual e, opcionalmente, o nome do arquivo de origem. Se você deseja substituir o nome do arquivo, mas deixar o número da linha em branco, use a __LINE__macro.

Por exemplo, você pode adicionar isso próximo ao topo de file.c:

#line __LINE__ "file.c"

O único problema disso é que ele atribui o número da linha especificada à linha a seguir e o primeiro argumento #linedeve ser uma sequência de dígitos, para que você não possa fazer algo como

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

Assegurando que o nome do arquivo no #line diretiva corresponda ao nome real do arquivo seja deixado como um exercício.

Pelo menos para o gcc, isso também afetará o nome do arquivo relatado nas mensagens de diagnóstico.

Um pouco atrasado para a festa, mas para o GCC dê uma olhada na -ffile-prefix-map=old=newopção:

Ao compilar arquivos que residem no diretório antigo , registre todas as referências a eles no resultado da compilação como se os arquivos residissem no diretório novo . Especificar esta opção é equivalente a especificar todas as -f*-prefix-mapopções individuais . Isso pode ser usado para criar construções reproduzíveis independentes do local. Veja também -fmacro-prefix-mape -fdebug-prefix-map.

Portanto, para minhas compilações Jenkins , adicionarei uma -ffile-prefix-map=${WORKSPACE}/=/outra para remover o prefixo local de instalação do pacote de desenvolvimento.

OBSERVAÇÃO Infelizmente, a -ffile-prefix-mapopção só está disponível no GCC 8 em diante, como é o -fmacro-prefix-mapque, penso eu , faz a __FILE__parte. Por exemplo, no GCC 5, temos apenas o -fdebug-prefix-mapque não parece (afetar) __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__)]);
  }

O código gera um deslocamento do tempo de compilação quando:

• gcc: pelo menos gcc6.1 + -O1

• msvc: colocar resultado na variável constexpr:

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

• clang: persiste na não compilação da avaliação do tempo

Existe um truque para forçar todos os 3 compiladores a compilarem a avaliação do tempo, mesmo na configuração de depuração com otimização desabilitada:

    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

No VC, ao usar /FC, __FILE__expande para o caminho completo, sem a /FCopção __FILE__expande o nome do arquivo. ref: aqui

Não há tempo de compilação para fazer isso. Obviamente, você pode fazê-lo em tempo de execução usando o tempo de execução C, como algumas das outras respostas demonstraram, mas em tempo de compilação, quando o pré-processador entrar em ação, você estará sem sorte.

Use a função basename () ou, se você estiver no Windows, _splitpath () .

#include <libgen.h>

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

Tente também man 3 basenameem uma concha.

Se você estiver usando o CMAKEcompilador GNU, isso globaldefine bem:

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

Eu uso a mesma solução com a resposta do @Patrick há anos.

Há um pequeno problema quando o caminho completo contém um link de símbolo.

Melhor solução.

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 $<))\"'")

Por que usar isso?

• -Wno-builtin-macro-redefinedpara silenciar os avisos do compilador para redefinir a __FILE__macro.

  Para esses compiladores não suportam isso, consulte a maneira Robusta abaixo.

• Tirar o caminho do projeto do caminho do arquivo é o seu requisito real . Você não vai gostar de perder tempo para descobrir onde está um header.harquivo src/foo/header.hou src/bar/header.h.

• Devemos tirar a __FILE__macrocmake arquivo de configuração.

  Essa macro é usada na maioria dos códigos existentes. Simplesmente redefina que pode liberar você.

  Compiladores como gccpredefinem essa macro a partir dos argumentos da linha de comando. E o caminho completo é escrito em makefiles gerado por cmake.

• CMAKE_*_FLAGSÉ necessário o código rígido .

  Existem alguns comandos para adicionar opções ou definições do compilador em uma versão mais recente, como add_definitions()e add_compile_definitions(). Esses comandos analisam as funções make, como substantes se aplicam aos arquivos de origem. Não é isso que queremos.

Maneira robusta para -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)

Lembre-se de remover esta opção do compilador da set(*_FLAGS ... -D__FILE__=...)linha.

Uma pequena variação do que o @ red1ynx proposto criaria a seguinte macro:

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

Em cada um dos seus arquivos .c (pp), adicione:

SET_THIS_FILE_NAME();

Então você pode consultar em THIS_FILE_NAMEvez de __FILE__:

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

Isso significa que a construção é executada uma vez por arquivo .c (pp) em vez de cada vez que a macro é referenciada.

É limitado a usar apenas de arquivos .c (pp) e não pode ser usado nos arquivos de cabeçalho.

Eu fiz uma macro __FILENAME__ que evita cortar caminho completo a cada vez. O problema é manter o nome do arquivo resultante em uma variável local cpp.

Isso pode ser feito facilmente, definindo uma variável global estática no arquivo .h . Essa definição fornece variáveis ​​separadas e independentes em cada arquivo .cpp que inclui o arquivo .h . Para ser uma prova de multithreading, vale a pena fazer com que a (s) variável (s) também encadeie (TLS) local.

Uma variável armazena o nome do arquivo (reduzido). Outro detém o valor não cortado que __FILE__deu. O arquivo h:

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

A própria macro chama método com toda a lógica:

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

E a função é implementada desta maneira:

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;
}

O removePath () pode ser implementado de diferentes maneiras, mas o rápido e o simples parecem estar com o 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;
}

O compilador Clang recente possui uma __FILE_NAME__macro (veja aqui ).

só espero melhorar um pouco a macro FILE:

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

isso captura / e \, como Czarek Tomczak solicitou, e funciona muito bem no meu ambiente misto.

Experimentar

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

após as instruções de inclusão no seu arquivo de origem e adicione

#pragma pop_macro("__FILE__")

no final do seu arquivo de origem.

Aqui está uma função portátil que funciona para Linux (caminho '/') e Windows (combinação de '\' e '/').
Compila com 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;
}

Saída padrão:

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: 

Aqui está a solução que usa o cálculo em tempo de compilação:

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 você acabou nesta página procurando uma maneira de remover o caminho de origem absoluto que está apontando para o local de criação feio do binário que você está enviando, abaixo pode atender às suas necessidades.

Embora isso não produza exatamente a resposta que o autor expressou seu desejo, pois pressupõe o uso do CMake , ele fica bem próximo. É uma pena que isso não tenha sido mencionado anteriormente por ninguém, pois teria me poupado muito tempo.

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

A configuração acima da variável para ONgerará o comando build no formato:

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

Como resultado, a __FILE__macro resolverá../../src/path/to/source.c

Documentação do CMake

Cuidado com o aviso na página de documentação:

Use caminhos relativos (pode não funcionar!).

Não é garantido que funcione em todos os casos, mas funcionou no meu - CMake 3.13 + gcc 4.5

Como você está usando o GCC, você pode tirar proveito de

__BASE_FILE__Essa macro se expande para o nome do arquivo de entrada principal, na forma de uma constante de seqüência C. Este é o arquivo de origem especificado na linha de comandos do pré-processador ou compilador C

e depois controle como você deseja exibir o nome do arquivo alterando a representação do arquivo de origem (caminho completo / caminho relativo / nome da base) no momento da compilação.

Aqui está uma solução que funciona para ambientes que não possuem a biblioteca de strings (kernel do Linux, sistemas incorporados etc.):

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

Agora basta usar em FILENAMEvez de __FILENAME__. Sim, ainda é uma coisa de tempo de execução, mas funciona.

#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

Uma resposta curta e funcional para Windows e * nix:

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