I've written a C++ Apache module for a simple web app before. It's definitely harder than using a scripting framework though, not so much because of the language, but more that frameworks have functions that help you do just about anything (e.g. sanitize input, construct safe SQL). In C++ land you're more on your own since most people aren't crazy enough to build a web app in C++.
Also, if you go down this route and you're particular about C vs. C++, check out mod_cpp for building Apache modules: http://sourceforge.net/projects/modcpp/
I echo the advice that if you have something performance-sensitive, build it in C/C++, but proxy it through something built with a better-known framework. Thrift is great for this: http://incubator.apache.org/thrift/
I heard about Thrift when Protocol Buffers came along but didn't bother to look into it. Is it any better than PB? Does anyone have any experience on this to share?
Personally, I like Thrift better. More languages and greater community participation.
http://uk.techcrunch.com/2008/09/21/techcrunchtalk-video-sta...
Rather, they use C++ because the library that powers their IM client, libpurple, is written in C. Writing a C/C++ bridge to whatever (Java, Ruby, Python, PHP) isn't hard and there are lots of generic solutions out there already, e.g., Thrift.
It uses c++: http://www.okws.org/doku.php?id=okws:tutorial
If you're doing something computationally intensive (like, a dating or quiz site, for example, with the impressive statistical analysis that OkCupid and HelloQuizzy deliver up very quickly), then it would pay to look at an approach that's working well right now.
Use KLone http://koanlogic.com/klone/ .
It lets you write web pages with embedded C/C++ code (php-style escaping).
It's VERY fast and provides all common functions/features you need to parse incoming HTTP variables, sessions, file uploads, etc.
If you need more features you can link it against any C/C++ library and call library functions from within web pages.
Let me know what you end up doing.
Build on a mature best-of-breed product that provides a quality programming model and all required HTTP and logging services. Also easily take advantage of other apache mods such as memcached or wackamole.
Good luck.
Contact me if you are looking for someone to do that kind of work.
If I were starting a new web app from scratch today, I would code it in C using Thomas Boutelle's cgic library. Of course, it seems one rarely starts anything from scratch these days.
Please contact me at jonas@codeazur.com.br with IM info, I'd love to introduce you to some of the stuff we want to do (so maybe you can help).
That said, even as a hard-core C++ guy, I can't see why you'd really want to write a web application in C++. If you want C++-like syntax, you'd be better off with Java for web stuff.
And start saving money for memory and large amount of servers...
I'd really love to come up with a standardized way of deploying small, context-specific RESTful API servers in either C or C++. I'm starting to think that a possible C++/Python bridge via Thrift is likely the best option. But then again, if I just managed to keep it all in a C++ application without needing to run the Python interpreter, it could totally rock (for an application that is supposed to serve 100k+ users on cheap hardware).
It's cool to see cloud computing going mainstream and now applications written in any language can be reasonably fast with the help of EC2, a load balancer and memcached. But I still think there's great value to coming up with truly lightweight solutions that really use nearly all computing power a single node can possibly offer.
That is compounded with the typical architecture of Java frameworks. Also finding issues sometimes feels like occult magic on modern JVMs. And then, running with compatibility issues on JVM versions and all that.
Java failed in the browser and now it will probably have a crash at the server. There is no more budget for multimillion dollar datacentres everywhere. But thanks for all the jobs! :)
http://shootout.alioth.debian.org/u64/benchmark.php?test=all...
It's no proof, but real life shows something even worse than that against Java. For example the one thread per connection model everywhere or the XML web services throwing away objects faster than the GC can handle.
Hence my statement: > ignoring the way "enterprises" mostly use java (which is just silly)
Of course the thread per connection model is long gone (at least what I have heard, but software tends to not die) and the XML beast is dying... but that it more how people abuse it.
but if its memory you want, you can't do better then using the OS to its full power via C/C++, which is what you are doing when you are using C/C++. Using anything that is a full VM (like jvm, or if you think that is opaque - give erlang a try !) then you kind of tell the OS to "go away" and the VM becomes an OS etc...
You can't generalize like that. It's a language. It works. It scales, and is solid.
Sure, if you're just putting up something that needs quick prototyping then java is probably overkill, but if you're writing something quite complex, java can do a great job.
I think the "golden bullet" for startups is having a good programmer with a passion for something. Language isn't so relevant IMHO.
(Mibbit currently handles around 3.5million visits a month on a single VPS in java which I'm pretty happy with).
Second, please look my other posts 4 and 6 minutes before this one you just did.
On a C++ thread some people above say the thread creator should use Java. I refuted that argument with my opinion and reasoning. It is not bashing:
bash: - To engage in harsh, accusatory, threatening criticism. -ing When you deliberately attack a person using offensive and/or inappropriate language.
See on top of this page: "Suppose I wanted to write a C++ based web application... [...] But what if I just wanted to write plain C++?"
Can't Java people play along? Can't you guys even play pretend? There are very good comments in this thread (both pro and con.) And if you think C++ Web Applications are a bad idea, fine, say so and state your case. There was no need to bring up Java. Of course you are free to do so. But that allows others (moi) to counter-argue with you.
Thank you.
I don't think anyone would have really jumped on the memory comment originally, but what made the thread asbestos-o-riffic however was the assertion that Java is inappropriate for a startup, which is, well, just plain silly.
In a comment 15 hours ago I stated it's probably not worth it due to current cheap hosting prices.
Web apps can work in any language (I wrote a couple in assembly once)...
Choosing the language is not really that important.
Having big images/videos wouldn't really make any difference to which language you choose. That's just static media files which are irrelevant.
I really don't see how having more images on the page would make it harder to scale :/ if only the site were as simple as serving up some images...
Apparently that is all too hard for some web 2.0 startups.
I'm thinking of ditching JSP and have PHP talking to our Java services via Thrift.
Chances are you may end up with a story like this: http://groups.google.com/group/comp.lang.python/browse_threa...
Albeit micro-benchmarks may indicate that Python is 100-200 times slower than C++, they may not be applicable to the real world. Python can be very efficient. And when combined with libraries like NumPy, beating it's performance with hand-crafted C++ is difficult.
Emperor has no clothes.
On the upside, it was 100 lines instead of several thousand.
On the downside, it was several hundred times slower.
I didn't bother trying to write serious simulation codes in Python after that.
My point is that some people assume that if they would just sit and write something in C++ without putting enough time and effort and skill in it, it would be somehow magically faster and better than high-level language, just because it's C++. They are mistaken.
Python standard library is extremely fast. For example 'list.sort()' in Pytohn could run 3 times faster than C++ 'sort(vector<string>)'.
Here are few examples when simple Python code runs faster than the same code in C++: http://groups.google.com/group/comp.lang.python/browse_threa...
Again comparing apples to oranges.
I can't wait for them to finally get the on the fly compiler working. Good times coming in the language competition.
There are many ways to look at complexity as an abstract concept. You could look at code length. Or you can count how many 'degrees of freedom' your code allows you to have, and be sure that you need to control each of those. C++ affords too much freedom for developer.
The trend meanwhile is towards reducing complexity at system/core level and focusing on application unique added value. Today, in large web applications, complex behavior is build using simple components. Those components are normally done in C, and then wrapped by some scripting language. C is not too flexible. The components are rock-solid as a result, they lack unexpected behaviour. Their code's 'degrees of freedom' are easier to control.
On top of that, there is trend towards frameworks in scripting languages which reduces 'degrees of freedom' at core/foundation level even further. Finally, there is this REST thing that wants to standardize API of a typical web app, offering us even larger blocks to code to work with. Again, all these trends have one objective - allowing to focus on unique application functionality, on interaction with other systems etc and hiding underlying complexity from the developer.
By using C++ you are likely to get complex behaviour in your code very early, at a very fundamental level. As you add functionality, the complexity/behaviour quirks will grow exponentially and you will fail.
I am convinced that Microsoft failure with Vista is mostly due to them using C++. They were simply defeated by mounting complexity, not by lack of engineering talent. Meanwhile, Unix success (Apple OS X included) is determined by relative 'dumbness' of underlying C language, Unix tradition of small single-purpose tools etc.
It is an event-driven, staged (threads communicating via message passing) application server, written in C++. It has stages for HTTP server and client, disk IO, gzip, logging (basically all CPU-intensive or IO tasks). Messages between stages are defined in IDL. You can send those over the network via Sun-RPC or JSON-RPC.
Not directly related to your request, but still handy: it also has a stage that wraps the Python VM, so you can write parts of your app in Python.
There are plenty of C/C++ HTTP libraries and frameworks out there. Just proxy your homebrew app server behind squid, lighttpd, apache, nginx, or $YOUR_FAVORITE_PROXY and you are set.
In fact, it makes it really easy to develop and test your app that way. There is no web server to configure and you can easily stick in printfs all you want. I use CherryPy (standalone HTTP framework for Python) that way exactly for these reasons. I'd do the same with C++.
The traditional HTTP side of it is trivial (just use nginx or something like that.) For template engine you have already Clearsilver and it's the fastest that I know of by an order of magnitude.
The key is solving how the application's developers could extend the web application. You can't expect them to code in C++ and compile every little change to their site. That's the beauty of CMF systems like Zope, you can put plain Python code in there with pages and components.
Doing a CMF in any lower level language and having to switch to a higher level language VM for every snippet would kill your original performance savings.
Find an element to fix that and you'll have a strong new contender in the CMF arena. Stuff like OpenMP and all that comes bundled in the new C++ libraries, transparently.
(BTW IMHO don't even think of starting without memorizing the Essential C++ books and all it's need-to-know patterns.)
1 - build your app as an extension of an existing http server. Start with lighttpd or nginx source and build out from there. nginx has a nice module structure. Perhaps your app can be just a new module. Both of these code bases are C and use event driven sockets. You might be able write your extensions in C++.
2 - Use a known solid http C++ library to roll your own server. Depending on the complexity of your app, you may end up spending a lot more energy going this route.
My relay server for http://shellshadow.com is C++. I had my C++ programmer look at the structure and methods used in one of the two http servers named above. We ended up not re-using their source (our relay isn't http protocol) but did get some useful insight for developing our server daemon.
You may want to investigate the following libraries:
fcgi++: Interface with the web server using fast cgi; keep the program resident in memory between requests.
botan: For generating cryptographic hashes.
cgicc: For handling input from the web browser.
xerces-c: For implementing a templating system and generating the output which gets sent to the web browser.
libpqxx: Interfacing with Postgres.
cppunit: Unit-testing critical or difficult-to-test bits.
It's not as hard as everyone likes to make it sound (assuming you are on the right side of the C++ learning curve). The real question is whether you want to spend your time writing a framework rather than actual applications.
Now, the concept is moot...a good OO web platform is so much more robust.
This seems like a good guide on how not to fuck things up with C++.
You can write your events in C++ or Delphi or both. (flame on)
If you want to see how much better an ORM in ruby/C can be, look at datamapper http://datamapper.org. This is mainly used with merb. The new datamapper uses data_objects which has been completely rewritten with C underpinnings to be much more efficient than previous datamapper. I haven't seen any recent benchmarks against ActiveRecord. But I do believe the datamapper team met their goals of being faster.
In fact we, the core DM contributors, have spent very little time optimizing the library. Up until now we've been mostly focused on creating a clean API, and keeping the internals simplified. I would expect the gap to widen much further once the API stabilizes, and the spec coverage gets nearer 100% (it was in the low 90's last I checked).
Ive written a lot of C++, it was 'the one true way'.. but then I did see alot of people using python, ruby.. I learned a bit of lisp, and kind of de-conditioned myself.
If your not gonna use Lisp/arc/scheme/python/ruby... then, actually, I would go with C and not C++. You are just above the metal and you see exactly whats going on, and you dont spend time making cleverly convoluted constructs of infinite generality...
In C, you just get shit done. With a bit of discipline you can get a lot of the benefits of OO and even some of the benefits of FP in your C code. Heresy, I know.
I do love C++ still, its nice to see good RNG and regex APIs going into the language.. but its a bit verbose on balance.
gord.