Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #11892 > unrolled thread

.h and .cpp

Back to article view | Back to comp.lang.c++

Contents

  .h and .cpp Christopher <cpisz@austin.rr.com> - 2011-11-28 09:20 -0800
    Re: .h and .cpp Leigh Johnston <leigh@i42.co.uk> - 2011-11-28 17:30 +0000
      Re: .h and .cpp Christopher <cpisz@austin.rr.com> - 2011-11-28 10:39 -0800
        Re: .h and .cpp Tobias Müller <troplin@bluewin.ch> - 2011-11-28 19:09 +0000
    Re: .h and .cpp ralph <nt_consulting64@yahoo.net> - 2011-11-28 12:37 -0600
      Re: .h and .cpp Christopher <cpisz@austin.rr.com> - 2011-11-28 10:48 -0800
        Re: .h and .cpp ralph <nt_consulting64@yahoo.net> - 2011-11-28 14:24 -0600
        Re: .h and .cpp yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-11-30 11:24 +0000
          Re: .h and .cpp Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-12-01 21:42 +0000
            Re: .h and .cpp Rui Maciel <rui.maciel@gmail.com> - 2011-12-02 02:03 +0000
              Re: .h and .cpp Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-12-02 20:59 +0000
    Re: .h and .cpp "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2011-11-28 19:45 +0100
      Re: .h and .cpp Leigh Johnston <leigh@i42.co.uk> - 2011-11-28 19:03 +0000
        Re: .h and .cpp "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2011-11-28 20:36 +0100
      Re: .h and .cpp Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-11-28 22:52 +0000
        Re: .h and .cpp yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-11-30 11:39 +0000
          Re: .h and .cpp Juha Nieminen <nospam@thanks.invalid> - 2011-11-30 12:50 +0000
            Re: .h and .cpp yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-11-30 13:57 +0000
              Re: .h and .cpp Juha Nieminen <nospam@thanks.invalid> - 2011-11-30 15:06 +0000
            Re: .h and .cpp Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-11-30 16:21 +0000
          Re: .h and .cpp Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-11-30 16:12 +0000
    Re: .h and .cpp Goran <goran.pusic@gmail.com> - 2011-11-28 10:58 -0800
      Re: .h and .cpp Christopher <cpisz@austin.rr.com> - 2011-11-28 13:30 -0800
        Re: .h and .cpp Tobias Müller <troplin@bluewin.ch> - 2011-11-29 06:44 +0000
        Re: .h and .cpp Goran <goran.pusic@gmail.com> - 2011-11-29 01:17 -0800
        Re: .h and .cpp Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-30 00:53 -0800
      Re: .h and .cpp "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2011-11-29 10:57 +0100
      Re: .h and .cpp yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-11-30 12:05 +0000
    Re: .h and .cpp Rui Maciel <rui.maciel@gmail.com> - 2011-11-28 20:07 +0000
    Re: .h and .cpp Geoff <geoff@invalid.invalid> - 2011-11-28 12:17 -0800
      Re: .h and .cpp Ian Collins <ian-news@hotmail.com> - 2011-11-29 11:41 +1300
        Re: .h and .cpp gwowen <gwowen@gmail.com> - 2011-11-29 07:37 -0800
      Re: .h and .cpp Goran <goran.pusic@gmail.com> - 2011-11-29 00:08 -0800
      Re: .h and .cpp Daniel <danielaparker@gmail.com> - 2011-11-29 08:31 -0800
        Re: .h and .cpp ralph <nt_consulting64@yahoo.net> - 2011-11-29 14:49 -0600
          Re: .h and .cpp Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-11-30 00:21 +0000
    Re: .h and .cpp Andy Champ <no.way@nospam.invalid> - 2011-11-28 21:30 +0000
    Re: .h and .cpp Paavo Helde <myfirstname@osa.pri.ee> - 2011-11-28 18:05 -0600
    Re: .h and .cpp Paavo Helde <myfirstname@osa.pri.ee> - 2011-11-28 18:27 -0600
    Re: .h and .cpp Juha Nieminen <nospam@thanks.invalid> - 2011-11-29 07:55 +0000
      Re: .h and .cpp Christopher <cpisz@austin.rr.com> - 2011-11-29 12:15 -0800
        Re: .h and .cpp Leigh Johnston <leigh@i42.co.uk> - 2011-11-29 20:19 +0000
          Re: .h and .cpp Christopher <cpisz@austin.rr.com> - 2011-11-29 12:31 -0800
            Re: .h and .cpp Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-11-30 00:31 +0000
          Re: .h and .cpp Juha Nieminen <nospam@thanks.invalid> - 2011-11-30 09:43 +0000
        Re: .h and .cpp Ian Collins <ian-news@hotmail.com> - 2011-11-30 09:23 +1300

