Can C++ be used as a server-side web development language?
I'd like to get into web development using C++ as the "scripting language" on the server-side. My server infrastructure is *nix based, so doing web development in C++ on Azure is not applicable and C++/CLI ASP.NET is also not applicable.
Separate from legacy CGI applications, can web development be done using C++ ?
@Ed - Thanks for your comment Ed. I suppose the current choices would be Python or Ruby, but I'm trying to leverage my investment in C++ development...even if it means more work in C++.
Possible cross-site duplicate: http://stackoverflow.com/questions/417816/how-popular-is-c-for-making-websites-web-applications
Any programming language that can parse strings can be used in CGI or a servlet. Any language that can implement bindings with C libraries can also be used to develop modules for ISAPI- or Apache-compatible servers.
It's not particularly easy in C++, and good templating engines are few and far between, but it can be done.
Of course, the question of whether this is a good idea is another matter entirely. :)
Do note: Major websites like Amazon.com, eBay, and Google do use C++ for parts of their infrastructure. Realize, however, that Google only uses C++ for speed-critical systems, and Amazon.com only relatively recently switched away from Lisp (which angered some of their senior staff :).
Facebook formerly compiled PHP to C++, but their HipHop compiler (written partly in C++) has since been retooled as a bytecode virtual machine.
+1 For citing various frameworks. You should add that it's common for (very) big web apps to be powered by c++ (and other languages) : amazon.com, google.com, now facebook.com via hiphop, etc.
@Klaim: It's common, but it is by no means the rule. Amazon's architecture was historically Lisp-based and only recently rewritten in C++. Google's architecture involves Java, Python, and others almost as often as C++, all for various reasons. Facebook only uses hiphop now because they found out PHP doesn't scale. :)
I agree, but I meant that they still are well-known examples of use of C++ - to answer directly the original question title.
+1 for "FastCGI's mainline implementation is in C, and directly supports several languages, including C++."
@greyfade To nitpick: PHP scales linearely in a nice and easy way due to its shared nothing architecture. At Facebook's scale PHP apparently doesn't perform well enough, though.
@johannes Facebook's scaling problem stems from the fact that they have to maintain an order of magnitude more servers than are otherwise necessary, specifically because of the poor performance of an optimized PHP script. Linear scaling simply isn't good enough for such a large infrastructure. But remember that the "shared nothing" approach is not exclusive to PHP. C and C++ can do that, too.
@greyfade and remember, the more servers you need to run because your software is inefficient, the more power you have to pay for, and the more Co2 is created. Write in C++, save a tree dude :)
While this is a really good answer I still can't see why anyone would write for the web in C++ these days. I know of at least one web infrastructure that is part .NET and part Java that serves billions of hits a day. Why add the extra maintainability burden when it isn't needed?
@Rig these days are days to write in c++ for web check cppCMS and many others i think c++ for web is here to stay and grow..
@amar The thing is there is little return except in the 0.1% of apps that need that raw performance. You could serve in 1/3 of the time in most other languages with good web stack support. Banks, web advertisers, etc all serve massive scale without resorting to C++. Even Facebook. Twitter. StackOverflow. All do it in higher level languages. Its here to stay but it isn't going to become the majority again. Probably ever.
@greyfade, "they have to maintain an order of magnitude more servers than are otherwise necessary, specifically because of the poor performance of an optimized PHP script". Which PHP script is that?
@PaulDraper: Does it matter? The point, and implication, is that the reason Facebook moved away from using a pure PHP infrastructure is the expense of scaling, specifically because of the execution overhead of PHP interpreters. Surely that's changed, but my point stands, unaltered.