Live data from Hacker News

Building a Website with C++

blog.sourcerer.io

61–70 of 122 posts

Re: Building a Website with C++

#61
post #42
post #37

> In this article, I’ll explain how you can use C++ to develop a website and some concrete reasons why you might consider doing so. I only saw one reason: performance. Did I miss some? Do people have other good use cases that justify paying the dev cost of using C++ for a web server? I'd guess with caching and a decent backend, it would be fairly hard to demonstrate a true need for performance that requires C++, but…

You missed IoT. Preferably one would use some kind of network protocol with a native management console, but nowadays it is fashionable to have a mini webserver exposing a Web UI instead.

> You missed IoT.

I did? I just read the article again, and I don't see any mention of IOT or small or embedded devices aside from Docker, can you point me to what you saw? The article is assuming Apache is running...

Re: Building a Website with C++

#62

Just use rust man :| why do you want to bring all your security vulnerabilities and undefined behaviors to web?

Why do people think the C++ of today is the same as the C++ of 1998? Today we have concepts such as RAII to clean up our objects when they go out of scope. We have references which are essentially safe pointers to an extent (see dangling references). References have always existed, but people insist on using raw pointers still. Finally, for those use cases where heap allocated memory is absolutely necessary , we have…

There's still plenty of ways to shoot yourself in the foot if you are "not careful" with the modern C++ code you write. See for example http://foonathan.net/blog/2017/03/22/string_view-temporary.h...

Modern C++ has a lot of great stuff to help, but the sense of safety you get when you use Rust is something else entirely.

Re: Building a Website with C++

#64

Earlier quoted context omitted.

I doubt the performance of a c++ web site would be better than c#/java or some other compiled languages for most non-trivial web sites. Once things like jits come into play, and you see large projects (1million+ loc) the performance advantage of c++ often disappears or it becomes less performant for things like web sites. Most companies do not have the time nor ability to do all those optimizations that theoretically…

The performance would be notable. However, hardware is cheap these days.

> The performance would be notable.

Can you quantify & explain what you mean by notable? I've written a lot of C++ and also a lot of scripted web services like node.js and flask (python). For most normal websites, I doubt that you could make significant and noticeable performance improvements to a decent scripted backend by switching to c++, from the user's point of view. A latency savings of a millisecond or two across the board I could buy, but making it obviously faster to a user, I'm skeptical, unless the site has non-traditional high performance requirements.

Re: Building a Website with C++

#65
Interested parties desiring production quality security and significanlty better performance than CGI, check out the C++11 library Restbed https://github.com/corvusoft/restbed Restbed replaces Apache, or put another way puts the web server inside your application, so your C++ app is its own server. It is easy to create REST APIs with executable as small as 100K, and that is all you need - no Apache or Nginx other web server needed. I have created a fairly sophisticated facial recognition REST API that host itself, only occupies 500K and can run circles around pretty much anything - while running on a $99 Intel Compute Stick. I've created web sites and servers and web APIs in a most of the fashionable web best practices, and I gotta say Restbed blows everything away.

Re: Building a Website with C++

#66

Earlier quoted context omitted.

Isn't cgi slow ? Don't you need something like fast-cgi (which lambda does I think) ?

CGI is slow because of the spin up time for individual processes for each request. FastCGI is fast because they run as one long running process that handles multiple requests. While plain CGI is a slower, the advantage is that you don't have long running and potentially idle processes for low traffic periods, and process isolation is a little security boost. I chose to have a slightly slower startup time, which hopef…

Also the spinup time is considerably larger problem for various interpreters and virtual machines than for native code binary.

I would even expect that you can write non-trivial CGI application whose startup time is smaller than the additional overhead from parsing of the FastCGI protocol.

Re: Building a Website with C++

#67

Just use rust man :| why do you want to bring all your security vulnerabilities and undefined behaviors to web?

Why do people think the C++ of today is the same as the C++ of 1998? Today we have concepts such as RAII to clean up our objects when they go out of scope. We have references which are essentially safe pointers to an extent (see dangling references). References have always existed, but people insist on using raw pointers still. Finally, for those use cases where heap allocated memory is absolutely necessary , we have…

Because Rust lets you hire noobs that don't know what they're doing and contains their damage. C++ is fine if you know what you're doing. It's ridiculous to claim that memory safety is helped by the use of references.

Re: Building a Website with C++

#70
post #52
post #40

Really? Escaping, people! This code isn't practical or useful; it's dangerous and sloppy. cout \n"; ... cout \n"; FWIW I wrote an article about HTML escaping and shell here: http://www.oilshell.org/blog/2017/09/19.html Followup: http://www.oilshell.org/blog/2017/09/29.html Also if you want to use a native language for web sites (which I don't), Go is a better choice, as the standard library has html/template which pr…

Yeah... this example code is bad. Not to mention that CGI is slow, problematic, and chock full of potential security issues. At the very least, spawning a process per request is a DOS attack waiting to happen, even if the code were immaculate.

Classic CGI is not the best performing interface, yes. But there's a big difference in launching a complete interpreter for every request, and running a small purpose-built native program. And remember that people did manage the former 20 years ago, sites like Slashdot were running CGI Perl scripts back then.

I'm not sure about the "chock full of potential security issues". You have to be careful with trusting environment variables as the Bash guys learned, but I don't know what else there is that is specific to CGI.

Post reply on HN