Makro __FILE__ pokazuje pełną ścieżkę

Standardowe predefiniowane makro __FILE__dostępne w języku C pokazuje pełną ścieżkę do pliku. Czy jest jakiś sposób na skrócenie ścieżki? Mam na myśli zamiast

/full/path/to/file.c

Widzę

to/file.c

lub

file.c

Próbować

#include <string.h>

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

W systemie Windows użyj „\\” zamiast „/”.

Oto wskazówka, jeśli używasz cmake. Z: http://public.kitware.com/pipermail/cmake/2013-J January 053117.html

Kopiuję wskazówkę, więc wszystko jest na tej stronie:

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

Jeśli używasz make GNU, nie widzę powodu, dla którego nie mógłbyś rozszerzyć tego na własne pliki makefile. Na przykład możesz mieć taką linię:

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

gdzie $(SOURCE_PREFIX)jest prefiks, który chcesz usunąć.

Następnie użyj __FILENAME__zamiast __FILE__.

Właśnie wymyśliłem świetne rozwiązanie, które działa zarówno z plikami źródłowymi, jak i nagłówkowymi, jest bardzo wydajne i działa w czasie kompilacji na wszystkich platformach bez rozszerzeń specyficznych dla kompilatora. To rozwiązanie zachowuje również względną strukturę katalogów projektu, dzięki czemu wiesz, w którym folderze znajduje się plik, i tylko w odniesieniu do katalogu głównego projektu.

Chodzi o to, aby uzyskać rozmiar katalogu źródłowego za pomocą narzędzia do budowania i po prostu dodać go do __FILE__makra, całkowicie usuwając katalog i wyświetlając tylko nazwę pliku, zaczynając od katalogu źródłowego.

Poniższy przykład jest zaimplementowany przy użyciu CMake, ale nie ma powodu, dla którego nie działałby z innymi narzędziami do kompilacji, ponieważ sztuczka jest bardzo prosta.

W pliku CMakeLists.txt zdefiniuj makro, które ma długość ścieżki do twojego projektu na 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}")

W kodzie źródłowym zdefiniuj __FILENAME__makro, które po prostu dodaje rozmiar ścieżki źródłowej do __FILE__makra:

#define __FILENAME__ (__FILE__ + SOURCE_PATH_SIZE)

Następnie użyj tego nowego makra zamiast __FILE__makra. To działa, ponieważ __FILE__ścieżka zawsze zaczyna się od ścieżki do katalogu źródłowego CMake. Usuwając go z __FILE__łańcucha, preprocesor zajmie się określeniem poprawnej nazwy pliku i wszystko będzie zależne od katalogu głównego projektu CMake.

Jeśli zależy Ci na wydajności, jest to tak samo wydajne, jak użycie __FILE__, ponieważ obie __FILE__i SOURCE_PATH_SIZEsą znanymi stałymi czasu kompilacji, więc kompilator może je zoptymalizować.

Jedynym miejscem, w którym to się nie powiedzie, jest sytuacja, w której używasz tego na wygenerowanych plikach i znajdują się one w folderze kompilacji poza źródłem. Wtedy prawdopodobnie będziesz musiał utworzyć inne makro, używając CMAKE_BUILD_DIRzmiennej zamiast CMAKE_SOURCE_DIR.

Czysto skompiluj tutaj rozwiązanie czasu. Opiera się na fakcie, że sizeof()literał ciągu znaków zwraca swoją długość + 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__)

Możesz swobodnie rozszerzyć kaskadę operatorów warunkowych do maksymalnej rozsądnej nazwy pliku w projekcie. Długość ścieżki nie ma znaczenia, o ile sprawdzasz wystarczająco daleko od końca łańcucha.

Zobaczę, czy uda mi się uzyskać podobne makro bez zakodowanej długości z rekurencją makra ...

Przynajmniej dla gcc wartością __FILE__jest ścieżka do pliku określona w wierszu poleceń kompilatora . Jeśli kompilujesz w file.cten sposób:

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

__FILE__poszerzy się "/full/path/to/file.c". Jeśli zamiast tego zrobisz to:

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

następnie __FILE__rozwinie się do just "file.c".

Może to być praktyczne lub nie.

Standard C nie wymaga takiego zachowania. Mówi tylko o __FILE__tym, że rozwija się do „Domniemana nazwa bieżącego pliku źródłowego (literał ciągu znaków)”.

