Is Space Allowed in Filename?

Discussion in 'C++' started by Bryan Parkoff, Dec 7, 2005.

  1. I have seen that C/C++ Compiler supports long filename up to 254
    characters plus the extension. Can header files and source code files
    accept space between alphabet character and numeric character? Is it the
    best practice to use underscore instead of space? If so, please explain
    why.
    Would you prefer to avoid using two double quote marks in the long
    filename if space is there? Without it, it would be underspace.

    For example:

    #include "GameLoop.h" // Valid Filename so C/C++ Compiler accepts it.
    #include "Game_Loop.h" // Valid Filename so C/C++ Compiler accepts it.
    #include "Game Loop.h" // Can it be valid or invalid? It does work.

    What do you recommend which #include ... is best practice?

    Bryan Parkoff
    Bryan Parkoff, Dec 7, 2005
    #1
    1. Advertising

  2. Bryan Parkoff wrote:
    > I have seen that C/C++ Compiler supports long filename up to 254
    > characters plus the extension. Can header files and source code files
    > accept space between alphabet character and numeric character?


    Yes. The only characters prohibited are the newline and the double
    quote character.

    > Is it
    > the best practice to use underscore instead of space?


    No. There is no "best practice".

    > If so, please
    > explain why.
    > Would you prefer to avoid using two double quote marks in the long
    > filename if space is there?


    Huh?

    > Without it, it would be underspace.


    Huh?

    >
    > For example:
    >
    > #include "GameLoop.h" // Valid Filename so C/C++ Compiler accepts it.
    > #include "Game_Loop.h" // Valid Filename so C/C++ Compiler accepts it.
    > #include "Game Loop.h" // Can it be valid or invalid? It does work.


    Yes, it is valid. If your file is named "Game<space>Loop.h", where the
    <space> designates a single space character, then that's what you need to
    give your preprocessor.

    > What do you recommend which #include ... is best practice?


    Do whatever feels better.

    V
    Victor Bazarov, Dec 7, 2005
    #2
    1. Advertising

  3. Bryan Parkoff

    Sigmathaar Guest

    > #include "GameLoop.h" // Valid Filename so C/C++ Compiler accepts it.
    > #include "Game_Loop.h" // Valid Filename so C/C++ Compiler accepts it.
    > #include "Game Loop.h" // Can it be valid or invalid? It does work


    I recomend you to use the first one since most of the people are used
    to do so (at least in my country). You may also want to see what's used
    to be done in your work place (if it's work that you are doing) or see
    what's used to be done in open source projects.

    As Victor Bazarov told you there is not such a thing as a best practice
    but there are some writing conventions and you may chose to use them or
    not. In my case I would use :

    #include "gameLoop.h"
    Sigmathaar, Dec 7, 2005
    #3
  4. Victor Bazarov wrote:
    > Bryan Parkoff wrote:
    >
    > > Is it
    > > the best practice to use underscore instead of space?wrote

    >
    > No. There is no "best practice".
    >


    May be there isn't any but I'd recommend to use Unix names:
    all letters lower-case. This simplifies the usage and makes less
    confusions for programmers, especially working on multiplatform
    projects (Windows - case insensitive FS, Unix - case sensitive FS).
    Consider why SourceForge.net uses Unix names for all hosted projects.
    Second, what a rule would you define for files naming in order to make
    it easy to use and set it predictable?

    This is clear:
    #include "MyBrownCar.h"
    but what name will you give in case of single-word name:
    #include "utils.h"
    or
    #include "Utils.h"

    In this case, naming cohesion may be broken easily:
    #include "MyBrownCar.h"
    #include "utils.h"

    Now, when I go to Unix and I will use
    #include "Utils.h", by analogy to MyBrownCar.h then compiler won't find
    the file because its name is utils.h.

    All other variations like
    "My_Brown_Car.h"
    or
    "My Brown Car.h"
    will make the usage a real headache.

    If you say "all file names are lower case" there is no problem with all
    files on all platforms.

    Cheers
    --
    Mateusz Loskot
    http://mateusz.loskot.net
    Mateusz Loskot, Dec 7, 2005
    #4
  5. Bryan Parkoff

    Rolf Magnus Guest

    Victor Bazarov wrote:

    > Bryan Parkoff wrote:
    >> I have seen that C/C++ Compiler supports long filename up to 254
    >> characters plus the extension. Can header files and source code files
    >> accept space between alphabet character and numeric character?

    >
    > Yes. The only characters prohibited are the newline and the double
    > quote character.


    That's wrong. You can specify characters like space in an #include
    directive, but how the characters are mapped to actual file names is
    implementation-defined. IOW: Whether spaces in header file names are
    allowed depends on the implemenation and is usually determined by the
    operating system the compiler is running under and the file system the
    headers are stored in. Under MSDOS e.g., spaces in file names are not
    allowed, and all compilers that I have seen do a 1:1 mapping of the
    header-names specified in #include and the actual file names.
    Rolf Magnus, Dec 7, 2005
    #5
  6. Bryan Parkoff

    Guest

    > That's wrong. You can specify characters like space in an #include
    > directive, but how the characters are mapped to actual file names is
    > implementation-defined. IOW: Whether spaces in header file names are
    > allowed depends on the implemenation and is usually determined by the
    > operating system the compiler is running under and the file system the
    > headers are stored in. Under MSDOS e.g., spaces in file names are not
    > allowed, and all compilers that I have seen do a 1:1 mapping of the
    > header-names specified in #include and the actual file names.


    1: under DOS you can have spaces, but not two adjacent or at one at the

    beginning or the end of a name (not all programs agree, though)
    2: IBM's C++ compiler had some weird kind of non-file storage once?
    There
    is no reason, after all, for headers to be files.
    3: Nor do translation units have to be files - they don't even need
    preprocessor names!
    4: Most compilers that I know use something like /I flags to translate
    header
    file names into filesystem names. Not a straight 1:1 mapping,
    especially if
    a single name occurs in more than one directory.
    5: The system headers are even weirder, especially on Unix systems
    where
    some compiler vendors mix OS and C++ headers.

    HTH,
    Michiel Salters
    , Dec 7, 2005
    #6
  7. Bryan Parkoff wrote:
    ...
    >
    > What do you recommend which #include ... is best practice?
    >


    A ruleset I use (and now my company uses) is:

    a) all lower case (reduce issues with case sensitivity on different
    platforms).

    b) prefix with the namespace or project code (e.g. "at_" for Austria c++
    - at_lifetime.h).

    c) all header files are ".h" - not .hpp or no suffix like the STL.

    d) if the file being included is within the source tree then use '""'
    type includes and not "<>" type includes.

    So they look like:

    #include "##_@@@@@.h"

    where ## is a prefix for the subsystem that the header pertains to and
    @@@@@ is somthing descriptive.
    Gianni Mariani, Dec 7, 2005
    #7
  8. I forgot one rule.

    Gianni Mariani wrote:
    > Bryan Parkoff wrote:
    > ..
    >
    >>
    >> What do you recommend which #include ... is best practice?
    >>

    >
    > A ruleset I use (and now my company uses) is:
    >
    > a) all lower case (reduce issues with case sensitivity on different
    > platforms).
    >
    > b) prefix with the namespace or project code (e.g. "at_" for Austria c++
    > - at_lifetime.h).
    >
    > c) all header files are ".h" - not .hpp or no suffix like the STL.
    >
    > d) if the file being included is within the source tree then use '""'
    > type includes and not "<>" type includes.


    e) No spaces in the file name.

    This is because some of the build tools won't deal properly with files
    with spaces in them.

    >
    > So they look like:
    >
    > #include "##_@@@@@.h"
    >
    > where ## is a prefix for the subsystem that the header pertains to and
    > @@@@@ is somthing descriptive.
    Gianni Mariani, Dec 7, 2005
    #8
  9. Gianni Mariani wrote:
    >
    > b) prefix with the namespace or project code (e.g. "at_" for Austria c++
    > - at_lifetime.h).
    >


    Why not to put namespaces into separate directories -> packages?

    Cheers
    --
    Mateusz Loskot
    http://mateusz.loskot.net
    Mateusz Loskot, Dec 7, 2005
    #9
  10. Bryan Parkoff

    Rolf Magnus Guest

    wrote:

    >> That's wrong. You can specify characters like space in an #include
    >> directive, but how the characters are mapped to actual file names is
    >> implementation-defined. IOW: Whether spaces in header file names are
    >> allowed depends on the implemenation and is usually determined by the
    >> operating system the compiler is running under and the file system the
    >> headers are stored in. Under MSDOS e.g., spaces in file names are not
    >> allowed, and all compilers that I have seen do a 1:1 mapping of the
    >> header-names specified in #include and the actual file names.

    >
    > 1: under DOS you can have spaces, but not two adjacent or at one at the
    >
    > beginning or the end of a name (not all programs agree, though)


    There may be hacks that still make it possible, but Microsoft's FAT
    specification says that spaces are not allowed for short file names (which
    is what MSDOS uses).

    > 2: IBM's C++ compiler had some weird kind of non-file storage once?


    I have heard about that, but don't know any details.

    > There is no reason, after all, for headers to be files.


    Depends on what you mean by "files". From the C++ standard:

    ************************************************************************

    16.2 Source file inclusion

    1 A #include directive shall identify a header or source file that can be
    processed by the implementation.

    ************************************************************************

    So it clearly speaks of "files" in conjunction with headers, and not only in
    this place. However, it doesn't define how such a file is stored.

    > 3: Nor do translation units have to be files - they don't even need
    > preprocessor names!


    I don't exactly know what you mean by that.

    > 4: Most compilers that I know use something like /I flags to translate
    > header file names into filesystem names. Not a straight 1:1 mapping,
    > especially if a single name occurs in more than one directory.


    This search sequence is not the mapping that the C++ standard is talking
    about.

    Something more from section 16.2:

    ************************************************************************

    3 A preprocessing directive of the form

    # include "q-char-sequence" new-line

    causes the replacement of that directive by the entire contents of the
    source file identified by the specified sequence between the " delimiters.
    The named source file is searched for in an implementation-defined
    manner. If this search is not supported, or if the search fails, the
    directive is reprocessed as if it read

    # include <h-char-sequence> new-line

    with the identical contained sequence (including > characters, if any)
    from the original directive.

    ************************************************************************

    So those /I flags are what the C++ standard means by "searched for in an
    implementation-defined manner".

    > 5: The system headers are even weirder, especially on Unix systems
    > where some compiler vendors mix OS and C++ headers.


    I haven't seen anything unusual here. They are often using a lot of #defines
    and #ifdefs and #include other headers that in turn #include more headers,
    but nothing that uses something else than the 1:1 filename mapping.
    Rolf Magnus, Dec 7, 2005
    #10
  11. Rolf Magnus wrote:
    > Victor Bazarov wrote:
    >
    >> Bryan Parkoff wrote:
    >>> I have seen that C/C++ Compiler supports long filename up to 254
    >>> characters plus the extension. Can header files and source code
    >>> files accept space between alphabet character and numeric character?

    >>
    >> Yes. The only characters prohibited are the newline and the double
    >> quote character.

    >
    > That's wrong. [..]


    No, it's not. Read the relevant portion of the Standard.
    Victor Bazarov, Dec 8, 2005
    #11
  12. Bryan Parkoff

    Rolf Magnus Guest

    Victor Bazarov wrote:

    > Rolf Magnus wrote:
    >> Victor Bazarov wrote:
    >>
    >>> Bryan Parkoff wrote:
    >>>> I have seen that C/C++ Compiler supports long filename up to 254
    >>>> characters plus the extension. Can header files and source code
    >>>> files accept space between alphabet character and numeric character?
    >>>
    >>> Yes. The only characters prohibited are the newline and the double
    >>> quote character.

    >>
    >> That's wrong. [..]

    >
    > No, it's not. Read the relevant portion of the Standard.


    I did. That's what made me realize that you are wrong. Maybe you didn't read
    my posting?
    Rolf Magnus, Dec 8, 2005
    #12
  13. Rolf Magnus wrote:
    > Victor Bazarov wrote:
    >
    >> Rolf Magnus wrote:
    >>> Victor Bazarov wrote:
    >>>
    >>>> Bryan Parkoff wrote:
    >>>>> I have seen that C/C++ Compiler supports long filename up to
    >>>>> 254 characters plus the extension. Can header files and source
    >>>>> code files accept space between alphabet character and numeric
    >>>>> character?
    >>>>
    >>>> Yes. The only characters prohibited are the newline and the double
    >>>> quote character.
    >>>
    >>> That's wrong. [..]

    >>
    >> No, it's not. Read the relevant portion of the Standard.

    >
    > I did. That's what made me realize that you are wrong. Maybe you
    > didn't read my posting?


    And what in it did you give to prove your assertion? Between double
    quotes any character is allowed except a newline or a double quote.
    Between angle brackets any character is allowed except a newline or
    a closing angle bracket (a greater-than sign). What else is there
    to contradict my statement? Please, don't foget chapter and verse.

    V
    Victor Bazarov, Dec 8, 2005
    #13
  14. Bryan Parkoff

    Ron Natalie Guest

    Mateusz Loskot wrote:
    > Victor Bazarov wrote:
    >> Bryan Parkoff wrote:
    >>
    >>> Is it
    >>> the best practice to use underscore instead of space?wrote

    >> No. There is no "best practice".
    >>

    >
    > May be there isn't any but I'd recommend to use Unix names:
    > all letters lower-case.


    Huh? UNIX makes no such restrictions on names. UNIX names
    can have pretty much any character except for the nul and slash.
    Ron Natalie, Dec 8, 2005
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Shuo Xiang

    Stack space, global space, heap space

    Shuo Xiang, Jul 9, 2003, in forum: C Programming
    Replies:
    10
    Views:
    2,886
    Bryan Bullard
    Jul 11, 2003
  2. Christian Seberino
    Replies:
    21
    Views:
    1,651
    Stephen Horne
    Oct 27, 2003
  3. Ian Bicking
    Replies:
    2
    Views:
    1,009
    Steve Lamb
    Oct 23, 2003
  4. Ian Bicking
    Replies:
    2
    Views:
    721
    Michael Hudson
    Oct 24, 2003
  5. Iñaki Baz Castillo
    Replies:
    13
    Views:
    497
    Iñaki Baz Castillo
    May 1, 2011
Loading...

Share This Page