Having an issue with virtual....

[SpreadTooThin]

If this is the definition of a class:

class outbuf : public std::streambuf
{
protected:

virtual int_type overflow (int_type c) {
if (c != EOF) {
// convert lowercase to uppercase
c = std::toupper(c,getloc());

// and write the character to the standard output
if (putchar(c) == EOF) {
return EOF;
}
}
return c;
}
};

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);
};

[outbuf.cpp]
virtual int_type outbuff:verflow (int_type c) {
if (c != EOF) {
// convert lowercase to uppercase
c = std::toupper(c,getloc());

// and write the character to the standard output
if (putchar(c) == EOF) {
return EOF;
}
}
return c;
}

Seems the compiler doesn't like this because the of the virtual key
word...

 

[Victor Bazarov]

If this is the definition of a class:

class outbuf : public std::streambuf
{
protected:

virtual int_type overflow (int_type c) {

BTW, what's 'int_type'? Is it internal to 'outbuf'?

if (c != EOF) {
// convert lowercase to uppercase
c = std::toupper(c,getloc());

// and write the character to the standard output
if (putchar(c) == EOF) {
return EOF;
}
}
return c;
}
};

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);
};

[outbuf.cpp]
virtual int_type outbuff:verflow (int_type c) {

Drop the "virtual" - it cannot be outside of a class definition.

If 'int_type' is internal to 'outbuf' (or 'outbuff'? check your
spelling), then you need to qualify it here:

outbuf::int_type outbuf:verflow(int_type c) {

(not sure whether you need to qualify it in the parentheses, ADL may apply.

if (c != EOF) {
// convert lowercase to uppercase
c = std::toupper(c,getloc());

// and write the character to the standard output
if (putchar(c) == EOF) {
return EOF;
}
}
return c;
}

Seems the compiler doesn't like this because the of the virtual key
word...

Yes, and it's actually right.

V

 

[Dennis Jones]

If this is the definition of a class:

class outbuf : public std::streambuf
{
protected:

virtual int_type overflow (int_type c) {
if (c != EOF) {
// convert lowercase to uppercase
c = std::toupper(c,getloc());

// and write the character to the standard output
if (putchar(c) == EOF) {
return EOF;
}
}
return c;
}
};

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);
};

[outbuf.cpp]
virtual int_type outbuff:verflow (int_type c) {
if (c != EOF) {
// convert lowercase to uppercase
c = std::toupper(c,getloc());

// and write the character to the standard output
if (putchar(c) == EOF) {
return EOF;
}
}
return c;
}

Seems the compiler doesn't like this because the of the virtual key
word...

Remove the 'virtual' keyword from the definition (in the .CPP file). It is
only needed in the declaration (in the .H file). If this was the result of
copy/paste, then you also need to fix the spelling of "outbuf" in your
definition (only one 'f' in "outbuf", not two).

- Dennis

 

[James Kanze]

If this is the definition of a class:

class outbuf : public std::streambuf
{
protected:

virtual int_type overflow (int_type c) {
if (c != EOF) {
// convert lowercase to uppercase
c = std::toupper(c,getloc());

// and write the character to the standard output
if (putchar(c) == EOF) {
return EOF;
}
}
return c;
}
};

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

[outbuf.cpp]
virtual int_type outbuff:verflow (int_type c) {
if (c != EOF) {
// convert lowercase to uppercase
c = std::toupper(c,getloc());

// and write the character to the standard output
if (putchar(c) == EOF) {
return EOF;
}
}
return c;
}

Seems the compiler doesn't like this because the of the
virtual key word...

That's because the virtual key word shouldn't be used here. It
probably won't like int_type, either, since that's a member of
std::streambuf (and thus your class), and won't be visible until
the start of the function. Try:

outbuf::int_type outbuf:verflow( int_type c )
{
// ...
}

Several other comments:

-- I'd use the toupper function directly on the locale, e.g.:
c = getloc().toupper( c ) ;
, and

