Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > .h and .cpp

Reply
Thread Tools

.h and .cpp

 
 
Daniel
Guest
Posts: n/a
 
      11-29-2011
On Nov 28, 3:17*pm, Geoff <(E-Mail Removed)> wrote:
> For some very interesting coding standards referenced by no less
> authority than Stroustrup himself:
>
> http://www2.research.att.com/~bs/JSF-AV-rules.pdf
>

Interesting to see the recommended naming conventions,

Example_class_name

RGB_colors

example_function_name

Underscores don't seem to be that popular though, more likely to be
seen are ExampleClassName, RGBColors or RgbColors, and
exampleFunctionName.

Daniel
 
Reply With Quote
 
 
 
 
Christopher
Guest
Posts: n/a
 
      11-29-2011
On Nov 29, 1:55*am, Juha Nieminen <(E-Mail Removed)> wrote:
> > 1b) A .h file should never contain class implementation (except for
> > inline functions or methods)

>
> * That's a null statement. If a header file contains implementations,
> they will be inline by necessity (else you'll get linker errors if the
> header is included more than once), so that rule isn't really saying
> anything.



I've seen this claim in several of the replies. I made a minimal
example that compiles and links in Visual Studio 2008 SP1 (what they
use at work).

--ClassA.h---
#ifndef CLASSA_H
#define CLASSA_H

#include <iostream>

class A
{
public:

A()
:
m_x(0)
{
std::cout << "Contructor" << std::endl;
}

~A();

int Method1(const int y)
{
m_x = 4 * y;
return m_x;
}

int Method2(const int y);

private:

int m_x;
};

#endif

--ClassA.cpp---

#include "ClassA.h"

A::~A()
{
}

int A::Method2(const int y)
{
m_x = 2 * y;
return m_x;
}


--main.cpp---

#include "ClassA.h"


int main()
{
A a;
std::cout << a.Method1(5) << std::endl;
std::cout << a.Method2(5) << std::endl;
}

--dummy.cpp--
#include "ClassA.h"

void Foo()
{
for(int x = 0; x < 10; ++x)
{
A a;
std::cout << "I constructed an A " << x << "times." <<
std::endl;
}
}

------

ClassA.h contains implementation of the A class. So does ClassA.cpp.
ClassA.h is included in more than one compilation unit: ClassA.cpp,
main.cpp, and dummy.cpp
No linker errors.

Yet, this is an example of what I am talking about that should not be
done. The constructor and Method1 are not inline, and have no business
being implemented in the header. They should be in the .cpp, unless
they were inlined. Keep in mind these are simple for example purposes.





 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      11-29-2011
On 11/30/11 09:15 AM, Christopher wrote:
> On Nov 29, 1:55 am, Juha Nieminen<(E-Mail Removed)> wrote:
>>> 1b) A .h file should never contain class implementation (except for
>>> inline functions or methods)

>>
>> That's a null statement. If a header file contains implementations,
>> they will be inline by necessity (else you'll get linker errors if the
>> header is included more than once), so that rule isn't really saying
>> anything.

>
>
> I've seen this claim in several of the replies. I made a minimal
> example that compiles and links in Visual Studio 2008 SP1 (what they
> use at work).
>
> --ClassA.h---
> #ifndef CLASSA_H
> #define CLASSA_H
>
> #include<iostream>
>
> class A
> {
> public:
>
> A()
> :
> m_x(0)
> {
> std::cout<< "Contructor"<< std::endl;
> }


This is an inline function.

--
Ian Collins
 
Reply With Quote
 
Christopher
Guest
Posts: n/a
 
      11-29-2011
On Nov 29, 2:19*pm, Leigh Johnston <(E-Mail Removed)> wrote:
> Yes no linker errors because Method1 is inline;
>
> /Leigh-


I'm using it. I was not aware it could be inline without explicitly
using the inline keyword.
I just read the faq 9.6 after your response. Learn something new
everyday.

Ok, so I should instead argue that the "best practices" in the FAQ are
followed, which state that the method should be defined outside the
class body, using the inline keywork. It would make the inlining
obvious and keep the spirit of the class defintion telling us what the
class offers instead of how. Furthermore, there should be a clear
advantage in inline the method for it to be inlined. 60,000 line
functions that spawn threads are probably not good canidates for
inlining.

 
Reply With Quote
 
ralph
Guest
Posts: n/a
 
      11-29-2011
On Tue, 29 Nov 2011 08:31:55 -0800 (PST), Daniel
<(E-Mail Removed)> wrote:

>On Nov 28, 3:17*pm, Geoff <(E-Mail Removed)> wrote:
>> For some very interesting coding standards referenced by no less
>> authority than Stroustrup himself:
>>
>> http://www2.research.att.com/~bs/JSF-AV-rules.pdf
>>

>Interesting to see the recommended naming conventions,
>
>Example_class_name
>
>RGB_colors
>
>example_function_name
>
>Underscores don't seem to be that popular though, more likely to be
>seen are ExampleClassName, RGBColors or RgbColors, and
>exampleFunctionName.
>
>Daniel


What you are describing is called Camel Case or Camelback. Most
historians trace its use as a direct migration from using inner
underscores as a delimiter to using uppercase to separate words.
Mostly because it saved space and yet still provides readability.

Underscores were popular in the early days of C and C++, and it is
just that popularity that has led to discouraging their use. So many
libraries and implementations used underscores - collisions were
inevitable.

ANSI now forbids them in some contexts.

However, it might be useful to remember before posting that there are
three subjects that are best avoided in this newsgroup:
1) Favorite Editors,
2) Indent Styles,
3) and Naming Conventions

