Having an issue with virtual....

[James Kanze]

* Juha Nieminen:

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.

And it has been pointed out that this not always the case.
There are situations (e.g. mixed C and C++) where there is a
cost. (In a pure C++ environemnt, the cost of treating .ada
files as C++ headers is also so low you'd never notice it.)

But the cost, insignificant as it is, does not matter anyway
because we derive a lot of benefits from treating .h as C++.

Such as confusing some readers, who come from other
environments?

Especially considering the very large number of libraries with
C++ .h headers. Boost is a fairly unique exception.

Along with the pre-standard implementations of the standard
librarys, e.g. <iostream.hpp>. IMHO, that pretty much set the
tone.

As a general rule, an experienced programmer will have no real
problems, regardless of the conventions in force where he works
(and such conventions often define several extensions, e.g. .tcc
for template implementation code). For a beginner, who may
later have to work in mixed language projects, it's better if he
avoid .h, since that will create confusion as soon as any C is
present (e.g. <windows.h>, <unistd.h>, etc.).

 

[Ian Collins]

And it has been pointed out that this not always the case.
There are situations (e.g. mixed C and C++) where there is a
cost. (In a pure C++ environemnt, the cost of treating .ada
files as C++ headers is also so low you'd never notice it.)

As I asked before, what is there in C headers that causes problems if an
editor highlights them as C++? Whilst C source isn't a subset of C++, C
headers pretty much are.

Such as confusing some readers, who come from other
environments?


Along with the pre-standard implementations of the standard
librarys, e.g. <iostream.hpp>. IMHO, that pretty much set the
tone.

I don't think I've ever seen that. Every old library I used (both Unix
and windows) used <iostream.h>.

 

[Noah Roberts]

Do you name your C++ source files with the ".c" extension? If not, why
not?

Because my compiler treats them differently and will activate the C
compiler rather than the C++ one.

If all you do is C++, what would be the difference?

My projects would not compile.

And why can't
your answer be applied to the header files as well?

Because my header files are brought in, by name, by the preprocessor and
it doesn't care what the name is. I can include .cpp files too if I
wanted (and do in rare cases with unit tests and such) but if I did that
in a project that contains them I'd have serious issues.

Plus, using cpp or C for C++ code files is a pretty widely accepted
standard. I actually hardly ever see .hpp used and if it wasn't for
boost I might not see it at all.

 

[Noah Roberts]

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?

Let's compare:

1) create file with .cpp extension
DONE

Your way:

1) create file with .c extension
2) open property dialog
3) edit command line for file
DONE?

Don't even know if your way works to tell the truth.

 

[Noah Roberts]