Page 1 of 3  [1] 2 3  Next page →

#11892 — .h and .cpp

If you were on a team of developers that had little C++ experience,
how would you go about explaining the reasoning as to why the
following rules should be followed? (Or why they shouldn't)

1) Class defintions go in their own .h (or .hpp for templates) file
named after the class
1a) Every class should have its own .h (or .hpp for templates) file
1b) A .h file should never contain class implementation (except for
inline functions or methods)

2) Class implementations go in their own .cpp file (except for
templates)
2a) A .cpp should never contain a class definition

3) One should not define multiple classes in a single .h file
3a) Nested class defintions should be avoided without good reason
(what's good reason?)

6) Variables should never be defined in a .h file
7) Globals should not be defined in a .h file
8) Every .cpp file should compile into a .obj file without error or
warning on its own.
     i.e In Visual Studio, you should be able to right click a .cpp in
the source tree and choose compile, without error or warning in the
output.
----

Sadly, I find myself having to justify these things. (of course
someone might point out I am wrong or exceptions to the above), but
these are things that I've always had drilled into my head throughout
the years and have rarely come acorss other developers that didn't do
the same. I am finding it frustrating to work on a project where 30
classes defintions reside in the .h same .h file, a single .cpp file,
or worse a precompiled header. There is discussion, but I have to
explain reasoning.

So far, I've come up with the testability argument:
When unit testing one frequently wants to test a single class. A proxy
class may need to be created to test its protected or privare methods.
Proxies may have to be created for its input and outputs. I should be
able to include a single .h file, link in the appropriate .obj files
and compile a unit test without the added clutter of satisfying
includes or linkage needed by unrelated classes.

I don't know what else to say aside from, "just do it, its the thing
to do." and noone is going to buy that.

[toc] | [next] | [standalone]

#11893

On 28/11/2011 17:20, Christopher wrote:
> If you were on a team of developers that had little C++ experience,
> how would you go about explaining the reasoning as to why the
> following rules should be followed? (Or why they shouldn't)
>
> 1) Class defintions go in their own .h (or .hpp for templates) file
> named after the class

It seems irrational to me to have classes in .h and templates in .hpp; 
either use .h for all C++ code; .hpp for all C++ code.

It seems popular to use .hpp for C++ code and .h for C code these days.

/Leigh

[toc] | [prev] | [next] | [standalone]

#11896

> It seems irrational to me to have classes in .h and templates in .hpp;
> either use .h for all C++ code; .hpp for all C++ code.
>
> It seems popular to use .hpp for C++ code and .h for C code these days.
>
> /Leigh

That would be fine with me.
I am looking for some explanation I can give though for why not to put
a class definition in a .cpp file. What would you say?

[toc] | [prev] | [next] | [standalone]

#11901

Christopher <cpisz@austin.rr.com> wrote:
>> It seems irrational to me to have classes in .h and templates in .hpp;
>> either use .h for all C++ code; .hpp for all C++ code.
>> 
>> It seems popular to use .hpp for C++ code and .h for C code these days.
>> 
>> /Leigh
> 
> That would be fine with me.
> I am looking for some explanation I can give though for why not to put
> a class definition in a .cpp file. What would you say?

Generally, you don't #include .cpp files (this is what .h files are made
for), so a class defined in a cpp file is really only visible in that
single file.

Normally you want a class to be reusable in other files, but there are rare
cases where it makes sense to have a class that is "private" to some .cpp
file and you don't want it to be used by others.

Tobi

[toc] | [prev] | [next] | [standalone]

#11895

On Mon, 28 Nov 2011 09:20:13 -0800 (PST), Christopher
<cpisz@austin.rr.com> wrote:

>If you were on a team of developers that had little C++ experience,
>how would you go about explaining the reasoning as to why the
>following rules should be followed? (Or why they shouldn't)
>
>1) Class defintions go in their own .h (or .hpp for templates) file
>named after the class
>1a) Every class should have its own .h (or .hpp for templates) file
>1b) A .h file should never contain class implementation (except for
>inline functions or methods)
>
>2) Class implementations go in their own .cpp file (except for
>templates)
>2a) A .cpp should never contain a class definition
>
>3) One should not define multiple classes in a single .h file
>3a) Nested class defintions should be avoided without good reason
>(what's good reason?)
>
>6) Variables should never be defined in a .h file
>7) Globals should not be defined in a .h file
>8) Every .cpp file should compile into a .obj file without error or
>warning on its own.
>     i.e In Visual Studio, you should be able to right click a .cpp in
>the source tree and choose compile, without error or warning in the
>output.
>----
>
>Sadly, I find myself having to justify these things. (of course
>someone might point out I am wrong or exceptions to the above), but
>these are things that I've always had drilled into my head throughout
>the years and have rarely come acorss other developers that didn't do
>the same. I am finding it frustrating to work on a project where 30
>classes defintions reside in the .h same .h file, a single .cpp file,
>or worse a precompiled header. There is discussion, but I have to
>explain reasoning.
>
>So far, I've come up with the testability argument:
>When unit testing one frequently wants to test a single class. A proxy
>class may need to be created to test its protected or privare methods.
>Proxies may have to be created for its input and outputs. I should be
>able to include a single .h file, link in the appropriate .obj files
>and compile a unit test without the added clutter of satisfying
>includes or linkage needed by unrelated classes.
>
>I don't know what else to say aside from, "just do it, its the thing
>to do." and noone is going to buy that.
>

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.

Number 8 above 
"8) Every .cpp file should compile into a .obj file without error
 or warning on its own"
can be corrected with daily builds and penalties for "breaking the
build".

-ralph

[toc] | [prev] | [next] | [standalone]

#11899

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

> Number 8 above
> "8) Every .cpp file should compile into a .obj file without error
>  or warning on its own"
> can be corrected with daily builds and penalties for "breaking the
> build".

Not really, because the build in its entirety brings in other .cpp
and .h files as well as precompiled headers, in which things were
defined in the wrong places, but the compiler remains happy. It just
ends up being a fragile build that breaks often, because standards
weren't followed. When compiling just one .cpp by itself, everything
has to be defined and correct.

[toc] | [prev] | [next] | [standalone]

#11906

On Mon, 28 Nov 2011 10:48:17 -0800 (PST), Christopher
<cpisz@austin.rr.com> 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.
>
>> Number 8 above
>> "8) Every .cpp file should compile into a .obj file without error
>>  or warning on its own"
>> can be corrected with daily builds and penalties for "breaking the
>> build".
>
>Not really, because the build in its entirety brings in other .cpp
>and .h files as well as precompiled headers, in which things were
>defined in the wrong places, but the compiler remains happy. It just
>ends up being a fragile build that breaks often, because standards
>weren't followed. When compiling just one .cpp by itself, everything
>has to be defined and correct.

I was thinking of intermediate or validation "builds" as part of the
daily build. Which is something I often enforce with large projects,
ie, no translation unit gets through with warnings and errors. Even
so, as you noted, the build is fragile and will destruct sooner or
later. Making those responsible for breaking the build - responsible
for repairing the build, will go a long way to getting the message
across.

Also frequent Code Reviews will help.

Setting up and maintaining an enterprise level development effort is
not a trivial exercise. It encompasses more that just "coding
standards".

As others noted not all your rules are "unquestionable". Few *best
practices* are. There are always exceptions, though as the proverb
says "it is the exception that makes the rule".

You have to start somewhere. Having a good reason to break a rule is
very useful in gaining an understanding of why the rule was there in
the first place.

Hold on. Chew away. Be happy if you can make a change. Don't beat
yourself up when you can't. (ie, don't take it home with you. <g>)

-ralph

[toc] | [prev] | [next] | [standalone]

#11975

In article <ad50180d-04cd-4ca6-a24e-b0bbbda72ec7@d17g2000yql.googlegroups.com>,
Christopher  <cpisz@austin.rr.com> 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.

[toc] | [prev] | [next] | [standalone]

#12007

On Wed, 2011-11-30, yatremblay@bel1lin202.(none) (Yannick Tremblay) wrote:
...
> 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.

But that's a *good* thing! Not being able to find irrelevant things is
a good thing.

More to the point, if you're scanning the header files looking for
whatever, you don't want to find things which only concern the inner
workings of one translation unit.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#12009

Jorgen Grahn wrote:

> But that's a good thing! Not being able to find irrelevant things is
> a good thing.
> 
> More to the point, if you're scanning the header files looking for
> whatever, you don't want to find things which only concern the inner
> workings of one translation unit.

If each class is declared/defined in separate, dedicated source files then 
there is no need to employ any grep voodoo to ignore what is considered 
irrelevant when searching for any declaration/definition.  


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#12030

On Fri, 2011-12-02, Rui Maciel wrote:
> Jorgen Grahn wrote:
>
>> But that's a good thing! Not being able to find irrelevant things is
>> a good thing.
>> 
>> More to the point, if you're scanning the header files looking for
>> whatever, you don't want to find things which only concern the inner
>> workings of one translation unit.
>
> If each class is declared/defined in separate, dedicated source files then 
> there is no need to employ any grep voodoo to ignore what is considered 
> irrelevant when searching for any declaration/definition.  

Sorry, I don't understand your reasoning.  Can you give an example?
It seems to me that it's when you *do* move implementation details
into the header files that you have to employ "grep voodoo" to
eliminate some of the noise.

I have never tried to do it that way, but it feels like I would end up
with too much global information to keep track of -- things that would
normally be safely hidden away in an anonymous namespace.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#11897

On 28.11.2011 18:20, Christopher wrote:
> If you were on a team of developers that had little C++ experience,
> how would you go about explaining the reasoning as to why the
> following rules should be followed? (Or why they shouldn't)
>
> 1) Class defintions go in their own .h (or .hpp for templates) file
> named after the class
> 1a) Every class should have its own .h (or .hpp for templates) file

Instead of such mechanical rules, have a rule about clarity and possibly 
about testability.

Two or more classes may be strongly coupled and belong in the same header.

Many classes are just implementation details and do not deserve their 
own headers.


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

The "except" makes this rule self-contradictory.

Perhaps the author intended to write a rule about always making sure 
that a function definition in a header file is `inline`, whether 
explicitly or implicitly by being defined in a class definition.



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

That might help to reduce build times for a complex system.

But note that "complex" is an euphemism for "spaghetti".

Better, IMO, to instead avoid the spaghetti.


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

That's incredibly restricting.

For example, it would preclude the ordinary PIMPL idiom, or else force 
an extra header file for that.


> 3) One should not define multiple classes in a single .h file
> 3a) Nested class defintions should be avoided without good reason
> (what's good reason?)

These two rules contradict each other.


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

That's idiotic, it precludes defining constants.


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

It's a good idea to avoid global variables in general.

But this connection with .h files is meaningless.


> 8) Every .cpp file should compile into a .obj file without error or
> warning on its own.

Good idea, and I do agree, although many people disagree.

Those who disagree find it more work to structure the code so as to get 
rid of warnings, than to merely ignore the warnings, and they argue that 
it is futile to try to shut up future compiler versions.

For example, building the Boost library produces a lot of warnings.


>       i.e In Visual Studio, you should be able to right click a .cpp in
> the source tree and choose compile, without error or warning in the
> output.

Yes, I think that's a good ideal.

Also, with any compiler, remember to enable a higher warning level than 
default, but not so extreme as to be impractical.

For example, with Visual C++ use at least /W4, and with g++ use at least 
-Wall


> ----
>
> Sadly, I find myself having to justify these things. (of course
> someone might point out I am wrong or exceptions to the above), but
> these are things that I've always had drilled into my head throughout
> the years and have rarely come acorss other developers that didn't do
> the same.

Oh, you've been unfortunate.


> I am finding it frustrating to work on a project where 30
> classes defintions reside in the .h same .h file, a single .cpp file,
> or worse a precompiled header.

Yes, that's bad, but I think not solvable by mechanical rules that are 
just as bad (in the other direction).


> There is discussion, but I have to
> explain reasoning.
>
> So far, I've come up with the testability argument:
> When unit testing one frequently wants to test a single class. A proxy
> class may need to be created to test its protected or privare methods.
> Proxies may have to be created for its input and outputs. I should be
> able to include a single .h file, link in the appropriate .obj files
> and compile a unit test without the added clutter of satisfying
> includes or linkage needed by unrelated classes.
>
> I don't know what else to say aside from, "just do it, its the thing
> to do." and noone is going to buy that.

Cheers & hth.,

- Alf

[toc] | [prev] | [next] | [standalone]

#11900