Alternatywą jest skorzystanie z #linedyrektywy. Zastępuje bieżący numer wiersza i opcjonalnie nazwę pliku źródłowego. Jeśli chcesz nadpisać nazwę pliku, ale pozostawić sam numer linii, użyj __LINE__makra.

Na przykład możesz dodać to w górnej części file.c:

#line __LINE__ "file.c"

Jedynym problemem jest to, że przypisuje określony numer linii do następnej linii, a pierwszy argument #linemusi być sekwencją cyfr, więc nie możesz zrobić czegoś takiego

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

Zapewnienie, że nazwa pliku w #linedyrektywie jest zgodna z rzeczywistą nazwą pliku, pozostaje jako ćwiczenie.

Przynajmniej w przypadku gcc wpłynie to również na nazwę pliku zgłaszaną w komunikatach diagnostycznych.

Trochę za późno na imprezę, ale dla GCC spójrz na -ffile-prefix-map=old=newopcję:

Podczas kompilowania plików znajdujących się w katalogu old , zapisz wszelkie odniesienia do nich w wyniku kompilacji, tak jakby pliki znajdowały się w katalogu new . Określenie tej opcji jest równoważne określeniu wszystkich indywidualnych -f*-prefix-mapopcji. Można to wykorzystać do tworzenia odtwarzalnych kompilacji, które są niezależne od lokalizacji. Zobacz także -fmacro-prefix-mapi -fdebug-prefix-map.

Więc dodam do moich kompilacji Jenkinsa-ffile-prefix-map=${WORKSPACE}/=/ , a drugą, aby usunąć prefiks instalacji lokalnego pakietu deweloperskiego.

UWAGA Niestety -ffile-prefix-mapopcja jest avalable tylko w GCC 8 roku, jak to -fmacro-prefix-map, które myślę , robi __FILE__część. Bo, powiedzmy, GCC 5, mamy tylko to, -fdebug-prefix-mapco nie (wydaje się) mieć wpływ __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__)]);
  }

Kod generuje przesunięcie czasu kompilacji, gdy:

• gcc: co najmniej gcc6.1 + -O1

• msvc: wstaw wynik do zmiennej constexpr:

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

• clang: utrzymuje się przy braku oceny czasu kompilacji

Istnieje sztuczka polegająca na zmuszeniu wszystkich 3 kompilatorów do oceny czasu kompilacji, nawet w konfiguracji debugowania z wyłączoną optymalizacją:

    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

W VC, podczas używania /FC, __FILE__rozwija do pełnej ścieżki, bez /FCopcji __FILE__rozwija nazwę pliku. ref: tutaj

Nie ma sposobu, aby to zrobić. Oczywiście możesz to zrobić w czasie wykonywania, używając środowiska wykonawczego C, jak pokazały niektóre inne odpowiedzi, ale w czasie kompilacji, kiedy uruchamia się pre-procesor, nie masz szczęścia.

Użyj funkcji basename () lub, jeśli pracujesz w systemie Windows, _splitpath () .

#include <libgen.h>

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

Spróbuj także man 3 basenamew muszli.

Jeśli używasz CMAKEkompilatora GNU, to globalzdefiniowanie działa dobrze:

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

Muszę użyć tego samego rozwiązania z @Patrick jest odpowiedzią na lata.

Ma mały problem, gdy pełna ścieżka zawiera łącze symboliczne.

Lepsze rozwiązanie.

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

Dlaczego warto tego używać?

• -Wno-builtin-macro-redefinedwyciszyć ostrzeżenia kompilatora dotyczące przedefiniowania __FILE__makra.

  Te kompilatory nie obsługują tego, zapoznaj się z poniższym sposobem Robust .

• Usunięcie ścieżki projektu ze ścieżki do pliku jest Twoim prawdziwym wymaganiem. Nie chcesz tracić czasu, aby dowiedzieć się, gdzie jest header.hplik src/foo/header.hlub src/bar/header.h.

• Powinniśmy usunąć __FILE__makro w cmakepliku konfiguracyjnym.

  To makro jest używane w większości istniejących kodów. Po prostu przedefiniuj to, aby cię uwolnić.

  Kompilatory, takie jak, gccwstępnie definiują to makro na podstawie argumentów wiersza poleceń. Pełna ścieżka jest zapisywana w makefiles wygenerowanych przez cmake.

