Improvements are always welcome, but this seems more like a case of a marketing exercise to try and keep C++ in the game as a serious language for general application development, which IMNSHO is something that should have been relegated to legacy systems.
Actually, the improvements are fundamental and the biggest change C++ ever experienced. concepts, lambda, variadic templates, type deduction, these aren't just nice toys. Add into this language-level support for multithreading, garbage collection etc. and you almost get a new language.
Many of the tools you described are in the tr1 already,meaning they are a de-facto standard, and official in C++0x. Using stuff like shared_ptr makes writing custom refcounting unnecessary in ~80-90% of all cases. I suggest you look up TR1, C++0x novelties, and Boost 1.36. Oh, and Modern C++ Design by Alexei Alexandrescu.
And I can say with a straight face that you are wrong.
If you base your experiences on pre-2000s C++, you know very little of modern C++. I have been developing in it for more than 10 years, and a few years ago I would have agreed with you, but things have changed. Really.
Yeah except he's absolutely wrong. C++ makes it much easier to shoot yourself, but the effect is more like dropping an atomic weapon on yourself.
I keep hearing this, and every time I see the actual code, its a horrible mess. C++ has bazillions of features; if people are too stupid to understand them, then they shall not blame it on the language. The same people abhor Lisp because its so complicated, Haskell because its so alien etc. and stay in C#/Java wonderland.
Of course there are problems with C++, like the horrible, over-complicated syntax, slow compilation, etc. but most people dont come even close to these.
I'll consider Java and C# as C++ replacements once they get:
REAL templates, not this generics joke
Proper RAII, which many programmers mistakenly believe to be useful for memory management ONLY (scoped locks come to mind) (Java/C# finalizers are no replacement)
Java: operator overloading
These points are serious, especially the first, without real templates, generic programming/metaprogramming at compile-time is not possible. These two are one of C++'s biggest strenghts, though.
To be fair, C# 3.0 is somewhat nice, especially its functional core. Java is a totally uninteresting language with very small expressiveness. Of course, if the job requires it, there is no discussion, but in my spare time, I prefer C++.
Yet again, somebody thinks Raytracing is a magical wand which automatically improves image quality.
Here's the deal:
1) Raytraced shadows do NOT look real. Better than shadowmaps, but not real (they are too sharp). Casting multiple shadows to soften it is expensive, and causes banding if done poorly.
2) Raytracing does NOT improve lighting. It makes shadows easy, yes, but the lighting equation(s) remain the same. Pure raytracing takes into account only direct lighting; indirect lighting is left out, and belongs to the area of global illumination techniques, which are more or less orthogonal to the direct rendering method (meaning they can be used with both rasterization and raytracing).
3) The only real speed gain of raytracing is in the secondary ray scenario (e.g. indirect stuff like refractions, reflection, shadows etc.) For primary rays, the rasterizer is better, BECAUSE the rasterizer is nothing else than a special case of raytracing where the actual tracing can be optimized away and the coefficients between the vertices can be linearly interpolated. It is totally stupid to use raytracing here. Example: a grey concrete wall. Rasterization delivers perfectly correct results here easily. So, use rasterization when possible, raytracing when necessary. Rasterization will always be faster than raytracing for these cases, and we are still far away from the point when the actual speed gain is negligible.
4) The X million triangles per second counts are irrelevant in games. (And, consumer 3D cards are typically used for games.) Games favor less complex models, but with complex materials. There are subtle but important benefits from texture mapping vs. high-detail models, one being the fact that details applied to textures are much less affected by aliasing, while high-detail models tend to flicker intensely, unless very high AA levels are employed. Also, raytracing has significant issues regarding cache coherency, even with bundled rays. Rasterizes just fetch and interpolate all the time; cache coherency is trivial here.
Its about the ratio of nourishment stored as fat. Its normal that a part of what you eat ends up as fat, but if your metabolism is way off, this part can be much larger. Then there are people who don't get fat even after eating tons of food - usually they have an atypical metabolism as well.
A) is true, and the reason I talked about a hybrid - the benefits in (A) come from secondary ray effects.
B) is true, but irrelevant IRL, because games usually put the complexity on the shaders/materials, NOT on the geometry. Highly detailed geometry is painful to edit, and suffers from visible aliasing. It is much more efficient to bake tiny details into texture maps. The one reason why geometry complexity could increase is usally instancing, like, 10000 soldiers, or a forest where the trees near to the camera are all fully rendered (the trees far away are approximated with impostors).
What you missed is that rasterizers can be very cache friendly with ease, whereas raytracers require non-trivial changes - and especially for complex scenes, cache coherency is VERY important. Also, for the opaque diffuse surfaces rasterization IS an optimization, as said. This means that it will always be more efficient than raytracing in this narrow domain. Many years will pass before rendering diffuse opaque surfaces using raytracing is only slightly slower than by using rasterization. Until then, I have the option of either rendering a room with 100% raytracing, or an entire city using a hybrid.
As a general rule, raytracing excels at secondary-ray tasks (= when one additional ray is shot originating from point of impact of the first, primary ray) like shadows, reflections, refractions, and the like, but doesn't pay off for primary-ray only tasks (solid wall, ground,...) This is because rasterization is an optimization for the primary-ray-only case - you need local information only, no need to shoot rays for the entire surface, you can interpolate across it.
Now, those doorknobs will make... how much % of the visible frame? In typical game scenes, opaque surfaces are the majority. This is not because of hardware limitations, but simply because most game worlds are NOT full of shiny surfaces.
A hybrid is the best approach. You correctly guessed that with rasterization, secondary-ray effects need to be calculated in multiple (and costly) passes. Moreover, since these passes usually render to a texture, you get aliasing issues because the texture pixels do not 1:1 match the screen pixels. You get blocky shadowmaps, blocky reflections, or noticeable noise when moving (in case the map is too large).
First, adding Linux means adding TONS of work for support. Linux distros are much less static than Windows or OSX - the platform can vary greatly. This makes support very hard, this is why id and Epic do not give support for their ports.
Also, OSX and Linux have many subtle differences which might catch you off-guard. Expect lots of testing and debugging.
When we move to consoles its a different story altogether. Forget about one cross-platform toolkit, the platforms are too diverse. If you want to exploit the raw power of, say, the PS3, you NEED to do a real port. Write the code as modular as possible, but expect rewrites. Forget about using the SDL on the PS3, for instance, or OpenGL - if you want full power, you program the chipset directly. Also, a cross-platform toolkit ends up consuming resources, something you often cannot afford (a good example is the PS2 with its lousy 32MB RAM). In short, a simple cross-compile won't do the trick, unfortunately.
Indeed. This idea is why I admire Scheme (though it might be a bit too small:) ). In my opinion, lots of C++ bits could be scrapped, starting with the C legacies.
Templates of course. They are C++'s true strength, and its main weakness thanks to the syntax and the turing completeness being an accident rather than a design decision.
On a sidenote, C++ HAS for_each in the STL. lambda constructs are available in Boost (Boost.Lambda, Boost.Phoenix), and a true lambda will come in C++0x.
Indeed I have - as an academic curiosity. Especially the type system would be an interesting playground - instead of primitive and structured types in C style, I'd think about more Haskell-like ones. Also, I would specify access and traversal semantics (in case its a compound type), treating variables like fiber bundles (or maybe even sheafs).
It is absolutely out of the question for production stuff of course. But I am not sure about Java byte code. IIRC it works at a high level, knowing about classes etc. this makes heterogenous templates a challenge. Or am I mistaken and homogenous templates are purely a Java issue? If not, LLVM might be more interesting.
This is such a C++ attitude! You missed the part where I said "But there is a lot of accidental difficulty in C++, thats right". If a language is more flexible and powerful, it is also more difficult to master it in its entirety. Its pathetically easy to comprehend procedural programming. Its a little harder to comprehend all the things that are possible with Lisp. THIS is inherent difficulty. Usually, the accidental difficulty (= avoidable problems; stuff like the ugly C++ template syntax for example) is orders of magnitude larger, in C++ its so large the inherent one is almost nonexistant.
Of course Lisp eats C++ for breakfast. I never disputed that. If it were by me, Lisp would be king - I have written this already (but not in the GP). The main problems with Lisp are the less polished toolchain (which is understandable - C++ has a slightly bigger audience than Lisp) and a niche position. None of the two reasons are inherently Lisp-centric, or somehow the result of the language, but unfortunately, today C++, C, C#, Java are the rulers. Unless you write a self-contained program in your spare time, or end up in a niche business, you will hardly get to code Lisp.
And trust me, writing self-manipulating code in CL *does* feel good. Writing homoiconic pure functional collision detection code is pure gold. Etc.
Somewhere else I wrote that one of C++'s weaknesses is the absence of reflection. But I actually think its more of a platform issue rather than a pure language one. I think it was the wrong decision to leave dynamic library handling up to the platform, and not standardize it like Java.class and C#/.net assemblies. Such a thing *is* being considered for C++0x, though. Also, LLVM is likely to have this.
Oh, and #include indeed is one ugly hack. Unfortunately, modules have been voted down. Curse them for this:( But for errors and compilation speed there is hope in sight. Concepts will make sure the errors happen where they should (and not somewhere else deep within the template), variadic templates will significantly reduce template complexity (because you no longer need N versions for max N parameters), and delayed template instantiation will make sure the template is not instantiated X times (this one is the real killer).
Yes, I've seen C# 3.0 functional stuff, and its wonderful. I am glad to see progress in C#. Now, extend generics with the C++ template power (minus its problems), and C# will own:) But its undeniable that C# makes progress while Java doesn't. If this continues, Java will be left in the dust. I also think it should be easier to add true templates to C#, since its generics are already heterogenous. MS, look at D for an example!
One more thing: D compiles incredibly fast, too, and almost reaches C++'s expressiveness. Its still a bit immature, but I definitely recommend watching D 2.0.
I would like a language with the *power* of C++ (i.e. multiparadigmatic, metaprogrammable, turing-complete templates, generic programming, operator overloading - which only makes sense with generic programming -...) but WITHOUT its many weaknesses and errors (like the dreaded template syntax). Metaprograms get unreadable quickly. Also, C++ still lacks a standardized reflection mechanism. And the compile time is abysmal too.
D is a hot candidate, but is quite unpolished and unfinished (don't bother lookin at 1.0, wait for 2.0), and doesnt have the same momentum C++ and Java have. I see them on a good path, though.
Can I use a vector as a template parameter? No.
That can never be standard, because arrays of different things require different output methods. Still, it's pretty simple to write a template streaming operator to do something reasonable. Um, this CAN be standard, because the output of the container type is orthogonal to the container itself. TR1 tuple has a standard output, for example. int i[j]; cout << i; could yield [1, 2, 3, 4]. string s[j]; cout << s; yields ["some", "strings"]. The container takes care of [ , and ] - the values are handled by the container's value type.
Well, duh. Any "object" does exactly that, in any language. Other languages just hide the things wrapped and pretend they don't exist, just as you don't seem to even know they exist. Yes, Java containers have a low-level implementation too, you just can't hack it within the language. The difference lies in the semantics available to the compiler at compile-time. I cannot use arrays as template parameters in C++ because the compiler doesn't HAVE arrays as explicit types - they just exist as constructs. I cannot perform compile-time overflow checks or slicing. First-class arrays don't have aliasing issues. etc.
And it isn't now? gcc is perfectly capable of performing basic operations (like strlen, or printf format checking) on strings. Or are you talking about something else entirely? "First-class arrays"? WTF? Learn what compile-time means, grasshopper. So far, only D has first-class arrays (among the C++ derivatives). Try doing something like the regexp compiler (scroll to the middle of the page): http://digitalmars.com/d/2.0/templates-revisited.html
Of course, everyone here automatically knows what a DSEL is. It's soooo obvious. It must stand for Dumb S*** Easy Language. Domain Specific Embedded Language.
You mix Java the language and Java the platform. The platform is excellent, I agree. The LANGUAGE is a bastardized lobotomized C++. "Java is C++ minus its weaknesses and strengths."
Its easy to find a language that is more powerful than Java. Python, Perl, Lisp, Haskell, C++, Scheme, Clean, Smalltalk, Objective-C,....
For business, there is little chance to avoid Java. But please, separate the language from the platform.
I've yet to meet a Ruby, PERL, or PHP advocate who I would consider to be a good software developer. Ironically, I've yet to meet a C++ developer who has difficulties learning Java (same goes to Haskell/Lisp/etc. developers), and on the other hand a Java developer that can pick up C++ with ease. (And not just tiny bits of it - boost/STL-class C++.) I have no doubt that great Java developers exist - the language is ultimately secondary, after all. But if I wish to build shiny new houses, I don't choose a cheap hammer.
I thought it gave developers too much rope when it first came out and the rope has only gotten longer. More powerful languages require more studies. The inherent difficulty always increases with increased ability. But there is a lot of accidental difficulty in C++, thats right. Let me emphasize one thing here: I don't think C++ is the pinnacle of programming. Far from it. But its undeniably powerful, and there is no other language that has this amount of expressiveness and range. Java and C# are severely limited in comparison. Python and Lisp are much more flexible, but at the cost of performance. Where else can I write metaprograms that construct a code path at compile-time, for example? With all the compile-time optimizations applied to the result?
I also gave examples already. Try replicating Boost.Fusion or Boost.Proto in C# or Java. Try replicating Blitz++, or Spirit. Try generic programming in C++, then in Java and C# (you'll curse at the latter two's generics). Look up what's possible with C++ metaprograms (-> Boost.MPL & Fusion). Read books from Scott Meyers and Alexei Alexandrescu (especially Modern C++ Design).
If you want to compare LOC, compare an email client written in Java versus one written in C++ --or-- compare an html push app written in Perl versus one written in C++. C++ won't even come close, because, that's not what it was designed for. But using metaprogramming you can write enough tools to come close in C++. You seem to be trapped in arpa/inet.h or land - try writing a HTTP server or an email client in C++ using boost (especially boost.asio), THEN compare the LOC. (In fact, there is a HTTP server example supplied with asio.)
Lets make the comparison fair - write an email client WITHOUT the Java Standard Library. Just a thin wrapper over the socket API and the system, one that equals the C++ stdlib. I even go as far as saying that with asio, boost, and tr1, I could beat Java's LOC WITH its standard library. (Generally, when a problem demands high language expressiveness, Java's LOC count goes through the roof.)
A lot of the arguments against C++ originate from obsolete C++ code and practices. This is 2008, folks. MFC-style C++ has less than 1% in common with modern C++.
Generic Programming in general is impossible in C# because of underpowered generics. Unless stuff like
template void random(Container &container, Accessor const &accessor) {
for (unsigned int i = 0; i (i) = typename Accessor::value_type(std::rand()); }
is possible in C#, this argument holds. (Note that this is an artificial example I came up with; for a good example of real-world usage, check out Adobe GIL).
C++'s true power lies in its templates. Templates are turing complete, meaning that they for a meta language. Using this meta language, I can adapt code to a specific situation. For example, I can have compile-time polymorphism, which is very useful when there is enough information while compiling to choose the actual type. I can have a list of factory class types, and do a call like create_image (img); which gets compiled to the actual creator function ONLY. No virtual functions, the compiler can even inline without problems. Yes, a JIT could detect that function X has been used with the same parameters for 400 seconds, but this way, I can rationalize unnecessary runtime overhead right from the start. Yet another use was to generate code paths that only differed in pixel format type. I wrote a templated version, and iterated over a list of enums at compile-time. This helped a lot in being cache friendly while not requiring to clone tons of code. Using templates, one can write scientific computing code that rivals even Fortran in terms of performance. See: http://www.oonumerics.org/blitz/
I know C# 3.0 has a functional core, and this is wonderful - many problems can be solved much easier and cleaner with functional style. Generic programming and metaprogramming are the things I sorely miss. I would really like to have a language that has all the strengths of C++, minus its weaknesses (most notably C legacy, hideous template syntax, #include files). So far, D is the closest one, but its not there yet. Also, C++ has an ENORMOUS momentum...
I *know* how memory and pointers work. I have been using C since 93. I also didnt say objects, I said entities. Arrays as first-class entities already exist for the stack (well, sort of). Also, arrays STILL aren't first-class entities in C++, vector just wraps the allocation and access facilities. With first-class arrays, compile-time string parsing would be possible in C++, for instance - this would make writing DSELs a trivial task.
Also note that C99 finally acknowledged the usefulness of first-class arrays to a small degree; int i = 50; char c[i]; works, for example. (It equals char *c = malloc(sizeof(char) * i).)
Slashdot Mirror
Improvements are always welcome, but this seems more like a case of a marketing exercise to try and keep C++ in the game as a serious language for general application development, which IMNSHO is something that should have been relegated to legacy systems.
Actually, the improvements are fundamental and the biggest change C++ ever experienced. concepts, lambda, variadic templates, type deduction, these aren't just nice toys. Add into this language-level support for multithreading, garbage collection etc. and you almost get a new language.
Many of the tools you described are in the tr1 already,meaning they are a de-facto standard, and official in C++0x. Using stuff like shared_ptr makes writing custom refcounting unnecessary in ~80-90% of all cases. I suggest you look up TR1, C++0x novelties, and Boost 1.36. Oh, and Modern C++ Design by Alexei Alexandrescu.
And I can say with a straight face that you are wrong.
If you base your experiences on pre-2000s C++, you know very little of modern C++. I have been developing in it for more than 10 years, and a few years ago I would have agreed with you, but things have changed. Really.
Yeah except he's absolutely wrong. C++ makes it much easier to shoot yourself, but the effect is more like dropping an atomic weapon on yourself.
I keep hearing this, and every time I see the actual code, its a horrible mess. C++ has bazillions of features; if people are too stupid to understand them, then they shall not blame it on the language. The same people abhor Lisp because its so complicated, Haskell because its so alien etc. and stay in C#/Java wonderland.
Of course there are problems with C++, like the horrible, over-complicated syntax, slow compilation, etc. but most people dont come even close to these.
Well, if you use generic programming properly, you can in fact beat C with C++. Expression templates are an example.
I'll consider Java and C# as C++ replacements once they get:
These points are serious, especially the first, without real templates, generic programming/metaprogramming at compile-time is not possible. These two are one of C++'s biggest strenghts, though.
To be fair, C# 3.0 is somewhat nice, especially its functional core. Java is a totally uninteresting language with very small expressiveness. Of course, if the job requires it, there is no discussion, but in my spare time, I prefer C++.
Yet again, somebody thinks Raytracing is a magical wand which automatically improves image quality.
Here's the deal:
1) Raytraced shadows do NOT look real. Better than shadowmaps, but not real (they are too sharp). Casting multiple shadows to soften it is expensive, and causes banding if done poorly.
2) Raytracing does NOT improve lighting. It makes shadows easy, yes, but the lighting equation(s) remain the same. Pure raytracing takes into account only direct lighting; indirect lighting is left out, and belongs to the area of global illumination techniques, which are more or less orthogonal to the direct rendering method (meaning they can be used with both rasterization and raytracing).
3) The only real speed gain of raytracing is in the secondary ray scenario (e.g. indirect stuff like refractions, reflection, shadows etc.) For primary rays, the rasterizer is better, BECAUSE the rasterizer is nothing else than a special case of raytracing where the actual tracing can be optimized away and the coefficients between the vertices can be linearly interpolated. It is totally stupid to use raytracing here. Example: a grey concrete wall. Rasterization delivers perfectly correct results here easily. So, use rasterization when possible, raytracing when necessary. Rasterization will always be faster than raytracing for these cases, and we are still far away from the point when the actual speed gain is negligible.
4) The X million triangles per second counts are irrelevant in games. (And, consumer 3D cards are typically used for games.) Games favor less complex models, but with complex materials. There are subtle but important benefits from texture mapping vs. high-detail models, one being the fact that details applied to textures are much less affected by aliasing, while high-detail models tend to flicker intensely, unless very high AA levels are employed. Also, raytracing has significant issues regarding cache coherency, even with bundled rays. Rasterizes just fetch and interpolate all the time; cache coherency is trivial here.
.....
No, its not about magically created fat.
Its about the ratio of nourishment stored as fat. Its normal that a part of what you eat ends up as fat, but if your metabolism is way off, this part can be much larger. Then there are people who don't get fat even after eating tons of food - usually they have an atypical metabolism as well.
A) is true, and the reason I talked about a hybrid - the benefits in (A) come from secondary ray effects.
B) is true, but irrelevant IRL, because games usually put the complexity on the shaders/materials, NOT on the geometry. Highly detailed geometry is painful to edit, and suffers from visible aliasing. It is much more efficient to bake tiny details into texture maps. The one reason why geometry complexity could increase is usally instancing, like, 10000 soldiers, or a forest where the trees near to the camera are all fully rendered (the trees far away are approximated with impostors).
What you missed is that rasterizers can be very cache friendly with ease, whereas raytracers require non-trivial changes - and especially for complex scenes, cache coherency is VERY important. Also, for the opaque diffuse surfaces rasterization IS an optimization, as said. This means that it will always be more efficient than raytracing in this narrow domain. Many years will pass before rendering diffuse opaque surfaces using raytracing is only slightly slower than by using rasterization. Until then, I have the option of either rendering a room with 100% raytracing, or an entire city using a hybrid.
As a general rule, raytracing excels at secondary-ray tasks (= when one additional ray is shot originating from point of impact of the first, primary ray) like shadows, reflections, refractions, and the like, but doesn't pay off for primary-ray only tasks (solid wall, ground, ...) This is because rasterization is an optimization for the primary-ray-only case - you need local information only, no need to shoot rays for the entire surface, you can interpolate across it.
... how much % of the visible frame? In typical game scenes, opaque surfaces are the majority. This is not because of hardware limitations, but simply because most game worlds are NOT full of shiny surfaces.
Now, those doorknobs will make
A hybrid is the best approach. You correctly guessed that with rasterization, secondary-ray effects need to be calculated in multiple (and costly) passes. Moreover, since these passes usually render to a texture, you get aliasing issues because the texture pixels do not 1:1 match the screen pixels. You get blocky shadowmaps, blocky reflections, or noticeable noise when moving (in case the map is too large).
Unfortunately, its not as easy.
First, adding Linux means adding TONS of work for support. Linux distros are much less static than Windows or OSX - the platform can vary greatly. This makes support very hard, this is why id and Epic do not give support for their ports.
Also, OSX and Linux have many subtle differences which might catch you off-guard. Expect lots of testing and debugging.
When we move to consoles its a different story altogether. Forget about one cross-platform toolkit, the platforms are too diverse. If you want to exploit the raw power of, say, the PS3, you NEED to do a real port. Write the code as modular as possible, but expect rewrites. Forget about using the SDL on the PS3, for instance, or OpenGL - if you want full power, you program the chipset directly. Also, a cross-platform toolkit ends up consuming resources, something you often cannot afford (a good example is the PS2 with its lousy 32MB RAM). In short, a simple cross-compile won't do the trick, unfortunately.
Indeed. This idea is why I admire Scheme (though it might be a bit too small :) ). In my opinion, lots of C++ bits could be scrapped, starting with the C legacies.
Ok, the code example was truncated thanks to the < > symbols. In hindsight, it wasn't a good example anyway. Instead, I recommend looking at Adobe's presentations, which are full of C++ wonders: http://stlab.adobe.com/wiki/index.php/Papers_and_Presentations
And of course the GIL:
http://opensource.adobe.com/wiki/display/gil/Generic+Image+Library
Templates of course. They are C++'s true strength, and its main weakness thanks to the syntax and the turing completeness being an accident rather than a design decision.
On a sidenote, C++ HAS for_each in the STL. lambda constructs are available in Boost (Boost.Lambda, Boost.Phoenix), and a true lambda will come in C++0x.
Indeed I have - as an academic curiosity. Especially the type system would be an interesting playground - instead of primitive and structured types in C style, I'd think about more Haskell-like ones. Also, I would specify access and traversal semantics (in case its a compound type), treating variables like fiber bundles (or maybe even sheafs).
It is absolutely out of the question for production stuff of course. But I am not sure about Java byte code. IIRC it works at a high level, knowing about classes etc. this makes heterogenous templates a challenge. Or am I mistaken and homogenous templates are purely a Java issue? If not, LLVM might be more interesting.
Nope, never used Groovy.
Of course Lisp eats C++ for breakfast. I never disputed that. If it were by me, Lisp would be king - I have written this already (but not in the GP). The main problems with Lisp are the less polished toolchain (which is understandable - C++ has a slightly bigger audience than Lisp) and a niche position. None of the two reasons are inherently Lisp-centric, or somehow the result of the language, but unfortunately, today C++, C, C#, Java are the rulers. Unless you write a self-contained program in your spare time, or end up in a niche business, you will hardly get to code Lisp.
And trust me, writing self-manipulating code in CL *does* feel good. Writing homoiconic pure functional collision detection code is pure gold. Etc.
Somewhere else I wrote that one of C++'s weaknesses is the absence of reflection. But I actually think its more of a platform issue rather than a pure language one. I think it was the wrong decision to leave dynamic library handling up to the platform, and not standardize it like Java .class and C#/.net assemblies. Such a thing *is* being considered for C++0x, though. Also, LLVM is likely to have this.
:(
:) But its undeniable that C# makes progress while Java doesn't. If this continues, Java will be left in the dust. I also think it should be easier to add true templates to C#, since its generics are already heterogenous. MS, look at D for an example!
Oh, and #include indeed is one ugly hack. Unfortunately, modules have been voted down. Curse them for this
But for errors and compilation speed there is hope in sight. Concepts will make sure the errors happen where they should (and not somewhere else deep within the template), variadic templates will significantly reduce template complexity (because you no longer need N versions for max N parameters), and delayed template instantiation will make sure the template is not instantiated X times (this one is the real killer).
Yes, I've seen C# 3.0 functional stuff, and its wonderful. I am glad to see progress in C#. Now, extend generics with the C++ template power (minus its problems), and C# will own
One more thing: D compiles incredibly fast, too, and almost reaches C++'s expressiveness. Its still a bit immature, but I definitely recommend watching D 2.0.
I would like a language with the *power* of C++ (i.e. multiparadigmatic, metaprogrammable, turing-complete templates, generic programming, operator overloading - which only makes sense with generic programming - ...) but WITHOUT its many weaknesses and errors (like the dreaded template syntax). Metaprograms get unreadable quickly. Also, C++ still lacks a standardized reflection mechanism. And the compile time is abysmal too.
D is a hot candidate, but is quite unpolished and unfinished (don't bother lookin at 1.0, wait for 2.0), and doesnt have the same momentum C++ and Java have. I see them on a good path, though.
In fact, your template suggestion proves this.
Its easy to find a language that is more powerful than Java. Python, Perl, Lisp, Haskell, C++, Scheme, Clean, Smalltalk, Objective-C,
For business, there is little chance to avoid Java. But please, separate the language from the platform. I've yet to meet a Ruby, PERL, or PHP advocate who I would consider to be a good software developer. Ironically, I've yet to meet a C++ developer who has difficulties learning Java (same goes to Haskell/Lisp/etc. developers), and on the other hand a Java developer that can pick up C++ with ease. (And not just tiny bits of it - boost/STL-class C++.) I have no doubt that great Java developers exist - the language is ultimately secondary, after all. But if I wish to build shiny new houses, I don't choose a cheap hammer.
I also gave examples already. Try replicating Boost.Fusion or Boost.Proto in C# or Java. Try replicating Blitz++, or Spirit. Try generic programming in C++, then in Java and C# (you'll curse at the latter two's generics). Look up what's possible with C++ metaprograms (-> Boost.MPL & Fusion). Read books from Scott Meyers and Alexei Alexandrescu (especially Modern C++ Design). If you want to compare LOC, compare an email client written in Java versus one written in C++ --or-- compare an html push app written in Perl versus one written in C++. C++ won't even come close, because, that's not what it was designed for. But using metaprogramming you can write enough tools to come close in C++. You seem to be trapped in arpa/inet.h or land - try writing a HTTP server or an email client in C++ using boost (especially boost.asio), THEN compare the LOC. (In fact, there is a HTTP server example supplied with asio.)
Lets make the comparison fair - write an email client WITHOUT the Java Standard Library. Just a thin wrapper over the socket API and the system, one that equals the C++ stdlib. I even go as far as saying that with asio, boost, and tr1, I could beat Java's LOC WITH its standard library. (Generally, when a problem demands high language expressiveness, Java's LOC count goes through the roof.)
A lot of the arguments against C++ originate from obsolete C++ code and practices. This is 2008, folks. MFC-style C++ has less than 1% in common with modern C++.
Stuff like this:
http://boost-sandbox.sourceforge.net/libs/proto/doc/html/boost_proto/users_guide/examples/lazy_vector.html
Generic Programming in general is impossible in C# because of underpowered generics. Unless stuff like
template
void random(Container &container, Accessor const &accessor)
{
for (unsigned int i = 0; i (i) = typename Accessor::value_type(std::rand());
}
is possible in C#, this argument holds. (Note that this is an artificial example I came up with; for a good example of real-world usage, check out Adobe GIL).
Another example: http://www.gsse.at/multiprogramming/
C++'s true power lies in its templates. Templates are turing complete, meaning that they for a meta language. Using this meta language, I can adapt code to a specific situation. For example, I can have compile-time polymorphism, which is very useful when there is enough information while compiling to choose the actual type. I can have a list of factory class types, and do a call like create_image (img); which gets compiled to the actual creator function ONLY. No virtual functions, the compiler can even inline without problems. Yes, a JIT could detect that function X has been used with the same parameters for 400 seconds, but this way, I can rationalize unnecessary runtime overhead right from the start. Yet another use was to generate code paths that only differed in pixel format type. I wrote a templated version, and iterated over a list of enums at compile-time. This helped a lot in being cache friendly while not requiring to clone tons of code. Using templates, one can write scientific computing code that rivals even Fortran in terms of performance. See: http://www.oonumerics.org/blitz/
I know C# 3.0 has a functional core, and this is wonderful - many problems can be solved much easier and cleaner with functional style. Generic programming and metaprogramming are the things I sorely miss. I would really like to have a language that has all the strengths of C++, minus its weaknesses (most notably C legacy, hideous template syntax, #include files). So far, D is the closest one, but its not there yet. Also, C++ has an ENORMOUS momentum...
I *know* how memory and pointers work. I have been using C since 93. I also didnt say objects, I said entities. Arrays as first-class entities already exist for the stack (well, sort of). Also, arrays STILL aren't first-class entities in C++, vector just wraps the allocation and access facilities. With first-class arrays, compile-time string parsing would be possible in C++, for instance - this would make writing DSELs a trivial task.
Also note that C99 finally acknowledged the usefulness of first-class arrays to a small degree; int i = 50; char c[i]; works, for example. (It equals char *c = malloc(sizeof(char) * i).)
Repeat after me:
C++ is NOT a "Microsoft language".