On 28/11/2011 18:45, Alf P. Steinbach wrote:
> On 28.11.2011 18:20, Christopher wrote:
>
>> 6) Variables should never be defined in a .h file
>
> That's idiotic, it precludes defining constants.

Traditionally constants are called constants not variables.

/Leigh

[toc] | [prev] | [next] | [standalone]

#11903

On 28.11.2011 20:03, Leigh Johnston wrote:
> On 28/11/2011 18:45, Alf P. Steinbach wrote:
>> On 28.11.2011 18:20, Christopher wrote:
>>
>>> 6) Variables should never be defined in a .h file
>>
>> That's idiotic, it precludes defining constants.
>
> Traditionally constants are called constants not variables.

You got a point.

I was associating too strongly to formal terminology.


Cheers, & thanks,

- Alf

[toc] | [prev] | [next] | [standalone]

#11914

On Mon, 2011-11-28, Alf P. Steinbach wrote:
> On 28.11.2011 18:20, Christopher wrote:
>> If you were on a team of developers that had little C++ experience,
>> how would you go about explaining the reasoning as to why the
>> following rules should be followed? (Or why they shouldn't)
...

>> 1b) A .h file should never contain class implementation (except for
>> inline functions or methods)
>
> The "except" makes this rule self-contradictory.
>
> Perhaps the author intended to write a rule about always making sure 
> that a function definition in a header file is `inline`, whether 
> explicitly or implicitly by being defined in a class definition.

That still does not cover templates though. You may want to define
template classes, but not ask for inlining of everything.

...
>>       i.e In Visual Studio, you should be able to right click a .cpp in
>> the source tree and choose compile, without error or warning in the
>> output.
>
> Yes, I think that's a good ideal.
>
> Also, with any compiler, remember to enable a higher warning level than 
> default, but not so extreme as to be impractical.
>
> For example, with Visual C++ use at least /W4, and with g++ use at least 
> -Wall

I've mentioned it before, but IMHO -Wall is far from enough. I default
to

-Wall -Wextra -pedantic -std=c++98 -g -O3

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#11976

In article <slrnjd845a.1bk.grahn+nntp@frailea.sa.invalid>,
Jorgen Grahn  <grahn+nntp@snipabacken.se> wrote:
>On Mon, 2011-11-28, Alf P. Steinbach wrote:
>>
>> For example, with Visual C++ use at least /W4, and with g++ use at least 
>> -Wall
>
>I've mentioned it before, but IMHO -Wall is far from enough. I default
>to
>
>-Wall -Wextra -pedantic -std=c++98 -g -O3

You weakling! "Real Men" use:

-Wall -Wextra -pedantic -std=c++98 -Weffc++ -Wold-style-cast -Werror

:-)

[toc] | [prev] | [next] | [standalone]

#11978

Yannick Tremblay <yatremblay@bel1lin202.(none)> wrote:
> -Wall -Wextra -pedantic -std=c++98 -Weffc++ -Wold-style-cast -Werror

  Turning a bunch of warning flags and then making them errors is an
extremely dubious practice. Why? Because your program might compile
with one version of a compiler, but not with another, solely because
of the "-Werror" and without there being any real mistake in the program.
(It might also not compile with a different compiler which supports the
same flags. For example I think Intel's compiler supports most of the
same flags as gcc.)

  There's a relatively popular open source program whose main developers
had the odd principle that any official build must be built with every
single warning flag that they could find on the gcc documentation, plus
-Werror. This had the adverse side-effect that completely inconsequential
warnings, such as the compiler not being able to inline a function marked
as "inline" (and, IIRC, even if it was unable to inline a *template*
function) would cause the compilation to fail, even though there were no
mistakes whatsoever in the code.

  This completely idiotic principle caused that the program had to be,
basically, fine-tuned for a specific version of gcc. A newer or older
version of gcc with different optimization strategies could well decide
not to inline one of those functions, causing the program not to compile.
(And yes, this indeed was the case in practice.)

  I don't know if they still have this idiotic principle.

[toc] | [prev] | [next] | [standalone]

#11979

In article <4ed626aa$0$3099$7b1e8fa0@news.nbl.fi>,
Juha Nieminen  <nospam@thanks.invalid> wrote:
>Yannick Tremblay <yatremblay@bel1lin202.(none)> wrote:
>> -Wall -Wextra -pedantic -std=c++98 -Weffc++ -Wold-style-cast -Werror

