How to extract the source filename without path and suffix at compile time?

Question

Using both gcc with -std=c11 and g++ with -std=c++14.

E.g. for a file named src/dir/Hello.cxx it should expand to something like e.g.:

const char basename[] = "Hello";

or

const char basename[] = getStaticBasename(__FILE__);

as where getStaticBasename() is a macro (for C sources) or constexpr function (for C++ sources) which results to "Hello".

I have to avoid splitting the string from __FILE__ at runtime, because the path and suffix must not be compiled into the executable in any way.

The solution must be without dependencies to huge libraries such as boost.

As I have no makefiles, solutions like this cannot be used in my case.

Did one have a solution for that?

Edit 2015-07-02:

• I have no influence on how the compiler and linker was invoked (sometimes via makefile, sometimes from command line, or some IDE (Eclipse CDT managed make, Crossworks, Xcode et cetera. So the solution needs to be in code only.
• My use case is to provide some kind of "generic region identifier" for a small footprint logging solution. The application code (which uses my logger) should only #include <Joe/Logger.h> and within the later calls to e.g. LOG_DEBUG(...) I'll implicitely take use of the automatically generated "generic region identifier".
• My current solution is that the application code have to declare a JOE_LOG_FILE_REGION(Hello); (after #include <Joe/Logger.h>) before it could place LOG_DEBUG(...) in its code.

Solution 1

1. gcc builtin function can get the file name of a full path at compile time.

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

or

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

2. c++11 constexpr also can do this at compile time.

c++11 constexpr function can only use a return-statement.

example:

#include <stdio.h>

constexpr const char* str_end(const char *str) {
    return *str ? str_end(str + 1) : str;
}

constexpr bool str_slant(const char *str) {
    return *str == '/' ? true : (*str ? str_slant(str + 1) : false);
}

constexpr const char* r_slant(const char* str) {
    return *str == '/' ? (str + 1) : r_slant(str - 1);
}
constexpr const char* file_name(const char* str) {
    return str_slant(str) ? r_slant(str_end(str)) : str;
}

int main() {
    constexpr const char *const_file = file_name(__FILE__);
    puts(const_file);
    return 0;
}

source file name is foo/foo1/foo2/foo3/foo4.cpp

use g++ -o foo.exe foo/foo1/foo2/foo3/foo4.cpp -std=c++11 --save-temps to compile this file.

you can see this.

.file   "foo4.cpp"
        .section        .rodata
.LC0:
        .string "foo/foo1/foo2/foo3/foo4.cpp"
        .text
        .globl  main
        .type   main, @function
main:
.LFB4:
        .cfi_startproc
        pushq   %rbp
        .cfi_def_cfa_offset 16
        .cfi_offset 6, -16
        movq    %rsp, %rbp
        .cfi_def_cfa_register 6
        subq    $16, %rsp
        movq    $.LC0+19, -8(%rbp) 
        movl    $.LC0+19, %edi
        call    puts
        movl    $0, %eax
        leave
        .cfi_def_cfa 7, 8
        ret
        .cfi_endproc
.LFE4:
        .size   main, .-main
        .ident  "GCC: (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4"
        .section        .note.GNU-stack,"",@progbits

movl $.LC0+19, %edi .LC0 + 19 is the address of file name string without path and suffix

3. c++14 constexpr function can do this in a simple way

#include <iostream>

constexpr const char* file_name(const char* path) {
    const char* file = path;
    while (*path) {
        if (*path++ == '/') {
            file = path;
        }
    }
    return file;
}

int main() {
    constexpr const char* file = file_name(__FILE__);
    std::cout << file << std::endl;
    return 0;
}

c++14 constexpr function can use loop and local variable.

the file_name function will replace with a address of const char * at compiler time. ~

Solution 2

extract the base filename at compile time with no preprocessor tricks and no external scripts? c++14? no problem sir.

#include <iostream>
#include <string>

using namespace std;

namespace detail {
    constexpr bool is_path_sep(char c) {
        return c == '/' || c == '\\';
    }

    constexpr const char* strip_path(const char* path)
    {
        auto lastname = path;
        for (auto p = path ; *p ; ++p) {
            if (is_path_sep(*p) && *(p+1)) lastname = p+1;
        }
        return lastname;
    }

    struct basename_impl
    {
        constexpr basename_impl(const char* begin, const char* end)
        : _begin(begin), _end(end)
        {}

        void write(std::ostream& os) const {
            os.write(_begin, _end - _begin);
        }

        std::string as_string() const {
            return std::string(_begin, _end);
        }

        const char* const _begin;
        const char* const _end;
    };

    inline std::ostream& operator<<(std::ostream& os, const basename_impl& bi) {
        bi.write(os);
        return os;
    }

    inline std::string to_string(const basename_impl& bi) {
        return bi.as_string();
    }

    constexpr const char* last_dot_of(const char* p) {
        const char* last_dot = nullptr;
        for ( ; *p ; ++p) {
            if (*p == '.')
                last_dot = p;
        }
        return last_dot ? last_dot : p;
    }
}

// the filename with extension but no path
constexpr auto filename = detail::strip_path(__FILE__);
constexpr auto basename = detail::basename_impl(filename, detail::last_dot_of(filename));

auto main() -> int
{
    cout << filename << endl;
    cout << basename << endl;

    cout << to_string(basename) << endl;

    return 0;
}

Solution 3

If you run gcc from the folder where the source file is located, you will get a different __FILE__ than if you pass an absolute path (i.e. handed to gcc through an IDE).

• gcc test.c -otest.exe gives me __FILE__ as test.c.
• gcc c:\tmp\test.c -otest.exe gives me __FILE__ as c:\tmp\test.c.

Perhaps calling gcc from the path where the source is located is sufficient as work-around?

---

EDIT

Here is a "dirty" but safe hack which removes the file extension in compile-time. Not really something I'd recommend, but it was fun to write :) So take it for what it is worth. It only works in C.

#include <stdio.h>

#define EXT_LENGTH (sizeof(".c") - 1) // -1 null term

typedef union
{
  char filename_no_nul [sizeof(__FILE__)-EXT_LENGTH-1]; // -1 null term
  char filename_nul    [sizeof(__FILE__)-EXT_LENGTH];
} remove_ext_t;

int main (void)
{
  const remove_ext_t file = { __FILE__ };

  puts(file.filename_nul);

  return 0;
}

The union allocates one member which is large enough to hold the full path minus extension and null terminator. And it allocates one member which is large enough to hold the full path minus extension, though with a null terminator.

The member which is too small to hold the full __FILE__ is initialized with as much of __FILE__ as can fit. This is ok in C but not allowed in C++. If __FILE__ contains test.c, the union member will now be initialized to contain test with no null terminator.

There will however still be trailing zeroes after that string, because this hack abuses the fact that the other union member has been initialized according to the rules of "aggregate/union" initialization. This rule forces any remaining items in the "aggregate" to be initialized as if they had static storage duration, i.e to zero. Which happens to be the value of the null terminator.

Solution 4

It turns out to be very simple, you just need the #line preprocessor directive, example

#line 0 "Hello"

at the top of the file, this as is, if all you want is to hide the file name completely then

#line 0 ""

would work.

If you don't want to use Makefiles, you can use this

file=cfile;
content=$(sed -e "1s/^/#line 0 \"$file\"\n/" example/${file}.c);
echo $content | gcc -xc -O3 -o ${file} -

The -xc gcc flag above means (from gcc's documentation):

-x language:

Specify explicitly the language for the following input files (rather than letting the compiler choose a default based on the file name suffix). This option applies to all following input files until the next -x option. Possible values for language are:

          c  c-header  cpp-output
          c++  c++-header  c++-cpp-output
          objective-c  objective-c-header  objective-c-cpp-output
          objective-c++ objective-c++-header objective-c++-cpp-output
          assembler  assembler-with-cpp
          ada
          f77  f77-cpp-input f95  f95-cpp-input
          go
          java

If you don't have any sort of script that helps you building the source then there is no way to do it I think.

Also, you can see from the above quote of the gcc documentation, that you can save the files without any extension at all, and then combine @Lundin's original solution with this and use

gcc -xc -o file filename_without_extension

in this case __FILE__ would expand to "filename_without_extension", and you would achieve what you want, although you need to compile the file in the same directory where it lives, because otherwise it will contain the path to the file.

View more solutions

Comments

[P.P]

How do you put the string "hello" in the source file (i.e. in the #line directive)? The file name can be anything, not just hello.cpp.

[too honest for this site]

That becomes a nightmare when renaming files.

[Iharob Al Asimi]

@Olaf which is why using a Makefile is the best solution.

[Jens Gustedt]

This doesn't look very helpful. If you have to place the string of interest into the source, anyhow, you can just as well use it directly to initialize the variable.

[too honest for this site]

That would hardly help as such inside the code. (but would allow to pass a macro)

[Iharob Al Asimi]

@Olaf you are right, I don't think there is a solution that meets all the requirements. The good thing about this solution is that it doesn't require changing the __FILE__ macro if it was already used.

[Iharob Al Asimi]

@JensGustedt You can of course downvote if you like.

[too honest for this site]

If have required similar, but I pass it from SCons by -DFILE_BASE=.... The name is processed in Python/SCons that way.

[Iharob Al Asimi]

Why do you use scons? it's so complicated to use python tools, it's version 3 or 2 and all that cr*p... But yes, you are right, that would be a perfect solution, if the OP wanted to use build scripts of any kind. I don't like scons because my linux distro has a package manager rolled by my self, so if I need some new package I must compile it from source, which is a nightmare when the build tools are scons or waf.

[Iharob Al Asimi]

This is really smart, what can I say? ;).

[too honest for this site]

Yes, quite hackish, and I know some who would shoot me with a rope using such that. However, you could pack that into a header using 'static` and include in every file.

[Jens Gustedt]

What I meant is that you could just do gcc -O3 -o ${file} -DFILE_BASE="\"${file}\"" "${file}.c" directly without passing your source through sed and complicated stuff like that.

[Richard Hodges]

plast points to the last path separator (or beginning of string if there is none) so you want to return one past the separator to return the filename. However, you also don't want to return an empty string if the path happens to end with a slash (it's a corner case I know, but still...)

[mhsmith]

At least with gcc 6.3.0, the compiler does not allow __builtin_strrchr to be used in the initializer of a static variable, because "initializer element is not constant".

[Eric Postpischil]

There is text in the standard saying “If there are fewer initializers in a brace-enclosed list than there are elements or members of an aggregate, or fewer characters in a string literal used to initialize an array of known size than there are elements in the array, the remainder of the aggregate shall be initialized implicitly the same as objects that have static storage duration.” But this cannot literally be true, or union { int a, b; } = { 3 } would leave 0 in the union. It must be interpreted in light of…

[Eric Postpischil]

… “When no designations are present, subobjects of the current object are initialized in order according to the type of the current object: array elements in increasing subscript order, structure members in declaration order, and the first named member of a union.”

[alex]

I've tried your example with plain strrchr and strstr and in both cases optimization took place, so it seems it is not necessary to use __builtin_strrchr. Compiler: "GCC: (Debian 6.3.0-18+deb9u1) 6.3.0 20170516".

[Dmytro]

cute, they're extending the preprocessor but at the same time they don't give it full eval power of switching to php, so it can't delete files/google things/fetch/send network requests from preprocessor

[Dmytro]

cute, this constexpr thing really wants to become it's own programming language like PHP.

[Trevor Boyd Smith]

i tried to use your #define __FILENAME__ with constexpr const char* basename=__FILENAME__ but my g++ 4.8.5 complains about a function not being constexpr. so it seems that this solution depends on having compiler optimizations enabled.

[Trevor Boyd Smith]

I prefer your c++ only solution because it is always compile time (and you don't have to worry about optimizer being turned off and then your #define is runtime).

[Trevor Boyd Smith]

@Dmitry re "constexpr .. it's own programming language": myself and many articles I've read do consider constexpr it's own language. in addition there is the c++ templates... they are another language. preprocessor is another language.

[Trevor Boyd Smith]

RichardHodges your implementation is about 2 or 3 times more lines of code than @pexeer's solution and uses two for loops, uses struct, uses std::string, uses operator overloading, uses std::ostream. what features/added-benefit does your implementation do compared to @pexeer's?

[Richard Hodges]

@TrevorBoydSmith as far as I can see, I'm offering a little more utility in terms of providing ostream and to_stream overloads, and handling both windows and unix paths. However, peexer's solution was written a year after mine so he may have had more time to digest the question.

[Emile Cormier]

I wonder if compile times will be affected in projects that use the latter metafunction heavily.

[shargors]

These solutions leave the suffix so they does not satisfy the question. Or am I missing something?

[Fake Code Monkey Rashid]

@RichardHodges: More than that, yours is the only C++ solution that actually removes the suffix.