web app.?!

Pages: 12
With tntnet (http://www.tntnet.org/) you can write webapps with C++ using tntnet. And they are really fast.
closed account (EzwRko23)

To claim any universal rule like "C++ is never suitable for web app programming" just exposes your bias and hinders your ability to make the best choice.


Ok, then. Writing a web-app in C++ is like writing a desktop app in PHP. You surely can do it but it is pointless. Now better?


I said if you code carefully and strip things down to its bare necessities, you can avoid the overhead


No, you can't. You can only make it smaller. But you still pay for starting a new process with every request. Starting a process is an extremely costly task, compared to just invoking a method call. The last time I checked, a simple Hello World application written in C couldn't be executed more than 100 times per second. On the same machine, a simple Java servlet runs at over 5000 requests per second (natively compiled code like C++, yet no process loading overhead). You are not able to reach that performance with CGI, even if you hand-coded it in assembly. You can do that with FastCGI, but you have to be totally insane to use C++ based FastCGI on a production server.
Last edited on
You should really look at tntnet. It is a webserver for writing webapplications in C++. The applications are persistent as PHP but native like C++. There is no overhead for loading the application nor interpreting it. It is compiled into native code and run in a persistent multithreaded server. Simple dynamic pages in C++ are faster than static pages in apache.

And it is not really that difficult to write safe C++ programs. C++ has a much richer feature set than C has. We write webapplications in C++ and have no problems with memory leaks, buffer overflows and whatever happens in C. But you have to know your tools. A bad programmer writes bad programs. But a bad programmer shouldn't write programs for the public web anyway - not even in PHP or Java.

And yes - CGI is awful slow. But you can't say, that C++ programs as CGI are always slower than PHP. If you do a lot of processing, the program start time becomes more negligible.
closed account (EzwRko23)
I was not saying it is slower than PHP (PHP is interpreted, slow). I meant it is slower than Java and .NET which are compiled natively just as C++, and have no overhead of process-loading.


And it is not really that difficult to write safe C++ programs


Even if it is not that difficult, it takes significant amount of time to design the memory management code and to make sure obvious memory management bugs are absent. The time that could be spent on validating program logic. And all of this for no real benefit. A great programmer writes great programs in any language, but given better tools (Scala's Lift is unbeatable web-framework ever), he writes even greater programs.

Any success stories with tntnet? Something of the size of Twitter, LinkedIn or Foursquare with millions of users and complex business logic? Until it is not proven in some large web-app, it should be considered a toy.
Last edited on
Hi xorebxebx,

as you think, it takes significant amount of time to design the memory management code, I conclude, that you have not much experience in C++. Take a good book about C++ before talking about it.
closed account (EzwRko23)
This means that all those people that created Windows, KDE, Firefox etc. are poor coders. Memory management related bugs and vulnerabilities are still common there.

Whatever you say, manual memory management and concurrent programming is considerd hard and error-prone by many computer scientists. That is why some great hackers developed garbage collection and lockless programming. BTW: at the server side, where memory is cheap and you have plenty of it, garbage collection is much more efficient than manual memory allocation.

Back to my orignal questions:
1. Any success stories?
2. What are benefits of using C++ for a web-app? Performance is definitely not one of them.
Last edited on
I agree completely; there's no benefit from using some hacky way to still use C++ for applications like these. The persistence to keep using C++ is a bad habit: Be open to use whatever is best to use in your current situation. Of course, that only applies to big projects which you seek to release or when you try to go beyond some functionality of a programming language (like using foolish tricks and batch calls on standard i/o to create, for example, a console game).

In the current situation (creating web applications) you are best off using a programming language that was built for creating these.
xorebxebx wrote:
Ok, then. Writing a web-app in C++ is like writing a desktop app in PHP. You surely can do it but it is pointless. Now better?


No, that's way off the mark. There's a huge benefit in performance between C++ and PHP. How is that pointless? And do you have that benefit with using PHP for writing a desktop app?

You're throwing ridiculous generalizations and you're on some weird zealot agenda, that's become apparent. The rest of us just say that there IS a time and place when C++ can be used in a web application. You just want to rule it out.

That site Galik pointed to was a good enough real-life example of how signifcant the performance difference can be:
http://www.wrensoft.com/zoom/benchmarks.html

(Java's not in there, but let's address one of your wild claims one at a time)

xorebxebx wrote:
But you still pay for starting a new process with every request. Starting a process is an extremely costly task, compared to just invoking a method call. The last time I checked, a simple Hello World application written in C couldn't be executed more than 100 times per second. On the same machine, a simple Java servlet runs at over 5000 requests per second (natively compiled code like C++, yet no process loading overhead). You are not able to reach that performance with CGI, even if you hand-coded it in assembly. You can do that with FastCGI, but you have to be totally insane to use C++ based FastCGI on a production server.


Love the logic there. You can't do it because [reason] ... well you can, but "you have to be totally insane". So your reason really boils down to a very rational, "it's insane".

You obviously don't like to do manual memory management, and think of it as the most horrible thing in programming. Certainly it is a difficulty, and certainly it can be a hindering factor in certain development situations (where there's no benefit to be gained from manual memory management).

But you're either being blindly driven to prove a point, or plain ignorant to not recognize the advantages of manual memory management -- allowing for optimizations / data compression methods that cater to the nature of the data or the use of the data specifically, that wouldn't otherwise be possible. That is a fact, and a very real benefit.

Not every situation demands such an ability, but to claim that you never need that ability just means you're very close minded to the existance of situations you've not encountered yourself.

Success stories? I gave them before: Google, eBay and Yahoo all uses C++. Is that "success" enough for you?
closed account (EzwRko23)

There's a huge benefit in performance between C++ and PHP


This is a completely irrelevant argument to my claim. Compare C++ to Java or .NET, not to PHP.
I say it once again: writing a webapp in C++ is just as cumbersome as writing a desktop app in PHP. You can do it, but you will be fighting with your tools all the time. And there is no performance advantage, because there is .NET and Java, which are just as fast as C++.


Love the logic there. You can't do it because [reason] ... well you can, but "you have to be totally insane". So your reason really boils down to a very rational, "it's insane".


Are you really sure that your 1 MLOC FastCGI application doesn't have a memory leak? If you are, then you are either genius or insane. If not, you are insane to run it in production.


You obviously don't like to do manual memory management, and think of it as the most horrible thing in programming


No. Concurrent programming is harder. I'm only saying manual memory management costs time that could be spent on other more important things like functionality or performance. In server environments virtual machines do memory management better than programmers, because deallocation cost = 0 and allocation cost is 3-10x smaller. Additionally GC can be hardware accelerated (Azul produces such hardware), making GC cost = 0. GC is a clear win in server environments, period.


Google, eBay and Yahoo all uses C++.


I asked for tnt success stories, not "C++ as a webapp" success stories. That someone uses C++ somewhere in their stack is obvious (at the OS or webserver level), especially if the app comes from the pre-Java era (before 2000). Anyway, you are wrong - Google uses Java GWT for their webapps, not C++. And Yahoo uses LISP for at least some of their webapps (Yahoo store).
@xorebxebx I had given up on this debate because you obviously have a very biased and unbalanced view. This statement is a good example of your reasoning:
xorebxebx wrote:
This is a completely irrelevant argument to my claim. Compare C++ to Java or .NET, not to PHP.

Yet you were praising PHP over C++. Then when someone points out that C++ is tens of times faster than PHP you suddenly start comparing it to Java running on a MP server with Gigabytes of RAM.

Let's get this straight. C++ is not right for every situation. But the fact is that it is massively quicker in certain environments. Even when launched through CGI.

On top of your 'arguing for one thing by comparing it with a different thing' you are totally ignoring the fact that neither loading-speed nor 'requests per second' are necessarily the most important factor in every situation. If you already have an application written in C++ and simply want to put a web front-end to it it may not make sense to develop in multiple languages.

I have been through the process of wrapping C based application software in Java using JNI and it adds a whole layer of skills to the application development requirements and a whole complex slice to the interface where awkward, hard to find bugs can manifest.

You need to stop believing everything the Java web-site is advertising and realise that there are many reasons why Java is not always the easiest, most cost effective or quickest running solution. I worked on a system where Java was going to be used to webify a mature stock-controlling system written in 4GL/C. One consideration was that the customer's servers were not always the most modern up-to-date systems. We had no control over how much RAM was available and what other concurrent demands were being made from their server running other people's software. Arguing that on a perfect machine with infinite RAM Java does quite well is simply unrealistic in many situations.

Last edited on
closed account (EzwRko23)

Yet you were praising PHP over C++.


I was not. PHP was used only to illustrate how unnatural writing a web-app in C++ is. C++ was never designed for web-apps, just as PHP was never designed for desktop apps. But both of them can do that.

BTW, actually PHP is not that slow as you think. It is enough fast for the purpose it was created - to power web frontends and it is almost never the bottleneck, because it doesn't do anything complex. On the other hand it is just as terribly designed and misused language as C++.


Arguing that on a perfect machine with infinite RAM Java does quite well is simply unrealistic in many situations.


No, on a perfect machine with plenty of RAM and many cores it usually does better than C++, mostly because of faster memory management and lock optimisations, and because programmers finished the project earlier and had more time to apply algorithmic optimisations (the time they would have otherwise spent fixing memory management bugs). In typical situations it is on par with C++. Anyway, it doesn't matter - cheap computers are really fast now, and unless you don't write another Facebook, I can guess even PHP is fast enough for your purpose.


Last edited on
xorebxebx wrote:
Anyway, it doesn't matter - cheap computers are really fast now, and unless you don't write another Facebook, I can guess even PHP is fast enough for your purpose.

Well at least one of my points is getting through. ;o)
xorebxebx wrote:
Are you really sure that your 1 MLOC FastCGI application doesn't have a memory leak? If you are, then you are either genius or insane. If not, you are insane to run it in production.


