[betterunix]

I am not sure it is ever true that there are no doubts about C++ being "right." It might be "good enough," but it is a generally bad language that would not be my first choice for anything (I would sooner use C, but even that's not my top choice).

[alexchamberlain]

And I would sooner use modern C++, it is personal preference and experience.

[betterunix]

It's not about experience, it is about the language. Modern C++ is basically a motorized stone hand-ax. Even experienced C++ programmers are surprised by undefined behavior and unexpected semantics.

[pbsd]

A significant amount of undefined (and unexpected) behavior in C++ is inherited from C, for compatibility. You'd sooner use C, and fall into undefined behavior quickly as well.

C++ is large and hard to master, but I don't think UB is the best reason to choose C over it.

[CCs]

C++11 is years ahead of Java. http://herbsutter.com/elements-of-modern-c-style/

I especially like the fact that you can specify which variables are captured by the closure: http://www.cprogramming.com/c++11/c++11-lambda-closures.html

I use both C++ and Scala on daily basis and there are just a few things I wish C++ had from Scala. On the other hand it is a huge time saver not having to worry about the JVM GC freeze.

[betterunix]

"C++11 is years ahead of Java"

OK but so what? It is also years ahead of BF.

C++11 has a few nice features, but it is really dragged down by low level issues. You talk about garbage collection like it is a problem, but C++ still does not even offer good garbage collection (not even optional garbage collection) for those situations where it makes sense. At least with Java you do not need to manually break cyclic references to prevent memory leaks.

As for closures, why would I want to specify which variables are captured? If I reference a variable from the enclosing environment, I capture it. If I mask the variable, I do not capture it. What point is there in explicitly declaring this? Frankly, the entire C++11 approach to closures is insane. Why add the extra syntax to explicitly declare how variables are captured, when capture by value covers all cases?

I stand by what I said. C++ is an awful language.

[CCs]

Since it has deterministic destructor and RAII is easy to implement, garbage collector is not needed. It works not only with memory allocation, but any other resource you need to release: mutex, serial port, window handle, file handle etc. Also move schematics really helps with performance: create, copy & destroy can be avoided altogether. No garbage, nothing to collect. :)

BTW, Normally you should avoid "new" and "delete", only very special use cases need it.

Specifying the closure variables is optional and it is both for performance and encapsulation. You can specify "nothing", "everything by reference", "everything with copy", just some by copy or reference - mix & match. If this is too much to start with then just copy everything with [=] and clean it up later if it turns out to be a bottleneck. The point is: you can save on cycles if you want to/have to.

If you think C++ is not a match for you, that's OK, there are plenty other languages. You don't need performance all the time - some are OK with 400 queries/sec, others want 7,000 on the same server: http://www.techempower.com/benchmarks/#section=data-r6&hw=i7...

[betterunix]

"Since it has deterministic destructor and RAII is easy to implement, garbage collector is not needed"

This is kind of like saying, "x86 has CALL, PUSH, and POP operations, so there is no need for a language with subroutines! Just use inline assembly!" Garbage collectors are not strictly needed in any imperative language. The point of garbage collection is to enable programmers to think at a high level, without having to divert their attention to low-level issues.

"Also move schematics really helps with performance: create, copy & destroy can be avoided altogether. No garbage, nothing to collect."

Move semantics are a solution to an artificial problem. Sensible defaults like allocating objects on the heap and using references everywhere would have solved this problem and many others. Yes, I know that the C++ approach to programming is supposed to give programmers the power to do things for themselves, but that does not mean that the default semantics have to be brain-damaged. If code like this:

  std::vector<int> vec;

Caused an object to be allocated on the heap, and created a reference to that object, move semantics would not be needed. To stay true to the C++ way of doing things you could have a special non-reference type. Note, of course, that this really needs garbage collection to work well, and that the garbage collector would be entirely optional (as Bjarne Stroustrup suggested): programmers wanting to avoid the garbage collector would use non-reference types and pointers to non-reference types.

"Specifying the closure variables is optional and it is both for performance and encapsulation"

I am not seeing how it makes sense for either. Specifying anything about how variables are captured is a pointless exercise. Variables should just be captured if they are not shadowed, and they should always be captured as copies. When programmers need to capture by reference, they should just create a reference and capture that. Introducing another syntax just to declare how variables should be captured, and then making another nonsensical default behavior (no capture at all), is just silly.

"You don't need performance all the time - some are OK with 400 queries/sec, others want 7,000 on the same server"

You know, it is not a very strong argument when the top result (in C++) is only marginally faster than the next best (in Java). The fact that another C++ framework happens to be much further down, below systems written in Java, Scala, PHP, and Lua, is also not helping you. If anything, that test shows that the cost of using a high level language is not so bad; fantastic performance can be achieved without having to fumble around at a low level, and low level languages like C++ are not a guarantee of good performance.

[happy_dino]

> not having to worry about the JVM GC freeze

Bad engineers blame their tools.

[CCs]

Android: http://www.war-worlds.com/blog/2012/06/on-android-garbage-co...

C#: http://conversations.nokia.com/2012/06/01/interview-with-mat...

Ruby: https://blog.twitter.com/2011/building-faster-ruby-garbage-c... (It was not good enough, they dumped Ruby)

Accepted answer? "Manual tracking of objects" http://stackoverflow.com/questions/2484079/how-can-i-avoid-g...

Google has 14 million web pages about Garbage Collector issues...

[CCs]

Good engineers start with good tools and avoid wasting time.

See section 9 http://www.joelonsoftware.com/articles/fog0000000043.html

[happy_dino]

Yeah, let's use a memory unsafe language, handle memory management by hand and just completely ignore the fact that no human being has ever managed to consistently write bullet-proof code in it.

Using software which automates memory management, engineered by the brightest minds on this topic, is for hipsters, right?

I guess you also roll your own crypto and implement stuff in assembler “for performance”?

[pothibo]

Well, I might have over-emphasize on what is "right". Blame this on the language barrier :)