[j_baker]

You know, every time I see one of these types of frameworks the first thing that comes to mind is "Some people are just determined to make C++ look cool again". I mean sure, sometimes you run into a case where you are running computer vision algorithms on an embedded device and have to choose C or C++.

But how common are those use-cases really? And why on earth would you want to worry about buffer overflows and memory leaks when you're already worrying about XSS and CSRF attacks?

As fast as modern Java is, it just seems unnecessary.

[yati]

> And why on earth would you want to worry about buffer overflows and memory leaks

Have you written a line of code in modern C++? Know what RAII is? If you use C arrays and char*s in C++, that's your problem - the language provides idioms that are "as safe as" Java.

[kybernetyk]

This. I can count the occasions where I used new/delete (and worried about lifetime of objects) in the last year on one hand. And I'm a full time C++ developer.

[Skinney]

RAII doesn't save you from buffer overflows, or memory leaks when you need an object to live beyond the current scope.

C arrays and pointers can still be used on the stack, and are sometimes simply the right tool for the job.

While RAII greatly reduces memory leaks and enhances resource-management, it doesn't save you in all cases, which means there still is an overhead and you will still have to worry about it.

Java doesn't have Undefined Behaviour, buffer overflows, or memory leaks (not completely true, I'm not counting space leaks here but I hear it's possible to introduce a memory leak by writing a faulty class loader).

While C++ does provide idioms for writing safe code, C++ can't remove them, which means you will always have to worry about it. Sometimes the problem isn't actually your code, but the library you're using, which is the case at my job, which again made me miss a safer language :(

[eatitraw]

> RAII doesn't save you from buffer overflows

How do other languages solve this problem?

> or memory leaks when you need an object to live beyond the current scope.

Have you ever heard about smart pointers? They take most pain from dealing with pointers. Managing circular references remains a bit complex though.

[Skinney]

> How do other languages solve this problem?

Reading or writing past the allocated parts of a buffer is treated as a runtime error, wheras in C/C++ you just end up with corrupted memory.

> Have you ever heard about smart pointers?

Ahh, completely forgot about these. You're right, they're great.

[stevekemp]

> If you use C arrays and char*s in C++, that's your problem

Sadly it's not that cut and dried. I've written a mail-client in C++, with an embedded Lua intepreter for the scripting. Guess what the Lua API wants to use?

There are many many situations where you need to integrate with libraries that only present C-bindings, and that gives you a lot of constraints.

(Though I admit I was pleased with the C++ API of libmimetic, the MIME-library.)

[yati]

I agree there are rough edges, and for specialized use cases like yours, you might have to walk that extra mile. But when I hear that a framework/library/tool is worth nothing just because it is written in C++ and not in the hip Ruby/Python/Go, it makes me sick. This guy wrote CppCMS taking inspiration from modern frameworks hoping to make life better for himself and for people who care to write webservices/apps in idiomatic C++ and NOT C. Imagine if someone had written a had a well designed, idiomatic C++/Lua API(like, say, boost::python) and open sourced it, would we not have commended their efforts?

[Skinney]

RAII doesn't save you from buffer overflows, or memory leaks when you need an object to live beyond the current scope.

C arrays and pointers can still be used on the stack, and are sometimes simply the right tool for the job.

While RAII greatly reduces memory leaks and enhances resource-management, it doesn't save you in all cases, which means there still is an overhead and you will still have to worry about it.

[j_baker]

Nope. Nor do I plan on it. Why should I use a language that forces me to know about RAII and the difference between C pointers and "language provided idioms" to begin with? Tell you what: I'll buy your "modern C++ is safe" argument if you buy my "modern Java is fast" argument.

[yati]

> Why should I use a language that forces me to know about RAII and the difference between C pointers and "language provided idioms" to begin with?

No one asked you to. I don't like Eclipse that much personally, but I did not go to their page and say "Hey, you know what, I hate Java so your product sucks!". (I have deep respect for Java and the Java community, BTW). But frankly, as someone who has not written a line of code in C++ - however bad it may be - you're not really qualified enough to preach the world about its utility.

> I'll buy your "modern C++ is safe" argument if you buy my "modern Java is fast" argument.

Yes, the JVM is an engineering marvel - we all know that! What we also know is that it is adept at hogging all resources you might have(unless you learn how to use those bazillion -X<options>) - so no, thanks. I prefer compiling to native code and having total control, and in cases I don't want all that, I might just stick to Go or Python.

[tomjen3]

C++ is never going to be hip, but as an HTML5 game developer I can't tell you how many times I have wished for the ability to stack allocate objects, or to use RAII.

C++ gives you plenty of ways to go harm yourself, but unlike C they are pretty easy to work around. And the nice thing is that for the most part wrong code looks wrong.

[TelmoMenezes]

Gah! Enough with the "use-cases" already! They're "uses" or "cases". Why the redundancy? What next, "profit-money"? "Price-point"? Oh wait...