La macro __FILE__ affiche le chemin complet

La macro standard prédéfinie __FILE__disponible en C montre le chemin complet du fichier. Existe-t-il un moyen de raccourcir le chemin? Je veux dire au lieu de

/full/path/to/file.c

je vois

to/file.c

ou

file.c

Essayer

#include <string.h>

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

Pour Windows, utilisez «\\» au lieu de «/».

Voici une astuce si vous utilisez cmake. De: http://public.kitware.com/pipermail/cmake/2013-January/053117.html

Je copie le conseil donc tout est sur cette page:

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

Si vous utilisez GNU make, je ne vois aucune raison pour laquelle vous ne pourriez pas étendre cela à vos propres makefiles. Par exemple, vous pourriez avoir une ligne comme celle-ci:

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

où $(SOURCE_PREFIX)est le préfixe que vous souhaitez supprimer.

Ensuite, utilisez __FILENAME__à la place de __FILE__.

Je viens de penser à une excellente solution à cela qui fonctionne à la fois avec les fichiers source et en-tête, est très efficace et fonctionne au moment de la compilation sur toutes les plates-formes sans extensions spécifiques au compilateur. Cette solution préserve également la structure de répertoires relative de votre projet, afin que vous sachiez dans quel dossier se trouve le fichier, et uniquement par rapport à la racine de votre projet.

L'idée est d'obtenir la taille du répertoire source avec votre outil de construction et de l'ajouter simplement à la __FILE__macro, en supprimant entièrement le répertoire et en affichant uniquement le nom du fichier commençant à votre répertoire source.

L'exemple suivant est implémenté à l'aide de CMake, mais il n'y a aucune raison qu'il ne fonctionne avec aucun autre outil de construction, car l'astuce est très simple.

Dans le fichier CMakeLists.txt, définissez une macro qui a la longueur du chemin vers votre projet sur 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}")

Sur votre code source, définissez une __FILENAME__macro qui ajoute simplement la taille du chemin source à la __FILE__macro:

#define __FILENAME__ (__FILE__ + SOURCE_PATH_SIZE)

Ensuite, utilisez simplement cette nouvelle macro au lieu de la __FILE__macro. Cela fonctionne car le __FILE__chemin commencera toujours par le chemin de votre répertoire source CMake. En le supprimant de la __FILE__chaîne, le préprocesseur se chargera de spécifier le nom de fichier correct et tout sera relatif à la racine de votre projet CMake.

Si vous vous souciez des performances, c'est aussi efficace que d'utiliser __FILE__, car les deux __FILE__et SOURCE_PATH_SIZEsont des constantes de temps de compilation connues, de sorte qu'elles peuvent être optimisées par le compilateur.

Le seul endroit où cela échouerait est si vous l'utilisez sur des fichiers générés et qu'ils se trouvent dans un dossier de construction hors source. Ensuite, vous devrez probablement créer une autre macro en utilisant la CMAKE_BUILD_DIRvariable au lieu de CMAKE_SOURCE_DIR.

Solution de temps de compilation purement ici. Il est basé sur le fait qu'un sizeof()littéral de chaîne renvoie sa longueur + 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__)

N'hésitez pas à étendre la cascade d'opérateurs conditionnels au nom de fichier sensible maximal dans le projet. La longueur du chemin n'a pas d'importance, tant que vous vérifiez suffisamment loin de la fin de la chaîne.

Je vais voir si je peux obtenir une macro similaire sans longueur codée en dur avec la récursivité des macros ...

Au moins pour gcc, la valeur de __FILE__est le chemin du fichier tel que spécifié sur la ligne de commande du compilateur . Si vous compilez file.ccomme ceci:

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

le __FILE__va s'étendre à "/full/path/to/file.c". Si vous faites plutôt ceci:

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

puis __FILE__s'étendra à juste "file.c".

Cela peut être pratique ou non.

La norme C n'exige pas ce comportement. Tout ce qu'il dit, __FILE__c'est qu'il se développe en "Le nom présumé du fichier source actuel (une chaîne de caractères littérale)".

