You are suggesting that google moves into a chicken-and-egg situation and solves it with sheer force. Thing is, google does not have to do that. They don't have to make Theora popular. All they need it to choose h264, which is *already* popular and established. Google has no benefit from using Theora. The licensing issues are non existent, since their video hosting site is free.
It is. Google will not magically turn all these embedded hardware into Theora players. If people can't play anything on it, they turn to other sites which do support h264.
Forcing kinds to watch X instead of Y is likely to lead them to hate X and crave for Y. Irrelevant of the quality of X and Y.
My father didn't force me to watch something, but couldn't stand when I was watching some comics that were crap in his opinion. By the time I had my own TV, I got myself video cassettes and watched tons of that stuff.
Well, that's interesting. Certainly if we're picking a format designed to be on a hard disk (or SSD), I'd implement it today with something like zip, with some xml files inside it. That's right, un-mux'd, as muxing is completely unnecessary pretty much anywhere except optical storage.
You need muxing for streams, unless you have two streams.
No, I'm talking about things like the menus, which just aren't going to be that big. This is after working on HD-DVD, which did use XML -- basically, you'd read the XML and other related assets off simple archives on the disc, and keep them in RAM while you play the actual video data.
I do not understand this insistence towards XML. There is no reason for XML for menus here, either - EBML is already present. Sticking semistructured data into semistructured data has no advantage.
EBML can be read much faster than compressed XML or JSON, while being smaller at the same time. Both of these advantages are critical for video streams. In addition, compressed XML means that either the whole thing is compressed - which disallows streaming - or chunks are compressed, which is not a satisfying solution.
EBML is a hierarchical semi-structured container for binary data. It does have its place.
Actually, our brains do not store video. They idealize the contents in an abstract shape and store *this*. For example, if a video shows a spinning cube, you do not store the frames, but the notion of a spinning cube, nothing more.
As for Dirac, just look it up in the Doom9 forums.
Let web developers develop and let users use applications to publish - it's worked so well as many Web 2.0 successes have shown.
Actually, it didn't. HTML 5 isn't actually suited for *web applications*. It is suited for *documents*. These two are entirely different entities - for example, there is no need for navigation buttons in a web application. HTML 5 reflects today's actual web needs much better. The web is no longer primarily made up of hypertext document, it is primarily made up of web applications.
Also, the market forcing a standard ends up with closed standards that require licensing and whatnot. Even if the specs are open.
Intel's icc is a collection of special cases. If your code does not fit into this grid of special cases, it will be slow. Your actual answer is called LLVM.
If they didn't include these lame aliens, it would have been a nice game indeed. The way the enemies behave and sound is even hilarious at times. But the second half ruined everything, and proved to me that Crytek mostly cared about the tech.
Cevat Yerli likes to yell. This was no exception. So, take his complaints with a grain of salt. Crysis sales did not suffer from piracy, they suffered from Crysis' insane price for what basically is a techdemo with a little bit of gameplay. The times where the hype about the graphics was enough to sell a game are definitely over. Crytek didn't learn this lesson yet.
By default, opening multiple files with GVim does not create tabs for each one of them. Neither do I have handy keystrokes like Ctrl+Left / Ctrl+Right to switch between tabs, or something like Ctrl+1, Ctrl+8... to quickly switch to the first 9 or 10 tabs. I have been trying to ages to get this to work, so far it never worked fully. Switching caused *buffer* changes, not tab changes, which is really bad regarding the undo history. Googling for this did not help, and IMO, these things should exist by default.
But the things he mentions affect the workflow greatly. It is an immense improvement in the workflow if one does not have to tab through windows to get to the terminal and then back to the editor. It is *one* action - rebuild. It should not involve more than one step, but this is precisely what happens with vim + make/scons/.... (I do use vim and the terminal, btw, but I am adding commands inside vim to invoke the build tool, essentially turning vim into an IDE).
There are several tasks that happen frequently: - build - clean - rebuild - search - replace - open N files - switch between opened files - save files
These should be instantly available as a keystroke. vim has issues with multiple files, even with tabs. I'm trying to tweak it to be easily able to switch, but this is not the default. Build happens so often, it MUST be one keystroke. Rebuild happens less often, it could be something like ctrl+f5. Clean, the same. Search, replace, open, save are self explanatory.
One other important thing is to be able to quickly have an overview over the project's content. Source files, classes, closures, functions etc. This is something where IDEs excel, and I sorely miss this in large projects.
With a better isolated ABI such as the one found in Qt, you just update the shared library package, and all applications may continue on unchanged.
Unless something changed in the API (not the ABI - the API) that, say, changes the stack frame in classes. Then you must recompile, or your shiny new shared libraries will cause the application to crash. Do you really think this is better? I went this route once. I do not look back. Even with versioning things can get complicated, and ugly.
And the reasons for C++ compiler vendors to restrict themselves from implementing the ANSI/ISO C++ standard fully were?..
This is about why Qt still restricts itself to a subset, not about compiler vendors. The historical reasons are well-known. Today's reason no.1 is support for old compilers.
Nobody denies that C++ parsers are exceedingly hard to write. But lets stick to the subject, shall we?
I understand exceptions that have a full-fledged execution environment to support them. With C++, you have to care exceedingly about throwing an exception in certain methods, such as a constructor (and goodness forbid admitting an exception in a destructor). Also, if your software has some non-C++ parts and those call back to the C++ code, be sure to catch all exceptions your callbacks might throw and rely on good old ways of error reporting, or you'll have leaks and "undefined behavior".
True, however look at these cases carefully. Exceptions in destructors are known to cause problems. Exceptions from/to non-C++ parts (for example, Spidermonkey) is also a delicate issue. This is well-known, too etc. in all summary, exception issues are the cause for perhaps 5% of all errors I encounter.
Please go back in the thread and reread my comments carefully before misquoting and misinterpreting them.
Okay, so you referenced Boost/STL indirectly. My point still stands. Qt did not reject templates because of your perceived bloat and "emitting mountains of non-shared, hard to update code". Qt rejected templates because the compilers back then just didn't support them, and because Moc gives them thread safety and introspection abilities, which is useful for the Designer and for IPC/RPC.
Tell that to Erlang fans:) That's why really convenient and productivity-friendly languages like Python and Scala are getting ever more popular, and even Java gains in this respect, without turning into the disaster that C++ ended up to be.
At last, we are reaching an agreement. I fully agree that C++ is a mess. However, there is nothing out there that can fully replace it. There are languages that: - a bad joke, but have powerful toolchains (Java) - have interesting features, but have issues with patents, and still lack the ability for fully generic programming (C#) - are dynamic, which allows for anything imaginable, but are far too slow (Python, Ruby) - contain functionality for functional and generic programming far beyond C++, but are way too obscure (Haskell, Lisp, OCaml, Scala, Clean) - are still a bit of an underdog, and aspire to supersede C++, but have a real focus problem, because "being better than C++" is not really a goal (D)
Note that for your typical business application, any of these will do, however languages with almost no features like Java will force you to write a lot of extra code, because essential stuff like lambda is not present.
However, C++ is extensively used in high-performance areas like scientific computing, and is one of the few languages able to beat Fortran in this domain. But without template meta-programming and generic programming, it is not possible to use both high-level and low-level featuresets in the same project; this very contrast is one of the most important features of modern C++. I can write my code to, say, solve Navier Stokes equations, and the code looks in fact like said equat
Overwriting all binaries that depend on your library when the inlined implementation needs to change (e.g. because a security-critical bug has been found there), is.
Which is why you should have a system that automatically designates the changed binaries. This is what I did. The build system is able to package changed files. The package is the update. Transmit, unpack, done.
Yes, I frequently use STL and Boost in embedded environments.
Your clients can congratulate themselves with the file size and memory footprint cost of all the inlined/instantiated code.
Indeed they can, since it is small, fast, and uses little memory. The trick is to use templates, STL, boost correctly. Besides, newer gcc versions reuse instantiated code much better then older ones.
And, finally, embedded devices of 2009 are lightyears ahead of embedded devices of 2004. It is becoming quite common to have more than 16 MB and 300 MHz for a web radio, for example. A lot of software stacks are huge, not because of boost, but because they include a lot of stuff, and don't care about filesize, precisely because memory costs are dropping.
The problem is, it's too easy to make these errors, unless you're a card-carrying member of the C++ Lawyer Bar Association. A lot of people have since learned that it doesn't have to be this way.
You don't have to be "a card-carrying member of the C++ Lawyer Bar Association", you just have to understand exceptions correctly. I have yet to see what is so extraordinarily difficult about them.
Qt does not submit to STL and boost for a variety of reasons. You did not name any of them.
I did name the few that I feel are important.
What you feel is irrelevant. You stated that "these are the reasons why Qt does not use Boost/STL". You were obviously wrong.
Yes, there are also historical reasons: Qt was developed at a time when the compiler support for the more advanced C++ features was far from solid.
This is correct. The other reason being that many Trolltech customers still use outdated compilers.
It tells you something when workable implementations lag years behind the approved standard.
This happens to any language. For example, SCons has to restrict itself to a subset of current Python versions to be able to run on ancient setups with Python 1.5.x.
On a sidenote, C++ code that looks like Java is something I personally abhor. Once one starts using function objects and generic programming, this "old style" C++ looks and feels dated, inefficient, bloated, primitive. The vast increase in productivity confirms this. And I cannot understand why anybody would prefer writing C++ in the old, Java-like style. The only objective reason is a restriction to an old compiler.
1) does not make any sense. The Qt memory management is both simple and absolutely perfect for GUIs, which naturally tend to be object oriented. Having parent object clean up their children is the right way to go.
4) Is not trivially possible, because Qt signals and slots and boost::signals do not cover the same functionality. Qt signals/slots allow for introspection, so it is possible to do IPC and RPC with them. In addition, they are thread-safe by storing Qt signal emissions on Qt's main loop.
boost::signals does not allow for any of these features. signals2 is thread-safe, but not in the way Qt signals do it.
2) and 3) are "nice to have", but not important.
What matters is the cost-to-benefit ratio Qt delivers (cost = time to integrate, study etc.) and if it translates into a net gain. Not one of these four points help achieving this goal. I personally use both Qt and Boost, and while I do want to see function objects supported as slots for example, I can live with moc, etc. precisely because Qt offers so damn much. And, as said, in the end, that is all that matters.
Now thats amusing. Overwriting an old binary with a newer one is hard to do now? I have written software that supports updates. I have yet to encounter any of the problems you mentioned. Yes, I frequently use STL and Boost in embedded environments. The main reason why I don't use them more often are the compilers, which tend to be g++ 3.x. (However, several large manufacturers already have g++ 4.1, so things are improving here.)
The sentence about "real exceptions" is entertaining as well. Good code avoids all of the problems you mentioned. Honestly, it is sickening to see how many people blame their language for their own errors. C++ is far from perfect, but not for the reasons you mentioned.
Qt does not submit to STL and boost for a variety of reasons. You did not name any of them.
There are unofficial qmakespecs for visual studio. The missing official VS support has got something to do with licensing incompatibilities between LGPL/GPL IIRC (but I'm unsure).
Note however that when I showed C++ coders what function objects are, they liked it every time. It is somewhat strange at the beginning, but once you grasp it fully, you never want to put function objects, bind, lambda etc. away.
Slashdot Mirror
You are suggesting that google moves into a chicken-and-egg situation and solves it with sheer force. Thing is, google does not have to do that. They don't have to make Theora popular. All they need it to choose h264, which is *already* popular and established. Google has no benefit from using Theora. The licensing issues are non existent, since their video hosting site is free.
It is. Google will not magically turn all these embedded hardware into Theora players. If people can't play anything on it, they turn to other sites which do support h264.
No, the problem is decoding. As the GP said, there are loads of h264 playing hardware out there. Theora? Nil.
Forcing kinds to watch X instead of Y is likely to lead them to hate X and crave for Y.
Irrelevant of the quality of X and Y.
My father didn't force me to watch something, but couldn't stand when I was watching some comics that were crap in his opinion. By the time I had my own TV, I got myself video cassettes and watched tons of that stuff.
The stream itself is in EBML?
Well, that's interesting. Certainly if we're picking a format designed to be on a hard disk (or SSD), I'd implement it today with something like zip, with some xml files inside it. That's right, un-mux'd, as muxing is completely unnecessary pretty much anywhere except optical storage.
You need muxing for streams, unless you have two streams.
No, I'm talking about things like the menus, which just aren't going to be that big. This is after working on HD-DVD, which did use XML -- basically, you'd read the XML and other related assets off simple archives on the disc, and keep them in RAM while you play the actual video data.
I do not understand this insistence towards XML. There is no reason for XML for menus here, either - EBML is already present. Sticking semistructured data into semistructured data has no advantage.
EBML can be read much faster than compressed XML or JSON, while being smaller at the same time. Both of these advantages are critical for video streams. In addition, compressed XML means that either the whole thing is compressed - which disallows streaming - or chunks are compressed, which is not a satisfying solution.
EBML is a hierarchical semi-structured container for binary data. It does have its place.
Actually, our brains do not store video. They idealize the contents in an abstract shape and store *this*. For example, if a video shows a spinning cube, you do not store the frames, but the notion of a spinning cube, nothing more.
As for Dirac, just look it up in the Doom9 forums.
Dirac too is inferior to h.264, while being several times slower.
Nothing beats h.264.
HTML 5 isn't actually suited for *web applications*.
For some reason, Slashdot submit ate the <.
It should read "HTML <"
Let web developers develop and let users use applications to publish - it's worked so well as many Web 2.0 successes have shown.
Actually, it didn't. HTML 5 isn't actually suited for *web applications*. It is suited for *documents*. These two are entirely different entities - for example, there is no need for navigation buttons in a web application. HTML 5 reflects today's actual web needs much better. The web is no longer primarily made up of hypertext document, it is primarily made up of web applications.
Also, the market forcing a standard ends up with closed standards that require licensing and whatnot. Even if the specs are open.
Intel's icc is a collection of special cases. If your code does not fit into this grid of special cases, it will be slow.
Your actual answer is called LLVM.
You fight like a dairy farmer!
If they didn't include these lame aliens, it would have been a nice game indeed. The way the enemies behave and sound is even hilarious at times. But the second half ruined everything, and proved to me that Crytek mostly cared about the tech.
Cevat Yerli likes to yell. This was no exception. So, take his complaints with a grain of salt. Crysis sales did not suffer from piracy, they suffered from Crysis' insane price for what basically is a techdemo with a little bit of gameplay. The times where the hype about the graphics was enough to sell a game are definitely over. Crytek didn't learn this lesson yet.
Hmm ..
A shiny staircase with Carrara marble steps and sides covered with quartz glass, but one needs special apple iShoes to use it.
By default, opening multiple files with GVim does not create tabs for each one of them. Neither do I have handy keystrokes like Ctrl+Left / Ctrl+Right to switch between tabs, or something like Ctrl+1, Ctrl+8 ... to quickly switch to the first 9 or 10 tabs. I have been trying to ages to get this to work, so far it never worked fully. Switching caused *buffer* changes, not tab changes, which is really bad regarding the undo history. Googling for this did not help, and IMO, these things should exist by default.
But the things he mentions affect the workflow greatly. It is an immense improvement in the workflow if one does not have to tab through windows to get to the terminal and then back to the editor. It is *one* action - rebuild. It should not involve more than one step, but this is precisely what happens with vim + make/scons/.... (I do use vim and the terminal, btw, but I am adding commands inside vim to invoke the build tool, essentially turning vim into an IDE).
There are several tasks that happen frequently:
- build
- clean
- rebuild
- search
- replace
- open N files
- switch between opened files
- save files
These should be instantly available as a keystroke. vim has issues with multiple files, even with tabs. I'm trying to tweak it to be easily able to switch, but this is not the default. Build happens so often, it MUST be one keystroke. Rebuild happens less often, it could be something like ctrl+f5. Clean, the same. Search, replace, open, save are self explanatory.
One other important thing is to be able to quickly have an overview over the project's content. Source files, classes, closures, functions etc. This is something where IDEs excel, and I sorely miss this in large projects.
The canvas element is likely to be part of HTML 5 too, and is much better suited for dynamic vector art.
With a better isolated ABI such as the one found in Qt, you just update the shared library package, and all applications may continue on unchanged.
Unless something changed in the API (not the ABI - the API) that, say, changes the stack frame in classes. Then you must recompile, or your shiny new shared libraries will cause the application to crash. Do you really think this is better? I went this route once. I do not look back. Even with versioning things can get complicated, and ugly.
And the reasons for C++ compiler vendors to restrict themselves from implementing the ANSI/ISO C++ standard fully were?..
This is about why Qt still restricts itself to a subset, not about compiler vendors. The historical reasons are well-known. Today's reason no.1 is support for old compilers.
Nobody denies that C++ parsers are exceedingly hard to write. But lets stick to the subject, shall we?
I understand exceptions that have a full-fledged execution environment to support them. With C++, you have to care exceedingly about throwing an exception in certain methods, such as a constructor (and goodness forbid admitting an exception in a destructor). Also, if your software has some non-C++ parts and those call back to the C++ code, be sure to catch all exceptions your callbacks might throw and rely on good old ways of error reporting, or you'll have leaks and "undefined behavior".
True, however look at these cases carefully. Exceptions in destructors are known to cause problems. Exceptions from/to non-C++ parts (for example, Spidermonkey) is also a delicate issue. This is well-known, too etc. in all summary, exception issues are the cause for perhaps 5% of all errors I encounter.
Please go back in the thread and reread my comments carefully before misquoting and misinterpreting them.
Okay, so you referenced Boost/STL indirectly. My point still stands. Qt did not reject templates because of your perceived bloat and "emitting mountains of non-shared, hard to update code". Qt rejected templates because the compilers back then just didn't support them, and because Moc gives them thread safety and introspection abilities, which is useful for the Designer and for IPC/RPC.
Tell that to Erlang fans :) That's why really convenient and productivity-friendly languages like Python and Scala are getting ever more popular, and even Java gains in this respect, without turning into the disaster that C++ ended up to be.
At last, we are reaching an agreement. I fully agree that C++ is a mess. However, there is nothing out there that can fully replace it. There are languages that:
- a bad joke, but have powerful toolchains (Java)
- have interesting features, but have issues with patents, and still lack the ability for fully generic programming (C#)
- are dynamic, which allows for anything imaginable, but are far too slow (Python, Ruby)
- contain functionality for functional and generic programming far beyond C++, but are way too obscure (Haskell, Lisp, OCaml, Scala, Clean)
- are still a bit of an underdog, and aspire to supersede C++, but have a real focus problem, because "being better than C++" is not really a goal (D)
Note that for your typical business application, any of these will do, however languages with almost no features like Java will force you to write a lot of extra code, because essential stuff like lambda is not present.
However, C++ is extensively used in high-performance areas like scientific computing, and is one of the few languages able to beat Fortran in this domain. But without template meta-programming and generic programming, it is not possible to use both high-level and low-level featuresets in the same project; this very contrast is one of the most important features of modern C++. I can write my code to, say, solve Navier Stokes equations, and the code looks in fact like said equat
Overwriting all binaries that depend on your library when the inlined implementation needs to change (e.g. because a security-critical bug has been found there), is.
Which is why you should have a system that automatically designates the changed binaries. This is what I did. The build system is able to package changed files. The package is the update. Transmit, unpack, done.
Yes, I frequently use STL and Boost in embedded environments.
Your clients can congratulate themselves with the file size and memory footprint cost of all the inlined/instantiated code.
Indeed they can, since it is small, fast, and uses little memory. The trick is to use templates, STL, boost correctly. Besides, newer gcc versions reuse instantiated code much better then older ones.
And, finally, embedded devices of 2009 are lightyears ahead of embedded devices of 2004. It is becoming quite common to have more than 16 MB and 300 MHz for a web radio, for example. A lot of software stacks are huge, not because of boost, but because they include a lot of stuff, and don't care about filesize, precisely because memory costs are dropping.
The problem is, it's too easy to make these errors, unless you're a card-carrying member of the C++ Lawyer Bar Association. A lot of people have since learned that it doesn't have to be this way.
You don't have to be "a card-carrying member of the C++ Lawyer Bar Association", you just have to understand exceptions correctly. I have yet to see what is so extraordinarily difficult about them.
Qt does not submit to STL and boost for a variety of reasons. You did not name any of them.
I did name the few that I feel are important.
What you feel is irrelevant. You stated that "these are the reasons why Qt does not use Boost/STL". You were obviously wrong.
Yes, there are also historical reasons: Qt was developed at a time when the compiler support for the more advanced C++ features was far from solid.
This is correct. The other reason being that many Trolltech customers still use outdated compilers.
It tells you something when workable implementations lag years behind the approved standard.
This happens to any language. For example, SCons has to restrict itself to a subset of current Python versions to be able to run on ancient setups with Python 1.5.x.
On a sidenote, C++ code that looks like Java is something I personally abhor. Once one starts using function objects and generic programming, this "old style" C++ looks and feels dated, inefficient, bloated, primitive. The vast increase in productivity confirms this. And I cannot understand why anybody would prefer writing C++ in the old, Java-like style. The only objective reason is a restriction to an old compiler.
1) does not make any sense. The Qt memory management is both simple and absolutely perfect for GUIs, which naturally tend to be object oriented. Having parent object clean up their children is the right way to go.
4) Is not trivially possible, because Qt signals and slots and boost::signals do not cover the same functionality. Qt signals/slots allow for introspection, so it is possible to do IPC and RPC with them. In addition, they are thread-safe by storing Qt signal emissions on Qt's main loop.
boost::signals does not allow for any of these features. signals2 is thread-safe, but not in the way Qt signals do it.
2) and 3) are "nice to have", but not important.
What matters is the cost-to-benefit ratio Qt delivers (cost = time to integrate, study etc.) and if it translates into a net gain. Not one of these four points help achieving this goal. I personally use both Qt and Boost, and while I do want to see function objects supported as slots for example, I can live with moc, etc. precisely because Qt offers so damn much. And, as said, in the end, that is all that matters.
No one uses STL containers?
Are we talking about the same C++?
Don't tell me you honestly use self-made containers.
Now thats amusing. Overwriting an old binary with a newer one is hard to do now? I have written software that supports updates. I have yet to encounter any of the problems you mentioned. Yes, I frequently use STL and Boost in embedded environments. The main reason why I don't use them more often are the compilers, which tend to be g++ 3.x. (However, several large manufacturers already have g++ 4.1, so things are improving here.)
The sentence about "real exceptions" is entertaining as well. Good code avoids all of the problems you mentioned. Honestly, it is sickening to see how many people blame their language for their own errors. C++ is far from perfect, but not for the reasons you mentioned.
Qt does not submit to STL and boost for a variety of reasons. You did not name any of them.
Better luck next time.
There are unofficial qmakespecs for visual studio. The missing official VS support has got something to do with licensing incompatibilities between LGPL/GPL IIRC (but I'm unsure).
Note however that when I showed C++ coders what function objects are, they liked it every time. It is somewhat strange at the beginning, but once you grasp it fully, you never want to put function objects, bind, lambda etc. away.