Макрос __FILE__ показывает полный путь

Стандартный предопределенный макрос, __FILE__доступный в C, показывает полный путь к файлу. Есть ли способ сократить путь? Я имею ввиду вместо

/full/path/to/file.c

я вижу

to/file.c

или

file.c

Пытаться

#include <string.h>

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

Для Windows используйте «\\» вместо «/».

Вот совет, если вы используете cmake. От: http://public.kitware.com/pipermail/cmake/2013-January/053117.html

Я копирую совет, так что все это на этой странице:

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

Если вы используете GNU make, я не вижу причин, по которым вы не могли бы распространить это на ваши собственные make-файлы. Например, у вас может быть такая строка:

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

где $(SOURCE_PREFIX)префикс, который вы хотите удалить.

Тогда используйте __FILENAME__вместо __FILE__.

Я только что подумал об отличном решении, которое работает как с исходными файлами, так и с заголовочными файлами, очень эффективно и работает во время компиляции на всех платформах без специфичных для компилятора расширений. Это решение также сохраняет относительную структуру каталогов вашего проекта, чтобы вы знали, в какой папке находится файл, и только относительно корня вашего проекта.

Идея состоит в том, чтобы получить размер исходного каталога с помощью инструмента сборки и просто добавить его в __FILE__макрос, полностью удалив каталог и показывая только имя файла, начиная с исходного каталога.

Следующий пример реализован с использованием CMake, но нет никаких причин, по которым он не будет работать с любыми другими инструментами сборки, потому что трюк очень прост.

В файле CMakeLists.txt определите макрос, имеющий длину пути к вашему проекту в 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}")

В исходном коде определите __FILENAME__макрос, который просто добавляет размер исходного пути к __FILE__макросу:

#define __FILENAME__ (__FILE__ + SOURCE_PATH_SIZE)

Тогда просто используйте этот новый макрос вместо __FILE__ макроса. Это работает, потому что __FILE__путь всегда будет начинаться с пути к вашему исходному каталогу CMake. Удалив его из __FILE__строки, препроцессор позаботится о том, чтобы указать правильное имя файла, и все это будет относиться к корню вашего проекта CMake.

Если вы заботитесь о производительности, это так же эффективно, как использование __FILE__ , потому что оба __FILE__и SOURCE_PATH_SIZEявляются известными константами времени компиляции, поэтому он может быть оптимизирован компилятором.

Единственное место, где это может потерпеть неудачу, - это если вы используете это в сгенерированных файлах, а они находятся в папке для сборки вне исходного кода. Тогда вам, вероятно, придется создать другой макрос, используя CMAKE_BUILD_DIRпеременную вместо CMAKE_SOURCE_DIR.

Чисто скомпилируйте временное решение здесь. Он основан на том факте, что sizeof()строковый литерал возвращает свою длину + 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__)

Не стесняйтесь расширять каскад условных операторов до максимально разумного имени файла в проекте. Длина пути не имеет значения, если вы проверяете достаточно далеко от конца строки.

Я посмотрю, смогу ли я получить подобный макрос без жестко запрограммированной длины с макрорекурсией ...

По крайней мере для gcc значение __FILE__- это путь к файлу, указанный в командной строке компилятора . Если вы компилируете file.cтак:

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

__FILE__будет расширяться "/full/path/to/file.c". Если вы вместо этого сделаете это:

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

затем __FILE__расширится до всего"file.c" .

Это может или не может быть практичным.

Стандарт C не требует такого поведения. Все это говорит о__FILE__ это то, что он расширяется до «Предполагаемого имени текущего исходного файла (символьная строка литерала)».

Альтернативой является использование #lineдирективы. Он переопределяет текущий номер строки и, необязательно, имя исходного файла. Если вы хотите переопределить имя файла, но оставить номер строки в покое, используйте__LINE__ макрос.

Например, вы можете добавить это в верхней части file.c:

#line __LINE__ "file.c"

Единственная проблема с этим состоит в том, что он назначает указанный номер строки следующей строке, и первый аргумент #lineдолжен быть последовательностью цифр, чтобы вы не могли сделать что-то вроде

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

Проверка того, что имя файла в #lineдирективе соответствует фактическому имени файла, оставляется в качестве упражнения.

По крайней мере для gcc это также повлияет на имя файла, указанное в диагностических сообщениях.

Немного опоздал на вечеринку, но для GCC взглянем на -ffile-prefix-map=old=newвариант:

При компиляции файлов, находящихся в старом каталоге , запишите любые ссылки на них в результате компиляции, как если бы файлы находились в новом каталоге . Указание этого параметра эквивалентно указанию всех отдельных -f*-prefix-mapпараметров. Это может использоваться для создания воспроизводимых сборок, которые не зависят от местоположения. Смотрите также -fmacro-prefix-mapи -fdebug-prefix-map.

Так что для моих сборок Jenkins я добавлю-ffile-prefix-map=${WORKSPACE}/=/ и еще один, чтобы удалить префикс локальной установки пакета dev.

П р и м е ч а н и е - К сожалению, эта -ffile-prefix-mapопция доступна только в GCC 8 и более поздних версиях, -fmacro-prefix-mapчто, я думаю , и делает свою __FILE__роль. Например, GCC 5, у нас есть только то, -fdebug-prefix-mapчто не влияет __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__)]);
  }

Код генерирует смещение времени компиляции, когда:

• gcc: по крайней мере, gcc6.1 + -O1

• msvc: положить результат в переменную constexpr:

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

• clang: сохраняется при некомпилированной оценке времени

