Having an issue with virtual....

[peter koch]

"Logically"?  What's illogical about giving your headers the '.h'
extension?  They are *h*eaders, aren't they?  In the beginning I
remember giving some code fragments extensions '.inc' (it may have been
ASM or some such) because they were *inc*luded.  Is that logical?

Well, in my opinion .h is not a logical choice if you want to be able
to see the difference between a C and a C++ header. While both
probably work, I find it nice that you, when you see an #include,
readily can differentiate between a C header and a C++ header. And
while you might not code in C, you will most probably include some C
headers, e.g. files from the standard C library, from Posix or some
third-party library.
I myself prefer cpp for source and hpp for headers, partly because
that's what I have always done and partly because it is the defacto
standard - look e.g. at boost. I have no strong feelings, however, as
long as its not the foolish Linux/Unix convention using .C for
sources. That convention is not portable to case-insensitive file-
systems.

/Peter

 

[Juha Nieminen]

"Logically"? What's illogical about giving your headers the '.h'
extension? They are *h*eaders, aren't they?

That's exactly as silly as arguing that PDF files should have the
extension '.txt' because they contain, after all, text.

The extension should *disambiguate* the file type, and '.h' does not
disambiguate if it's used for headers of different languages.

 

[Victor Bazarov]

That's exactly as silly as arguing that PDF files should have the
extension '.txt' because they contain, after all, text.

The extension should *disambiguate* the file type, and '.h' does not
disambiguate if it's used for headers of different languages.

*IF*

On my system those files are used for two languages: C++ and C++/CLI
(not that I myself use it, just part of the project). Suits *me*.
Suits the OP, or so it seems. Nothing illogical *here* (or *there*).
If you need it differently, fine. James was the one who picked on the
extension. I don't understand the need to defend or attack any side of
this "debate" any longer, though.

V

 

[James Kanze]

And the alternative is what? Not associating them at all,
which gives *no* syntax coloring, right?

My editor syntax hilights .h files as C, .hh and .hpp files as
C++.

And the problem exists only if you have a definition of a "C
file".

It comes with the editor; by default. It's not difficult to
change it so that .h will also syntax hilight as C++, but that
means that I get the wrong hilighting for C headers.

I don't develop in C, I couldn't care less about that.

What system to you develop on? All of the Posix headers are C,
and so are all of the Windows headers I've seen.

So, my system does not have them associated as "C" files, they
are "C++" files here.

OK. If you're 100% sure that you'll never have to work on a
system which supports C (no Unix, no Windows, probably no
VMX...), maybe. That's not most people's situation.

 

[James Kanze]

* James Kanze:
I have not experienced this problem.

+1

Since I don't work in C, and the [integrated] editor I use
colors all keywords the same C++ way (even the language
extensions), I don't really care. Besides, if I ever needed
to code in C, why would I use a C++ keyword? Just because I
can? And how? As a variable name? <shrug>

Solution: Just tell your tool that .h is a C++ source (just
like .C or .cc) and everything's gonna be easier, I think.

How is that easier than using a different extension? C and C++
are different langauges---it only makes sense to use different
extensions for their headers.

 

[James Kanze]

On 13 Aug., 19:38, Victor Bazarov <[email protected]> wrote:

I myself prefer cpp for source and hpp for headers, partly
because that's what I have always done and partly because it
is the defacto standard - look e.g. at boost.

The de facto standard depends a bit on the environment; I think
..cc and .hh are more common than .cpp and .hpp in Unix
environments.

Globally, however, you're probably right. My library uses .cc
and .hh because it was originally developed under Unix, but if I
had it to do again, I'd use .cpp and .hpp.

I have no strong feelings, however, as long as its not the
foolish Linux/Unix convention using .C for sources.

That was the original convention, back when all of the existing
C++ compilers (all one of them) only ran under Unix. Many of
the Unix at the time limited filename length to 14 characters,
so there was some argument to keeping the extension as short as
possible.

That convention is not portable to case-insensitive file-
systems.

Which is why it died, at least 15 years ago.

I seem to recall an early C++ compiler (for MS-DOS) which used
..cxx and .hxx as well.

 

[James Kanze]

Boost went for .hpp, but most (if not all?) pre-standard
compilers used .h for library headers (remember
<iostream.h>?).

Under Unix. I don't know why, but the original Unix convention
was .C/.h. The early C++ implementations under MS-DOS used
..cpp/.hpp. Today, the most widespread convention I've seen
under Unix seems to be .cc/.hh, and Windows seems 100%
..cpp/.hpp. But some Unix shops do seem stuck in .h, even when
they've migrated to .cc for the source files.

There's no real universal convention, and it really doesn't
matter which one you choose, as long as it distinguishes between
C and C++ headers.

 

[Ian Collins]

My editor syntax hilights .h files as C, .hh and .hpp files as
C++.


It comes with the editor; by default. It's not difficult to
change it so that .h will also syntax hilight as C++, but that
means that I get the wrong hilighting for C headers.

What's unique to C headers that makes this a problem?

 

[Ian Collins]

I have no strong feelings, however, as
long as its not the foolish Linux/Unix convention using .C for
sources. That convention is not portable to case-insensitive file-
systems.

case-insensitive filesystems? How quaint!

 

[Juha Nieminen]

This distinction seems rather artificial, in that it's an artifact of
one particular type of tool (text editors) that sometimes can't deal
with this difference. Smarter editors keep per-file settings information
so that even if the default doesn't match what you want, once you change
it for a particular file, you get what you want.

