CVS: main/libmpdemux demux_mkv.cpp,1.2,1.3
Update of /cvsroot/mplayer/main/libmpdemux In directory mail:/var/tmp.root/cvs-serv22723 Modified Files: demux_mkv.cpp Log Message: Fixes for gcc 3.2 Index: demux_mkv.cpp =================================================================== RCS file: /cvsroot/mplayer/main/libmpdemux/demux_mkv.cpp,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- demux_mkv.cpp 30 Apr 2003 18:35:16 -0000 1.2 +++ demux_mkv.cpp 30 Apr 2003 19:35:28 -0000 1.3 @@ -1150,12 +1150,12 @@ mp_msg(MSGT_DEMUX, MSGL_V, "[mkv] | + Default flag: %u\n", track->default_track); - } else if ((EbmlId(*l3) != - KaxTrackFlagLacing::ClassInfos.GlobalId) && - (EbmlId(*l3) != - KaxTrackMinCache::ClassInfos.GlobalId) && - (EbmlId(*l3) != - KaxTrackMaxCache::ClassInfos.GlobalId)) + } else if ((!(EbmlId(*l3) == + KaxTrackFlagLacing::ClassInfos.GlobalId)) && + (!(EbmlId(*l3) == + KaxTrackMinCache::ClassInfos.GlobalId)) && + (!(EbmlId(*l3) == + KaxTrackMaxCache::ClassInfos.GlobalId))) mp_msg(MSGT_DEMUX, MSGL_V, "[mkv] | + unknown element@3: " "%s\n", typeid(*l3).name());
On Wed, 30 Apr 2003 21:35:59 +0200 Moritz Bunkus CVS <mosu@mplayerhq.hu> wrote:
- } else if ((EbmlId(*l3) != - KaxTrackFlagLacing::ClassInfos.GlobalId) && - (EbmlId(*l3) != - KaxTrackMinCache::ClassInfos.GlobalId) && - (EbmlId(*l3) != - KaxTrackMaxCache::ClassInfos.GlobalId)) + } else if ((!(EbmlId(*l3) == + KaxTrackFlagLacing::ClassInfos.GlobalId)) && + (!(EbmlId(*l3) == + KaxTrackMinCache::ClassInfos.GlobalId)) && + (!(EbmlId(*l3) == + KaxTrackMaxCache::ClassInfos.GlobalId))) mp_msg(MSGT_DEMUX, MSGL_V, "[mkv] | + unknown element@3: " "%s\n", typeid(*l3).name());
Could it be that == is overloaded ? Otherwise i cant imagine why != should not work Attila Kinali -- Emacs ist für mich kein Editor. Für mich ist das genau das gleiche, als wenn ich nach einem Fahrrad (für die Sonntagbrötchen) frage und einen pangalaktischen Raumkreuzer mit 10 km Gesamtlänge bekomme. Ich weiß nicht, was ich damit soll. -- Frank Klemm, de.comp.os.unix.discussion
On Sat, May 10, 2003 at 12:04:21PM +0200, Attila Kinali wrote:
On Wed, 30 Apr 2003 21:35:59 +0200 Moritz Bunkus CVS <mosu@mplayerhq.hu> wrote:
- } else if ((EbmlId(*l3) != - KaxTrackFlagLacing::ClassInfos.GlobalId) && - (EbmlId(*l3) != - KaxTrackMinCache::ClassInfos.GlobalId) && - (EbmlId(*l3) != - KaxTrackMaxCache::ClassInfos.GlobalId)) + } else if ((!(EbmlId(*l3) == + KaxTrackFlagLacing::ClassInfos.GlobalId)) && + (!(EbmlId(*l3) == + KaxTrackMinCache::ClassInfos.GlobalId)) && + (!(EbmlId(*l3) == + KaxTrackMaxCache::ClassInfos.GlobalId))) mp_msg(MSGT_DEMUX, MSGL_V, "[mkv] | + unknown element@3: " "%s\n", typeid(*l3).name());
Could it be that == is overloaded ? Otherwise i cant imagine why != should not work
If this is true, I rest my case that the Matroska developers are idiots.... Rich
On Sat, 10 May 2003 19:39:33 -0400 D Richard Felker III <dalias@aerifal.cx> wrote:
If this is true, I rest my case that the Matroska developers are idiots....
Why ? Operator overloading is one of the best features of C++. it makes the code much more readable if you have to handle complex objects. Attila Kinali -- Emacs ist für mich kein Editor. Für mich ist das genau das gleiche, als wenn ich nach einem Fahrrad (für die Sonntagbrötchen) frage und einen pangalaktischen Raumkreuzer mit 10 km Gesamtlänge bekomme. Ich weiß nicht, was ich damit soll. -- Frank Klemm, de.comp.os.unix.discussion
On Sun, May 11, 2003 at 12:48:52PM +0200, Attila Kinali wrote:
On Sat, 10 May 2003 19:39:33 -0400 D Richard Felker III <dalias@aerifal.cx> wrote:
If this is true, I rest my case that the Matroska developers are idiots....
Why ? Operator overloading is one of the best features of C++. it makes the code much more readable if you have to handle complex objects.
IMO it makes code unreadably confusing, at least when you overload certain operators. Even worse still is when you overload == but not !=, + but not +=, etc. so that it's inconsistent! Rich
Hi,
On Sun, May 11, 2003 at 12:48:52PM +0200, Attila Kinali wrote:
On Sat, 10 May 2003 19:39:33 -0400 D Richard Felker III <dalias@aerifal.cx> wrote:
If this is true, I rest my case that the Matroska developers are idiots....
Why ? Operator overloading is one of the best features of C++. it makes the code much more readable if you have to handle complex objects.
IMO it makes code unreadably confusing, at least when you overload certain operators. Even worse still is when you overload == but not !=, + but not +=, etc. so that it's inconsistent!
Not talking about the case if you redefine == to behave as != and vice versa :) A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu
Hi! Actually, you can write comprehensible code in c++ too - that of course is just one of your options. bye Denes
Why ? Operator overloading is one of the best features of C++. it makes the code much more readable if you have to handle complex objects.
IMO it makes code unreadably confusing, at least when you overload certain operators. Even worse still is when you overload == but not !=, + but not +=, etc. so that it's inconsistent!
Not talking about the case if you redefine == to behave as != and vice versa :)
A'rpi / Astral & ESP-team
On Sun, 11 May 2003 21:47:30 +0200 Arpi <arpi@thot.banki.hu> wrote:
Not talking about the case if you redefine == to behave as != and vice versa :)
What about #define add(a,b) a-b #define sub(a,b) a+b :) Attila Kinali -- Emacs ist für mich kein Editor. Für mich ist das genau das gleiche, als wenn ich nach einem Fahrrad (für die Sonntagbrötchen) frage und einen pangalaktischen Raumkreuzer mit 10 km Gesamtlänge bekomme. Ich weiß nicht, was ich damit soll. -- Frank Klemm, de.comp.os.unix.discussion
On Sun, 2003-05-11 at 21:47, Arpi wrote:
D Richard Felker III <dalias@aerifal.cx> wrote:
If this is true, I rest my case that the Matroska developers are idiots....
Why ? Operator overloading is one of the best features of C++. it makes the code much more readable if you have to handle complex objects.
IMO it makes code unreadably confusing, at least when you overload certain operators. Even worse still is when you overload == but not !=, + but not +=, etc. so that it's inconsistent!
sorry, but it seems to me that you simply don't like C++, and won't accept anything as good in C++. i overloaded == a zillion times.. i find it much cleaner to write: if (obj1 == obj2) {} than if(obj1.equals(obj2)) or if(equals(obj1,obj2)); of course there are some pros and cons for this, but afaik that's the same with the use of macros, don't you think? gabor
On Sunday 11 May 2003 20:21, D Richard Felker III wrote:
On Sun, May 11, 2003 at 12:48:52PM +0200, Attila Kinali wrote:
On Sat, 10 May 2003 19:39:33 -0400
D Richard Felker III <dalias@aerifal.cx> wrote:
If this is true, I rest my case that the Matroska developers are idiots....
Why ? Operator overloading is one of the best features of C++. it makes the code much more readable if you have to handle complex objects.
IMO it makes code unreadably confusing, at least when you overload certain operators. Even worse still is when you overload == but not !=, + but not +=, etc. so that it's inconsistent!
I must admit that operator overloading is not easy to handle, but it really has nice uses eg. when working with complex numbers. Anyways you can't compare C to C++ as they have different uses. C is used for system near programing with high level of code control, while C++ is good for abstracting processes and data giving an easy to use/human friendly api for accessing those from other places without needing to know stuff about the coding internas. Eg. I prefer object oriented approaches for bigger database driven projects, where code speed doesn't play a primary role. In such case I can have an object keeping track of my database connections and associated data without me needing to keep an eye when to open or close a connection etc. For time critic or system near stuff of course C is the best choice, juiced up with asm where needed. So I think both object oriented and non-object oriented languages have their use, only in different areas.
Rich
-- Best Regards, Atmos ____________________________________________ - MPlayer Developer - http://mplayerhq.hu/ - ____________________________________________
On Thu, May 15, 2003 at 12:45:24AM +0200, Felix Buenemann wrote:
On Sunday 11 May 2003 20:21, D Richard Felker III wrote:
On Sun, May 11, 2003 at 12:48:52PM +0200, Attila Kinali wrote:
On Sat, 10 May 2003 19:39:33 -0400
D Richard Felker III <dalias@aerifal.cx> wrote:
If this is true, I rest my case that the Matroska developers are idiots....
Why ? Operator overloading is one of the best features of C++. it makes the code much more readable if you have to handle complex objects.
IMO it makes code unreadably confusing, at least when you overload certain operators. Even worse still is when you overload == but not !=, + but not +=, etc. so that it's inconsistent!
I must admit that operator overloading is not easy to handle, but it really has nice uses eg. when working with complex numbers. Anyways you can't compare C to C++ as they have different uses. C is used for system near programing with high level of code control, while
Yes.
C++ is good for abstracting processes and data giving an easy to use/human friendly api for accessing those from other places without needing to know stuff about the coding internas.
No, a good object oriented language is good for this, as is a very high level language. ocaml comes to mind, and python is prolly ok too for more script/prototyping type tasks. IMO C++ is not good for anything. It's just the worst of both worlds...
Eg. I prefer object oriented approaches for bigger database driven projects, where code speed doesn't play a primary role. In such case I can have an object keeping track of my database connections and associated data without me needing to keep an eye when to open or close a connection etc.
I agree here. Object oriented languages have their place where, and ONLY WHERE, data is the center of focus. When the process is the center of focus, a procedural language makes sense. Trying to make procedures into objects (with a few settings to control their behavior as the 'data' for the class) is nonsense! Rich
On Thu, 2003-05-15 at 05:49, D Richard Felker III wrote:
Eg. I prefer object oriented approaches for bigger database driven projects, where code speed doesn't play a primary role. In such case I can have an object keeping track of my database connections and associated data without me needing to keep an eye when to open or close a connection etc.
I agree here. Object oriented languages have their place where, and ONLY WHERE, data is the center of focus. When the process is the center of focus, a procedural language makes sense. Trying to make procedures into objects (with a few settings to control their behavior as the 'data' for the class) is nonsense!
could you describe this more? i mean for example in the case of mplayer the process is in the center of focus? one could say that mplayer is manipulating with video data, and because of that, mplayer is an application with data in the center of focus. in my experiences, problems can be solved usually as well in procedural as in object oriented way. (of course i'm not talking about very small problems). gabor
Hi!
I agree here. Object oriented languages have their place where, and ONLY WHERE, data is the center of focus. When the process is the center of focus, a procedural language makes sense. Trying to make procedures into objects (with a few settings to control their behavior as the 'data' for the class) is nonsense!
afaik (one of) the aims of c++ is that eg. if you have modules in a player, they can inherit the same super-class, and than if you change something in the moduleloading/info structures you only have to change it in one place (the super-class), and than one small change in the api won't give you 1 hour work. Also if eg. a module has a priv struct, that basicly means you are emulating objects in c - to me at least. sure it might not be so efficient in some areas, but an oop language's compiler usually does lot of the work of the human (and is less error prone) if you use the language features wisely. best regards Denes
On Thu, May 15, 2003 at 03:52:12PM +0200, Balatoni Denes wrote:
Hi!
I agree here. Object oriented languages have their place where, and ONLY WHERE, data is the center of focus. When the process is the center of focus, a procedural language makes sense. Trying to make procedures into objects (with a few settings to control their behavior as the 'data' for the class) is nonsense!
afaik (one of) the aims of c++ is that eg. if you have modules in a player, they can inherit the same super-class, and than if you change something in the moduleloading/info structures you only have to change it in one place (the super-class), and than one small change in the api won't give you 1 hour work. Also if eg. a module has a priv struct, that basicly means you are emulating objects in c - to me at least.
sure it might not be so efficient in some areas, but an oop language's compiler usually does lot of the work of the human (and is less error prone) if you use the language features wisely.
This is OO propeganda -- nice in theory, but not something I've ever observed in reality. Rich
participants (7)
-
Arpi -
Attila Kinali -
Balatoni Denes -
D Richard Felker III -
Felix Buenemann -
gabor -
Moritz Bunkus CVS