-- I'd have the outbuf contain a pointer to a target streambuf,
so that it could output to anything, and not just to the
console. (Standard filtering streambuf idiom.)

 

[Victor Bazarov]

[..]
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? No extension (like the library headers)? Then
I vote for .h because on some systems files are associated (in UI) with
some applications based on the extension. 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... If they are, it's
conceivable that they will also include something like

#ifndef __cplusplus
#error This header is not to be included from any other language
#endif

at the top.

Of course we could recommend the OP to put it in a .hpp file, but that's

[..]

V

 

[Jorgen Grahn]

....
[someone named his files foo.cpp and foo.h]

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

It's not a universal rule. I use foo.h for pure C++ header files. I
cannot remember where I got that from -- possibly TC++PL. And I cannot
remember what the argument against foo.hh/hpp/hxx was.

It must have been a source which I respected though, because I
initially didn't like it. I wanted to use foo.cc and foo.hh.

/The Elements of C++ Style/ (Misfeldt et al) also uses foo.h, but with
no rationale. And they talk about putting each class in its own file
-- Java damage, I suppose.

/Jorgen

 

[Juha Nieminen]

Then
I vote for .h because on some systems files are associated (in UI) with
some applications based on the extension.

Yes: They are associated as *C* files, which then messes up things
like syntax coloring and such.

 

[Ian Collins]

....
[someone named his files foo.cpp and foo.h]

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

It's not a universal rule. I use foo.h for pure C++ header files. I
cannot remember where I got that from -- possibly TC++PL. And I cannot
remember what the argument against foo.hh/hpp/hxx was.

It must have been a source which I respected though, because I
initially didn't like it. I wanted to use foo.cc and foo.hh.

/The Elements of C++ Style/ (Misfeldt et al) also uses foo.h, but with
no rationale. And they talk about putting each class in its own file
-- Java damage, I suppose.

Or common sense.

If I want to look at the declaration of Foo I look in Foo.h. Simple.

 

[James Kanze]

[..]
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]

....
[someone named his files foo.cpp and foo.h]

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

It's not a universal rule. I use foo.h for pure C++ header
files. I cannot remember where I got that from -- possibly
TC++PL. And I cannot remember what the argument against
foo.hh/hpp/hxx was.

I'd be interested in hearing them. The only one I can think of
is that on early Unix, when filenames were limited to 14
characters, it left an additional character or two for the real
semantic information. But such systems distinguished case, and
the convention I saw on them was .C and .H for C++.

I don't know why myself, but a lot of early C++, especially on
Unix, did use only .h. I seems to clearly be a poor choice,
however, especially now that editors need to distinguish for
syntax highlighting.

Or common sense.

If I want to look at the declaration of Foo I look in Foo.h.
Simple.

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

 

[Alf P. Steinbach]

* James Kanze:

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

I have not experienced this problem.


Cheers,

- Alf

 

[Victor Bazarov]

Yes: They are associated as *C* files, which then messes up things
like syntax coloring and such.

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

And the problem exists only if you have a definition of a "C file". I
don't develop in C, I couldn't care less about that. So, my system does
not have them associated as "C" files, they are "C++" files here.

V

 

[Victor Bazarov]

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

V

 

[Juha Nieminen]

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

Exactly which editor which supports C++ syntax coloring has no
associations to typical C++ header file extensions?

 

[Juha Nieminen]

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

Easier than what? Than naming your files logically?

 

[Victor Bazarov]

Exactly which editor which supports C++ syntax coloring has no
associations to typical C++ header file extensions?

I don't understand the question or you didn't understand what I meant.
What's a "typical C++ header file extension"? In my world it's ".h".

V

 

[Victor Bazarov]

Easier than what? Than naming your files logically?

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

V

 

[JustBoo]

I don't understand the question or you didn't understand what I meant.
What's a "typical C++ header file extension"? In my world it's ".h".

V

".hpp"

 

[Ian Collins]

Easier than what? Than naming your files logically?

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

 

[Victor Bazarov]

".hpp"

Well, in *my world* that's not "typical". That's all.

V