Thinking in Sepples Vol. 2

I have just finished reading part 2 of this book and I feel so fucking disappointed with the whole language. I thought the standard algorithms would let me avoid writing boring loops. I got predicates and funky syntax instead.
I thought more advanced template techniques were an awesome way to keep type-safety. Nobody mentioned there was no way to indicate what methods were needed by the template (aka concepts in C++0xF).

I thought it would be fun to try some more advanced C++ in a project I'm planning. Now it looks like it would be fucking painful. Is there anyone in here with professional C++ experience with those features? Are these features worth using in the long run?

>>6
It's wrong in what way? Examples badly needed.
Every way. Think of something about Sepples, and it's wrong. I mean, even starting from the top, infix syntax is an iffy decision. But besides that: mixing new features with those from C++ means you've got to know two ways to do everything, each of which fails in different circumstances, it doesn't even have FUCKING KEYWORD ARGUMENTS, its macros are pathetically weak, its approach to memory protection is to let you use pointers then crash (and the pointer syntax, although inherited, isn't especially good), templates are the worst approach to generic programming I've ever seen, static typing without a powerful type system is utterly brain-dead, as is weak typing, it's still using C strings, there are contexts in which certain features can't be used (array initialisers, macros, if/then) for no logical reason at all, iostreams suck hard (how do I hard coded order of parameters in messages?), exception systems are dumb, because they force you to either restart a possibly lengthy process or else code recovery logic at a level too low for your application's logic, there's no garbage collection by default, and I really don't feel like thinking about Sepples any more right now.

And then when it comes to implementability, by being frequently ambiguous Sepples makes it impossible to write good, fast compilers.

>>9
Memory and response time. I have a couple of big, weighted graphs and I have to walk through them almost constantly with A* and dijkstra. The graphs are changed relatively infrequently.
And what makes you think CL is not suitable for this? It will even make it easier to implement the caching strategy you probably ought to employ.