[MPlayer-cvslog] r18990 - trunk/libmpdemux/demux_lavf.c

[Diego Biurrun]

On Mon, Jul 10, 2006 at 11:21:05AM -0400, Rich Felker wrote:
> On Mon, Jul 10, 2006 at 04:52:40PM +0200, Diego Biurrun wrote:
> > On Mon, Jul 10, 2006 at 10:27:24AM -0400, Rich Felker wrote:
> > > On Mon, Jul 10, 2006 at 07:16:00AM +0300, Uoti Urpala wrote:
> > > > On Mon, 2006-07-10 at 04:53 +0200, rfelker wrote:
> > > > > Log:
> > > > > more c++ decl crap
> > > > 
> > > > It's not C++, as you should well know. It's C, as opposed to legacy C
> > > 
> > > It's called C++ declarations for the same reason // comments are
> > > called C++ comments.
> > > 
> > > > with workarounds for broken compilers. Seems nobody else had tried
> > > > compiling with gcc 2.95 for 3 weeks. Time to drop support for it I
> > > > think.
> > > 
> > > No, absolutely not. If you continue with such trolling I will
> > > fight to have you removed from development. gcc3 generates SLOWER CODE
> > > than gcc 2.95 and gcc 4 DOES NOT COMPILE on machines with less than
> > > several gigs of virtual memory. Thus 2.95 is the only option.
> > 
> > gcc 3.4 does not generate slower code than 2.95, it just takes far
> > longer but the end result is slightly faster.  Look up the numbers I
> > generated ages ago.
> 
> Perhaps I will sometime. Still >double compile time is a ridiculous
> price to pay for "slightly" faster, and I doubt it's faster on all
> cpus even if it is on our K6-IIIs.

IIRC it's a 40% increase in compile time.

> > Now stop this useless flamage.
> 
> I propose the following. Either Uoti stop committing broken code, or
> send me a patch to gcc 2.95's parser to make it accept C++ style
> declarations.

Yes, Uoti needs to avoid this.  It's always been our policy to avoid
C++-style declarations.

Diego