Здравствуйте, пффф, Вы писали:

П>В чем проблема при выводе в лог обрезать имена сорцов как тебе нравится?
Он хочет не светить свои C:\Users\Пупсик\Сырки\Этот_козёл_постоянно_задерживает_оплату\MySampleProject\SpisokMudakoff.h в бинаре

MS в документации брешет, что макрос __FILE__ раскрывается в полный путь только при указании ключа /FC. На деле же все компиляторы от 15.00 до 19.29 (совсем последних у меня нет) при отсутствии /FC кладут без путей только имена файлов .c/.cpp. Если __FILE__ встречается в заголовке, то для файлов, включенных #include "file.h", всегда кладутся полные пути, а для включенных #include <file.h> — относительные.

По логике, если уж класть полный путь, невзирая на отсутствие /FC, то надо бы наоборот — только для "внешних" файлов, включаемых #include <>. Для "собственных", включаемых #include "", следовало бы класть только имя (или то, что указано в кавычках).

Такое поведение тянет на баг, или ему есть более разумное объяснение?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Еще раз, по буквам:

Или, логика другая


ЕМ>- Для .h-файлов, включенных директивами #include "xxx.h" (так традиционно включаются "свои", локальные файлы), в объектный файл всегда кладется полный путь.

Так включаются все файлы, которые не являются файлами стандартной библиотеки языка, и ищутся в путях /I. Куда они указывают — хз, поэтому кладём полный путь


ЕМ>- Для .h-файлов, включенных директивами #include <xxx.h> (так традиционно включаются "чужие", библиотечные файлы), в объектный файл всегда кладется путь относительно его каталога, указанного в /I.

Так включаются только стандартные хидеры, соответственно, путь к ним фиксированный (лежат где-то рядом с компилятором)


ЕМ>Если второе еще можно считать логичным, то где логика в первом?

Вообще говоря, подключение инклюдов по <> компилятором может делаться как угодно, этих файлов вполне может не быть физически на диске. Это по стандарту так. Поэтому логика у компилятора по части пути в __FILE__ относительно стандарта вполне логичная.

Здравствуйте, Евгений Музыченко, Вы писали:

V>>Выглядит разумно
ЕМ>А разумное объяснение сделать сможете?

Попытаюсь:
— файлы c/cpp включаются в проект явно;
— файлы h/hpp могут залететь в проект "откуда угодно" из доступного + доп.указанного пути.

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>В чем именно Вы видите логику писать в бинарник полный путь к заведомо локальному файлу?

Вот прям заведомо-заведомо? А может, RTFM, все-таки?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Такое поведение тянет на баг, или ему есть более разумное объяснение?

Выглядит разумно

Здравствуйте, vdimas, Вы писали:

V>Выглядит разумно

А разумное объяснение сделать сможете?

Здравствуйте, vdimas, Вы писали:

V>- файлы c/cpp включаются в проект явно;
V>- файлы h/hpp могут залететь в проект "откуда угодно" из доступного + доп.указанного пути.

Еще раз, по буквам:

— Для .h-файлов, включенных директивами #include "xxx.h" (так традиционно включаются "свои", локальные файлы), в объектный файл всегда кладется полный путь.

— Для .h-файлов, включенных директивами #include <xxx.h> (так традиционно включаются "чужие", библиотечные файлы), в объектный файл всегда кладется путь относительно его каталога, указанного в /I.

Если второе еще можно считать логичным, то где логика в первом?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Еще раз, по буквам:
ЕМ>- Для .h-файлов, включенных директивами #include "xxx.h" (так традиционно включаются "свои", локальные файлы), в объектный файл всегда кладется полный путь.

Но подхватиться может "не свой" файл.


ЕМ>- Для .h-файлов, включенных директивами #include <xxx.h> (так традиционно включаются "чужие", библиотечные файлы), в объектный файл всегда кладется путь относительно его каталога, указанного в /I.

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

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


ЕМ>Если второе еще можно считать логичным, то где логика в первом?

В первом вообще ноль вопросов.

Здравствуйте, vdimas, Вы писали:

ЕМ>>- Для .h-файлов, включенных директивами #include "xxx.h" (так традиционно включаются "свои", локальные файлы), в объектный файл всегда кладется полный путь.

V>Но подхватиться может "не свой" файл.

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

ЕМ>>Если второе еще можно считать логичным, то где логика в первом?

V>В первом вообще ноль вопросов.

В чем именно Вы видите логику писать в бинарник полный путь к заведомо локальному файлу?

