Можно ли сделать это средствами стандартной библиотеки и boost-а? (Хотелось
бы иметь кросплатформенность) Я смотрел в бусте namespace boost::filesystem.
там есть функция initial_path которая возвращает путь соответствующий
текущей директории. Мне это понятное дело не походит. Другой функции
возращающей то, что мне надо я не нашёл. Естественно в Windows я могу
получить путь с помощью GetModuleFileName, но желательна
кроссплатформенность

Здравствуйте, Аноним, Вы писали:

А>Можно ли сделать это средствами стандартной библиотеки и boost-а? (Хотелось бы иметь кросплатформенность)

Универсального решения нет. Помимо ОС с развитыми файловыми системами (такими, как MSDOS, Windows, *Nix) есть всякие встроенные, для которых этот вопрос вообще не стоит.

Поэтому я бы не стал вообще заморачиваться, а сделал функцию get_program_path(), реализованную для тех платформ, на которые собираюсь портировать программу.

Кстати говоря: а зачем вообще нужно узнавать путь к экзешнику? Чтобы вытащить из этого каталога конфиги и т.п., чтобы грузить плагины?
Может быть, более правильное решение — написать инсталлятор, прописывающий пути туда, куда это положено на данной платформе (в никсах — привязаться к каталогам /usr/bin и т.п., в виндоузе — записать пути в реестр).
И опять же, написать функции get_plugin_path(), get_conf_path()
Это будет более человечно с т.з. разделения прав: скажем, в c:\program files может писать только администратор, поэтому конфиги хранить там не стоит.

Здравствуйте, Аноним, Вы писали:

А>Можно ли сделать это средствами стандартной библиотеки и boost-а? (Хотелось
А>бы иметь кросплатформенность) Я смотрел в бусте namespace boost::filesystem.
А>там есть функция initial_path которая возвращает путь соответствующий
А>текущей директории. Мне это понятное дело не походит. Другой функции
А>возращающей то, что мне надо я не нашёл. Естественно в Windows я могу
А>получить путь с помощью GetModuleFileName, но желательна
А>кроссплатформенность

Чем значение, возвращаемое функцией GetModuleFileName, лучше чем argv[0]?

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

MX>Чем значение, возвращаемое функцией GetModuleFileName, лучше чем argv[0]?

Тем, что содержимое argv[0] может содержать всё, что угодно по желанию шелла.
Пример

int main(int argc, char* argv[])
{
  printf("path = %s\n", argv[0]);
}

запускаем

C:\Temp> test
path = C:\Temp\test.exe

C:\Temp> tEsT
path = C:\Temp\tEsT.exe

C:\Temp> call test
path = test

C:\Temp> call ..\temp\.\.\test
path = ..\temp\.\.\test

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

К>Здравствуйте, Аноним, Вы писали:

А>>Можно ли сделать это средствами стандартной библиотеки и boost-а? (Хотелось бы иметь кросплатформенность)

К>Универсального решения нет. Помимо ОС с развитыми файловыми системами (такими, как MSDOS, Windows, *Nix) есть всякие встроенные, для которых этот вопрос вообще не стоит.

К>Поэтому я бы не стал вообще заморачиваться, а сделал функцию get_program_path(), реализованную для тех платформ, на которые собираюсь портировать программу.

К>Кстати говоря: а зачем вообще нужно узнавать путь к экзешнику? Чтобы вытащить из этого каталога конфиги и т.п., чтобы грузить плагины?
К>Может быть, более правильное решение — написать инсталлятор, прописывающий пути туда, куда это положено на данной платформе (в никсах — привязаться к каталогам /usr/bin и т.п., в виндоузе — записать пути в реестр).
К>И опять же, написать функции get_plugin_path(), get_conf_path()
К>Это будет более человечно с т.з. разделения прав: скажем, в c:\program files может писать только администратор, поэтому конфиги хранить там не стоит.

Спасибо. Ну да, именно ради того что бы вытащить конфиги. Хотя я прочитал, понял что вы правы на 100% и действительно стоит делать так как вы сказали.

Здравствуйте, Аноним, Вы писали:

А>Можно ли сделать это средствами стандартной библиотеки и boost-а? (Хотелось
А>бы иметь кросплатформенность) Я смотрел в бусте namespace boost::filesystem.
А>там есть функция initial_path которая возвращает путь соответствующий
А>текущей директории. Мне это понятное дело не походит. Другой функции
А>возращающей то, что мне надо я не нашёл. Естественно в Windows я могу
А>получить путь с помощью GetModuleFileName, но желательна
А>кроссплатформенность


Имхо, кроссплатформенность придется реализовывать вам =) Условная компиляция и соответствующая литература в помощь

