Здравствуйте, igna, Вы писали:
I>Вот. То есть #include "./path/to/header.h" в той же мере "глупая конструкция" что и #include <./Dir/Header.h>. А то почитав твой первый ответ можно было подумать, будто в зависимости от использованных ограничителей точка с косой чертой в начале пути может иметь смысл или не иметь его. На самом деле они никогда не имеют смысла.
В специфических контекстах — могут иметь смысл: include_alias в MSVC:
#pragma include_alias("file.h", "path/file.h")
#include"file.h"// фактически - "path/file.h"#include"./file.h"// фактически - "file.h", требуется полное соответствие
Имхо, глупая конструкция. В угловых скобках указываются файлы, которые компилятор ищет в "системных" каталогах (заданных через -I), а здесь путь относительный
CEG>Посему вопрос: нужен ли и для чего этот "./" в именах заголовочных файлов?
Относительные пути иногда бывают нужны для разрешения неоднозначности (в случае коллизии имён файлов или путей), но они указываются через кавычки (#include "./path/to/header.h")
В общем, пишут либо #include <Dir/Header.h> (путь относительно одного из каталогов, заданных через -I) либо #include "Dir/Header.h" (зависит от контекста, обычно это путь относительно текущего каталога).
Здравствуйте, byleas, Вы писали:
B>Ничем. Я имел ввиду относительные вообще (ведь есть и "../").
Вот. То есть #include "./path/to/header.h" в той же мере "глупая конструкция" что и #include <./Dir/Header.h>. А то почитав твой первый ответ можно было подумать, будто в зависимости от использованных ограничителей точка с косой чертой в начале пути может иметь смысл или не иметь его. На самом деле они никогда не имеют смысла.
Столкнулся с тем, что среда MSVC 2008 не хочет открыть файл Header.h через контекстное меню Open Document <./Dir/Header.h>.
Пути к директориям, где лежат header-ы, прописаны, указанный файл там есть, программа успешно компилится.
А при попытке открыть этот файл, говорит, что не может найти его. Лечится это удалением префикса "./". Но как-то не хочется менять исходный код ради прихотей среды разработки.
Посему вопрос: нужен ли и для чего этот "./" в именах заголовочных файлов?
CEG>Посему вопрос: нужен ли и для чего этот "./" в именах заголовочных файлов?
По-моему оно ни на что не влияет.
Re: Для чего нужно "./" в #include?
От:
Аноним
Дата:
17.08.09 15:49
Оценка:
CEG>Посему вопрос: нужен ли и для чего этот "./" в именах заголовочных файлов?
Для того чтобы указывать что путь начинается от текущей директории, а не от корня FS на юниксах.
В винде скорее всего пофиг.
Здравствуйте, ChainEG, Вы писали:
CEG>Посему вопрос: нужен ли и для чего этот "./" в именах заголовочных файлов? Здесь
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[3]: Для чего нужно "./" в #include?
От:
Аноним
Дата:
17.08.09 22:54
Оценка:
А>>Для того чтобы указывать что путь начинается от текущей директории, а не от корня FS на юниксах. I>А что, #include <Dir/Header.h> "на юниксах" означает то же, что #include </Dir/Header.h>
хз, что сделает #include <Dir/Header.h>, но команд-лайн шелл не исполняет файл который находится в подкаталоге относительно текущего если в начале не указать .
Re[2]: Для чего нужно "./" в #include?
От:
Аноним
Дата:
17.08.09 23:00
Оценка:
CEG>>Посему вопрос: нужен ли и для чего этот "./" в именах заголовочных файлов? V>Здесь
Вопрос был не о кавычках/уголках, а о точке
Здравствуйте, Аноним, Вы писали:
А>хз, что сделает #include <Dir/Header.h>, но команд-лайн шелл не исполняет файл который находится в подкаталоге относительно текущего если в начале не указать .
Верно, он будет искать только файлы, путь к которым указан в переменной PATH. В некотором смысле аналогом двум возможностям задавать имя команды, с "./" в начале и без, является угловые скобки и кавычки в #include. А "./" в начале пути #include избыточен независимо от того, какие ограничители используются.
Re[3]: Для чего нужно "./" в #include?
От:
Аноним
Дата:
18.08.09 06:59
Оценка:
Здравствуйте, igna, Вы писали:
I>Здравствуйте, Аноним, Вы писали:
А>>Для того чтобы указывать что путь начинается от текущей директории, а не от корня FS на юниксах.
I>А что, #include <Dir/Header.h> "на юниксах" означает то же, что #include </Dir/Header.h>
Нет.
Первое пляшет от текущего каталога, второе от корня ФС == "/".
А #include, в линунксе, пляшет от /usr/include. Например вот равноценные записи:
Здравствуйте, byleas, Вы писали:
B>Относительные пути иногда бывают нужны для разрешения неоднозначности (в случае коллизии имён файлов или путей), но они указываются через кавычки (#include "./path/to/header.h")
Да? А чем #include "./path/to/header.h" отличается от #include "path/to/header.h"?
Здравствуйте, igna, Вы писали:
I>Здравствуйте, byleas, Вы писали:
B>>Относительные пути иногда бывают нужны для разрешения неоднозначности (в случае коллизии имён файлов или путей), но они указываются через кавычки (#include "./path/to/header.h") I>Да? А чем #include "./path/to/header.h" отличается от #include "path/to/header.h"?
Ничем. Я имел ввиду относительные вообще (ведь есть и "../"). А вообще, это implementation-defined.
А его конструкция вообще работать не обязана.
Т.к. он открывает файл относительно текущего каталога, а что им в этот момент
будет для процесса-компилятора вообще непонятно.
Здравствуйте, Аноним, Вы писали:
А> команд-лайн шелл не исполняет файл который находится в подкаталоге относительно текущего если в начале не указать .
Не болтайте ерундой.
Re[5]: Для чего нужно "./" в #include?
От:
Аноним
Дата:
18.08.09 11:58
Оценка:
А>> команд-лайн шелл не исполняет файл который находится в подкаталоге относительно текущего если в начале не указать . _>Не болтайте ерундой.
а вы попробуйте
Здравствуйте, Аноним, Вы писали:
А>>> команд-лайн шелл не исполняет файл который находится в подкаталоге относительно текущего если в начале не указать . _>>Не болтайте ерундой. А>а вы попробуйте
Я каженный божий день пробую по несколько раз. ЧЯДНТ?
Re[7]: Для чего нужно "./" в #include?
От:
Аноним
Дата:
18.08.09 13:00
Оценка:
А>>>> команд-лайн шелл не исполняет файл который находится в подкаталоге относительно текущего если в начале не указать . _>>>Не болтайте ерундой. А>>а вы попробуйте _>Я каженный божий день пробую по несколько раз. ЧЯДНТ?
и файлы/скрипты которые вы исполняете не прописаны в PATH?
если команда начинается не на ./ то файл ищется по PATH
если на / — то ето рут
если на ./ — файл ищется в текущем каталоге
Здравствуйте, igna, Вы писали:
I>Вот. То есть #include "./path/to/header.h" в той же мере "глупая конструкция" что и #include <./Dir/Header.h>.
Ну, я бы не сказал. В первом случае явное указание, новичкам поможет, а вреда не будет. Во втором я даже не знаю, что будет
Здравствуйте, Death_Mokar, Вы писали:
I>>А "./" нужен "для того чтобы указывать что путь начинается от текущей директории, а не от корня FS на юниксах"?
D_M>Да. В явном виде.
Неверно. Нужным в данном случае (напомню, что речь об инклюде) "./" не назовешь, он что есть, что его нет.
D_M>И это не фишка линукса. Так уж издревле пошло: "." — текущий каталог, ".." — родительский каталог...
Это фишка юникса. Не знаю уж, можно ли сказать, что это издревле.
Здравствуйте, igna, Вы писали:
I>Здравствуйте, Death_Mokar, Вы писали:
I>>>А "./" нужен "для того чтобы указывать что путь начинается от текущей директории, а не от корня FS на юниксах"?
D_M>>Да. В явном виде.
I>Неверно. Нужным в данном случае (напомню, что речь об инклюде) "./" не назовешь, он что есть, что его нет.
"нужен" <> "необходим", т.е. в данном контексте "нужен" == "используется для"
D_M>>И это не фишка линукса. Так уж издревле пошло: "." — текущий каталог, ".." — родительский каталог...
I>Это фишка юникса. Не знаю уж, можно ли сказать, что это издревле.
...ну, когда-то работая учителем информатики в школе, я учил детей этому под ДОС, уж не знаю считать ли это "издревлем"
Здравствуйте, Аноним, Вы писали:
А>>>>> команд-лайн шелл не исполняет файл который находится в подкаталоге относительно текущего если в начале не указать . _>>>>Не болтайте ерундой. А>>>а вы попробуйте _>>Я каженный божий день пробую по несколько раз. ЧЯДНТ? А>и файлы/скрипты которые вы исполняете не прописаны в PATH?
Не все.
А>если команда начинается не на ./ то файл ищется по PATH
Это не совсем так.
А>если на / — то ето рут
Не понял фразу. Вы можете выражаться яснее?
Если путь начинается с /, то это абсолютный путь, и искать ничего не надо.
А>если на ./ — файл ищется в текущем каталоге