[benjamincburns]

Some of the negative comments here really anger me, and I feel a need to speak up.

Who gives a flying fuck if this tool is the right one for whatever is your individual definition of web development? The fact is that someone had a need for a particular solution and they were kind enough to build it, document it, and show it off here for free. Turning your nose up at this based on language choice just makes you a close-minded fool.

Applications for this do in fact exist, and I'm quite pleased that the author was kind enough to post this.

On a past project I've had to write my own asynchronous web framework in C based on the wonderful libmicrohttpd. I decided on C because this was a resource limited device on which I was already using every available CPU cycle on a realtime computer vision algorithm and it all was just barely performing within acceptable limits. I needed as tiny a footprint as I could get.

I'm in the early stages of a different project which will probably face a similar situation, except on this massive concurrency will be key. I will absolutely be looking into CppCMS when the time comes.

[mtdewcmu]

"I'm in the early stages of a different project which will probably face a similar situation, except on this massive concurrency will be key..."

I'm a fan of native code, and I use C++ at work and C and C++ on my personal projects. In my last job I was doing web work, writing PHP for Drupal sites. My reaction to CppCMS is just to note that it wouldn't necessarily be easy to create a faster CMS using C++ versus PHP. Drupal sites can be slow as dogs, but the reason has nothing to do with PHP per se. The Drupal codebase is extremely bloated and fairly inefficient in its design, but even worse are the modules that get piled on, and there can easily be well over 100 modules on a site. I've watched the database queries that come out from a real site and it was stunning and appalling to see the volume and the redundancy that occurs on a single page. I was also amazed by the sheer quantity of PHP that gets loaded and parsed (if you're not caching) on a single page. So that tells me that PHP is pretty fast to be able to support that enormous edifice of code. It's not a guarantee that C++ would make you faster than an interpreted language, because the work that goes into generating a webpage plays to the strengths of interpreted languages and away from C++: you'd have to be careful and think through how to handle lots of strings and memory management. A good garbage collector is said to be faster than malloc/new when churning through lots of memory, because it can amortize the work and run on a background thread. I think lots of little strings could especially become a problem unless you planned out a strategy for handling them efficiently. Also, as others have pointed out, a lot of the issues with making a website fast aren't about executing code on the cpu. It wouldn't necessarily be easy to beat something like node.js at handling requests asynchronously, for instance. That stuff can be hard to write. So, I think it would be a good idea to do even a very high performance site in an interpreted web language first, then decide cautiously if there's a way to make it faster by replacing some or all of it with hand-written C++.

[stevelaz]

I couldn't agree more. Disclaimer, I work mostly in embedded systems. But, still. There's something to be said about being too quick to judge based on the language or tool used to accomplish the job. Every tool has its use and my guess is that plenty of people will use this.

[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...

[Skinney]

Why on earth would you use C++ for a massively concurrent app? While I understand using C/C++ for low-memory devices or where deterministic/manual memory handling is important. Concurrency/Paralellism is simply not C/C++, Java's, or any language which relies primarily on locks, cup of tea.

If possible, try to make Go work. It's concurrency model is great for massive concurrency.

[benjamincburns]

This isn't an "app." It's one service that's a small but important piece of a rather large backend. It's essentially a content-aware WebSockets proxy. I want it to be extremely light weight with minimal latency addition (less than 1 msec, ideally).

So why C/C++? When it comes to language choice I have a very simple rule: use whatever I think I can be most successful with.

Go prescribes a particular concurrency model. C and C++ do not. I have many years of experience wielding C to write very small, very fast programs that do very big things. I have zero years of experience with Go. Go would be interesting if I was writing something more general purpose or something that needed lots of extensibility, or something on which I plan to collaborate with people who don't have a lot of concurrent programming experience. None of those cases apply.

[Skinney]

app, application, I wasn't thinking about mobile apps or the like.

I agree completely with using whatever I can be most successful with line of thinking. This is why I try to learn as many languages as I can, so I have a good notion of what is the best tool for the job.

Whenever I think "loads of concurrency" I immidietly think about Erlang, Clojure or Go, as they have great concurrency models. Then again, you'll always be more productive in the language in which you have most experience, so to each his own I guess :)

[SamReidHughes]

C++ doesn't rely on locks. You can use whatever you want.

[Skinney]

Hmm. Most of what I've seen uses mutexes and semaphores for synchronization. Do you have actors and/or channels libraries for C++? I recon you do, but how good are they?

[SamReidHughes]

I don't know much about the public actors or channels libraries for C++, since I work on a project that rolled its own green threads system and doesn't have much of a use for channels -- we end up having types that perform fifo enforcement in other ways, and our way of "sending a message" is often popping a green thread that switches itself to the appropriate POSIX thread before doing something, using some sort of fifo enforcement object to rearrange things in the right order at the right time (and then holding a short term userland single-threaded lock -- with no cross-posix-thread synchronization -- to do some atomic business once you get your turn).

You could create a channel library that is "as good as" other libraries you'd see, except that they'd use C++ constructors/destructors and you might want a family of channel types depending on ownership semantics -- such as a single-producer single-consumer channel, versus a (less performant) channel with more shared ownership.

The state of existing actors or channels libraries is probably dismal. A channels library would need to be rolled together with a specific green threads system, and that's one of the advantages Go or other languages with a canonical green threads implementation has.