Une alternative consiste à utiliser la #linedirective. Il remplace le numéro de ligne actuel et éventuellement le nom du fichier source. Si vous souhaitez remplacer le nom du fichier mais laissez le numéro de ligne seul, utilisez la __LINE__macro.

Par exemple, vous pouvez ajouter ceci près du haut de file.c:

#line __LINE__ "file.c"

Le seul problème avec ceci est qu'il attribue le numéro de ligne spécifié à la ligne suivante , et le premier argument #linedoit être une séquence de chiffres afin que vous ne puissiez pas faire quelque chose comme

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

S'assurer que le nom de fichier dans la #linedirective correspond au nom réel du fichier est laissé comme exercice.

Au moins pour gcc, cela affectera également le nom de fichier indiqué dans les messages de diagnostic.

Un peu tard à la fête, mais pour GCC, jetez un œil à l' -ffile-prefix-map=old=newoption:

Lors de la compilation de fichiers résidant dans le répertoire ancien , enregistrez toute référence à ceux-ci dans le résultat de la compilation comme si les fichiers résidaient dans le répertoire nouveau à la place. Spécifier cette option équivaut à spécifier toutes les -f*-prefix-mapoptions individuelles . Cela peut être utilisé pour créer des constructions reproductibles indépendantes de l'emplacement. Voir aussi -fmacro-prefix-mapet -fdebug-prefix-map.

Donc, pour mes builds Jenkins-ffile-prefix-map=${WORKSPACE}/=/ , j'ajouterai , et un autre pour supprimer le préfixe d'installation du package de développement local.

NOTE Malheureusement, l' -ffile-prefix-mapoption n'est disponible qu'à partir de GCC 8, comme c'est le cas -fmacro-prefix-map, je pense , pour la __FILE__partie. Pour, disons, GCC 5, nous n'avons que -fdebug-prefix-mapce qui ne (semble pas) affecter __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__)]);
  }

Le code génère un décalage de temps de compilation lorsque:

• gcc: au moins gcc6.1 + -O1

• msvc: place le résultat dans la variable constexpr:

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

• clang: persiste en ne compilant pas l'évaluation du temps

Il existe une astuce pour forcer les 3 compilateurs à compiler l'évaluation du temps même dans la configuration de débogage avec l'optimisation désactivée:

    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

Dans VC, lors de l'utilisation /FC, se __FILE__développe jusqu'au chemin complet, sans l' /FCoption __FILE__développe le nom du fichier. ref: ici

Il n'y a pas de moyen de temps de compilation pour ce faire. Évidemment, vous pouvez le faire au moment de l'exécution en utilisant le runtime C, comme certaines des autres réponses l'ont démontré, mais au moment de la compilation, lorsque le pré-processeur entre en action, vous n'avez pas de chance.

Utilisez la fonction basename () ou, si vous êtes sous Windows, _splitpath () .

#include <libgen.h>

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

Essayez également man 3 basenamedans une coque.

Si vous utilisez CMAKEavec le compilateur GNU, cette globaldéfinition fonctionne bien:

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

J'utilise la même solution avec la réponse de @Patrick depuis des années.

Il y a un petit problème lorsque le chemin complet contient un lien de symbole.

Meilleure solution.

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

Pourquoi utiliser cela?

• -Wno-builtin-macro-redefinedpour désactiver les avertissements du compilateur pour la redéfinition de la __FILE__macro.

  Pour que ces compilateurs ne prennent pas en charge cela, reportez-vous à la méthode Robust ci-dessous.

• Supprimer le chemin du projet du chemin du fichier est votre véritable exigence. Vous n'aimerez pas perdre de temps à savoir où se trouve un header.hfichier, src/foo/header.hou src/bar/header.h.

• Nous devrions supprimer la __FILE__macro dans le cmakefichier de configuration.

  Cette macro est utilisée dans la plupart des codes existants. Le redéfinir simplement peut vous libérer.

  Les compilateurs comme gccprédéfinissent cette macro à partir des arguments de ligne de commande. Et le chemin complet est écrit en makefiles généré par cmake.

• Un code en dur CMAKE_*_FLAGSest requis.

  Il existe des commandes pour ajouter des options ou des définitions de compilateur dans une version plus récente, comme add_definitions()et add_compile_definitions(). Ces commandes analyseront les fonctions make comme substavant et s'appliqueront aux fichiers source. Ce n'est pas ce que nous voulons.