Bit like saying if you can't be sure your software doesn't have any critical bugs in it, then you'd be insane to run it in production. Critical bugs, memory leaks or otherwise, exist in every language and you deal with it as a developer. Do you realize you can have memory leaks within the Java runtime? Even with compiled Java, if you get to be tricky enough.

Sorry but anyone who is that spooked by memory management just clearly has never had any commercial development experience in C++, and came from a lifelong/academic background in Java/garbage-collection and finds memory management daunting because they've not had to deal with it extensively.

And look, I've given you the benefits of manual memory management before, but you chose to ignore it.

I'll plant it to you simpler - if you have a project which is memory intensive, and you need to squeeze as much into memory (or as much out of the available memory) as possible to best do the job (e.g. a search engine such as Google or that Wrensoft Zoom thing above), then there's a very significant benefit with using C++ over Java (let alone the other languages mentioned before), and it becomes worthwhile to consider the costs or burden of dealing with memory management issues.

xorebxebx wrote:
Anyway, you are wrong - Google uses Java GWT for their webapps, not C++. And Yahoo uses LISP for at least some of their webapps (Yahoo store).


No, I'm not wrong. I said they all used C++. I didn't say they use only C++.

I know that for a fact with Google and it's well documented. I also know that with Yahoo having actually seen some of their code and knowing engineers from there.

