The author says he is content with C++ the way it is, yet he bemoans the good deal of time between major changes in the standard.
This is a little inconsistent. As a language that takes a long time to master, changing fundamental features of the language every 3rd year, for instance, would be a bit difficult to keep up with. Furthermore, the niche C++ lives in isn't one that needs to change every year. For some users, language stability and backwards compatibility are key, and with things like Boost, additions to C++ can be tried out in the wild for many years before being standardized (as many features slated for the newest standard were).
I see how that could sound inconsistent. But I'm not bemoaning the time it takes between changes to the standard as much as pointing out that these long intervals show that the language is done. I'd rather see the standards committee give up than hurry up.
It's fine for a language to be "done" or "over." It's still important until it has been replaced for practical purposes by another language. Until then, why not keep making improvements? I wouldn't put C++ on my list of favorite languages, but I expect my C++ skills to be an asset for a long time to come.
As always when talking about the continued relevance of C++, I will celebrate when I'm proved wrong.
I see your point, but agree with the parent comment more. The current state of the C++ just doesn't require the committee to hurry up, and the language is not done, even if it would take five more years to have new standard approved.
As I see it, the new standard just isn't something which would change the future of C++ in some significant way, and it is not the most pressing problem C++ has as a language.
From my perspective, what I would like to see more is some alternative to boost, with similar functionality but without that meta-meta-programming. ;-) Simply, more cross-platform libraries comprehensible for the average C++ programmers.
I've written in C++ professionally almost 12 years (17 years counting College), and in my opinion it is a shame how the language has not evolved properly.
Unsolved things:
- Unified C++ ABI call for making shared libraries without worrying about compiler manufacturer or version.
- Massive bloat. Take a look to the Boost libraries and cry.
- Poor debugging tools for templates (debugging templates it is crazy, and the promise of easy template debugging is almost a decade old).
Ridiculous things (in my opinion):
- Obsession for doing everything in "user-land" (e.g. source code templates) instead of built-in abstractions at object code-generation time instead of compile-time.
- Willing to introduce functional programing in the language, when, in my opinion, it makes more sense just to interface with true functional code (e.g. via SBCL).
C++ hour will come, with a non-bloated, system-software capable, "better than C", which could be labeled "simple C++", as in "simple English".
The thing I don't understand is that you go to the boost library website and you see that it touts itself as an all-volunteer effort.
Who are these people who volunteer their time to produce this massively bloated, over-elaborated code? What is their motivation? What's going on here? I understand bureaucracies usually bureaucrats are paid and produce code and memos to expand and control their turf. But here? What's up?
Boost certainly seems well done for what it is. But does this particular niche attract so many people?
Your complaints seem focused on poor implementations and not the language itself. You don't want C++ language evolution, you want tool support evolution.
Also, as far as I know, most compilers were settling on a fairly standardized IA64 ABI, even for other platforms. The problem gcc had, last I checked, was after every release, they found a bug in the implementation and fixing it made the next release incompatible, but the goal was to be interoperable.
> Unified C++ ABI call for making shared libraries without worrying about compiler manufacturer or version.
There's too many implementation decisions for this to be feasible. E.g., you'd have to standardize exception handling implementations and object layouts.
In practice, GCC has tried to standardize a C++ ABI for some platforms, but each proposed "standard ABI" has been buggy and required at least moderately backward-incompatible ABI changes between GCC releases.
> Massive bloat. Take a look to the Boost libraries and cry.
Define "bloat"? Large parts of Boost are absolutely horrid (e.g. Spirit), but I don't know what you mean by "bloat". Do you mean that the resulting object code is big?
> Poor debugging tools for templates (debugging templates it is crazy, and the promise of easy template debugging is almost a decade old).
> Obsession for doing everything in "user-land" (e.g. source code templates) instead of built-in abstractions at object code-generation time instead of compile-time.
Huh? What do you mean by "built-in abstractions at object code-generation time"?
> C++ hour will come, with a non-bloated, system-software capable, "better than C", which could be labeled "simple C++", as in "simple English".
I was hoping that Digital Mars D would be the "Simple C++", but it feels like D is losing momentum.
(Sidenote: I've been programming in C++ for about 13 years, and am a recovering C++ "language lawyer".)
> I was hoping that Digital Mars D would be the "Simple C++"
I was hoping for the same for a long time. Now my favourite "simple C++" is OOC (http://ooc-lang.org/). The syntax is a bit different (partially justified by faster parsing/compilation and has a lot of nice sugar), but it does support a lot of the good stuff: classes, generics, ability to use C-layout structures and attach "methods" to them, closures, pointers to allow easy C libs interaction and more...
"Massive bloat. Take a look to the Boost libraries and cry."
Aside from your tears, what is the evidence that boost is bloated? Too slow? Too much source code? Too many files?
I've been using Boost for nearly a decade. It does a ton of useful stuff (from template metaprogramming to fast matrix algebra), it's loosely coupled, and it's insanely fast. Given it's scope, it's the least bloated library of which I know.
C++ has been evolving, but for the last decade, all of the evolutionary changes have come in the world of templates and template metaprogramming. I think this is hard on the people who have restricted themselves to the C-with-classes mentality. They're missing every modern development in the language since ~1998.
There is bloat and there is bloat. I'm currently playing with a 200-line file that is mostly a wrapper around a subset of boost::polygon (basically it's a single-type specialization wrapped in a simpler API).
With gcc 4.4.5 and -O2, this one small file takes 22 seconds (!) to compile and produces a 14MB output file.
I guess that's... tolerable. But it isn't "lean" in any meaningful sense.
I don't know who your audience is. I understand that most (about 2/3) of that data is symbol information. The complaint was obviously that a 200 line file generates 8MB of symbols and takes longer to compile than the rest of the project put together. And the existence of this 200 line file is precicely a pimpl attempt to isolate the C++ brain damage as much as possible.
Your point seems to just be agreement with mine: C++ bloat is tolerable. It's still bloat.
Perhaps C++ will finally become a scripting language. So you don't get to complain about the compilation cost.
Seriously, I think it's too much trick to do meta-programming in the language. If meta-programming should be allowed, it should be easier, simpler, and for the ordinary people. Just like Ruby.
I agree very much, good comment. I think meta-programming in a language such as C makes a lot of sense, as you want to be able to generate efficient, compiled code, with as little developer effort as possible. Metaprogramming makes it possible to specialize abstract types, data structures, and so on.
But why does the metaprogramming syntax in C have to be so convoluted, bloated and difficult? Do we really need >30 second compile times per file on recent CPUs? If a language is hard to parse both for computers and humans, something went wrong. It should be easy to read for one of both, preferably both.
Also a lot of the template aerobatics generate a ginormous number of symbols which massively increase the binary size and cache pressure. In a former life I ripped out a pile of heavily templated code using Boost and replaced it with a well placed virtual function or three and dramatically reduced the cache misses in the application.
I've always seen Boost (and to a large extent the STL) as a demo library to show off what's possible with templates rather than something to be used in everyday code and have worked on a number of projects which forbade both.
There's a large rift in the C++ world between what I generally label Qt and Boost camps. The Boost people see the Qt folks as Java-esque dimwits that can't be bothered to learn the full extent of C++'s power and the Qt folks see the Boost following as unpragmatic architecture astronauts.
"It's actually not all that fast in a lot of cases. Boost's matrix manipulation support is particularly slow"
You've picked a benchmark of the most highly optimized matrix algebra libraries, and found that uBLAS is mid-pack, even though a) it isn't particularly optimized for any platform, and b) its goal is to result in the clearest possible syntax without sacrificing adequate performance. Talk about picking nits.
"Also a lot of the template aerobatics generate a ginormous number of symbols which massively increase the binary size and cache pressure."
When it really matters (which it rarely ever does): man strip
"I've always seen Boost (and to a large extent the STL) as a demo library to show off what's possible with templates rather than something to be used in everyday code"
I worked on shipping commercial products that used boost and the STL, and I did nearly all of my speed-sensitive code with it in grad school. It's far more than a demo library. Like I said before, you don't have to use all of it to use some of it.
First of all, please provide recent benchmarks (GCC 4.2 is not recent) on multiple OSes that test more than one small subset of Boost. Otherwise your statements about performance are doubtful at best.
Second of all, those symbols will have an effect on compile times, but they should certainly be stripped out by the linker. Why would symbols that do nothing sit in the executable?
Thirdly, Boost's purpose is to iterate faster than the C++ standard library and have real-world data about what libraries work and are needed. Those libraries would then be included in next C++ standards, as it has happened with TR1.
There are useful libraries inside Boost and there are research libraries or concept libraries. Don't use a library just because it's included in Boost!
I use Boost and Qt. Since TR1 I didn't need Boost as much, which means that it's achieved one of its goals.
But you can already have "simple C++", just specify for your project which parts of the language you want/don't want to use, and enforce it. This I think is a good coding practice, and for example Google also have its own C++ Style guide (http://google-styleguide.googlecode.com/svn/trunk/cppguide.x...). For example, you can specify that you will not use exceptions, template meta-programming, default parameters, etc.
This I think is the power of C++ - it is a multi-paradigm language, and you are perfectly free to not use some of the paradigms, or more powerful techniques.
Several years after I swore I would never work in C++ again, I agreed to do C++ in order to get a job with a company I was really interested in joining. I ended up working on a project that used C++ with lots of rules and restrictions, and it was not too bad except for lots of boilerplate.
I would like to see something better come along that has some of the low-level power of C, but also supports sophisticated high-level abstractions. I was hoping Go might fit that bill, but the Go designers have made some interesting choices that seem to alienate a lot of developers.
As a C++ programmer dabbling in Objective-C, I have been extremely impressed. After clearing the "weird syntax" hurdle, Objective-C is a beautiful language. It is object-oriented, type-safe when you want, dynamic when you want, and C-compatible without all the problems C++ added.
However, much of joy of using Objective-C is Apple's Cocoa Foundation classes. Stuff like autorelease and NSString are not part of Objective-C's core language. And support for Objective-C or Cocoa on non-Apple platforms is limited or not well-supported.
I've been intending to try Objective C for many years now. I like C, I like Smalltalk, and I like Mac OS. Maybe when I finish my degree, but there's no time now.
C++ is the only language I'm aware of where every extension made to the language is careful to only affect compilation time/complexity, while preserving the speed and operational semantics of the code at runtime. This makes it perfect for some domains, e.g. console game development, where the speeds required are only attainable by dicking around with pointers in C, but people want to use better abstractions than C is capable of. So no, continuing to add those extensions is not wasted effort; we'll still be learning and using them long into the future.
C++ takes a very simplistic view of runtime performance, however. Generics are implemented using templates; which instantiates the code for every type you use. Naively, this preserves the performance of simply writing the same code for each type (which is what you did before templates). However, that might not be the best performing way to implement generics at runtime.
One example of templates affecting runtime performance is poor use of the instruction cache due to code duplication in every instantiation of a template.
If you are instantiating equivalent functions (sorting foo* vs sorting bar* ) then the linker will merge their binaries -no dupes there. If you are generating different functions (sorting foo vs foo* ) then you are asking for different functions -no dupes there either. If you want to keep everything down to one function, qsort() didn't disappear when they added std::sort() and it is pretty close to what a dynamic language sort would do under the hood.
This is thing that annoys me about C++'s illusion of control: unless you have / take full responsibility over the compiler and standard library, the "control" that C++ gives you is actually an abnegation of choice which leaves you to reinvent the world if you want specific features. What if you want something like Smalltalk / Lisp images? Runtime code generation and optimization of virtual method calls? Precise garbage collection? C++ leaves you on your own if you want these things in your final executable, and you have to work very hard - to the point of implementing a DSL, or writing / modifying your own C++ compiler - if you do want them.
"What if you want something like Smalltalk / Lisp images? Runtime code generation and optimization of virtual method calls? Precise garbage collection?"
What is the point of controlling all of those things? The GP was talking about speed - how are GC, JIT and images related to this?
Precise GC, JIT and images all give you more speed.
Precise GC is asymptotically more efficient than manual allocation; you need to use other approaches, like arenas, to get back that lost time, but they are not always applicable or easy to introduce.
Optimizing virtual method calls at runtime (e.g. monomorphic or polymorphic inline caches) is rather awkward without JIT. Similarly, C++ templates cannot be instantiated at runtime, meaning less efficient, more general and indirected code needs to be used instead.
Images optimize startup hugely: they completely remove the need for any initialization not directly related to acquiring external resources. For example, this is one of the biggest reasons Chrome is so quick to start up - it uses freeze-dried heaps in V8 (its Javascript engine).
1. GC is fast at the cost of using more memory, which it turn slows the entire app down.
2. JIT can do all those optimizations, but how many of them are done in practice? How fast is the software compared to a binary compiled in C or C++?
3. Can be useful, but the only software that I've seen having trouble with startup times in the first place is written in .NET and Java :)
I guess that what I'm getting at is that C++ code is still faster than e.g .NET code even if C# has GC and JIT. In the end that's all that matter, not whether you can do optimization X.
.NET code is C++ code. The CLR is written in C++. In many ways this kind of argument is pointless, because it's really about a way of creating a piece of software, than particular to any one language. But some languages make life really hard here - in C++, you need to build a runtime.
I'll assert that memory is not normally a constraint in most situations that need to scale (i.e. not constrained clients), these days. (Though I will say I have noticed that Firefox 4 is significantly slower than FF 3 when switching tabs, and I believe it's because of memory reduction optimizations they've put in because of everybody moaning about bloat. I'd prefer it use more memory and less CPU.)
JIT optimizations like PICs? For over 20 years. The benefits are magnified in languages that make many operations virtual, so you see it in things like Smalltalk (very long time), Javascript (Chrome's V8) and Java JVMs (methods virtual by default so it's a win).
Re slow startup - you're deluding yourself if you think there isn't much software that doesn't have startup time issues. I need only restart any machine I have to know how slow initialization is; with HDD transfer rates in excess of 100MB/sec, there's no good reason for it to take more than 10 seconds or so when no hardware has changed. You're simply not aware of how much faster things could be if startup were faster because you're used to how slow everything is. You just know you can't e.g. fork utility X more than 200 times a second in a script, but don't realize it might be 10 or 100 times faster with a different approach.
That C++ doesn't impose, but does permit these runtime features is what allows it to adapt to such a wide variety of constrained environments. Baking those features into the language can certainly be much cleaner, at the cost of versatility.
We need system level languages and C++ currently stands alone in its combination of powerful abstractions, low level control, and ecosystem size, though it certainly has competition in these aspects individually.
I don't doubt that a language could be everything C++ is and much cleaner too, but that is a big challenge that relatively few language designers want to take on.
It's still the most useful language but you do get the feeling that everytime some new paradigm is claimed for another language C++ goes "I can do that - and I will do that in a way that doesn't break C code from 1979 - however weird that makes the language"
Languages are tools. Da Vinci with a mop and a bucket of mud would be a better painter than me. In fact I recently saw a video where Kelly Slater surfed a door and a coffee table as impressively as most weekend warriors surf on $700 custom shaped boards.
Focus on your skill not the tools. Surfing is more about timing, fitness and knowledge of waves than it is about the board. Likewise coding is more about RAM, CPUs, HDs, GPUs, busses, networks and ultimately users than it is about what tools you use to manipulate them.
"Likewise coding is more about RAM, CPUs, HDs, GPUs, busses, networks and ultimately users than it is about what tools you use to manipulate them."
My coding is primarily about managing complexity through good abstractions, and sometimes doing optimizations. Different languages are better suited to good abstractions. Kelly Slater might use a coffee table for fun one time, but he won't use one for his next competition.
You're right that people should be worried about their skills. But tools are a critical part of actually programming.
It's like saying "famous author X used pen and paper, hence complaining that Word 2010 doesn't handle Y properly is silly - focus on your writing!" (Worse even, as for pure writing, the speedup between pen/typewriter/Word is probably less pronounced than between programming languages.)
a video where Kelly Slater surfed a door and a coffee table as impressively as most weekend warriors surf on $700 custom shaped boards.
I saw a table tennis player all excited about his new carbon fiber paddle. Then one of the club champs picked up the box the new paddle had come in and, using the box as a paddle, proceeded to defeat the player with the carbon paddle.
I had a professor in University that beat some kid who thought he was all that at Table Tennis with a shoe, a baseball bat, a piece of cardboard, an empty plastic bottle, and then his bare hands.
It was absolutely hilarious how pissed this guy was getting with his fancy paddle and his attempts at tricking my professor with trick shots.
"It's a poor craftsman that blames his tools" does not mean, as so many programmers seem to believe, that tools don't matter at all, only skills do, so if someone failed it can't possibly be their tools, only their skill.
It means that part of being an expert craftsman is having the experience and skills to select excellent tools, and the experience and skills to drive those excellent tools to produce excellent results. Blaming your tools means either that you lack skill, or that you chose your tools poorly because you lack the experience and skills to choose correctly. Sitting there and defending bad tools does not impress me; it makes you sound like a craftsman who can not tell the difference between good tools and bad tools... and that's a bad craftsman.
Yes. Tools matter. Good tools won't bring you to your optimum peak performance on your own, but bad tools will guarantee you'll never get there. Bad tools typically take longer to work with, and typically teach bad habits to get around their deficiencies.
Da Vinci with a mop and a bucket of mud may be a better painter than you, but he would never beat Da Vinci with quality tools.
> Da Vinci with a mop and a bucket of mud would be a better painter than me.
Maybe. But Da Vinci would never paint the Mona Lisa with a mop and a bucket of mud. If he did, it wouldn't have survived to modern times. Am I stretching the analogy too much?
Paint Mona Lisas, people. With amazing skill and great tools.
I use C++ often, and what I'd like to see are good datastructures, built right into the language syntax, like Python does that with dicts, lists, tuples, sets etc... I know that STL has these, but using them still feels like some grafted-on afterthought.
TR1 added unordered maps/sets (hash tables) and tuples. Maybe it's because I use STL every day but the interface works fine for me. It takes some getting used to but it's pretty consistent. With the operator overloading it feels just like any built-in language syntax (that's even more true with C++0x's initializer lists).
C++ has a fundamental problem: that of being a real language that added OO features and static polymorphism in great haste; unwise decisions during the early stages of C++ cannot be unmade after their negative consequences are apparent.
There's some "good stuff" in C++1x, but of necessity, it's all additive, not subtractive. So the language gets bigger and more complicated.
I've never met an adept C++ programmer who didn't aggressively cut the language down to a subset. The sad thing is that I've met good C++ programmers - and seen good C++ libraries and frameworks - whose subsets are quite distinct; they are 'divided by a common language', like the old cliche goes.
68 comments
[ 3.2 ms ] story [ 132 ms ] threadThis is a little inconsistent. As a language that takes a long time to master, changing fundamental features of the language every 3rd year, for instance, would be a bit difficult to keep up with. Furthermore, the niche C++ lives in isn't one that needs to change every year. For some users, language stability and backwards compatibility are key, and with things like Boost, additions to C++ can be tried out in the wild for many years before being standardized (as many features slated for the newest standard were).
As always when talking about the continued relevance of C++, I will celebrate when I'm proved wrong.
As I see it, the new standard just isn't something which would change the future of C++ in some significant way, and it is not the most pressing problem C++ has as a language.
From my perspective, what I would like to see more is some alternative to boost, with similar functionality but without that meta-meta-programming. ;-) Simply, more cross-platform libraries comprehensible for the average C++ programmers.
Unsolved things:
- Unified C++ ABI call for making shared libraries without worrying about compiler manufacturer or version.
- Massive bloat. Take a look to the Boost libraries and cry.
- Poor debugging tools for templates (debugging templates it is crazy, and the promise of easy template debugging is almost a decade old).
Ridiculous things (in my opinion):
- Obsession for doing everything in "user-land" (e.g. source code templates) instead of built-in abstractions at object code-generation time instead of compile-time.
- Willing to introduce functional programing in the language, when, in my opinion, it makes more sense just to interface with true functional code (e.g. via SBCL).
C++ hour will come, with a non-bloated, system-software capable, "better than C", which could be labeled "simple C++", as in "simple English".
Indeed!
The thing I don't understand is that you go to the boost library website and you see that it touts itself as an all-volunteer effort.
Who are these people who volunteer their time to produce this massively bloated, over-elaborated code? What is their motivation? What's going on here? I understand bureaucracies usually bureaucrats are paid and produce code and memos to expand and control their turf. But here? What's up?
Boost certainly seems well done for what it is. But does this particular niche attract so many people?
There are many different components in there.
If you can give me an example of a part of this "continent" which is "lean and mean" rather than over-elaborated, I'd be grateful.
Also, as far as I know, most compilers were settling on a fairly standardized IA64 ABI, even for other platforms. The problem gcc had, last I checked, was after every release, they found a bug in the implementation and fixing it made the next release incompatible, but the goal was to be interoperable.
There's too many implementation decisions for this to be feasible. E.g., you'd have to standardize exception handling implementations and object layouts.
In practice, GCC has tried to standardize a C++ ABI for some platforms, but each proposed "standard ABI" has been buggy and required at least moderately backward-incompatible ABI changes between GCC releases.
> Massive bloat. Take a look to the Boost libraries and cry.
Define "bloat"? Large parts of Boost are absolutely horrid (e.g. Spirit), but I don't know what you mean by "bloat". Do you mean that the resulting object code is big?
> Poor debugging tools for templates (debugging templates it is crazy, and the promise of easy template debugging is almost a decade old).
Agreed. Hopefully clang is fixing that. http://clang.llvm.org
> Obsession for doing everything in "user-land" (e.g. source code templates) instead of built-in abstractions at object code-generation time instead of compile-time.
Huh? What do you mean by "built-in abstractions at object code-generation time"?
> C++ hour will come, with a non-bloated, system-software capable, "better than C", which could be labeled "simple C++", as in "simple English".
I was hoping that Digital Mars D would be the "Simple C++", but it feels like D is losing momentum.
(Sidenote: I've been programming in C++ for about 13 years, and am a recovering C++ "language lawyer".)
I was hoping for the same for a long time. Now my favourite "simple C++" is OOC (http://ooc-lang.org/). The syntax is a bit different (partially justified by faster parsing/compilation and has a lot of nice sugar), but it does support a lot of the good stuff: classes, generics, ability to use C-layout structures and attach "methods" to them, closures, pointers to allow easy C libs interaction and more...
Aside from your tears, what is the evidence that boost is bloated? Too slow? Too much source code? Too many files?
I've been using Boost for nearly a decade. It does a ton of useful stuff (from template metaprogramming to fast matrix algebra), it's loosely coupled, and it's insanely fast. Given it's scope, it's the least bloated library of which I know.
C++ has been evolving, but for the last decade, all of the evolutionary changes have come in the world of templates and template metaprogramming. I think this is hard on the people who have restricted themselves to the C-with-classes mentality. They're missing every modern development in the language since ~1998.
With gcc 4.4.5 and -O2, this one small file takes 22 seconds (!) to compile and produces a 14MB output file.
I guess that's... tolerable. But it isn't "lean" in any meaningful sense.
Your point seems to just be agreement with mine: C++ bloat is tolerable. It's still bloat.
Seriously, I think it's too much trick to do meta-programming in the language. If meta-programming should be allowed, it should be easier, simpler, and for the ordinary people. Just like Ruby.
But why does the metaprogramming syntax in C have to be so convoluted, bloated and difficult? Do we really need >30 second compile times per file on recent CPUs? If a language is hard to parse both for computers and humans, something went wrong. It should be easy to read for one of both, preferably both.
It's actually not all that fast in a lot of cases. Boost's matrix manipulation support is particularly slow:
http://eigen.tuxfamily.org/index.php?title=Benchmark-August2...
Also a lot of the template aerobatics generate a ginormous number of symbols which massively increase the binary size and cache pressure. In a former life I ripped out a pile of heavily templated code using Boost and replaced it with a well placed virtual function or three and dramatically reduced the cache misses in the application.
I've always seen Boost (and to a large extent the STL) as a demo library to show off what's possible with templates rather than something to be used in everyday code and have worked on a number of projects which forbade both.
There's a large rift in the C++ world between what I generally label Qt and Boost camps. The Boost people see the Qt folks as Java-esque dimwits that can't be bothered to learn the full extent of C++'s power and the Qt folks see the Boost following as unpragmatic architecture astronauts.
You've picked a benchmark of the most highly optimized matrix algebra libraries, and found that uBLAS is mid-pack, even though a) it isn't particularly optimized for any platform, and b) its goal is to result in the clearest possible syntax without sacrificing adequate performance. Talk about picking nits.
"Also a lot of the template aerobatics generate a ginormous number of symbols which massively increase the binary size and cache pressure."
When it really matters (which it rarely ever does): man strip
"I've always seen Boost (and to a large extent the STL) as a demo library to show off what's possible with templates rather than something to be used in everyday code"
I worked on shipping commercial products that used boost and the STL, and I did nearly all of my speed-sensitive code with it in grad school. It's far more than a demo library. Like I said before, you don't have to use all of it to use some of it.
Second of all, those symbols will have an effect on compile times, but they should certainly be stripped out by the linker. Why would symbols that do nothing sit in the executable?
Thirdly, Boost's purpose is to iterate faster than the C++ standard library and have real-world data about what libraries work and are needed. Those libraries would then be included in next C++ standards, as it has happened with TR1. There are useful libraries inside Boost and there are research libraries or concept libraries. Don't use a library just because it's included in Boost!
I use Boost and Qt. Since TR1 I didn't need Boost as much, which means that it's achieved one of its goals.
This I think is the power of C++ - it is a multi-paradigm language, and you are perfectly free to not use some of the paradigms, or more powerful techniques.
I would like to see something better come along that has some of the low-level power of C, but also supports sophisticated high-level abstractions. I was hoping Go might fit that bill, but the Go designers have made some interesting choices that seem to alienate a lot of developers.
I was trying to say that he (is that you??) understand more about C++ than almost everybody.
Objective C this very well. It adds classes and protocols. Closures can be implemented with blocks. Everything else is the same as in C.
However, much of joy of using Objective-C is Apple's Cocoa Foundation classes. Stuff like autorelease and NSString are not part of Objective-C's core language. And support for Objective-C or Cocoa on non-Apple platforms is limited or not well-supported.
As you've said: everything else is the same as in C.
(Edit: Small change to make meaning clearer)
Note also the ability to extern templates added in C++0x, which allow you to collapse common instantiations to a single object file.
One example of templates affecting runtime performance is poor use of the instruction cache due to code duplication in every instantiation of a template.
What is the point of controlling all of those things? The GP was talking about speed - how are GC, JIT and images related to this?
Precise GC is asymptotically more efficient than manual allocation; you need to use other approaches, like arenas, to get back that lost time, but they are not always applicable or easy to introduce.
Optimizing virtual method calls at runtime (e.g. monomorphic or polymorphic inline caches) is rather awkward without JIT. Similarly, C++ templates cannot be instantiated at runtime, meaning less efficient, more general and indirected code needs to be used instead.
Images optimize startup hugely: they completely remove the need for any initialization not directly related to acquiring external resources. For example, this is one of the biggest reasons Chrome is so quick to start up - it uses freeze-dried heaps in V8 (its Javascript engine).
1. GC is fast at the cost of using more memory, which it turn slows the entire app down. 2. JIT can do all those optimizations, but how many of them are done in practice? How fast is the software compared to a binary compiled in C or C++? 3. Can be useful, but the only software that I've seen having trouble with startup times in the first place is written in .NET and Java :)
I guess that what I'm getting at is that C++ code is still faster than e.g .NET code even if C# has GC and JIT. In the end that's all that matter, not whether you can do optimization X.
I'll assert that memory is not normally a constraint in most situations that need to scale (i.e. not constrained clients), these days. (Though I will say I have noticed that Firefox 4 is significantly slower than FF 3 when switching tabs, and I believe it's because of memory reduction optimizations they've put in because of everybody moaning about bloat. I'd prefer it use more memory and less CPU.)
JIT optimizations like PICs? For over 20 years. The benefits are magnified in languages that make many operations virtual, so you see it in things like Smalltalk (very long time), Javascript (Chrome's V8) and Java JVMs (methods virtual by default so it's a win).
Re slow startup - you're deluding yourself if you think there isn't much software that doesn't have startup time issues. I need only restart any machine I have to know how slow initialization is; with HDD transfer rates in excess of 100MB/sec, there's no good reason for it to take more than 10 seconds or so when no hardware has changed. You're simply not aware of how much faster things could be if startup were faster because you're used to how slow everything is. You just know you can't e.g. fork utility X more than 200 times a second in a script, but don't realize it might be 10 or 100 times faster with a different approach.
We need system level languages and C++ currently stands alone in its combination of powerful abstractions, low level control, and ecosystem size, though it certainly has competition in these aspects individually.
I don't doubt that a language could be everything C++ is and much cleaner too, but that is a big challenge that relatively few language designers want to take on.
Focus on your skill not the tools. Surfing is more about timing, fitness and knowledge of waves than it is about the board. Likewise coding is more about RAM, CPUs, HDs, GPUs, busses, networks and ultimately users than it is about what tools you use to manipulate them.
My coding is primarily about managing complexity through good abstractions, and sometimes doing optimizations. Different languages are better suited to good abstractions. Kelly Slater might use a coffee table for fun one time, but he won't use one for his next competition.
It's like saying "famous author X used pen and paper, hence complaining that Word 2010 doesn't handle Y properly is silly - focus on your writing!" (Worse even, as for pure writing, the speedup between pen/typewriter/Word is probably less pronounced than between programming languages.)
I saw a table tennis player all excited about his new carbon fiber paddle. Then one of the club champs picked up the box the new paddle had come in and, using the box as a paddle, proceeded to defeat the player with the carbon paddle.
It was absolutely hilarious how pissed this guy was getting with his fancy paddle and his attempts at tricking my professor with trick shots.
It means that part of being an expert craftsman is having the experience and skills to select excellent tools, and the experience and skills to drive those excellent tools to produce excellent results. Blaming your tools means either that you lack skill, or that you chose your tools poorly because you lack the experience and skills to choose correctly. Sitting there and defending bad tools does not impress me; it makes you sound like a craftsman who can not tell the difference between good tools and bad tools... and that's a bad craftsman.
Yes. Tools matter. Good tools won't bring you to your optimum peak performance on your own, but bad tools will guarantee you'll never get there. Bad tools typically take longer to work with, and typically teach bad habits to get around their deficiencies.
Da Vinci with a mop and a bucket of mud may be a better painter than you, but he would never beat Da Vinci with quality tools.
Maybe. But Da Vinci would never paint the Mona Lisa with a mop and a bucket of mud. If he did, it wouldn't have survived to modern times. Am I stretching the analogy too much?
Paint Mona Lisas, people. With amazing skill and great tools.
There's some "good stuff" in C++1x, but of necessity, it's all additive, not subtractive. So the language gets bigger and more complicated.
I've never met an adept C++ programmer who didn't aggressively cut the language down to a subset. The sad thing is that I've met good C++ programmers - and seen good C++ libraries and frameworks - whose subsets are quite distinct; they are 'divided by a common language', like the old cliche goes.
think about that a minute.