There is a practical difference: If the naming is logical, then you
know that you can use a .h file in a C program if you need to write one,
and you know that a .hh/.hpp file won't work.

 

[Bo Persson]

My editor syntax hilights .h files as C, .hh and .hpp files as
C++.


It comes with the editor; by default. It's not difficult to
change it so that .h will also syntax hilight as C++, but that
means that I get the wrong hilighting for C headers.


What system to you develop on? All of the Posix headers are C,
and so are all of the Windows headers I've seen.

But the Windows headers

#include "windows.h"

definitely also compile as C++, so obviously they don't contain any
C++ reserved words used as other names. So the hilighting will work
either way.

Also, the MFC framework - containing lots of C++ classes - all come in
..h files. I don't want that hilighted as C code.


Bo Persson

 

[James Kanze]

James Kanze wrote:

So suppose I'm writing a project that's entirely in C++, but
some of the headers can be compiled as C. Do I have to name
them so that it's clear that they're C headers? Or do I name
them in accordance with the conventions of the project that
they're a part of, namely, C++?

It depends. Are they C++ headers, or headers designed to be
used for both languages? In other words, what is the contract
they are intended to fulfill?

This distinction seems rather artificial, in that it's an
artifact of one particular type of tool (text editors) that
sometimes can't deal with this difference.

No. The distinction is fundamental. If the header has the
suffix .h, then I don't have a right to put anything in it which
would not compile in C. If it has another suffix, I do.

 

[Ron]

No.  The distinction is fundamental.  If the header has the
suffix .h, then I don't have a right to put anything in it which
would not compile in C.  If it has another suffix, I do.

--

I do nearly 100% C++. I've never found it necessary to distinguish
the file name between C and C++ and universally use .h for both.
There's
so much more to the header than just knowing what language it was
written
for to be useful, it's not clear why it much matters.

 

[Juha Nieminen]

I do nearly 100% C++. I've never found it necessary to distinguish
the file name between C and C++ and universally use .h for both.
There's
so much more to the header than just knowing what language it was
written
for to be useful, it's not clear why it much matters.

Do you name your C++ source files with the ".c" extension? If not, why
not? If all you do is C++, what would be the difference? And why can't
your answer be applied to the header files as well?

 

[James Kanze]

Because the compiler cares what the extension is.

Not really. All of the compilers I know will comile .c files as
C++, given the right options. One of them (g++) even does so by
default. And I've always used .cc for source files (for
historical reasons)---for a long time, I had to use a special
option (/Tp) for VC++ to compile them as C++.

When it comes down to it, the extensions are largely chosen for
historical reasons. And using .h for a header file certainly
isn't a killer---I've worked in places where that was the
standard, and I've never felt it an important enough problem to
push for a change. But there are contexts where using something
else, and making the distinction, has a definite advantage, and
it's better that a beginner get into the habit of making the
distinction. Since it seems that I was responding to a relative
beginner, I thought I'd raise the issue. For him, not for
experienced programmers, who are almost all working in a context
where they don't have a choice anyway.

 

[Juha Nieminen]

Because the compiler cares what the extension is.

And if a text editor cares what the extension of the header file is,
exactly why is that a different thing?

If all you do is C++, what would be the difference? And why can't

Because you don't pass header files directly to the compiler.

But you edit them with text editors, which might support things like
code coloring, indentation and such.

 

[Juha Nieminen]

There's a fair amount of mental overhead involved when you use the
command line to specify what language to use for each file that's being
compiled. I'd rather not deal with that.

There's also a fair amount of mental overhead involved in telling an
editor which language it should interpret a file to be written in.
What's the difference?

 

[Juha Nieminen]

Not just might. I do. And it's simple (i.e. two mouse clicks or two
keystrokes) to change the language if the editor gets it wrong. And
after that it gets it right.

I find it ironic and contradictory that you argue for both the
necessity of disambiguating source code files and the non-necessity of
it, both at the same time.

 

[Alf P. Steinbach]

* Juha Nieminen:

I find it ironic and contradictory that you argue for both the
necessity of disambiguating source code files and the non-necessity of
it, both at the same time.

The cost of treating .h headers as C++, if there is such a cost, is so low that
e.g. I, or Victor, have not even noticed any such cost at all. But the cost,
insignificant as it is, does not matter anyway because we derive a lot of
benefits from treating .h as C++. Especially considering the very large number
of libraries with C++ .h headers. Boost is a fairly unique exception.

The cost of treating .c files as C++ source code is on the other hand
significant, and with no benefit from treating them as C++ instead of C.

So Pete is talking about two different kinds of files, namely files to compile,
and headers, and there is no self-contradiction and no irony.


Cheers & hth.,

- Alf

 

[James Kanze]

Yes, really.

All of the compilers I know will compile .c files as

There's a fair amount of mental overhead involved when you use
the command line to specify what language to use for each file
that's being compiled. I'd rather not deal with that.

The command is always:
make project
There's usually a lot of mental overhead involved in defining
how to compile a file in the makefile---no compiler I've
encountered does anything near the right thing by default, and
you generally need several dozen options. One more doesn't
really change that.

One of them (g++) even does so by

Been there, done that. Not interested.

To tell the truth, I can understand that. If I had it to do
over again, I'd have used .cpp and .hpp. But using the
special option wasn't any big deal.

None of which is really relevant to the choice of an extension
for header files.