On Sun, 12 Mar 2006 11:23:31 +0300, NoFate <22574@users.rsdn.ru> wrote:

>
> Имхо, кроссплатформенность придется реализовывать вам =) Условная
> компиляция и соответствующая литература в помощь

Возможно на ваших системах реализована функция getcwd().

--
на этом прощаюсь, CTpaHHoe
mailto-besso-at-hotbox-dot-ru

>> Имхо, кроссплатформенность придется реализовывать вам =) Условная
>> компиляция и соответствующая литература в помощь

CTH>Возможно на ваших системах реализована функция getcwd().


Каталог, откуда запущена программа и возвращаемое getcwd — совершенно ортогональны.

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

К>Здравствуйте, -MyXa-, Вы писали:

MX>>Чем значение, возвращаемое функцией GetModuleFileName, лучше чем argv[0]?

К>Тем, что содержимое argv[0] может содержать всё, что угодно по желанию шелла.
К>Пример
К>

К>int main(int argc, char* argv[])
К>{
К>  printf("path = %s\n", argv[0]);
К>}
К>

К>запускаем
К>

К>C:\Temp> test
К>path = C:\Temp\test.exe

К>C:\Temp> tEsT
К>path = C:\Temp\tEsT.exe

К>C:\Temp> call test
К>path = test

К>C:\Temp> call ..\temp\.\.\test
К>path = ..\temp\.\.\test
К>

Ну просто афигеть.. а сами вы то проверяли?
вот..чего оно у меня вывело.. Запускаем под виндой cmd
и дальше наблюдаем

C:\>cd C:\Projects\BuilderCpp\Temp\00\00\

C:\Projects\BuilderCpp\Temp\00\00>Project1
path = C:\Projects\BuilderCpp\Temp\00\00\Project1.exe

C:\Projects\BuilderCpp\Temp\00\00>ProjEct1
path = C:\Projects\BuilderCpp\Temp\00\00\Project1.exe

C:\Projects\BuilderCpp\Temp\00\00>call Project1
path = C:\Projects\BuilderCpp\Temp\00\00\Project1.exe

C:\Projects\BuilderCpp\Temp\00\00>call ..\00\.\.\pRoJeCt1.EXE
path = C:\Projects\BuilderCpp\Temp\00\00\Project1.exe

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

Здравствуйте, <Аноним>, Вы писали:

А>Ну просто афигеть.. а сами вы то проверяли?

А то ж. Ещё как проверял. И вот прямо сейчас проверил. Выводил значения argv[0] и ::GetCommandLine().

А>вот..чего оно у меня вывело.. Запускаем под виндой cmd
А>и дальше наблюдаем

А>C:\>cd C:\Projects\BuilderCpp\Temp\00\00\

А>C:\Projects\BuilderCpp\Temp\00\00>Project1
А>path = C:\Projects\BuilderCpp\Temp\00\00\Project1.exe

А>C:\Projects\BuilderCpp\Temp\00\00>ProjEct1
А>path = C:\Projects\BuilderCpp\Temp\00\00\Project1.exe

А>C:\Projects\BuilderCpp\Temp\00\00>call Project1
А>path = C:\Projects\BuilderCpp\Temp\00\00\Project1.exe

А>C:\Projects\BuilderCpp\Temp\00\00>call ..\00\.\.\pRoJeCt1.EXE
А>path = C:\Projects\BuilderCpp\Temp\00\00\Project1.exe

А>...согласитесь правда странно... Одно и тоже мне выводит.. Может вы поделетесь мне настройками для cmd под винду.., ну чтобы хоть вотдалёности иметь тот эффект о котором вы тут распространяетесь ..

А может, это у тебя cmd кривой? Я на трёх машинах проверял под 2000 и XP, и всё работало так, как работало.

А>Спасибо заранее...

Да пожалуйста!
В конце концов — неважно, какие у тебя настройки виндов.
Факт остаётся фактом: в argv[0] попадает не путь к приложению, а то, что захочет туда поместить шелл. Если конкретно твой шелл кладёт туда всегда абсолютный путь — это не значит, что на соседней машине будет то же самое.

Хм! А ведь я знаю, в чём дело!!!
В том, что ты пользуешься Дебилдером. Борланд всегда славился закидонами, вот и сейчас они так реализовали рантайм, что вместо стандартных WinAPI-шных функций ::GetCommandLine(), ::CommandLineToArgv() собирают массив argv[] вручную — из ::GetModuleFileName(NULL) и lpCmdLine полученного в WinMain.
Кстати, нужно проверить, корректно ли они распарсивают lpCmdLine — на предмет кавычек.