Current state of libbluray?

[trojanfoe]

Hi there, I am very interested in working on libbluray (http://www.assembla.com/spaces/bdplus) but there doesn't seem to have been much activity lately. Is this the best place to start or are there alternative projects that are better to start with?

[GLUBSCH]

It certainly LOOKS dead, buddy...

[froggy1]

there are no "external" bluray projects at the moment. If you want to take libbluray and go from there then you could, but please do it in C and not C++

[stax76]

Why not C++?

[froggy1]

Why not C++?

Because it is ridiculous for a library on Linux, especially since most multimedia libs are C (libmp3lame, libxvid, libx264, libtheora, etc) and both ffmpeg and mplayer dislike linking to C++ libs (or having much C++ code in them directly). Ask Mans Rullgard (mru on IRC in #ffmpeg-devel) and he'll preach to you all night why it isn't good

[cogman]

Because it is ridiculous for a library on Linux, especially since most multimedia libs are C (libmp3lame, libxvid, libx264, libtheora, etc) and both ffmpeg and mplayer dislike linking to C++ libs (or having much C++ code in them directly). Ask Mans Rullgard (mru on IRC in #ffmpeg-devel) and he'll preach to you all night why it isn't good

I was going to retort, but then I thought "How would C++'s features benefit someone writing a multimedia library" And I came up with nothing. The most I could see is easier threading and the STL is nice to use. However, because multimedia applications explicitly work with the individual bits, It is kind of hard to use a OOP paradigm.

The most benefit I could see would be in something like a thread pool.

[The Herminator]

However, because multimedia applications explicitly work with the individual bits, It is kind of hard to use a OOP paradigm.

Then don't write using the OOP paradigm. There is nothing to stop you from using C++ as an improved C to write procedural programs. Then just the extern "c" construct and you're fine with C code calling your library.

[The Herminator]

Because it is ridiculous for a library on Linux, especially since most multimedia libs are C (libmp3lame, libxvid, libx264, libtheora, etc) and both ffmpeg and mplayer dislike linking to C++ libs (or having much C++ code in them directly). Ask Mans Rullgard (mru on IRC in #ffmpeg-devel) and he'll preach to you all night why it isn't good

Yeah and before 1973 when Unix was rewritten into C, people used to say that writing an OS in anything but assembly was ridiculous to do. If the C++ library is written using the extern "C" construct and makes sure not to do anything that might cause incompatibility issues, what does it matter to any of the C calling code? This seems to be nothing more than long-standing bias of the programmers rather than anything of a technical merit.

[froggy1]

Yeah and before 1973 when Unix was rewritten into C, people used to say that writing an OS in anything but assembly was ridiculous to do. If the C++ library is written using the extern "C" construct and makes sure not to do anything that might cause incompatibility issues, what does it matter to any of the C calling code? This seems to be nothing more than long-standing bias of the programmers rather than anything of a technical merit.

Does it offer any advantages? If so, then why don't you go rewrite x264 or libxvid or any other lib in it?

Also, I don't know if libbluray offers any C interface so C apps can link to it. If it doesn't then that's really ridiculous

[The Herminator]

Does it offer any advantages?

Yes, it can offer advantages depending on what you want to do. Having access to things like auto_ptr, vectors, and the numerous other extensions are nice depending on what you are doing. Obviously if what you are doing doesn't require those things, then, sure, plain C might just be fine.

If so, then why don't you go rewrite x264 or libxvid or any other lib in it?

Why don't I rewrite those things? Because I don't care to do so and even if I did want them compiled as a C++ library one wouldn't have to rewrite them entirely to make them compilable C++ code. Secondly, this type of argument isn't very persuasive in showing that exclusion of C++ isn't just due to the bias of the programmers in the project. If you can provide actual technical reasons why one shouldn't write a library in C++ then please provide them.

Also, I don't know if libbluray offers any C interface so C apps can link to it. If it doesn't then that's really ridiculous

Then just mark the functions you want to call from C code as extern "C" and recompile. It's ridiculously easy to do.

[froggy1]

I guess the biggest problem for current C++ is that it does not provide features for creating multithreaded software, which is kinda the standard now for multimedia apps, especially libs. It can be achieved but at cost of complexity and possible portability concerns/issues. This will be addressed in the upcoming C++0x standard though. Still, even with this, I would prefer plain C not because I'm "biased" (I currently don't program in neither one of those) but having played with them, I find plain C easier than C++. Some would also argue that C++ is too bloated and of course, it has a longer compile time

[The Herminator]

I guess the biggest problem for current C++ is that it does not provide features for creating multithreaded software, which is kinda the standard now for multimedia apps, especially libs.

And neither does C natively either. If you want multithreaded C++ apps use either pthreads or the threading library provided by boost. If this is the "biggest problem" you can think of it's completely bogus since this exact same "problem" exists in C as well.

It can be achieved but at cost of complexity and possible portability concerns/issues.

What portability and complexity issues? Boost libraries and pthreads are cross-platform.


This will be addressed in the upcoming C++0x standard though. Still, even with this, I would prefer plain C not because I'm "biased" (I currently don't program in neither one of those) but having played with them, I find plain C easier than C++.

So then you admit there is no real technical reason for its exclusion.

Some would also argue that C++ is too bloated and of course, it has a longer compile time

Yeah, sure. One can write equivalent programs compiled as C and C++ and the difference size is negligible (I'd wager to guess that no more than 5% difference at the extreme which at the size of the most of the libraries you mention would be in the 10s of KB difference which is hardly some huge amount of bloat). Secondly, longer compile times? Like what? A few extra seconds, maybe? Oh no! If you have some real figures showing huge amounts of size difference and compile time between equivalent programs (and yes they have to be equivalent programs otherwise it's a meaningless comparison as everyone knows that there is overhead to using classes over just writing normal procedural code) compiled between the two I'd love to see it since I don't take your word for it.

It's fine if your preference is to use C over C++ but don't make up bogus excuses as if they are going to be convincing to anyone who can see write through it.

[froggy1]

I think you just registered here to promote C++ since all your posts were about it in this thread. As I said, I don't do much C nor C++ development and my knowledge is limited so if I'm incorrect, anyone is more than welcome to correct me. There must be a reason, however, why most prefer plain C (even if they know C++) for libs instead of C++ and it's hard for me to take your claims due to all being biased

[The Herminator]

I think you just registered here to promote C++ since all your posts were about it in this thread.

No, I didn't and I've made a post in the audio encoding forum. It's really a poor sign though that you can't dispute my points but try to attack me with irrelevant statements.

As I said, I don't do much C nor C++ development and my knowledge is limited so if I'm incorrect, anyone is more than welcome to correct me.

It's quite clear that you don't know much about them since what you say is mostly outright false or stretching the truth quite hardily.

There must be a reason, however, why most prefer plain C (even if they know C++) for libs instead of C++ and it's hard for me to take your claims due to all being biased

So then enumerate those reasons that are based on actual technical reasons and not made up crap like your claim about C++ and threading. Secondly, I don't have a bias against C as I use it far more than I ever do C++. But your bias, on the other hand, is quite clear and it's based not on anything of a technical merit but some random crap you make up.

[The Herminator]

And the reason why they most likely use C is because that is probably what they are most familiar with and have been using the longest. Which is perfectly fine personal reason for them to do so but that isn't a technical argument. That also doesn't mean there is no merit to writing a library in C++ since it's just perfectly fine to be callable from other C code when compiled with the extern "C" construct. Libflac for example has a C++ api for using the library and it's not the only project to create such a thing. But there is no logical flow from your claim of "X people write their libraries in C" to "No one should write a library in C++".

[froggy1]

LOL, where did I attack you or wrote words like "crap" and such? Obviously, you're doing it not me. As I said, playing around with C and C++ coding, I find the former easier to use than the latter. Since I don't code much in them nor do I know the ins and outs of them, I tell what I know now which may be incorrect and as said anyone can correct me. You're using rude language to attack me and try to intimidate with your "superior" knowledge...

Fact remains, lots of devs, especially ffmpeg and mplayer ones, do not like C++ much nor do they like linking to it that much. If you want to know their position on why, then ask them and I'm sure you'll have much fun arguing with them than with me

[The Herminator]

LOL, where did I attack you or wrote words like "crap" and such?

Oh please. Your comment "I think you just registered here to promote C++ since all your posts were about it in this thread." was clearly an attempt at ad hominem because you couldn't dispute my statements. Never said you used the word crap. I said what you posted was made up crap which it is.

Obviously, you're doing it not me.

I wasn't here to convince anyone of anything. I came to ask you to spell out actual reasons for why a library shouldn't be written in C++ and you just posted irrelevancies and flat out falsities. You claim it's ridiculous to do so and that no one should do so but you haven't posted a single technical argument to back yourself up and then when pointed out on this you get defensive.

As I said, playing around with C and C++ coding, I find the former easier to use than the latter.

And I already said that was perfectly fine, but that's not a technical reason why someone should not write a library in C++.

Since I don't code much in them nor do I know the ins and outs of them, I tell what I know now which may be incorrect and as said anyone can correct me. You're using rude language to attack me and try to intimidate with your "superior" knowledge...

I did correct you because you were flat out making stuff up like with the threading libraries nonsense.

Fact remains, lots of devs, especially ffmpeg and mplayer ones, do not like C++ much nor do they like linking to it that much.

That's great, but that's not a technical reason why someone shouldn't use C++ for a library (especially as it's trivially easy to link C and C++ code). If all of those devs wrote everything in x86 assembly over C would that be a persuasive argument that no one should use anything but x86 assembly to write a multimedia library? No. Argumentum ad populum is an unconvincing, fallacious argument.

If you want to know their position on why, then ask them and I'm sure you'll have much fun arguing with them than with me

Yeah, because they might actually have a semblance of a clue. You on the other hand made definitive statements based on nothing but your complete lack of knowledge of the subject.

[froggy1]

You want technical arguments? How bout jumping over to #ffmpeg-devel so mru can teach you a lesson? :p

I've heard more than enough from them to know, but I don't remember details of every single convo they had over the past years. Yes, I have a "complete lack of knowledge". Happy now, sir? it's a win/win situation for you, you arrogant bastard

Also, the complexity and problems I took over from wiki http://en.wikipedia.org/wiki/C%2B%2B#Criticism since it's incorrect, then maybe you should correct it ;)

It is possible to use operating system calls or third party libraries to do multi-threaded programming, but both approaches may create portability concerns

[The Herminator]

You want technical arguments? How bout jumping over to #ffmpeg-devel so mru can teach you a lesson? :p

Because I have no issue with the fact that MRU only wants to write things in C and doesn't want to link to C++ code. That's perfectly fine personal preference. My issue was with you providing justification for your own statements. I'm not going to go to some third party to argue with when my point of contention was with your statements.

I've heard more than enough from them to know, but I don't remember details of every single convo they had over the past years. Yes, I have a "complete lack of knowledge". Happy now, sir? it's a win/win situation for you, you arrogant bastard

No, I'm really not because this wasn't about some e-peen wagging. It's just amusing to see someone with technical incompetence telling others what they should and shouldn't do when writing their own code.

Also, the complexity and problems I took over from wiki http://en.wikipedia.org/wiki/C%2B%2B#Criticism since it's incorrect, then maybe you should correct it ;)

It is possible to use operating system calls or third party libraries to do multi-threaded programming, but both approaches may create portability concerns

You do realize that you need operating system calls and third party libraries to do multi-threaded programming in C as well, right? The whole point was that your criticism of C++ in this area is just as applicable to C. Secondly, that statement says "may" but that depends on what you use. If you use direct operating system calls to do multi-threading then yes you will have portability issues, but who actually does that when you can use either pthreads (available to both C and C++ and is used by those same libraries you mentioned for multi-platform threading) or using the boost libraries (again multi-platform) and widely used for cross-platform programs.

The comment about bloat ignores the fact that that "bloat" is due to a level of abstraction that C++ provides when giving you the facilities for OOP. One can also say that C is "bloated" compared to an assembly dialect due to the fact that it will be bigger in size due to the abstraction layers it provides. In my contention with your statement was that if I were to write an equivalent C++ procedural library versus that of what you can do in C the size will be negligibly different. Sure, if I take advantage of the OOP facilities my code will be larger, but that's not comparing equivalent programs anymore. Also nothing in that section backs up your wacky claim that compiling C++ is slower than C.

The overcomplicated part I will give you because it does try to give the facilities to due way too much and as such it makes it very hard to learn the entirety of the language. But what exactly is the merit in saying one shouldn't write a library in C++ just cause it may be complicated to learn? If the author knows it, what does anyone calling the code need to care? Other than that I really don't see anything of value in the section.

[The Herminator]

So I found a post on the ffmpeg-devel about why they removed C++ support from ffmpeg and it had nothing to do with anything you claimed.

FFmpeg is written in C, and "happened" to work with C++ programs
sometimes for some reasons.
Rather than having a half-broken C++ support it was decided to drop
support for C++. This is really a question of raising the quality of
FFmpeg by forcing people who use FFmpeg with other languages to use
the C API, that is supported actively.


Basically they only actively support their C API and they didn't want half broken C++ support because no one was actively maintaining it and according this that it worked with C++ programs seemed to be more coincidence. Their position was that if you want to use it in C++ just write C++ bindings like you would with GTK+, etc. It had nothing to do with C++ not having built-in multithreading compatibility or some bizarre claim of portability issues or any of your other claims. I see no reason why I should storm over to the ffmpeg developers and argue with them when this is a perfectly legitimate reason.

[The Herminator]

So I take back anything I might have said negative against the ffmpeg developers because you seem to have twisted their words. It seems from their own words that they only want to maintain a C code base because it's easier if everything is in one homogeneous language and that they don't want to maintain half-working C++ APIs when they wouldn't be very well supported internally. Which is a perfectly fine technical reason.

[froggy1]

Because I have no issue with the fact that MRU only wants to write things in C and doesn't want to link to C++ code. That's perfectly fine personal preference. My issue was with you providing justification for your own statements. I'm not going to go to some third party to argue with when my point of contention was with your statements.

Fair enough, I was wrong. But I also never pushed or forced anyone not to do C++ libs, only said that devs do not like it (ffmpeg/mplayer/xvid/etc) and suggested to do it in C instead



No, I'm really not because this wasn't about some e-peen wagging. It's just amusing to see someone with technical incompetence telling others what they should and shouldn't do when writing their own code.

Will you be satisfied if I give you my address so you can come over and kill me? As I'm so "incompetent" and this bothers you so much, then get rid of me... no? Yes, I "told" others how to do their development... where? You're reading way too much into my words and making a small issue that I mentioned about devs disliking C++ into one big world devastating problem.



You do realize that you need operating system calls and third party libraries to do multi-threaded programming in C as well, right? The whole point was that your criticism of C++ in this area is just as applicable to C. Secondly, that statement says "may" but that depends on what you use. If you use direct operating system calls to do multi-threading then yes you will have portability issues, but who actually does that when you can use either pthreads (available to both C and C++ and is used by those same libraries you mentioned for multi-platform threading) or using the boost libraries (again multi-platform) and widely used for cross-platform programs.

The comment about bloat ignores the fact that that "bloat" is due to a level of abstraction that C++ provides when giving you the facilities for OOP. One can also say that C is "bloated" compared to an assembly dialect due to the fact that it will be bigger in size due to the abstraction layers it provides. In my contention with your statement was that if I were to write an equivalent C++ procedural library versus that of what you can do in C the size will be negligibly different. Sure, if I take advantage of the OOP facilities my code will be larger, but that's not comparing equivalent programs anymore. Also nothing in that section backs up your wacky claim that compiling C++ is slower than C.

The overcomplicated part I will give you because it does try to give the facilities to due way too much and as such it makes it very hard to learn the entirety of the language. But what exactly is the merit in saying one shouldn't write a library in C++ just cause it may be complicated to learn? If the author knows it, what does anyone calling the code need to care? Other than that I really don't see anything of value in the section.

That's great explanation so put in on the wiki explaining in depth such things as it's too minimal atm. So "incompetent idiots" like me wouldn't learn much about it when they need to check something up.

About the #ffmpeg-devel, I was talking about other conversations I saw, not the one you quoted...

[The Herminator]

Fair enough, I was wrong. But I also never pushed or forced anyone not to do C++ libs, only said that devs do not like it (ffmpeg/mplayer/xvid/etc) and suggested to do it in C instead

Probably because they don't want to maintain a homogeneous code base. Perfectly reasonable especially if you are the one doing the maintenance. If all you're doing, on the other hand, is linking against a shared object it really wouldn't matter since with the extern "C" construct the object code links trivially easy to C object code.

Will you be satisfied if I give you my address so you can come over and kill me? As I'm so "incompetent" and this bothers you so much, then get rid of me... no? Yes, I "told" others how to do their development... where? You're reading way too much into my words and making a small issue that I mentioned about devs disliking C++ into one big world devastating problem.

No, I don't want to see you in real life as this was not about one-upping you. It's about the fact that you were blustering on to someone telling them they shouldn't do this or that when you had no idea what you were talking about. And secondly, it's not about them disliking C++ code from what I've read of their own words. They want to maintain a code base that is pretty strictly C89 compliant (with a few exceptions) and as such it's perfectly reasonable they wouldn't want C++ code in that base.

That's great explanation so put in on the wiki explaining in depth such things as it's too minimal atm. So "incompetent idiots" like me wouldn't learn much about it when they need to check something up.

Don't really care enough. If you want to post it, go ahead. I'm just sick of people claiming x or y about [insert programming language] and finding out that the people who bluster the most have the smallest amount of applicable knowledge when making these statements.

About the #ffmpeg-devel, I was talking about other conversations I saw, not the one you quoted...

From other quoted statements I've seen while searching through the ffmpeg-devel archives I still see nothing approaching what you were claiming their position was.

[The Herminator]

FFmpeg is programmed in the ISO C90 language with a few additional features from ISO C99, namely:

* the `inline' keyword;
* `//' comments;
* designated struct initializers (`struct s x = { .i = 17 };')
* compound literals (`x = (struct s) { 17, 23 };')

These features are supported by all compilers we care about, so we will not accept patches to remove their use unless they absolutely do not impair clarity and performance.

All code must compile with GCC 2.95 and GCC 3.3. Currently, FFmpeg also compiles with several other compilers, such as the Compaq ccc compiler or Sun Studio 9, and we would like to keep it that way unless it would be exceedingly involved. To ensure compatibility, please do not use any additional C99 features or GCC extensions. Especially watch out for:



This is the codified reason that they would prefer not to have C++ code in their code base or have to rely on linking with such code as they want to maintain C90 compliance as much as possible and compatibility with certain compilers and versions. As such, bringing in C++ to the code base, for example, would hamper this goal.

[froggy1]

Probably because they don't want to maintain a homogeneous code base. Perfectly reasonable especially if you are the one doing the maintenance. If all you're doing, on the other hand, is linking against a shared object it really wouldn't matter since with the extern "C" construct the object code links trivially easy to C object code.

That's a valid reason.



No, I don't want to see you in real life as this was not about one-upping you. It's about the fact that you were blustering on to someone telling them they shouldn't do this or that when you had no idea what you were talking about. And secondly, it's not about them disliking C++ code from what I've read of their own words. They want to maintain a code base that is pretty strictly C89 compliant (with a few exceptions) and as such it's perfectly reasonable they wouldn't want C++ code in that base.

Oh yes, I was telling trojanfoe how to do his development and which language to choose. I even emailed him and lobbied him to choose C for his new project. Scratch that, I went to his house and threatened him to use only C or else give up his life... If he's that knowledgeable like you seem about C/C++, then he surely will ignore my comments and even correct them, which he didn't as he didn't even replied once in his own thread. You instead went to insults, arrogance and intimidating because you can't stand someone who has lesser knowledge thus spreading misinformation or whatnot so you need to call him words instead of explaining more without the need for these words, which can be done perfectly well. You know? I can do the same thing about a topic you have no clue about. It works both ways ;) I already retracted most of what I said since you explained a few things I didn't know yet (wrt C/C++), but you seem to go on and on about it



From other quoted statements I've seen while searching through the ffmpeg-devel archives I still see nothing approaching what you were claiming their position was.

I was talking about IRC discussions, not mailing lists, as I said before.

[kreet]

libbluray is getting a new lease on life: http://forum.doom9.org/showthread.php?t=150014