MS в документации брешет, что макрос __FILE__ раскрывается в полный путь только при указании ключа /FC. На деле же все компиляторы от 15.00 до 19.29 (совсем последних у меня нет) при отсутствии /FC кладут без путей только имена файлов .c/.cpp. Если __FILE__ встречается в заголовке, то для файлов, включенных #include "file.h", всегда кладутся полные пути, а для включенных #include <file.h> — относительные.
По логике, если уж класть полный путь, невзирая на отсутствие /FC, то надо бы наоборот — только для "внешних" файлов, включаемых #include <>. Для "собственных", включаемых #include "", следовало бы класть только имя (или то, что указано в кавычках).
Такое поведение тянет на баг, или ему есть более разумное объяснение?
Здравствуйте, 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>В первом вообще ноль вопросов.
В чем именно Вы видите логику писать в бинарник полный путь к заведомо локальному файлу?
ЕМ>Такое поведение тянет на баг, или ему есть более разумное объяснение?
Отсутсвие жесткой записи абсолютных путей достигаеться сломанной компиляцией нескольких файлов с одинаковыми именами в разных папках.
Ломать еще и заголовки по всем библиотекам — до такого даже майкрософт не дойдет, отловят топов и говядиной насильно накормят.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Еще раз, по буквам:
Или, логика другая
ЕМ>- Для .h-файлов, включенных директивами #include "xxx.h" (так традиционно включаются "свои", локальные файлы), в объектный файл всегда кладется полный путь.
Так включаются все файлы, которые не являются файлами стандартной библиотеки языка, и ищутся в путях /I. Куда они указывают — хз, поэтому кладём полный путь
ЕМ>- Для .h-файлов, включенных директивами #include <xxx.h> (так традиционно включаются "чужие", библиотечные файлы), в объектный файл всегда кладется путь относительно его каталога, указанного в /I.
Так включаются только стандартные хидеры, соответственно, путь к ним фиксированный (лежат где-то рядом с компилятором)
ЕМ>Если второе еще можно считать логичным, то где логика в первом?
Вообще говоря, подключение инклюдов по <> компилятором может делаться как угодно, этих файлов вполне может не быть физически на диске. Это по стандарту так. Поэтому логика у компилятора по части пути в __FILE__ относительно стандарта вполне логичная.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Кто в здравом уме использует форму с кавычками для включения файлов, находящихся неизвестно где?
В здравом уме можно описаться в имени включаемого файла и попасть на "неизвестно где".
ЕМ>>>Если второе еще можно считать логичным, то где логика в первом? 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 под виндой
.
ЕМ>Такое поведение тянет на баг, или ему есть более разумное объяснение? Я бы сказал, что пути могут строится относительно того каталога, который является текущим для компилятора в момент запуска, а как там оно на самом деле —
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Ну да, я хочу, чтоб в бинарник складывались имена исходных файлов с номерами строк, в которых происходят различные операции, чтобы это можно было записывать в логи, но чтоб не демонстрировать миру структуру каталогов в моей рабочей системе.
В чем проблема при выводе в лог обрезать имена сорцов как тебе нравится?
Здравствуйте, пффф, Вы писали:
П>В чем проблема при выводе в лог обрезать имена сорцов как тебе нравится?
Он хочет не светить свои C:\Users\Пупсик\Сырки\Этот_козёл_постоянно_задерживает_оплату\MySampleProject\SpisokMudakoff.h в бинаре
ЕМ>Я не понял, где тут причина, а где следствие. Но, чтоб не ломалось, неплохо бы иметь возможность адекватно управлять формированием этих путей. А то оно вроде как управляется, а на деле все равно ведет себя, как ему вздумается.
Должны писаться абсолютные иначе неоднозначность, и нужен доступ к логике поиска файлов по относительным путям, но кто-то вбил костыль вокруг которого начались танцы.
Логику в отношении C++ компиляторов применять не следует, работает и слава Ктулху. Не надо ничего менять и перенастраивать — оно и так с трудом ворочается.
Язык старый и состоит из костылей и частных случаев, а какие там пути пишутся- это исключительно отладчика проблема, и пусть они с компилятором сами разгребаются.
