When Can You Omit the File Extension in an #Include Directive

When can you omit the file extension in an #include directive?

The C++ standard headers do not have a ".h" suffix. I believe the reason is that there were many, different pre-standard implementations that the standard would break. So instead of requiring that vendors change their exiting "iostream.h" (for example) header to be standards compliant (which would break their existing user's code), the standards committee decided that they'd drop the suffix (which, I believe no then existing implementation had already done).

That way, existing, non-standard programs would continue to work using the vendor's non-standard libraries. When the user wanted to make their programs standards compliant, one of the steps they would take is to change the "#include" directive to drop the ".h" suffix.

#include <iostream>     // include the standard library version
#include <iostream.h>   // include a vendor specific version (which by 
                        //      now might well be the same)

As other answers have mentioned, writers of non-standard libraries may choose either naming convention, but I'd think they would want to continue using ".h" or ".hpp" (as Boost has done) for a couple reasons:

if & when the library gets standardized, the standard version won't automatically override the previous, non-standard one (causing broken user code in all likelihood)
it seems to be a convention (more or less) that headers without a suffix are standard libraries, and those with a suffix (other than the old C headers) are non-standard.

Note that a similar problem happened when the committee went to add hash maps to the STL - they found that there are already many (different) hash_map implementations that exist, so instead of coming up with a standard one that breaks a lot of stuff out there today, they are calling the standard implementation "unordered_map". Namespaces were supposed to help prevent this type of jumping through hoops, but it didn't seem to work well enough (or be used well enough) to allow them to use the more natural name without breaking a lot of code.

Note that for the 'C' headers, C++ allows you to include either a <cxxxxxx> or <xxxxxx.h> variant. The one that starts with 'c' and has no ".h" suffix put their declarations in the std namespace (and possibly the global namespace), the ones with the ".h" suffix put the names in the global namespace (some compilers also put the names in the std namespace - it's unclear to me if that's standard compliant, though I don't see the harm).

Correct format of #include directive

To answer your question: no, the space cannot cause an issue. It is perfectly legal to have whitespace (spaces and tabs) between the # introducing a preprocessing directive and the directive's name. VS2005 is sufficiently modern to honour that.

However, what is very strange is that you're apparently including a source file (.cpp) and not just a header file. While technically there's nothing wrong with that, it's quite likely that is not what you really want to do. You didn't specify what errors you're getting, but double definition errors would be a typical class of error caused by including a source file (and compiling it separately as well).

C++ header files with no extension

It seems you are talking about this repository of C++ code.

It looks like the authors of that code decided to follow the patterns of the C++ standard library. In standard C++, library headers are not supposed to have the .h extension. So the following is correct:

#include <iostream>

With most implementations writing <iostream.h> would also work, but the version without an extension is actually correct. The C++ standard library was able to drop extensions in C++98 due to the introduction of namespaces, and introduction of the std namespace for the standard library.

The C++ standard neither requires nor forbids an extension for other headers, so it's entirely up to the authors of some software what file extension to use, if any. The most common choices are to use .h or .hpp, the latter being intended to distinguish C++ headers from C headers.

A quick look at the OpenSceneGraph code shows that they've followed the C++ standard library pattern in their includes. There are no extensions, and everything is in the osg namespace, analogous to the std namespace of the standard library. So using the OpenSceneGraph libraries is very similar to using the C++ standard library.

#include <osg/Camera> // Provides osg::Camera

It's the same pattern as:

#include <string> //Provides std::string

So I think it's safe to say that authors of the OSG wanted to follow the same pattern as in the C++ Standard Library. My personal opinion is that it's better to have a file extension, even if only to be able to search for header files.

why STL header files have no extension?

The #include directive doesn't discriminate file types (it's just a glorified copy-paste operation) - no automatic adding of .h is happening.
C++ standard header files are provided without the .h extension
Sometimes backward compatibility header files are provided by the vendor with the same name with the .h extension added

It all has to do with namespaces. The .h counterparts for C++ standard headers usually #includes the proper C++ standard header (without .h extension) and then issues a bunch of using (something like this):

FILE: iostream.h

#include <iostream>

using std::iostream;
using std::ostream;
using std::ios;
...

whereas the headerfile without the .h extension does not pollute the namespace with all the defined classes and types.

C++ #include [filename] but #include string is not a filename

string is not a valid filename

It is. The name of the header file is literally string. Search your include paths, e. g.:

find /usr/include /usr/local/include -name "string"

and you will have some results.

Python Sphinx include directive: ignore the header from included file

On the Sphinx documentation Directives page there are no details for .. include:: directive, but there is a link to Including an External Document Fragment.

Found that there are some options for .. include:: directive

The following options are recognized:
start-line : integer 
Only the content starting from this line will be
included. (As usual in Python, the first line has index 0 and negative
values count from the end.)
end-line : integer 
Only the content up to
(but excluding) this line will be included.
start-after : text to find in the external data file
Only the content after the first occurrence of the specified text will be included.
end-before : text to find in the external data file
Only the content before the first occurrence of
the specified text (but after any after text) will be included.
literal : flag (empty) 
The entire included text is inserted into the
document as a single literal block.
code : formal language (optional)
The argument and the content of the included file are passed to the
code directive (useful for program listings). (New in Docutils 0.9)
number-lines : [start line number] 
Precede every code line with a line
number. The optional argument is the number of the first line (defaut
1). Works only with code or literal. (New in Docutils 0.9)
encoding : name of text encoding 
The text encoding of the external data file.
Defaults to the document's input_encoding.
tab-width : integer 
Number of spaces for hard tab expansion. A negative value prevents expansion
of hard tabs. Defaults to the tab_width configuration setting.

With code or literal the common options :class: and :name: are recognized
as well.

Combining start/end-line and start-after/end-before is possible. The
text markers will be searched in the specified lines (further limiting
the included content).

but no examples how to use this syntax.

Looking at neighbour raw directive tried and now it works!

This code includes the part.rst from the 5th line (after my heading)

.. include::  part.rst
    :start-line: 5

or if modify part.rst addind a special label

Header level 2
----------------
.. include_after_this_label

My text to be included

I could use the same label in multiple files to include the file flexible

.. include::  part.rst
    :start-after: .. include_after_this_label

Removing .h extension in user defined c++ header file

Can we remove .h extensions while we define our own header file in c++?

Sure, as long as that matches the filename of the file. As far as the language is concerned, the name of the file is largely irrelevant.

However, .h or similar such as .hpp is conventional, and helps the reader of the source to understand what the file is used for. This is an important consideration.

Another consideration is that some tools use the filename as a heuristic to determine the purpose of the file. For example, your IDE might not assume that the file contains C++ code, and thus not enable C++ features such as source analysis unless you follow a common naming convention.

I have created a header file and named it add.h and tried it including in source file using #include "add" but it didn't work.i know i am missing some important concepts here.

What you're missing is that the include directive must match the name of the file. If you include "add", then you must name the file add, not add.h. If you name a file add.h, then you must include "add.h", not "add".

Is there any difference between the directive #include from C and the one from C++?

Yes, there are at least two differences. In C++ (WG21 N4567 [cpp.include]/5):

The implementation shall provide unique mappings for sequences
consisting of one or more nondigits or digits (2.10) followed by a
period (.) and a single nondigit. The first character shall not be
a digit. The implementation may ignore distinctions of alphabetical
case.

In C (WG14 N1570 6.10.2/5, emphasis mine):

The implementation shall provide unique mappings for sequences
consisting of one or more nondigits or digits (6.4.2.1) followed by a
period (.) and a single nondigit. The first character shall not be a
digit. The implementation may ignore distinctions of alphabetical case
and restrict the mapping to eight significant characters before the
period.

A conforming C implementation can map "foobarbaz.h" and "foobarbat.h" to the same source file. A conforming C++ implementation cannot.

Additionally, in C (N1570 6.4.7):

If the characters ', \, ", //, or /* occur in the sequence
between the < and > delimiters, the behavior is undefined.
Similarly, if the characters ', \, //, or /* occur in the
sequence between the " delimiters, the behavior is undefined.

while in C++ (N4567 [lex.header]/2):

The appearance of either of the characters ' or \ or of either of
the character sequences /* or // in a q-char-sequence or an
h-char-sequence is conditionally-supported with implementation-defined semantics, as is the appearance of the
character " in an h-char-sequence.

"conditionally-supported with implementation-defined semantics" means that

if the implementation doesn't support it, it must issue a diagnostic;
if the implementation does support it, its interpretation of this construct must be documented.

while "undefined behavior" means that the implementation can do whatever it wants.

What's the difference between including files with JSP include directive, JSP include action and using JSP Tag Files?

Overview of JSP Syntax Elements

First, to make things more clear, here is a short overview of JSP syntax elements:

Directives: These convey information regarding the JSP page as a
whole.
Scripting elements: These are Java coding elements such as
declarations, expressions, scriptlets, and comments.
Objects and scopes: JSP objects can be created either explicitly or
implicitly and are accessible within a given scope, such as from
anywhere in the JSP page or the session.
Actions: These create objects or affect the output stream in the JSP
response (or both).

How content is included in JSP

There are several mechanisms for reusing content in a JSP file.

The following 4 mechanisms to include content in JSP can be categorized as direct reuse:

(for the first 3 mechanisms quoting from "Head First Servlets and JSP")

1) The include directive:
<%@ include file="header.html" %>
Static: adds the content from the value of the file attribute to the current page at translation time. The directive was
originally intended for static layout templates, like HTML headers.

2) The <jsp:include> standard action:
<jsp:include page="header.jsp" />
Dynamic: adds the content from the value of the page attribute to the current page at request time. Was intended more for dynamic
content coming from JSPs.
3) The <c:import> JSTL tag:
<c:import url=”http://www.example.com/foo/bar.html” />
Dynamic: adds the content from the value of the URL attribute to the current page, at request time. It works a lot like
<jsp:include>, but it’s more powerful and flexible: unlike the
other two includes, the <c:import> URL can be from outside the
web Container!
4) Preludes and codas:
Static: preludes and codas can be applied only to the beginnings and ends of pages.

You can implicitly include preludes (also called headers) and codas
(also called footers) for a group of JSP pages by adding
<include-prelude> and <include-coda> elements respectively within
a <jsp-property-group> element in the Web application web.xml deployment descriptor.
Read more here:

• Configuring Implicit Includes at the Beginning and End of JSPs

• Defining implicit includes

Tag File is an indirect method of content reuse, the way of encapsulating reusable content.
A Tag File is a source file that contains a fragment of JSP code that is reusable as a custom tag.

The PURPOSE of includes and Tag Files is different.

Tag file (a concept introduced with JSP 2.0) is one of the options for creating custom tags. It's a faster and easier way to build custom tags.
Custom tags, also known as tag extensions, are JSP elements that allow custom logic and output provided by other Java components to be inserted into JSP pages. The logic provided through a custom tag is implemented by a Java object known as a tag handler.

Some examples of tasks that can be performed by custom tags include operating on implicit objects, processing forms, accessing databases and other enterprise services such as email and directories, and implementing flow control.

Regarding your Edit

Maybe in your example (in your "Edit" paragraph), there is no difference between using direct include and a Tag File. But custom tags have a rich set of features. They can

Be customized by means of attributes passed from the calling page.
Pass variables back to the calling page.
Access all the objects available to JSP pages.
Communicate with each other. You can create and initialize a JavaBeans component, create a public EL variable that refers to that bean in one tag, and then use the bean in another tag.
Be nested within one another and communicate by means of private variables.

Also read this from "Pro JSP 2": Understanding JSP Custom Tags.

Useful reading.

Difference between include directive and include action in
JSP
JSP tricks to make templating
easier
Very informative and easy to understand tutorial from coreservlet.com with beautiful
explanations that include <jsp:include> VS. <%@ include %>
comparison table:

Including Files and Applets in JSP
Pages
Another nice tutorial from coreservlets.com related to tag libraries and
tag files:

Creating Custom JSP Tag Libraries: The
Basics
The official Java EE 5 Tutorial with examples:

Encapsulating Reusable Content
Using Tag
Files.
This page from the official Java EE 5 tutorial should give you even
more understanding:

Reusing Content in JSP
Pages.
This excerpt from the book "Pro JSP 2" also discuses why do you need
a Tag File instead of using static include:

Reusing Content with Tag
Files
Very useful guide right from the Oracle documentation:

Static Includes Versus Dynamic Includes

Conclusion

Use the right tools for each task.

Use Tag Files as a quick and easy way of creating custom tags that can help you encapsulate reusable content.

As for the including content in JSP (quote from here):

Use the include directive if the file changes rarely. It’s the fastest mechanism. If your container doesn’t automatically detect changes, you can force the changes to take effect by deleting the main page class file.
Use the include action only for content that changes often, and if which page to include cannot be decided until the main page is requested.

When Can You Omit the File Extension in an #Include Directive