-ralph <bg>
[*Comments should receive honorable mention.]
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      11-30-2011
On Tue, 2011-11-29, ralph wrote:
> On Tue, 29 Nov 2011 08:31:55 -0800 (PST), Daniel
> <(E-Mail Removed)> wrote:
>
>>On Nov 28, 3:17*pm, Geoff <(E-Mail Removed)> wrote:
>>> For some very interesting coding standards referenced by no less
>>> authority than Stroustrup himself:
>>>
>>> http://www2.research.att.com/~bs/JSF-AV-rules.pdf
>>>

>>Interesting to see the recommended naming conventions,
>>
>>Example_class_name
>>
>>RGB_colors
>>
>>example_function_name
>>
>>Underscores don't seem to be that popular though, more likely to be
>>seen are ExampleClassName, RGBColors or RgbColors, and
>>exampleFunctionName.
>>
>>Daniel

>
> What you are describing is called Camel Case or Camelback. Most
> historians trace its use as a direct migration from using inner
> underscores as a delimiter to using uppercase to separate words.
> Mostly because it saved space and yet still provides readability.
>
> Underscores were popular in the early days of C and C++, and it is
> just that popularity that has led to discouraging their use.


Underscores is still my main style, for function and variable names.
It's also the style for the Linux kernel and many Unix utilities.

I suspect under_score is simply an old Unix convention. Most other
OSes seem to use some CamelCase variant. (Happily, none that I know of
uses ALL_UPPERCASE as the main style.)

> So many
> libraries and implementations used underscores - collisions were
> inevitable.


That doesn't make sense -- you cannot invent a new naming convention
for each library! Prefixes is the way it's done, pre-namespaces at
least.

> ANSI now forbids them in some contexts.
>
> However, it might be useful to remember before posting that there are
> three subjects that are best avoided in this newsgroup:
> 1) Favorite Editors,
> 2) Indent Styles,
> 3) and Naming Conventions


Yes, but we're ok as long as there's no advocacy involved.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      11-30-2011
On Tue, 2011-11-29, Christopher wrote:
> On Nov 29, 2:19*pm, Leigh Johnston <(E-Mail Removed)> wrote:
>> Yes no linker errors because Method1 is inline;
>>
>> /Leigh-

>
> I'm using it. I was not aware it could be inline without explicitly
> using the inline keyword.
> I just read the faq 9.6 after your response. Learn something new
> everyday.
>
> Ok, so I should instead argue that the "best practices" in the FAQ are
> followed, which state that the method should be defined outside the
> class body, using the inline keywork. It would make the inlining
> obvious and keep the spirit of the class defintion telling us what the
> class offers instead of how.


Well, the class definition already tells us a lot about the "how" --
the private section. I happily put trivial definitions in the class
itself, if it doesn't /overshadow/ the "this is the interface" view of
the class.

Besides, it's not as if defining the inline functions after the class
doesn't obscure anything else. I frequently have a number of "loose"
functions there which are just as important as the contents of the
class itself. It's a tradeoff, unfortunately.

> Furthermore, there should be a clear
> advantage in inline the method for it to be inlined. 60,000 line
> functions that spawn threads are probably not good canidates for
> inlining.


Better example: a function which compiles into a lot of object code,
and is called from many places.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      11-30-2011
On Nov 28, 9:30*pm, Christopher <(E-Mail Removed)> wrote:
> On Nov 28, 12:58*pm, Goran <(E-Mail Removed)> wrote:


<snip>

> > > 1b) A .h file should never contain class implementation (except for
> > > inline functions or methods)

>
> > Purely mechanically, this doesn't work due to C compilation model: if
> > the class parts are defined in a header, and said header is included
> > in more than one translation unit (source file), linker will encounter
> > duplicate symbols.

>
> > > 2) Class implementations go in their own .cpp file (except for
> > > templates)

>
> > Same as above