Un moyen robuste pour -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)

N'oubliez pas de supprimer cette option du compilateur de la set(*_FLAGS ... -D__FILE__=...)ligne.

Une légère variation de ce que @ red1ynx proposait serait de créer la macro suivante:

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

Dans chacun de vos fichiers .c (pp), ajoutez:

SET_THIS_FILE_NAME();

Ensuite, vous pouvez vous référer à THIS_FILE_NAMEau lieu de __FILE__:

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

Cela signifie que la construction est effectuée une fois par fichier .c (pp) au lieu de chaque fois que la macro est référencée.

Il est limité à une utilisation uniquement à partir de fichiers .c (pp) et serait inutilisable à partir de fichiers d'en-tête.

J'ai fait une macro __FILENAME__qui évite de couper le chemin complet à chaque fois. Le problème est de conserver le nom de fichier résultant dans une variable cpp-locale.

Cela peut être facilement fait en définissant une variable globale statique dans le fichier .h . Cette définition donne des variables séparées et indépendantes dans chaque fichier .cpp qui inclut le .h . Afin d'être une preuve multithreading, il vaut la peine de rendre la (les) variable (s) également thread local (TLS).

Une variable stocke le nom de fichier (réduit). Un autre détient la valeur non coupée qui a __FILE__donné. Le fichier h:

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

La macro elle-même appelle la méthode avec toute la logique:

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

Et la fonction est implémentée de cette façon:

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

Le removePath () peut être implémenté de différentes manières, mais le rapide et simple semble être avec 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;
}

Le compilateur Clang récent a une __FILE_NAME__macro (voir ici ).

espérons simplement améliorer un peu la macro FILE:

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

ceci attrape / et \, comme Czarek Tomczak l'a demandé, et cela fonctionne très bien dans mon environnement mixte.

Essayer

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

après les instructions d'inclusion dans votre fichier source et ajoutez

#pragma pop_macro("__FILE__")

à la fin de votre fichier source.

Voici une fonction portable qui fonctionne à la fois pour Linux (chemin «/») et Windows (mélange de «\» et «/»).
Compile avec gcc, clang et 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;
}

Sortie 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: 

Voici la solution qui utilise le calcul au moment de la compilation:

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

Si vous vous retrouvez sur cette page à la recherche d'un moyen de supprimer le chemin source absolu qui pointe vers l'emplacement de construction laide du binaire que vous expédiez, ci-dessous pourrait répondre à vos besoins.

Bien que cela ne produise pas exactement la réponse pour laquelle l'auteur a exprimé son souhait puisqu'il suppose l'utilisation de CMake , cela se rapproche assez. C'est dommage que cela n'ait été mentionné plus tôt par personne car cela m'aurait fait gagner beaucoup de temps.

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

Définir la variable ci-dessus sur ONgénérera une commande de construction au format:

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

En conséquence, la __FILE__macro se résoudra à../../src/path/to/source.c

Documentation CMake

Attention cependant à l'avertissement sur la page de documentation:

Utilisez des chemins relatifs (peut ne pas fonctionner!).

Il n'est pas garanti de fonctionner dans tous les cas, mais a fonctionné dans le mien - CMake 3.13 + gcc 4.5

Puisque vous utilisez GCC, vous pouvez profiter de

__BASE_FILE__Cette macro se développe au nom du fichier d'entrée principal, sous la forme d'une constante de chaîne C. Il s'agit du fichier source spécifié sur la ligne de commande du préprocesseur ou du compilateur C

puis contrôlez la manière dont vous souhaitez afficher le nom de fichier en modifiant la représentation du fichier source (chemin complet / chemin relatif / nom de base) au moment de la compilation.

Voici une solution qui fonctionne pour les environnements qui ne disposent pas de la bibliothèque de chaînes (noyau Linux, systèmes embarqués, 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; })

Maintenant, utilisez simplement à la FILENAMEplace de __FILENAME__. Oui, c'est toujours une chose d'exécution, mais cela fonctionne.

#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

Une réponse courte et fonctionnelle pour Windows et * nix:

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