Sorry, that was a <bad> joke, hence the smiley and the ""Real Men" use"

>  Turning a bunch of warning flags and then making them errors is an
>extremely dubious practice. Why? Because your program might compile
>with one version of a compiler, but not with another, solely because
>of the "-Werror" and without there being any real mistake in the program.
>(It might also not compile with a different compiler which supports the
>same flags. For example I think Intel's compiler supports most of the
>same flags as gcc.)
>
>  There's a relatively popular open source program whose main developers
>had the odd principle that any official build must be built with every
>single warning flag that they could find on the gcc documentation, plus
>-Werror. This had the adverse side-effect that completely inconsequential
>warnings, such as the compiler not being able to inline a function marked
>as "inline" (and, IIRC, even if it was unable to inline a *template*
>function) would cause the compilation to fail, even though there were no
>mistakes whatsoever in the code.
>
>  This completely idiotic principle caused that the program had to be,
>basically, fine-tuned for a specific version of gcc. A newer or older
>version of gcc with different optimization strategies could well decide
>not to inline one of those functions, causing the program not to compile.
>(And yes, this indeed was the case in practice.)
>
>  I don't know if they still have this idiotic principle.

So seriously:

I don't use -Werror however I use a policy that normally, all warnings
should be silenced.  Warnings oftens indicate real bugs, if the code
compile with hundreds of warning, peoples stop reading them.

-Werror is certainly unacceptable for code that is distributed in
 source format and expected to build in various environment.  However,
 in a closed source environment where that build environment changes
 either never or very rarely, this could be used as a way to enforce
 silencing warning.  I prefer a more diplomatic approach.  

I generally get on with -Wextra.  -Weffc++ is very hard to follow all
of the time in a large project.  In particular third party headers
tend to raise a lot of warnings.  I've never managed to get on with
-pedantic on a large project either.  It just tend to generate too
many warnings and warnings loose value due to noise. 

Yannick

[toc] | [prev] | [next] | [standalone]

#11980

Yannick Tremblay <yatremblay@bel1lin202.(none)> wrote:
> I don't use -Werror however I use a policy that normally, all warnings
> should be silenced.  Warnings oftens indicate real bugs, if the code
> compile with hundreds of warning, peoples stop reading them.

  That's certainly true. My point was, however, that not all warning flags
are indicative of (potential) errors in the code (nor even bad practice).
Some of them are purely informative (such as the warning that an inline
function couldn't be inlined).

  (Turn on enough warning flags and even the standard libraries will start
issuing warnings.)

  In other words, you should choose your warning flags carefully.

[toc] | [prev] | [next] | [standalone]

#11984

On Wed, 2011-11-30, Juha Nieminen wrote:
> Yannick Tremblay <yatremblay@bel1lin202.(none)> wrote:
>> -Wall -Wextra -pedantic -std=c++98 -Weffc++ -Wold-style-cast -Werror
>
>   Turning a bunch of warning flags and then making them errors is an
> extremely dubious practice. Why? Because your program might compile
> with one version of a compiler, but not with another, solely because
> of the "-Werror" and without there being any real mistake in the program.
> (It might also not compile with a different compiler which supports the
> same flags. For example I think Intel's compiler supports most of the
> same flags as gcc.)
>
>   There's a relatively popular open source program whose main developers
> had the odd principle that any official build must be built with every
> single warning flag that they could find on the gcc documentation, plus
> -Werror. This had the adverse side-effect that completely inconsequential
> warnings, such as the compiler not being able to inline a function marked
> as "inline" (and, IIRC, even if it was unable to inline a *template*
> function) would cause the compilation to fail, even though there were no
> mistakes whatsoever in the code.

We do this in a project, and I agree: -Werror sucks. I've lost many
weeks[1] to warnings about unused parameter/functions/variables, and
it also affects code quality negatively since people start writing
strange code to avoid the warnings-become-errors.  That we are heavily
#ifdefed doesn't help either.

Two things though:

- In absence of people who feel responsible to keep the number of
  serious warnings down, -Werror can save the code. But then you have
  a more fundamental problem ...

- In recent gcc releases you can selectively make warnings fatal or
  not -- so you can e.g. get warnings for unused functions and fatal
  errors for bad printf formatting strings.

/Jorgen

[1] Counting nightly builds which failed due to a harmless warning,
    and had to be rescheduled for the next night.


-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c++

csiph-web