Есть хитрость, заставляющая все 3 компилятора выполнять оценку времени компиляции даже в конфигурации отладки с отключенной оптимизацией:

    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

В VC, при использовании /FC, __FILE__расширяется до полного пути, без /FCопции __FILE__расширения имени файла. ссылка: здесь

Там нет времени компиляции способ сделать это. Очевидно, что вы можете сделать это во время выполнения, используя среду выполнения C, как продемонстрировали некоторые другие ответы, но во время компиляции, когда включается препроцессор, вам не повезло.

Используйте функцию basename () или, если вы работаете в Windows, _splitpath () .

#include <libgen.h>

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

Также попробуйте man 3 basenameв оболочке.

Если вы используете CMAKEкомпилятор GNU, это globalопределение отлично работает:

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

У меня есть использовать один и тот же раствор с @Patrick «s ответа в течение многих лет.

Есть небольшая проблема, когда полный путь содержит символьную ссылку.

Лучшее решение.

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

Зачем использовать это?

• -Wno-builtin-macro-redefinedотключить предупреждения компилятора для переопределения __FILE__макроса.

  Для тех компиляторов, которые не поддерживают это, обратитесь к Robust способ ниже.

• Уберите путь проекта из пути к файлу - это ваше реальное требование. Вам не понравится тратить время, чтобы узнать, где находится header.hфайл, src/foo/header.hили src/bar/header.h.

• Мы должны раздеть __FILE__макрос вcmake конфигурационном файле.

  Этот макрос используется в большинстве существующих кодов. Просто переопределите это может освободить вас.

  Компиляторы вроде gccпредопределяют этот макрос из аргументов командной строки. И полный путь записывается в makefileсгенерированном cmake.

• Жесткий код в CMAKE_*_FLAGSТребуется .

  Есть некоторые команды для добавления опций или определений компилятора в более позднюю версию, например, add_definitions()и add_compile_definitions(). Эти команды будут анализировать функции make, как и substраньше, к исходным файлам. Этого мы не хотим.

Надежный путь для -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)

Не забудьте удалить эту опцию компилятора из set(*_FLAGS ... -D__FILE__=...)строки.

Небольшое отклонение от предложенного @ red1ynx будет заключаться в создании следующего макроса:

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

В каждом из ваших .c (pp) файлов добавьте:

SET_THIS_FILE_NAME();

Тогда вы можете обратиться к THIS_FILE_NAMEвместо __FILE__:

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

Это означает, что построение выполняется один раз для каждого файла .c (pp) вместо каждого обращения к макросу.

Он ограничен использованием только из файлов .c (pp) и будет непригодным для использования из заголовочных файлов.

Я сделал макрос __FILENAME__ который избегает разрезания полного пути каждый раз. Проблема заключается в том, чтобы хранить полученное имя файла в локальной переменной cpp.

Это можно легко сделать, определив статическую глобальную переменную в файле .h . Это определение дает отдельные и независимые переменные в каждом файле .cpp, который включает в себя .h . Для того, чтобы быть многопоточным, стоит сделать переменную (и) также поточно локальной (TLS).

Одна переменная хранит имя файла (сокращенное). Другой содержит необрезанное значение, которое __FILE__дал. Файл h:

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

Сам макрос вызывает метод со всей логикой:

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

И функция реализована так:

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 () может быть реализован по-разному, но быстрый и простой, кажется, с 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;
}

В недавнем компиляторе Clang есть __FILE_NAME__макрос (см. Здесь ).

просто надеюсь немного улучшить макрос FILE:

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

это ловит / и \, как просил Царек Томчак, и это прекрасно работает в моей смешанной среде.

Пытаться

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

после включения операторов в ваш исходный файл и добавить

#pragma pop_macro("__FILE__")

в конце вашего исходного файла.

Вот переносимая функция, которая работает как для Linux (путь '/'), так и для Windows (сочетание '\' и '/').
Компилируется с gcc, clang и 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;
}

Стандартный вывод:

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: 

Вот решение, которое использует вычисление времени компиляции:

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

Если вы оказались на этой странице в поисках способа удалить абсолютный исходный путь, указывающий на некрасивое местоположение сборки из бинарного файла, который вы отправляете, приведенный ниже может удовлетворить ваши потребности.

Хотя это не дает точного ответа, о котором автор выразил свое желание, так как предполагает использование CMake , он довольно близок. Жаль, что никто не упоминал об этом раньше, так как это сэкономило бы мне массу времени.

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

Установка вышеуказанной переменной в ONсгенерирует команду сборки в формате:

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

В результате __FILE__макрос разрешится в../../src/path/to/source.c

CMake документация

Остерегайтесь предупреждения на странице документации, хотя:

Используйте относительные пути (может не работать!).

Не гарантируется работа во всех случаях, но работал в моем - CMake 3.13 + gcc 4.5

Так как вы используете GCC, вы можете воспользоваться в

__BASE_FILE__Этот макрос расширяется до имени основного входного файла в форме строковой константы C. Это исходный файл, который был указан в командной строке препроцессора или компилятора Си

а затем управляйте тем, как вы хотите отобразить имя файла, изменив представление исходного файла (полный путь / относительный путь / базовое имя) во время компиляции.

Вот решение, которое работает для сред, в которых нет строковой библиотеки (ядро Linux, встроенные системы и т. Д.):

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

Теперь просто используйте FILENAMEвместо __FILENAME__. Да, это все еще во время выполнения, но это работает.

#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

Краткий рабочий ответ для Windows и * nix:

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