Yeah, the fact that it takes a UnaryPredicate does pretty much mean you need to use a lambda or a functor. I also meant my comment half ironically. It is a step forward, but you still have shit on your shoe.

I actually use C++ for embedded programming, because when used with care, it can actually do a better job than C for a number of things. I use template meta-programming to compute various things at compile time, such as, say, register initialization values and what not. Sure, I can do the same with #define and a boat load of macros, but that has its own issues. Not only are macros messy in their own way, they don't provide a good way to sanity check your settings. With templates and types done right, I can actually get the compiler to sanity check my settings at compile time. I don't know how many times I've chased down a bug due to swapped macro parameters that could have been caught compile-time with some type checking / trait checking.

I've written an entire C++ based support library just for this purpose. One of its goals is extreme compactness and cycle efficiency, since the code often needs to run in RTL simulation. Software RTL simulation of a large SoC runs in the 10s to 1000s of cycles per second, so cycle efficiency is at an extreme premium.

What my library largely replaces is other C and assembly code that (often hamfistedly) computes everything at run time, and so my code can handily beat that.

I haven't quite hit the nirvana of generating an entire MMU page tree from a compact memory map description using templates (I have a perl script for that), but it sure beats 100,000s cycles or more computing it at run time when that translates to hours of sim time. (Fun fact: Some rather popular modern processors run really slow until you turn the MMU on, because they can't cache any data until you do.)

I have however written dynamic code generators that use templates and function overloading to resolve as much of the opcode encoding as possible at compile time, so that the run-time portion usually is just a "store constant" or maybe a quick field insert into a constant followed by a store. Those can pump opcodes to memory as fast as an opcode per cycle (and in some special cases, faster), which is pretty darn good. Again, all typechecked as much as possible at compile time, to minimize or eliminate the possibility I generate invalid instructions.

Suppose you want to determine if a collection c contains an element e. In any other language, you'd write something like c.contains(e).

I have good news for you! Sure, you still need to provide begin() and end() to specify a range, but it's a step forward. And, with the new non-member begin() and end() you can even use it on plain arrays.

Yeah, you still have to put all the pieces together yourself, but the pieces are a bit more uniform now and there's usually fewer to worry about. (Especially now with auto.)

Before auto it seemed like C++'s error messages were downright passive aggressive: "If you don't know what to put here, I'm not going to tell you." At least, it's not going to tell me the concise thing to put there. It will tell me the completely flattened type, which can be quite huge if you're trying to, say, get an iterator to a nested STL container holding a template class composed against some other classes (that themselves might be templated) a'la the Policy pattern.

I just wish I didn't have to code for the lowest common denominator compiler at work, so I can be sure I can use auto with impunity. :-)

I unfortunately claim ignorance on the license for the runtime. I know some of my employer's products use Dinkumware for the C++ library, but I'm not sure what this processor uses. (TMS320C6600 family, if you're curious.) I'm usually at the other end of the pipeline, using the pre-alpha tools before the silicon exists, so I'm pretty far removed from the customer toolchain distribution end of things. Sorry I can't be more helpful on that detail. I can tell you all about VLIW instruction scheduling and cache memory system pipeline behavior though!

You do have to be sure to compile with full optimization enabled, though, for STL to have a minimal hit. I use STL quite happily to do things I only too eagerly rolled my own implementation of years ago, and then clung to, even if it wasn't a perfect fit. For example, for eons I carried around this AVL tree implementation I wrote for a data structures class, and used it to implement associative containers, just so I wouldn't have to do it again. These days, it's simply map< yadda, yadda > and I'm on my way. I'm willing to bet map<> beats that creaky old AVL tree any day.

Without optimization, the STL containers can slow down quite a bit. I've heard the effect is especially large on some versions of MSVC++, since they have special debugging versions of the iterators that incur their own cost penalties in return for other checks. I wouldn't know; I do all my development under Linux or for embedded processors on bare metal.

With optimization on, I rarely if ever notice a performance issue due to STL. I do run into the occasional limitation, such as needing an actual resizeable 2-D array-like structure. (A vector< vector< ... > > doesn't cut it, because resizing the inner dimension doesn't resize all rows.) But, that's more exception than rule.

My biggest complaint about C++11 is that I won't realistically be able to use it for another few years. Grrr.

It seems like writing a terminal driver is a rite of passage. :-) I did one for our DSPs, and most recently, the Intellivision.

Just for fun, I tried the same experiment on one of our DSPs, and it pulled in just over 64K. I think our library is generally leaner in the locale department. In fact, I didn't see any locale data linked in. Most of what it pulled in looks to be actual ios/istream/ostream stuff, basic_string<char> and basic_string<wchar_t>.

Fortunately, those who did use him as an inspiration to get a life/career were also well adjusted enough to have a good laugh.

For all practical purposes, you're probably within 40 feet of a door that can never be opened. Or let's go the other way - hey, given enough time, you could probably find a crane and a wrecking ball, and destroy the building you're sitting in. Therefore, games without fully destructible environments are frustrating to you, because in real life, you can destroy everything? That's a silly line of reasoning. You're marking the line between what is reasonable and unreasonable that is clearly out of whack with the majority of players who accept that some level of suspension of disbelief is required in order to enjoy a video game. Game design conventions and art design directly addresses the concerns you're laying out in the vast majority of games with visual cues as to which objects are interactive and which are not. Anybody can be obstinate about those conventions, but to argue the point without acknowledging that they are a standard part of game and art design is being utterly disingenuous.

The vacuous thing about the slippery slope argument is we can't drag you out in public and have you admit you were wrong a couple of years down the road.

We knew you'd say that.

Yes, imagine a world where the laws of thermodynamics don't apply.

The peak theoretical efficiency of an internal combustion engine is bounded by the efficiency of an equivalent ideal Carnot cycle, which if I remember my ME301 Thermo class, is a bit below 40%. Wikipedia backs me up on this, quoting a limit of 37% for a steel engine block. That jibes with what I remember learning in Thermo.

To get 80% efficiency out of gasoline would require a different method of releasing its energy than an internal combustion engine.

Interesting. It'd be funnier if it weren't so sad.