ЕМ>Такое поведение тянет на баг, или ему есть более разумное объяснение?
Отсутсвие жесткой записи абсолютных путей достигаеться сломанной компиляцией нескольких файлов с одинаковыми именами в разных папках.
Ломать еще и заголовки по всем библиотекам — до такого даже майкрософт не дойдет, отловят топов и говядиной насильно накормят.

Здравствуйте, rg45, Вы писали:

R>Вот прям заведомо-заведомо?

Я ж не зря подчеркнул:

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>

ЕМ>Как он может подхватиться иначе, как по ошибке? Кто в здравом уме использует форму с кавычками для включения файлов, находящихся неизвестно где?

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Кто в здравом уме использует форму с кавычками для включения файлов, находящихся неизвестно где?

В здравом уме можно описаться в имени включаемого файла и попасть на "неизвестно где".


ЕМ>>>Если второе еще можно считать логичным, то где логика в первом?
V>>В первом вообще ноль вопросов.
ЕМ>В чем именно Вы видите логику писать в бинарник полный путь к заведомо локальному файлу?

Используй FILE из c/cpp — это ж обычно отладочные вещи какие-нить для целевого кода.

А в h-файлы оно может быть вставленно преднамеренно для отладки чуть другого — конфигурации билда.

Здравствуйте, Teolog, Вы писали:

T>Отсутсвие жесткой записи абсолютных путей достигаеться сломанной компиляцией нескольких файлов с одинаковыми именами в разных папках.

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

Здравствуйте, vdimas, Вы писали:

V>можно описаться в имени включаемого файла и попасть на "неизвестно где".

И при этом все продолжит успешно компилироваться и хотя бы более-менее работать? Сможете найти реальный пример, в котором такое может получиться случайно?

V>Используй FILE из c/cpp

И куда мне его засунуть?

V>это ж обычно отладочные вещи какие-нить для целевого кода.

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>MS в документации брешет, что макрос __FILE__ раскрывается в полный путь только при указании ключа /FC.
По ссылке не так написано. /FC — полный путь, отсутствие /FC — нет гарантий полного пути.

ЕМ>На деле же все компиляторы от 15.00 до 19.29 (совсем последних у меня нет) при отсутствии /FC кладут без путей только имена файлов .c/.cpp. Если __FILE__ встречается в заголовке, то для файлов, включенных #include "file.h", всегда кладутся полные пути, а для включенных #include <file.h> — относительные.
Вы проверяли это в системе с одним логическим диском?

ЕМ>По логике, если уж класть полный путь, невзирая на отсутствие /FC, то надо бы наоборот — только для "внешних" файлов, включаемых #include <>. Для "собственных", включаемых #include "", следовало бы класть только имя (или то, что указано в кавычках).
По логике компилятор не должен преобразовывать одни пути в другие, если его об этом не просят, а то будет как с gcc под виндой

Автор: B0FEE664
Дата: 08.09.21

.

ЕМ>Такое поведение тянет на баг, или ему есть более разумное объяснение?
Я бы сказал, что пути могут строится относительно того каталога, который является текущим для компилятора в момент запуска, а как там оно на самом деле —

Здравствуйте, Евгений Музыченко, Вы писали:

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


В чем проблема при выводе в лог обрезать имена сорцов как тебе нравится?

ЕМ>Я не понял, где тут причина, а где следствие. Но, чтоб не ломалось, неплохо бы иметь возможность адекватно управлять формированием этих путей. А то оно вроде как управляется, а на деле все равно ведет себя, как ему вздумается.
Должны писаться абсолютные иначе неоднозначность, и нужен доступ к логике поиска файлов по относительным путям, но кто-то вбил костыль вокруг которого начались танцы.
Логику в отношении C++ компиляторов применять не следует, работает и слава Ктулху. Не надо ничего менять и перенастраивать — оно и так с трудом ворочается.
Язык старый и состоит из костылей и частных случаев, а какие там пути пишутся- это исключительно отладчика проблема, и пусть они с компилятором сами разгребаются.

Здравствуйте, Teolog, Вы писали:

T>Должны писаться абсолютные

По-хорошему, это должно адекватно управляться.

T>какие там пути пишутся- это исключительно отладчика проблема

К отладчику это не имеет ни малейшего отношения.

Здравствуйте, CreatorCray, Вы писали:

CC>Он хочет не светить свои

Если что, я лишь несколько лет назад открыл для себя /pdbaltpath, а до этого бинарники много лет выпускались с полным путем к PDB. А сейчас просто сколходил себе набор средств для удобной регистрации ошибок и передачи их на верхние уровни, и теперь в бинарниках стало слишком много имен файлов с полными путями.

