[MPlayer-cvslog] CVS: main/libao2 afmt.c, 1.7, 1.8 afmt.h, 1.8, 1.9 ao_alsa.c, 1.9, 1.10 ao_alsa5.c, 1.19, 1.20 ao_arts.c, 1.8, 1.9 ao_dsound.c, 1.3, 1.4 ao_dxr2.c, 1.7, 1.8 ao_esd.c, 1.7, 1.8 ao_jack.c, 1.4, 1.5 ao_macosx.c, 1.5, 1.6 ao_mpegpes.c, 1.20, 1.21 ao_nas.c, 1.15, 1.16 ao_oss.c, 1.44, 1.45 ao_pcm.c, 1.21, 1.22 ao_plugin.c, 1.25, 1.26 ao_polyp.c, 1.1, 1.2 ao_sdl.c, 1.37, 1.38 ao_sgi.c, 1.7, 1.8 ao_sun.c, 1.29, 1.30 ao_win32.c, 1.16, 1.17 audio_out.c, 1.44, 1.45

[Aurelien Jacobs]

On Tue, 7 Dec 2004 22:47:51 -0500
D Richard Felker III <dalias at aerifal.cx> wrote:

> On Tue, Dec 07, 2004 at 03:48:18PM +0100, Aurelien Jacobs wrote:
> > On Tue, 7 Dec 2004 12:20:55 +0100
> > Felix Buenemann <atmosfear at users.sourceforge.net> wrote:
> > 
> > > On Tuesday 07 December 2004 10:05, Reimar Döffinger wrote:
> > > > Hi,
> > > >
> > > > > Modified Files:
> > > > >  afmt.c afmt.h ao_alsa.c ao_alsa5.c ao_arts.c ao_dsound.c
> > > > >  ao_dxr2.c ao_esd.c ao_jack.c ao_macosx.c ao_mpegpes.c
> > > > >  ao_nas.c ao_oss.c ao_pcm.c ao_plugin.c ao_polyp.c ao_sdl.c
> > > > >  ao_sgi.c ao_sun.c ao_win32.c audio_out.c
> > > > > Log Message:
> > > > > Make include paths consistent.
> > > >
> > > > So you didn't yet remove the double config.h includes.
> > > > But there is another thing I saw: nearly all modules that
> > > > include mp_msg.h include help_msg.h as well. And even those that
> > > > don't should do it IMHO as it makes translating easier. So my
> > > > suggestions is: make mp_msg.h include help_msg.h, and remove all
> > > > (except a few in the Gui) includes of help_msg.h. What do you
> > > > think about that?
> > > One common rule of thumb by arpi says, never include include-files
> > > from within include files...
> > 
> > Huh ! I really wonder why ? I guess there is a good reason for this
> > but I can't see one.
> > 
> > For example with a.h using a type defined in b.h, this mean that
> > every .c files including a.h also need to include b.h. And this
> > mean that developpers who include a.h somewhere need to know that
> > he have to include b.h. This also mean that if someone add a
> > declaration in a.h using a type in c.h, all the .c files using
> > a.h will have to be modified to also include c.h.
> > 
> > I really can't see the whole purpose of all this redondancy and
> > complexity ?
> 
> otherwise you'll often have the same header included many times, and
> the compiler has to parse the whole damn thing each time...

If all the headers are well included in #ifdef FILENAME_H, the compiler
won't have to parse them multiple times ! Only the preprocessor will
do it. And I guess this won't slow down things noticeably, but I don't
have actual numbers so I can't tell for sure. Anyone with numbers ?

BTW: not including headers into headers don't prevent mutiple includes,
Diego just removed some config.h duplicate include ;-)

Aurel