And it has been pointed out that this not always the case.
There are situations (e.g. mixed C and C++) where there is a
cost. (In a pure C++ environemnt, the cost of treating .ada
files as C++ headers is also so low you'd never notice it.)

Well, that's easy: such cases are unique and limited in scope to certain
projects. Follow the convention of the project that are meant to take
care of specific problems limited to IT. Doesn't mean the rest of the
planet needs to do the same thing.

IMHO it's fairly idiotic and pedantic to point out niche issues in
arguments regarding general rules.

Such as confusing some readers, who come from other
environments?


Along with the pre-standard implementations of the standard
librarys, e.g. <iostream.hpp>.

Interestingly, all the books and compilers I saw of that time use .h

IMHO, that pretty much set the
tone.

If that's what we want to use to set the standard...

 

[James Kanze]

As I asked before, what is there in C headers that causes
problems if an editor highlights them as C++? Whilst C source
isn't a subset of C++, C headers pretty much are.

On thinking about it, I think the technical issues are red
herrings. They are really negligible if you have decent tools.
On the other hand, C and mixed-language headers (I don't know of
any pure C headers anymore) have a different contract than C++
headers, and it's nice to let human readers know.

[...]

I don't think I've ever seen that. Every old library I used
(both Unix and windows) used <iostream.h>.

Both Borland C++ and Zortech C++ used <iostream.hpp> (and
<strstrea.hpp> . The convensions I've actually seen used
have been: .C/.h, .cc/.hh and .cpp/.hpp (and maybe .cxx/hxx---I
seem to have a vague memory of having seen it). One of the
reasons why the C++ committee dropped the extension for standard
headers is that there was no standard; different compilers did
it differently.

 

[James Kanze]

Interestingly, all the books and compilers I saw of that time
use .h

The only books I saw at the time also used .C for the source
files. Both Borland and Zortech used .hpp for header files.

If that's what we want to use to set the standard...

Gotta use something.

I firmly believe that there is value in using different
extensions for files with different contracts (at the file
level). I also use .tcc for template implementation code, for
example, and in the past (and some of that code is still
floating around and being used), .ihh for the implementation of
inline functions. In both cases, it's a case of physically
separating things that are logically separate, and communicating
a maximum of information to the reader. Obviously, such
communication only works if the reader is also aware of the
convention.

Anyway, it looks like a losing battle for me, since Stroustrup,
in _Programming: Principles and Practice Using C++_ uses .h, and
given the quality of the book, it will doubtlessly become the
standard learning text. So another "bad" (i.e. less than
optimal) tradition establishes itself.

 

[Jorgen Grahn]

I look in Foo.hh or Foo.hpp, depending on the conventions of the
library I'm using. And of course, it's only a very general
rule---sometimes, two or more classes do belong in a single
header, and of course, there are headers which don't contain any
classes whatsoever. (Sometimes, you have to put more than one
class in a single header. If the classes are nested, for
example.)

Yeah, my argument was similar. Of course I wouldn't place class Foo in
ooF.h for no other reason than to annoy Mr Collins

A rule "one class per file" (even if exceptions are allowed) can steer
inexperienced developers away from tiny special-purpose classes, free
functions and other things which are not traditional medium-sized
classes. Most people still hesitate to create dozens or hundreds of
tiny files, and renaming source files still causes tool problems.

/Jorgen

 

[Jorgen Grahn]

No. Normally, there should be *no* files on a system without an
extension. (Under Unix, you generally can't avoid omitting an
extension for executables. But that's really a design bug in
Unix.)

I don't see that bug -- I can run a binary called "foo.c" if I want on
all Unices I have ever used.

Those are not the usual opinions among Unix users. We tend to look
down on people and tools who rely on them. Of course, extensions are
sometimes useful, and some tools (make, gcc and the Apache web server
come to mind) are impossible or hard to use without them.

/Jorgen

 

[Pascal J. Bourguignon]

I don't see that bug -- I can run a binary called "foo.c" if I want on
all Unices I have ever used.

Those are not the usual opinions among Unix users. We tend to look
down on people and tools who rely on them. Of course, extensions are
sometimes useful, and some tools (make, gcc and the Apache web server
come to mind) are impossible or hard to use without them.

You're quite courageous, both of you, to use "extension" in the same
sentence as "unix".

On unix, directory entries are named by undiscriminate sequences of
_bytes_. The only two constraints are:

- length of the sequence usually limited to 255 bytes (but the limit
may be different, such as little as 14 bytes on old unix file
systems).

- no byte valued 0 or 47 must be present in the name.



Of course, when using non-unix file systems on unix systems, you may
have additionnal constraits, such as maximum 12 bytes with a single
byte valued 46 before the last three, and no byte valued 92 or some
other, but this doesn't concerns unix really.

 

[James Kanze]

I don't see that bug -- I can run a binary called "foo.c" if I
want on all Unices I have ever used.

That's not the issue (and that's not necessarily an advantage).

Those are not the usual opinion among Unix users. We tend to
look down on people and tools who rely on them. Of course,
extensions are sometimes useful, and some tools (make, gcc and
the Apache web server come to mind) are impossible or hard to
use without them.

Almost all tools rely on them somehow. You can do a recursive
search for all binary executables using 'file', grepping the
output and implementing the recursion in the shell, but it's a
lot easier under Windows, where I just use "find . -name
'*.exe'".

(Note that I'm not saying that extensions are the best solution,
since their not enforced by the OS, but you really do need a
means of easily determining the type of a file in tools like
find.)

 

[Jorgen Grahn]

I don't see that bug -- I can run a binary called "foo.c" if I want on
all Unices I have ever used.

Those are not the usual opinions among Unix users. We tend to look
down on people and tools who rely on them. Of course, extensions are
sometimes useful, and some tools (make, gcc and the Apache web server
come to mind) are impossible or hard to use without them.

You're quite courageous, both of you, to use "extension" in the same
sentence as "unix".

On unix, directory entries are named by undiscriminate sequences of
_bytes_. The only two constraints are: [...]

Sure, but if you look at applications the ones I mentioned above,
you'll find you cannot ignore the concept "file name extension".

Kanze and I just disagree on how common they are. I find that most
tools I use don't care. (There is a trend among recent GUI
applications to require them, or make life hard for people who don't
want them -- for example by having file open/save dialogues filter
away anything not called *.txt -- but I report such things as bugs.)

/Jorgen