__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を使用している場合、これを独自のmakefileに拡張できなかった理由はわかりません。たとえば、次のような行があるとします。

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場合はオプションを確認してください。

oldディレクトリにあるファイルをコンパイルするときは、ファイルが代わりにnewディレクトリにあるかのように、コンパイルの結果にそれらへの参照を記録します。このオプションを指定することは、個々の-f*-prefix-mapオプションをすべて指定することと同じです。これは、場所に依存しない再現可能なビルドを作成するために使用できます。-fmacro-prefix-mapおよびも参照してください -fdebug-prefix-map。

したがって、私のJenkinsビルドにはを追加し-ffile-prefix-map=${WORKSPACE}/=/、もう1つはローカル開発パッケージのインストールプレフィックスを削除します。

NOTEは残念ながら-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__が拡張ファイル名。ref：ここに

これを行うコンパイル時の方法はありません。他のいくつかの回答が示しているように、実行時にCランタイムを使用して実行できることは明らかですが、コンパイル時にプリプロセッサーが起動すると、運が悪くなります。

basename（）関数を使用します。Windowsの場合は、_splitpath（）を使用します。

#include <libgen.h>

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

またman 3 basename、シェルで試してください。

CMAKEGNUコンパイラを使用している場合、このglobal定義は正常に機能します。

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

@Patrickの回答で同じソリューションを何年も使用しています。

フルパスにシンボルリンクが含まれている場合、小さな問題があります。

より良いソリューション。

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__マクロを再定義するためのコンパイラ警告をミュートします。

  これらのコンパイラがこれをサポートしていない場合は、以下の堅牢な方法を参照してください。

• 実際の要件は、ファイルパスからプロジェクトパスを取り除くことです。あなたはここで見つけるために時間を無駄に好きではないだろうheader.hファイル、src/foo/header.hまたはsrc/bar/header.h。

• __FILE__マクロを削除する必要がありますcmakeファイルでます。

  このマクロは、ほとんどの既存のコードで使用されます。単にそれを再定義するだけであなたを自由にすることができます。

  のようなコンパイラgccは、コマンドライン引数からこのマクロを事前定義します。また、フルパスはによってmakefile生成されたs で記述されcmakeます。

• のハードコードCMAKE_*_FLAGSが必要です。

  やなどadd_definitions()、最近のバージョンにコンパイラオプションまたは定義を追加するコマンドがありますadd_compile_definitions()。これらのコマンドは、substソースファイルに適用する前のようにmake関数を解析します。それは私たちが望むことではありません。

の堅牢な方法-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）ファイルごとに1回実行されることを意味します。

.c（pp）ファイルからの使用に限定されており、ヘッダーファイルからは使用できません。

マクロした __FILENAME__毎回フルパスをカットしないようにを実行しました。問題は、結果のファイル名をcpp-local変数に保持することです。

これは、.hファイルで静的グローバル変数を定義することで簡単に実行できます。この定義は、.hを含む各.cppファイルに個別の独立した変数を与えます。マルチスレッディングに対応するには、変数をローカルスレッド（TLS）にすることも重要です。

1つの変数はファイル名（縮小）を格納します。もう1つは、__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__)

これは/と\をキャッチし、Czarek Tomczakが要求したように、これは私の混合環境でうまく機能します。

試す

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

ソースファイルのincludeステートメントの後に追加して

#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文字列定数の形式で、メイン入力ファイルの名前に展開されます。これは、プリプロセッサまたは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))