Re: Having an issue with virtual....
On Aug 12, 4:06 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
James Kanze wrote:
On Aug 12, 2:38 am, SpreadTooThin <bjobrie...@gmail.com> wrote:
[..]
How do I split this into a .h and .cpp file?
[oubuf.h]
class outbuf : public std::streambuf
{
protected:
virtual int_type overflow (int_type c);
};
So far, so good. (But why .h? This certainly isn't a C
header; .h is normally reserved for headers which can be
included from C.)
What's the alternative?
Anything you want.
What I've generally seen is replacing the c's in the source file
extension with h's, e.g. .hh in places where .cc was the usual
source file extension (most of the places I've worked), .hpp
where .cpp was the usual source file extention, and in the past,
..H for .C and .hxx for .cxx.
In my own code, I use additional conventions; my basic rule is
..cc and .hh, but I also use .tcc (for template implementation
files---these are really sources, but must be included), .lhh
(for local headers, which won't be exported...or scanned by
Doxygen), and in the past, some others as well.
No extension (like the library headers)?
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.)
Then I vote for .h because on some systems files are
associated (in UI) with some applications based on the
extension.
..h is already used. Using it for C++ headers creates an
ambiguity. The application associated with .h files is a C
program editor (i.e. a program editor configured for C); syntax
highlighting, for example, won't recognize class as a keyword,
but will highlight it as a user symbol.
For all we know, the OP never programs in anything but C++ and
those headers are not for sharing with anybody, so "normally"
may not apply here...
In which case, .xyz is equally good. In practice, it's best to
stick with some established conventions. And one of the most
widely established conventions is that .h is a C header file.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34