I also never said one should only use C++ for web applications. That would be madness. The whole point anyone here has presented is that there are cases, and situations where C++ is the best tool for a web application. You argue that anyone who uses C++ ever, for a web application is "insane". So that would include Google and Yahoo.
closed account (EzwRko23)

Bit like saying if you can't be sure your software doesn't have any critical bugs in it, then you'd be insane to run it in production. Critical bugs, memory leaks or otherwise, exist in every language and you deal with it as a developer.


Right. But this is all about probablity. When using a higher level language some nasty classes of bugs simply cannot happen by definition. Probablility of a critical JVM bug affecting your application stability or security is like 0.00001% or less. Typecheckers in Scala or D can prove much more about program's correctness than the C++ compiler can (e.g. they can typecheck your database queries). I have never had a bug that destabilized/killed the whole application. Usually these bugs are well isolated. The worst what happens is usually killing a thread or showing something incorrectly to the user, under some (untested) conditions. Tricking a buggy Java app to run untrusted external code is much more difficult than tricking a buggy C++ program. Making a leaking Java app is also much harder than making a leaking C++ program, and even if you manage to do so, you have still better tools to diagnose and fix the problem.


And look, I've given you the benefits of manual memory management before, but you chose to ignore it


Because for webapp they are irrelevant - memory is cheap and modern GCs are usually not significantly less memory efficient than manual management. RTJS addresses automatic memory management in memory tight environments and is comparable in efficiency to hand-coded C++ memory pools. So, this is a very weak argument; risking higher probablity of bugs is not worth saving that slight amount of memory.


