M?ns Rullg?rd wrote:
> Diego Biurrun <diego at biurrun.de> writes:
>
>
>> On Sat, Jan 27, 2007 at 08:45:43AM +0100, Diego Biurrun wrote:
>>
>>> On Fri, Jan 26, 2007 at 10:23:34AM +0100, Michael Niedermayer wrote:
>>>
>>>> On Fri, Jan 26, 2007 at 05:15:07AM +0100, Diego Biurrun wrote:
>>>>
>>>>> On Fri, Jan 26, 2007 at 01:24:39PM +1030, Yuri Vilmanis wrote:
>>>>>
>>>>>> Removed some dead code relating to C++. As no part of the codebase
>>>>>> will ever be seen by a C++ compiler, any code protected by
>>>>>> #ifdef__cplusplus will *never* get past the preprocessor, and so can
>>>>>> be safely removed. The files in which these guards appear are not
>>>>>> valid C++ anyway, so removing these references to C++ should reduce
>>>>>> future confusion on this issue. The C++ wrapper "fobs" (or other
>>>>>> C++ wrappers I'm not aware of) can be used by anyone requiring C++
>>>>>> support.
>>>>>>
>>>>> OK to apply this patch?
>>>>>
>>>> all the versions should be bumped a little at least so user apps
>>>> could detect if these macros are there or not
>>>>
>>>> now about the patch itself, i have no real oppinion on this, it where
>>>> c++ people who wanted it, and now its one c++ developer who wants it
>>>> removed, i think that the people who wanted this (see svnlog i dont
>>>> remember at all) should at least get a chance to comment first
>>>>
>>> Opinions are (unsurprisingly) mixed.
>>>
>>> I agree that we should have this either on all or none of our public
>>> header files and I vote for removing it everywhere for consistency.
>>> Baptiste and Reimar seem to be with me on this one.
>>>
>> Michael? Mans?
>>
>
> Well, I personally never use C++, so I wouldn't mind it being
> removed. It's not pretty, and it doesn't play nicely with emacs'
> automatic indentation.
>
OK, my assertion that it will "never be seen by a C++ compiler" may have
been a touch overstated, but is essentially the point. This patch should
not have a large impact on practical C++ usage though: if the C++
compiler being used by client software has access to inttypes.h (and/or
whatever other C99 headers are required) then the client code can simply
put the extern declaration around the includes, along the lines of:
extern "C" {
#include <avutil.h>
#include <avcodec.h>
#include <avformat.h>
}
Which will give the same behaviour as before the patch. The only
difference here is that the problem of whether the headers will work
with a particular C++ compiler now becomes the explicit responsibility
of the client software (where the decision was made to include C99
headers in a C++ program), not something which is implied to work
without additional support. This essentially removes the only valid
reason for people wanting 'inttypes.h emulation', clarifies that the
headers are C (not C++), and makes the headers a bit cleaner. Waiting
for a version number increment sounds like a good idea though, as this
patch will of course break linkage in C++ client code which doesn't have
its own extern "C" {}.
- Yuri
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4