«

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 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

> #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"

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

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.

> 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

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.

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 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

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.