No, I'm not wrong. I said they all used C++. I didn't say they use only C++.


No, they don't use C++ for **any** of their new webapps. They use it for some lower layers (like indexing engines) or for some old legacy stuff, but not for webapp frontends. This would be a waste - they have GWT for frontends. Even if there is some less important webapp written in C++ by Google of which I don't know, it does't condradict the fact that probably more than 99% of all webapps are written in PHP, Java, .NET, Python, Ruby, Perl and Scala. I suspect, by now there are even more Scala-powered webapps than C++ powered webapps; although C++ is many times more popular in general.

Last edited on
I give up.

Every argument you make in the above has already been answered and addressed in the posts before it. There's no point in repeating everything and having you ignore it again, and make up BS numbers like "0.0000001%" and "99%".

Believe what you want.
Last edited on
closed account (EzwRko23)
0.0000001% this is not a BS number. We've written more than 10M LOC in Java, and we haven't been beaten by a single JVM bug or memory leak. And we do hire sometimes average or cheap programmers. On the contrary, C++ memory management bugs and vulnerabilities are very common (everywhere) or extremely common in the setting where you can't afford super-hero programmers. Because of this, recommending C++ for production webapps (especially in long-running mode, where a single memory leak kills you) is just irresponsible fanboyism.

Apart from the memory management issue, there are no production-quality libraries for web-app support in C++. Which pretty much ends the discussion. C++ is not for webapps.
I believe you ALL have diverged from the topic at hand. The question was how to make a web app out of an existing C++ program.

@xorebxebx 70% of people can make up random statistics to try and prove their point

The rest of you should have ignored his comments as they have slowly dragged this poor persons thread where he/she asked for HELP into a flame contest.

How about, if you don't like C++ don't post here since this is where you'll get a lot of questions about it!

As for the ORIGINAL QUESTION, I would say that the CGI method would be my preferred way although Sockets is your alternative if you want to code it all yourself. If you give us more details about what you are trying to achieve we can help you decide further by giving you the pros and cons of each approach. Also ignore the flamers and those easily tempted to respond intelligently to irrational people inevitably prolonging a pointless argument, which is off topic.
closed account (EzwRko23)
True. So back to the topic.
My preferred way:

1. Generate wrapper for your program with SWIG - should not take you more than 5 minutes for a simple program.
2. Write the webapp frontend in a language best suited for the task (Scala, Ruby, Python, PHP, whatever you like).

The bonus part is that if you do it this way, and not the CGI way, you achieve clear separation between frontend and backend.
Last edited on
I'll also to add some content wrt the topic: Use Wt (http://www.webtoolkit.eu/wt).

It's easy to integrate with existing C++ code, has a built-in webserver (or uses one through fcgi/isapi), supports the latest web buzzwords (ajax, canvas, video, audio, ...), has built-in protection against XSS and CSRF.

The user community is very active and responsive.
Topic archived. No new replies allowed.
Pages: 12