[vdr] Re: minor code clean-up / suggestion for more

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

"Prakash K. Cheemplavam" wrote:
> 
> Klaus Schmidinger schrieb:
> > "Prakash K. Cheemplavam" wrote:
> 
> >>Whiel I am at it. I tried to compile VDR using -pedantic and saw that
> >>vdr usus a lot of gnu c++ features. Wouldn't it be preferable to try to
> >>clean up the source to use strict iso c++ conformance? GCC with each
> >>version gets stricter to iso, so I guess this would be the right
> >>direction to go.
> >>
> >>What do you think Klaus? If you think it is a good idea, I could start
> >>working on it, as currently I am a bit bored. ;-)
> >
> >
> > Well, before starting a monster patch for this, maybe you could point
> > out what exactly you are referring to.
> 
> In fact I wrote everything above. vdr uses gnu extensions to iso c++.

Well, I saw that - I was just wondering if you could be a little more
specific as to what that would exactly be.

> Of course you are free to do so, but this limits vdr to using gnu gcc. As I
> said gcc will slowly drop those extensions by first marking thing
> depreciated and then erroring out. I am not sure whether all of gnu
> extensions are going to be dropped, of course.

I suggest we cross that bridge when we get there. As long as the compilers
actually used work, I see no need to change anything.

> >>Another thing: What about incorporating the new gcc visibility stuff?
> >>
> >>See: http://www.nedprod.com/programs/gccvisibility.html
> >>
> >>Using it (properly) wouldn't break anything but take advantage of newer
> >>compilers. Gentoo's gcc 3.4.2 already uses the visibility patch and gcc
> >>4 will have it by default.
> >
> >
> > What exactly would be the benefit of this for VDR?
> 
> Smaller binaries (less exported smbols)

A stripped VDR executable is just about 1.3MB in size - not really an issue.

> and faster starting times (esp with lot of plugins).

Well, its' not like you start/stop VDR at such a high rate that this
would make much of a difference, do you?

> In fact the symbol visibility thing should have
> been there right from the start. You could say in windows it is the same
> principle as defining the dll exports and imports.
> 
> Of course using the visibility stuff on vdr alone won't help, but the
> plugins should do this as well. In the end the API should also look
> cleaner as one can easily say, what can (should) be accessed from
> outside of VDR and what not.

Again, as long as nothing goes wrong, there's no need for any activity
in that direction. There are far more important things to do...

> >>diff -Nurd vdr-1.3.13.o/sources.h vdr-1.3.13/sources.h
> >>--- vdr-1.3.13.o/sources.h      2004-01-11 11:35:36.000000000 +0100
> >>+++ vdr-1.3.13/sources.h        2004-10-23 12:26:01.277157848 +0200
> >>@@ -21,7 +21,7 @@
> >>      stTerr  = 0xC000,
> >>      st_Mask = 0xC000,
> >>      st_Neg  = 0x0800,
> >>-    st_Pos  = 0x07FF,
> >>+    st_Pos  = 0x07FF
> >
> >
> > This is intentional. That way, if a new one has to be added, no existing
> > line needs to be touched.
> 
> But not iso-c++... I think you won't like the idea of strict iso-c++, as
> it takes away a bit of comfort from you. ;-)

Well, I guess there will be an option to turn those checks off ;-)

Klaus