Working directory pragma

This is a discussion on Working directory pragma within the C++ Programming forums, part of the General Programming Boards category; Hello, I would like to know if there is a pragma that can tell the working directory for the current ...

  1. #1
    Registered User mikahell's Avatar
    Join Date
    Jun 2006
    Posts
    114

    Working directory pragma

    Hello, I would like to know if there is a pragma that can tell the working directory for the current file. I know that there is a defined macro called "__FILE__", which returns the source's filename with path. But is it possible to get only the directory without the file's name?

    Ex: "C:\MyFolder\File.cpp" would return "C:\MyFolder"


    I know I can probably solve this using substrings with a String class, but in my case I have to use it for a #define.

    Thanks!

  2. #2
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,046
    I know that there is a defined macro called "__FILE__", which returns the source's filename with path.
    Not necessarily. On many compilers, yes, that is what it contains; but I'm pretty sure that the preprocessor can stick just the file name into there if it wants to, without the path.

    Why do you need to do this? You probably don't need it to reference other files: most of the time, you can get away with relative directory paths. For example:
    Code:
    #include "header.h"
    #include "./header.h"
    #include "../header.h"
    #include "test/header.h"
    #include "../othertest/header.h"
    #include "../../../this/and/that/header.h"
    
    std::ifstream file("header.h");
    std::ifstream file2("./header.h");
    std::ifstream file3("../../this/header.h");
    I know I can probably solve this using substrings with a String class, but in my case I have to use it for a #define.
    Why not just use something like this?
    Code:
    const char *get_folder_name() { /* ... */ }
    Is there a particular reason you need a #define?

    To answer your question, I don't know how to do this at compile-time -- but you can do it at runtime with something like this:
    Code:
    const char *get_folder_name() {
        static char fullpath[] = __FILE__, *p;
        if((p = strrchr(fullpath, '\\'))) *p = 0;
        return fullpath;
    }
    Or, to handle slashes and backslashes, you could make use of strpbrk(). (I think that's the one. Maybe it was strspn().)
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  3. #3
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    I have been programming professionally for over 20 years, and I have yet to find a need to know which directory the source file is in within my source code. In fact, I can't really think what purpose it would serve to know this.

    Can you enlighten me to what the use of this is?

    By the way, I'm pretty sure that there are various variables in Visual Studio that you can use in the Project Properties to create a compiler define (-Dsomename=$CurrentDir or some such).

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  4. #4
    Registered User mikahell's Avatar
    Join Date
    Jun 2006
    Posts
    114
    Sorry for not being enough clear, why I need to do this, is because in some header file I need to import a .lib file, but I figured out that MS-VS 2003 (maybe 2005 handle it differently!) can't just stick to the relative path of my header file.

    Let's say I have "C:\project" where my project file is located, with folder "C:\project\source" being a root directory for source files... Then, I also have a secondary directory for other source files, say "C:\project\source\other"...

    If I have a file: "C:\project\source\something.cpp" and in it I want to include some header file located in directory "other", I will be able to write only:
    Code:
    #include "other\\some_other_file.h"
    But my problem is that if I try to include a .lib file the same way, it won't work:
    Code:
    #pragma comment (lib, "other\\some_lib.lib")
    Instead, I have to write:
    Code:
    #pragma comment (lib, "C:\\project\\source\\other\\some_lib.lib")
    I just don't understand why "#pragma comment" paths don't work the same way as "#include" does, so I thought about using a macro to get to the same result:

    Code:
    #define MY_PATH "##__CURRENT_FILE_DIRECTORY__##other\\some_lib.lib"
    #pragma comment (lib, MY_PATH)
    So basically that's what I was trying to build... A macro command that would get me the relative path to that .lib file. I would like to stick to relative paths instead of absolute! ^^

    But if you know a better way to import lib files in code, I would like to know it because I can't import .lib files using "#include" I know I can possibly set this in the project's options, but I'd like to have it directly in a file, so I would never forget to change options when I start a new application with the same sources....

    Sorry for the long post!!

  5. #5
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,434
    > #include "other\\some_other_file.h"
    This will be relative to the directory of the current source file.

    > #pragma comment (lib, "other\\some_lib.lib")
    This is probably going to be relative to the project directory (I guess), that is where your project file is.

    I generally dislike the #pragma approach for specifying which libraries to link against as being inflexible and unportable, and now also for being ambiguous.

    IMO, it is far better to use the project settings to specify where your libraries are, and what the names of the libraries are. Then your source code can be nice and clean, and refer only to those things which matter to the compiler, and not the linker.

    The #pragma approach works well if you have a single massive source file which needs one or two libraries, and you don't want to go to the trouble of making a separate project.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  6. #6
    Registered User mikahell's Avatar
    Join Date
    Jun 2006
    Posts
    114
    Ok so I should stick on with project settings....

    Well thanks, I will do it that way and try not to forget!

  7. #7
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    By the way, the #line directive can set __FILE__ to any arbitrary string the programmer wants, so it's not exactly reliable.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. How to tell if a file or directory
    By swappo in forum C++ Programming
    Replies: 4
    Last Post: 07-07-2009, 10:57 AM
  2. Replies: 4
    Last Post: 01-13-2008, 01:14 AM
  3. Programming a PIC 16F84 microcontroller in C
    By Iahim in forum C Programming
    Replies: 1
    Last Post: 05-13-2004, 02:23 PM
  4. Working with directories...
    By C Seņor in forum C Programming
    Replies: 4
    Last Post: 04-20-2002, 11:45 AM
  5. Directory reading trouble
    By samGwilliam in forum Linux Programming
    Replies: 0
    Last Post: 03-10-2002, 08:43 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21