• CMAKE_*_FLAGSWymagany jest twardy kod .

  Istnieje kilka poleceń dodających opcje lub definicje kompilatora w niektórych nowszych wersjach, takich jak add_definitions()i add_compile_definitions(). Te polecenia przeanalizują funkcje make, takie jak substprzed zastosowaniem do plików źródłowych. Tego nie chcemy.

Solidny sposób na -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)

Pamiętaj, aby usunąć tę opcję kompilatora z set(*_FLAGS ... -D__FILE__=...)linii.

Niewielką odmianą tego, co zaproponował @ red1ynx, byłoby utworzenie następującego makra:

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

W każdym z plików .c (pp) dodaj:

SET_THIS_FILE_NAME();

Następnie możesz odwołać się THIS_FILE_NAMEzamiast __FILE__:

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

Oznacza to, że konstrukcja jest wykonywana raz na plik .c (pp), a nie za każdym razem, gdy odwołuje się do makra.

Jest ograniczone do używania tylko z plików .c (pp) i byłoby bezużyteczne z plików nagłówkowych.

Zrobiłem makro, __FILENAME__które za każdym razem unika cięcia pełnej ścieżki. Problemem jest przechowywanie wynikowej nazwy pliku w zmiennej cpp-local.

Można to łatwo zrobić, definiując statyczną zmienną globalną w pliku .h . Ta definicja zapewnia oddzielne i niezależne zmienne w każdym pliku .cpp , który zawiera rozszerzenie .h . Aby być odpornym na wielowątkowość, warto sprawić, aby zmienna (e) była również lokalna (TLS) w wątku.

Jedna zmienna przechowuje nazwę pliku (skurczona). Inny ma wartość, która __FILE__dawała niecięta. Plik h:

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

Samo makro wywołuje metodę z całą logiką:

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

A funkcja jest realizowana w ten sposób:

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 () można zaimplementować na różne sposoby, ale szybkie i proste wydaje się być dzięki 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;
}

Najnowszy kompilator Clang ma __FILE_NAME__makro (patrz tutaj ).

mam tylko nadzieję, że poprawię trochę makro FILE:

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

to łapie / i \, jak zażądał Czarek Tomczak, a to działa świetnie w moim mieszanym środowisku.

Próbować

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

po instrukcjach include w pliku źródłowym i dodaj

#pragma pop_macro("__FILE__")

na końcu pliku źródłowego.

Oto przenośna funkcja, która działa zarówno w systemie Linux (ścieżka „/”), jak i Windows (połączenie „\” i „/”).
Kompiluje się z gcc, clang i 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;
}

Wyjście standardowe:

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: 

Oto rozwiązanie, które wykorzystuje obliczenia czasu kompilacji:

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__);

Jeśli znalazłeś się na tej stronie, szukając sposobu na usunięcie bezwzględnej ścieżki źródłowej, która wskazuje brzydką lokalizację kompilacji z pliku binarnego, który wysyłasz, poniżej może odpowiadać Twoim potrzebom.

Chociaż nie daje to dokładnej odpowiedzi, której wyraził autor, ponieważ zakłada użycie CMake , jest dość blisko. Szkoda, że ​​nikt o tym wcześniej nie wspominał, bo zaoszczędziłoby mi to mnóstwo czasu.

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

Ustawienie powyższej zmiennej na ONwygeneruje polecenie budowania w formacie:

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

W rezultacie __FILE__makro rozwiąże problem../../src/path/to/source.c

Dokumentacja CMake

Uważaj jednak na ostrzeżenie na stronie dokumentacji:

Użyj ścieżek względnych (może nie działać!).

Nie ma gwarancji, że zadziała we wszystkich przypadkach, ale zadziałał w moim - CMake 3.13 + gcc 4.5

Ponieważ używasz GCC, możesz skorzystać z

__BASE_FILE__To makro jest interpretowane jako nazwa głównego pliku wejściowego w postaci stałej w języku C. To jest plik źródłowy określony w wierszu poleceń preprocesora lub kompilatora C.

a następnie kontroluj sposób wyświetlania nazwy pliku, zmieniając reprezentację pliku źródłowego (pełna ścieżka / ścieżka względna / nazwa podstawowa) w czasie kompilacji.

Oto rozwiązanie, które działa w środowiskach, które nie mają biblioteki ciągów (jądro Linuksa, systemy wbudowane itp.):

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

Teraz po prostu użyj FILENAMEzamiast __FILENAME__. Tak, nadal jest to element środowiska uruchomieniowego, ale działa.

#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

Krótka, działająca odpowiedź zarówno dla systemu Windows, jak i * nix:

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