Здравствуйте, Евгений Музыченко, Вы писали:

V>>можно описаться в имени включаемого файла и попасть на "неизвестно где".
ЕМ>И при этом все продолжит успешно компилироваться и хотя бы более-менее работать?

Сэкономит время при удивлении, что там не компиллируется.


ЕМ>Сможете найти реальный пример, в котором такое может получиться случайно?

Вообще, несколько раз бывало, когда классы внутренних библиотек совпадают по именам (но в разных неймспейсах) с публичными классами, которыми пользуются клиенты либы.
Причём, еще и названия методов порой чуть ли не 1-в-1. ))


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

У нас для этого в h-файлах описаны макросы, которые используются в cpp-файлах.

Это достаточно общеупотребимая техника, используется примерно так:

namespace SomeNamespace {

struct SourceInfo {
    const char * fileName;
    const char * funcName;
    const char * fileLine; // угу, номер строки хранится как текст, а не как число

    SourceInfo() {}

    SourceInfo(const char * file, const char * line, const char * func)
        : fileName(file)
        , funcName(func)
        , fileLine(line) {}

    bool hasData() const {
        return !funcName.empty() || !fileName.empty();
    }

    bool empty() const {
        return !hasData();
    }
};

}
...

#define FULL_SOURCE_INFO \
    ::SomeNamespace::SourceInfo(__FILE__, BOOST_STRINGIZE(__LINE__), BOOST_CURRENT_FUNCTION)

#define SOURCE_FUNC \
    ::SomeNamespace::SourceInfo(nullptr, nullptr, BOOST_CURRENT_FUNCTION)

#define SOURCE_LINE \
    ::SomeNamespace::SourceInfo(__FILE__, BOOST_STRINGIZE(__LINE__), nullptr)

#if (defined(CFG_TRACE) || defined(CFG_DEBUG))
# ifdef CFG_DEBUG
#   define SOURCE_INFO FULL_SOURCE_INFO
# else
#   define SOURCE_INFO SOURCE_FUNC
# endif
#else
# define SOURCE_INFO \
    (::SomeNamespace::SourceInfo())
#endif

Ну и, операторы вывода << этого SourceInfo для std::ostream и своих легковесных форматтеров.

Насколько я понимаю, у тебя некие есть операции, в которых может происходить логгирование, и они описаны в h-файлах.
У нас такое встречается редко, там просто добавляется аргумент SourceInfo по константной ссылке, а в месте вызова из cpp юзается макро SOURCE_INFO.

Здравствуйте, Евгений Музыченко

Вы не хотите светить полные пути в бинарнике, так?

Идея вот в чём. Пишем consteval функцию, которая возвращает std::array
В функции мы от std::string_view{__FILE__} откусываем начальные пути из указанного перечня
И копируем остаток в результирующий std::array

Я проверил бинарник на содержание путей. Тема рабочая для vs community 2022 (и clang 16, судя по asm-у в готболте)

Чек: https://godbolt.org/z/8bWvqPM1v

upd: нулевой терминатор тут не копируется, тк массив уже с zero initialization

#include <iostream>
#include <string_view>
#include <array>
#include <algorithm>

using namespace std::literals::string_view_literals;

using omg = std::array<char, 100>; // или сколько надо

consteval omg
so_path(std::string_view path)
{
  std::array cut{
    "/app"sv,
    "/omg"sv
  };
  for( std::string_view it : cut )
  {
    if( path.starts_with(it) )
    {
      path.remove_prefix( it.size() );
      break;
    }
  }
  omg ret{};
  std::ranges::copy( path, ret.begin() );
  return ret;
}

constexpr omg
g_path = so_path(__FILE__);

int main()
{
  std::cout << g_path.data() << '\n';
  return 0;
}

Из минусов:
* приходится указывать в функции что откусываем, но это не идёт в бинарник
* массив фиксированной длинны

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>для файлов, включенных #include "file.h", всегда кладутся полные пути, а для включенных #include <file.h> — относительные.

Всю жизнь знал именно так, и удивился бы, если бы было не так. Может, авторы документации неправильно поняли?

Здравствуйте, Sm0ke, Вы писали:

S>Пишем consteval функцию, которая возвращает std::array

Да, идея рабочая, но я по ряду причин пока не хочу использовать возможности за пределами C++11. Ну а то, что для исправления древней кривизны годится только такой навороченный костыль — это ж гребаный стыд, забивание гвоздей микроскопом... ((