[Ffmpeg-devel] [PATCH] GUID is defined in the Windows API (DirectShow)
Wed Mar 1 21:51:17 CET 2006
On Wed, Mar 01, 2006 at 02:31:48PM -0600, Brian Brice wrote:
> Rich Felker wrote:
> >On Wed, Mar 01, 2006 at 08:24:07AM +0000, M?ns Rullg?rd wrote:
> >>Steve Lhomme <slhomme at divxcorp.com> writes:
> >>>Michael Niedermayer wrote:
> >>>>On Tue, Feb 28, 2006 at 03:33:07PM -1000, Steve Lhomme wrote:
> >>>>>...so this patch renames libavformat's GUID to wGUID. Feel free to
> >>>>>rename it to something better if you need.
> >>>>#define GUID microsuck_GUID
> >>>>around the #inlcude
> >>>>or something similar
> >>>Impossible, I use the "real" GUID definition in my code too.
> >>So replace all your GUID uses with microsuck_GUID too.
> >Exactly. Or better yet... LEARN HOW TO FUCKING WRITE MODULAR CODE.
> >There is no reason that your code using windows GUIDs should be in the
> >same file as code using lavc. If it is you need to go back to school
> >and learn a bit about software engineering rather than studying the MS
> Wowsa.. I also found that the use of namespaces is good. Since Steve is
> using C++, you can wrap the ffmpeg headers in their own namespace or
> anything else you want. I had some name comflicts with my project and
> some identifiers coming in from avformat.h, and this easily fixed it.
A namespace is not even needed. This is INTERNAL lavf code that should
never be included in the same file as windows stuff or any of Steve's
code. The only way it could have gotten together is if he:
a) incorrectly used lavf-internal headers in his code. OR
b) hacked lavf to use windows/directshow stuff internally.
The latter is blatently wrong and I'm not even sure if it's
LGPL-compatible. (A somewhat technical issue of code using the library
versus extending the library itself, I think.)
More information about the ffmpeg-devel