>
> I cannot visualize this scenario. Can you give a code example in which
> any part of class implementation is required to be in the header,
> excluding the use of templates?
>
> Use of inclusion guards has always taken care of duplicate symbols
> when a header is included in more than one source file and is pretty
> standard practice in my experience.


not if it's in two different compilation units. The key thing is "if
the class parts are /defined/ in a header" (emp. mine). In a nutshell
a declaration of an object (this probably applies to non-objects like
functions as well) says "this is the name of something- but doesn't
allocate any space" whilst a definition gives it soemwhere to live.
Naming something more than once is ok. Creating more than one copy of
something is wrong. This is sometimes referred to as The One
Definition Rule.

> > > 2a) A .cpp should never contain a class definition

>
> > Disagreed. There's classes that will only be used in one translation
> > unit. What can one gain by making another trivial header?

>
> In this case, what's wrong with putting it in the header? I suppose
> until I can visualize your argument for 1b and 2, I have trouble
> seeing this as well.


I'd say don't put it in a header if you don'e need to. It's just work.

<snip>

> > > 6) Variables should never be defined in a .h file

>
> > Same as for classes - duplicate symbols galore. Exception: literal
> > constants. If these are not constants, there should ideally be 0 of
> > those in any given codebase.

>
> Whoops, I believe I meant to say variable _declaration_. Definition
> and Declaration seem to very confusing terms as they have different
> meanings for classes and variables in C++.
>
> What I mean is
> int x = 10; should not appear in a .h file.
> int x; However, may appear in a .h file, but I'd still argue that
> there is probably a better way then using a global.


"global" isn't really a C++ term. ITYM "external". If you are using
them then declare 'em external.

// externals.h
int x;

// externals.c
#include "externals.h"
int x = 10;

// user.c
#include "externals.h"

void f()
{
doThing (x);
}

> const int x = 10; Should not appear in a .h file
> const int x; May appear in a .h file, but I'd rather see:
>
> static int GetX() const
> {
> * *return 10;
>
> }


that should be inline

> because some other global MyClass might make use of x and then I run
> into the static intialization fiasco.


really? This surprises me. Are const items of basic types really
subject to SIF? I thought declaring consts in a header was ok.

const double PI = 3.1415926535;

I thought the idea was to be able to replace C's

# define PI 3.1415926535

to have to hide it in a static function seems really icky. I tghink
I'll start using #define again...


> or better if only used in one class:
>
> class WhereXIsUsed
> {
> public:
> private:
> * const int m_x;
>
> };
>
> or possibly something like
>
> struct SystemConfigurationDefaults
> {
> * *const int m_x;
>
> };


namespaces maybe?


> > > 7) Globals should not be defined in a .h file

>
> > I am not sure to understand the difference between a variable and a
> > global?

>
> One is a superset of the other.
> But again, I think I meant declared instead.


you also need to expalin what a "global" is. The term is not terribly
well defined.

<snip>
 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      11-30-2011
Leigh Johnston <(E-Mail Removed)> wrote:
> The only non-inline functions you can have in header files are templates.


Template function definitions behave exactly like inline function
definitions (in that they can be included in more than one compilation
unit and, if no literal inlining happens, the linker will merge all the
instances into one).

I have heard rumors that there are some technical differences between
(non-inline) template functions and inline functions, but I really don't
know what those differences might be.
 
Reply With Quote
 
none
Guest
Posts: n/a
 
      11-30-2011
In article <(E-Mail Removed)>,
Christopher <(E-Mail Removed)> wrote:
>> Sounds like a group out-of-control.
>>
>> Sadly you either have the authority to enforce coding standards, or
>> you do not. If you do then "just do it, its the thing to do" OR *its
>> your job* is the only reliable answer. Otherwise, live with it chewing
>> away as opportunities present themselves, or seek other employment.

>
>I am beginning to think that might be the case, but if the boss says
>"I beleive you, you just have to give some reasoning aside from I said
>so." Then I wanted to at least try before joining the "I am looking
>for employment" group again.


Well, you should be able to justify the rules in your coding
guideline. Some of the justification may be weak but they should still
be rational. If you can't justify a rule, you may as well remove it
and only kep the ones that can be justified.

A typical rule is naming convention. Why is it better to use
CamelCase rather then under_score_separated_names (or vice-versa).
Taken in isolation, neither is better than the other. However, it can
be clearly demonstrated that a code base that use either randomly is
significantly harder to read than a code base that use a consistent
naming convention.

Many other rule may appear not useful at first sight but when thinking
about long term maintenance, they start becoming useful. Having some
classes defined in cpp means that they are potentially harder to
find. Keeping files shorter mean that it is easier to track changes
and potential side effects, etc.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
if and and vs if and,and titi VHDL 4 03-11-2007 05:23 AM



Advertisments