Given that most of those libraries, even high performance commercial libraries, have been written without such constructs, it's reasonable to postulate that it doesn't.
Wrong conclusion. That would mean type safety doesnt pay off because even high performance commercial libraries have been written without such constructs. Yes, you can do it without templates in C++, but it won't be as flexible, or fast.
Generic programming and metaprogramming just came to happen in C++, that is correct, and pretty much the point why I look for an alternative. I want a language where I get *compile-time* templates, e.g. the generalization is resolved while compiling, and not at run-time. So far, only D provides that. D *is* a language designed with these two in mind. Maybe it is the best candidate for replacement....
With templates, you can get at the very least information about the typename, and the debugger shows where *in the template* the crash happened. You cannot get that from preprocessor macros. You cannot even set breakpoints in a macro.
Actually, the C++ committee is quite conservative about new features in the language. They prefer new features by libraries. Thats why D has delegates in the language, and C++0x has std::function in the standard library, for example.
Most of the standards effort is going into template features that few will use and fewer still will use well. Trying to use the template expansion engine as a general purpose macro system is a terrible idea for production code. But it has a big fan club on the standards committee. Worse, the C++ commitee does very little to improve language safety and reliability. Which is why we still have buffer overflows in C++ code, fifteen years in.
Obviously, you never used modern C++ extensively.
Templates are not a macro system, they are a typesafe meta-language. I agree that their syntax sucks, but they are lightyears away from being a simple macro system. And lots of people use them, just look at the STL string or vector. You think few people will use concepts or variadic templates, think again. Generic programming is the actual edge of C++.
I really suggest you read "Modern C++ Design". There you can see perfectly valid examples of how to use templates. Policy-based is a good and powerful example. With this, I can customize my code at compile-time, for example, having a policy which locks a mutex in proper code sections, and another policy with no locks at all. This way, my code *can* be threadsafe, but does not *have* to be (thread safety is useless in a singlethreaded program). Oh yes, I could do that with the preprocessor too, but try debugging this. Also, say goodbye to namespaces, type safety and debugging support.
Safety and reliability have nothing to do with C++ itself. Many people overuse new and delete, without relying on proper RAII constructs, for example. If you think MFC-style C++ is the zenith, you don't know C++. I have been programming C++ for over 7 years and reached a point where memleaks happen extremely rarely (mostly due to rushed code). Its no black arts, no voodoo, just proper C++ usage.
C++ does not "support" functional programming, generic programming, object oriented programming, or even metaprogramming; if you invest a lot of work and effort, you can approximate small subsets of these programming styles in C++, badly. And I have yet to see that it's worth the effort; the best and most common use of C++ still seems to be as a slightly better C.
I use generic programmming and metaprogramming very often in C++. I does pay off. See http://www.antigrain.com/ for an example.
I agree that without templates C++ has no real advantages though.
C++ is far too complex yes. But there is nothing that can really replace it. A language which supports functional, generic, procedural, object-oriented programming, with static typing, metaprogramming, and heavily geared towards native building? I mean, do you know a language which can resolve iterators to simple pointer arithmetic when compiling? Of course there are far better languages feature-wise, but they all demand some performance penalties. This may or may not be relevant. For example, for video codecs its relevant, as it is for most other realtime stuff (try capturing with Java and its GC for instance).
So, C++ fills a niche. D *may* be a replacement, but I am skeptical. I don't know Eiffel well enough though, this may be a good candidate.
And lets not forget that C++ toolchains are among the most optimized and tested ones. For example, Lisp could be able to reach C++ performance, but doesnt simply because the Lisp toolchains arent as optimized. A simplified example: sometimes SBCL does register->memory->operation->register calls, where g++ optimizes to register->operation. And, the amount of C++ code in existence is staggering.
Well much of their legacy tech is crap (see WinAPI). But.Net, DirectX, Visual Studio are excellent projects. So, I have no problem with MS tech. I do have a problem with their attitude towards others (that is, crush them and grab every single dollar in the market). MS got unpopular because of their actions, not their tech.
Raytracing is really cool for global stuff like refractions, shadows, reflections, caustics. But in most cases, a rasterizer is better. Yes, raytracing is elegant, but a rasterizer will outperform it when rendering opaque surfaces. You should ask yourself why many CGI studios don't use (pure) raytracers anymore. A hybrid seems the way to go: rasterizing by default, but the ability to shoot rays in the pixel shader, which would be extremely cool for reflections and refractions.
This is NOT a justifiable move forward. A few specs are now mandatory, and that is enough to render expensive hardware obsolete. Now imagine Game X builds upon D3D10.1. Where is the actual progress? D3D10.1 would be fine if it had new actual features.
Yes, game developers are getting conservative nowadays, and always have been regarding support of new APIs. So many studios will continue using D3D9. But for the same reason many studios still wont switch to OpenGL. In both cases (D3D9->D3D10, D3D9->OpenGL 2.x or even the coming 3.x) the codebase has to be largely rewritten, so when studios MUST upgrade, they will probably prefer OpenGL this time...
The point is that D3D10.1 mainly just enforces stuff that was optional in 10.0. There are no new killer features. So a game requiring 10.1 will make your shine new 8800 obsolete with absolutely no gain. 9.0b->9.0c saw the addition of stream frequencies among others, which is essential for instancing (D3D10 redesigned the entire instancing thing again). Also, 9.0c was largely compatible with 9.0b. It was mostly a bugfix release with added samples and a couple of new features (which were optional).
And see, the prior art issue is the problem. Someone tell me how to invalidate ridiculous patents like Forgent's JPEG one (which actually patents the extremely trivial RLE0+Huffman combination). It is absolutely impossible, because for the court, RLE0+Huffman looks so sophisticated and advanced and whatnot, despite being usually one of the FIRST compression algorithm combinations people write. That is, it has been done a zillion times before Forgent even existed. The right thing to do would be a high penalty fee for Forgent and the USPTO for extorting developers with actual talent using this absurd patent.
Software patents have no justification and need to be eradicated completely. Best thing would be to get rid of Forgent, Acacia, SP etc. as well. Damn parasites. In fact, why shouldn't we make exclusive patent-holding a felony? They help no one, they don't invent anything, on the opposite, they PREVENT innovation.
Thats why peer review might be a good idea. Example:
> The patents in question are for Aloft's "Network Browser Graphical User Interface for Managing Web Content," US patent number 7,117,443, and "Network Browser Window with Adjacent Identifier Selector," US > patent number 7,194,691 (...). They were filed for in late 2003 and were granted in October of 2006 and March of 2007, respectively. They describe user interfaces in a network browsing window that display > the content at a specific URL as well as the URL itself somewhere on or around the window.
With peer review, the chance is higher that someone notices some prior art here: web browsers. Which have been around since, oh, 1992? Additionally, the general concensus should shift. When something is patented, it should not be so damn hard and expensive to invalidate it with proper prior art. In short: patents should not be carved in stone. We have too many patents today, and too many advances to be sure that a patent is 100% valid.
kparts, kioslaves, comparison of kaffeine vs. totem is a 100% win for kaffeine (try TV with totem, TV *recording* with totem), k3b vs. gnomebaker, konqueror vs. nautilus,.. technically, KDE wins hands down. The UI looks are another matter. (Though that can be pretty too.)
First, overlapping windows are often undesirable, users either maximize the current window or tile them. An exception are dialogs, which obviously cannot be tiled. (Toolwindows CAN be tiled, however.) It matches the design principle of an application's GUI: there, no widgets overlap, they are tiled, and/or organized into tabbed groups.
With the advent of large screens (and multi-monitor setups) tiling window managers like ion or wmii become more interesting. Now, something like a tiling KDE would be fine. (Exception to the tiling: dialog windows of course.) Automatically rearranging windows works well in ion, and would be a nice experiment in KDE's kwm.
Then, there is the fact that GUI applications often rely too much on mouse input. The mouse should not be overused, as the user can enter input much faster via the keyboard. Its the input *volume* that often speaks against the keyboard (like, typing this 30-char-filename instead of simply clicking it). Also, the mouse is obviously the input method of choice for 2d input (drawing without the mouse?). But, observe this website for example. Try posting something without using the mouse, ever. It is doable, but easier with the mouse.
Editors are a good example of where the mouse is often overused. Ideally, one never has to use the mouse for editing. vim and emacs shine here, but they have an awful learning curve, because it is hard to grasp all those commands at first. Editors like joe do it better for starters imo. In joe, the right upper corner contains the hint "press Ctrl-K H for help". You press that, and a quick summary appears. Perfect! One is not lost like in vim or emacs, yet the mouse is not necessary.
His point is that the kernels are optimized for servers. That is, focus on throughput, performance, but not latency or responsiveness. A desktop has the latter two as priorities, while sacrificing the former two. As an example, it doesn't matter if that mpeg4 video I/O eats a little more CPU, as long as other tasks don't interrupt its playback.
Guy A says that stealing from the rich, selfish guy is OK, Guy B says stealing is always wrong, since it corrupts. There. Absolute morality? How about euthanasia? Or people looking for higher goals in life? Etc.
Easy systems of values are always dangerous. Truth is: life is complex, life is confusing, and there is no easy system of values that handles everything well.
Re:If you can't tell the boundries, it ain't prope
on
Patents Don't Pay
·
· Score: 4, Informative
I disagree with (a). I found Deuteros (very old Amiga game) and Iron Seed (very old PC) game in this year on some abandonware sites, and I was glued to the screen. The same with old RPGs etc. What *really* pisses me off though are bad interfaces, frustrating the hell out of me. Unfortunately, the older the game, the higher the chance gets it has a bad interface.
Range coding is essentially the same as arithmetic coding, but patent-free. It is minimally worse than AC, but the difference is insignificant in practice.
1) Modeling is a very big part of compression, in fact its the one where AI might occur. 2) Huffman is only the optimum for integer symbol sizes. If one symbol has 2.117 bits, it won't be the optimum. If one symbol needs only 0.004 bits, then huffman gives it 1 bit, which is far too large. Arithmetic/range coding address these issues, and come VERY near to entropy, so entropy coding is a solved problem. Which leads me to (1) - its there where research happens.
Slashdot Mirror
Given that most of those libraries, even high performance commercial libraries, have been written without such constructs, it's reasonable to postulate that it doesn't.
Wrong conclusion. That would mean type safety doesnt pay off because even high performance commercial libraries have been written without such constructs. Yes, you can do it without templates in C++, but it won't be as flexible, or fast.
Generic programming and metaprogramming just came to happen in C++, that is correct, and pretty much the point why I look for an alternative. I want a language where I get *compile-time* templates, e.g. the generalization is resolved while compiling, and not at run-time. So far, only D provides that. D *is* a language designed with these two in mind. Maybe it is the best candidate for replacement....
With templates, you can get at the very least information about the typename, and the debugger shows where *in the template* the crash happened. You cannot get that from preprocessor macros. You cannot even set breakpoints in a macro.
Actually, the C++ committee is quite conservative about new features in the language. They prefer new features by libraries. Thats why D has delegates in the language, and C++0x has std::function in the standard library, for example.
Most of the standards effort is going into template features that few will use and fewer still will use well. Trying to use the template expansion engine as a general purpose macro system is a terrible idea for production code. But it has a big fan club on the standards committee. Worse, the C++ commitee does very little to improve language safety and reliability. Which is why we still have buffer overflows in C++ code, fifteen years in.
Obviously, you never used modern C++ extensively.
Templates are not a macro system, they are a typesafe meta-language. I agree that their syntax sucks, but they are lightyears away from being a simple macro system. And lots of people use them, just look at the STL string or vector. You think few people will use concepts or variadic templates, think again. Generic programming is the actual edge of C++.
I really suggest you read "Modern C++ Design". There you can see perfectly valid examples of how to use templates. Policy-based is a good and powerful example. With this, I can customize my code at compile-time, for example, having a policy which locks a mutex in proper code sections, and another policy with no locks at all. This way, my code *can* be threadsafe, but does not *have* to be (thread safety is useless in a singlethreaded program). Oh yes, I could do that with the preprocessor too, but try debugging this. Also, say goodbye to namespaces, type safety and debugging support.
Safety and reliability have nothing to do with C++ itself. Many people overuse new and delete, without relying on proper RAII constructs, for example. If you think MFC-style C++ is the zenith, you don't know C++. I have been programming C++ for over 7 years and reached a point where memleaks happen extremely rarely (mostly due to rushed code). Its no black arts, no voodoo, just proper C++ usage.
C++ does not "support" functional programming, generic programming, object oriented programming, or even metaprogramming; if you invest a lot of work and effort, you can approximate small subsets of these programming styles in C++, badly. And I have yet to see that it's worth the effort; the best and most common use of C++ still seems to be as a slightly better C.
I use generic programmming and metaprogramming very often in C++. I does pay off. See http://www.antigrain.com/ for an example.
I agree that without templates C++ has no real advantages though.
As said, LISP compilers I know dont beat gcc 4.
C++ is far too complex yes. But there is nothing that can really replace it. A language which supports functional, generic, procedural, object-oriented programming, with static typing, metaprogramming, and heavily geared towards native building? I mean, do you know a language which can resolve iterators to simple pointer arithmetic when compiling? Of course there are far better languages feature-wise, but they all demand some performance penalties. This may or may not be relevant. For example, for video codecs its relevant, as it is for most other realtime stuff (try capturing with Java and its GC for instance).
So, C++ fills a niche. D *may* be a replacement, but I am skeptical. I don't know Eiffel well enough though, this may be a good candidate.
And lets not forget that C++ toolchains are among the most optimized and tested ones. For example, Lisp could be able to reach C++ performance, but doesnt simply because the Lisp toolchains arent as optimized. A simplified example: sometimes SBCL does register->memory->operation->register calls, where g++ optimizes to register->operation. And, the amount of C++ code in existence is staggering.
If you really understand C++, migrating to C# is very easy. C#->C++ however...
but, if we talk about managed languages, I'd go straight for Python or Common Lisp.
Well much of their legacy tech is crap (see WinAPI). But .Net, DirectX, Visual Studio are excellent projects. So, I have no problem with MS tech. I do have a problem with their attitude towards others (that is, crush them and grab every single dollar in the market). MS got unpopular because of their actions, not their tech.
Raytracing is really cool for global stuff like refractions, shadows, reflections, caustics. But in most cases, a rasterizer is better. Yes, raytracing is elegant, but a rasterizer will outperform it when rendering opaque surfaces. You should ask yourself why many CGI studios don't use (pure) raytracers anymore. A hybrid seems the way to go: rasterizing by default, but the ability to shoot rays in the pixel shader, which would be extremely cool for reflections and refractions.
This is NOT a justifiable move forward. A few specs are now mandatory, and that is enough to render expensive hardware obsolete. Now imagine Game X builds upon D3D10.1. Where is the actual progress?
D3D10.1 would be fine if it had new actual features.
Yes, game developers are getting conservative nowadays, and always have been regarding support of new APIs. So many studios will continue using D3D9. But for the same reason many studios still wont switch to OpenGL. In both cases (D3D9->D3D10, D3D9->OpenGL 2.x or even the coming 3.x) the codebase has to be largely rewritten, so when studios MUST upgrade, they will probably prefer OpenGL this time...
But not 32bit floating point texture filtering.
The point is that D3D10.1 mainly just enforces stuff that was optional in 10.0. There are no new killer features. So a game requiring 10.1 will make your shine new 8800 obsolete with absolutely no gain. 9.0b->9.0c saw the addition of stream frequencies among others, which is essential for instancing (D3D10 redesigned the entire instancing thing again). Also, 9.0c was largely compatible with 9.0b. It was mostly a bugfix release with added samples and a couple of new features (which were optional).
And how could the diversity *in*crease? Multiple mutations in a short timeframe?
And see, the prior art issue is the problem. Someone tell me how to invalidate ridiculous patents like Forgent's JPEG one (which actually patents the extremely trivial RLE0+Huffman combination). It is absolutely impossible, because for the court, RLE0+Huffman looks so sophisticated and advanced and whatnot, despite being usually one of the FIRST compression algorithm combinations people write. That is, it has been done a zillion times before Forgent even existed. The right thing to do would be a high penalty fee for Forgent and the USPTO for extorting developers with actual talent using this absurd patent.
Software patents have no justification and need to be eradicated completely. Best thing would be to get rid of Forgent, Acacia, SP etc. as well. Damn parasites. In fact, why shouldn't we make exclusive patent-holding a felony? They help no one, they don't invent anything, on the opposite, they PREVENT innovation.
Thats why peer review might be a good idea. Example:
> The patents in question are for Aloft's "Network Browser Graphical User Interface for Managing Web Content," US patent number 7,117,443, and "Network Browser Window with Adjacent Identifier Selector," US
> patent number 7,194,691 (...). They were filed for in late 2003 and were granted in October of 2006 and March of 2007, respectively. They describe user interfaces in a network browsing window that display
> the content at a specific URL as well as the URL itself somewhere on or around the window.
With peer review, the chance is higher that someone notices some prior art here: web browsers. Which have been around since, oh, 1992?
Additionally, the general concensus should shift. When something is patented, it should not be so damn hard and expensive to invalidate it with proper prior art. In short: patents should not be carved in stone. We have too many patents today, and too many advances to be sure that a patent is 100% valid.
kparts, kioslaves, comparison of kaffeine vs. totem is a 100% win for kaffeine (try TV with totem, TV *recording* with totem), k3b vs. gnomebaker, konqueror vs. nautilus, ..
technically, KDE wins hands down. The UI looks are another matter. (Though that can be pretty too.)
There are certain problems with WIMP.
First, overlapping windows are often undesirable, users either maximize the current window or tile them. An exception are dialogs, which obviously cannot be tiled. (Toolwindows CAN be tiled, however.)
It matches the design principle of an application's GUI: there, no widgets overlap, they are tiled, and/or organized into tabbed groups.
With the advent of large screens (and multi-monitor setups) tiling window managers like ion or wmii become more interesting. Now, something like a tiling KDE would be fine. (Exception to the tiling: dialog windows of course.) Automatically rearranging windows works well in ion, and would be a nice experiment in KDE's kwm.
Then, there is the fact that GUI applications often rely too much on mouse input. The mouse should not be overused, as the user can enter input much faster via the keyboard. Its the input *volume* that often speaks against the keyboard (like, typing this 30-char-filename instead of simply clicking it). Also, the mouse is obviously the input method of choice for 2d input (drawing without the mouse?). But, observe this website for example. Try posting something without using the mouse, ever. It is doable, but easier with the mouse.
Editors are a good example of where the mouse is often overused. Ideally, one never has to use the mouse for editing. vim and emacs shine here, but they have an awful learning curve, because it is hard to grasp all those commands at first. Editors like joe do it better for starters imo. In joe, the right upper corner contains the hint "press Ctrl-K H for help". You press that, and a quick summary appears. Perfect! One is not lost like in vim or emacs, yet the mouse is not necessary.
His point is that the kernels are optimized for servers. That is, focus on throughput, performance, but not latency or responsiveness. A desktop has the latter two as priorities, while sacrificing the former two. As an example, it doesn't matter if that mpeg4 video I/O eats a little more CPU, as long as other tasks don't interrupt its playback.
Guy A says that stealing from the rich, selfish guy is OK, Guy B says stealing is always wrong, since it corrupts. There. Absolute morality?
How about euthanasia? Or people looking for higher goals in life? Etc.
Easy systems of values are always dangerous. Truth is: life is complex, life is confusing, and there is no easy system of values that handles everything well.
This has been invented already.
Its called "copyright".
I disagree with (a). I found Deuteros (very old Amiga game) and Iron Seed (very old PC) game in this year on some abandonware sites, and I was glued to the screen. The same with old RPGs etc. What *really* pisses me off though are bad interfaces, frustrating the hell out of me. Unfortunately, the older the game, the higher the chance gets it has a bad interface.
Range coding is essentially the same as arithmetic coding, but patent-free. It is minimally worse than AC, but the difference is insignificant in practice.
You forgot two other things:
1) Modeling is a very big part of compression, in fact its the one where AI might occur.
2) Huffman is only the optimum for integer symbol sizes. If one symbol has 2.117 bits, it won't be the optimum. If one symbol needs only 0.004 bits, then huffman gives it 1 bit, which is far too large. Arithmetic/range coding address these issues, and come VERY near to entropy, so entropy coding is a solved problem. Which leads me to (1) - its there where research happens.