4 ms·

Building a website with C++ (CppCMS)

16 points by andreygrehov 12y ago

therobot24 12y ago
not quite the same thing, but a few years ago i built a library that would print test results to a web framework (can dynamically add graphs, tests, analytics, etc) Ran an example where i find the pupil of an eye: http://users.ece.cmu.edu/~jsmereka/eye/imgtst2/index.html http://users.ece.cmu.edu/~jsmereka/eye/imgtst2/index.html
acron0 12y ago
Surely, in 2014 we can do better than CppCMS... srv.applications_pool().mount(cppcms::applications_factory<WebSite>()); Not doing us any favours there, at all. C++ is crying out for a bit of 'hip' and there's really no reason, with C++11 now pretty ubiquitous, we can't have some Sinatra-inspired frameworks. What is it that really holds C++ back from being a solid choice for web frameworks?
- vinkelhake 12y ago
  > C++ is crying out for a bit of 'hip' It is? > What is it that really holds C++ back from being a solid choice for web frameworks? Language wise? Not much. It's more of a library and culture "problem". There's no inherent reason why C++ can't be used for web frameworks.
  - waps 12y ago
    C++ would be an absolutely fantastic language if it were allowed to start from scratch library-wise. But that'll never happen.
    - flohofwoe 12y ago
      This is so true. The C++ stdlib has a few nice things (esp in C++11), but the most important part - the container classes - mostly suck (IMHO).
- brandonhsiao 12y ago
  What is it that really holds C++ back from being a solid choice for web frameworks? Its verbosity. I'll wager that it'll be a long time before a C++ web developer will be able to write faster code than an equally competent Python, Ruby, Haskell, or Clojure web developer.
  - nly 12y ago
    The CppCMS blog implementation, according to CLOC, is about 3,200 lines. It supports comments, markdown, multiple database backends, LaTeX formulae, CAPTCHAs, caching, RSS feeds, and has an admin interface. That's a pretty dense result for an MVC framework without any magic. And how do you account for PHP? Oodles of documentation, fast iteration, and swaths of libraries out of the box seem to have trumped basically every other concern, including its absurd verbosity. Backend languages don't and shouldn't matter, especially when most webdev backend is no more sophisticated than your average CLI and you're probably going to end up spending most of your time dicking with CSS and HTML anyway. You could probably count equivalent productivity lost in tens of thousands of lines of C++, just scanning the dizzying array of loonybin.js frameworks for frontend work. I'd gleefully do any backend job in C++ if it meant someone else handing me the database schema and the frontend ready to go.
shmerl 12y ago
That's very interesting, thanks for linking to it. I've never heard of it but it can come handy.
notduncansmith 12y ago
It seems (to me) like if statically typed, compiled languages are your bag, and you want to create web applications, Go is the right choice. I recently finished the MVP for a weekend side project in Go, and I had a lot of fun (coming from a Node.js/Ruby background). I finally understood the draw of static typing (the compiler saved me a ton of time), but I didn't feel limited by the type system, nor encumbered by the syntax. The performance boost was also quite nice (not even optimized, and it still made the equivalent Node implementation's performance look mediocre by comparison). It's hard to imagine needing even more performance, since the Node version still would have been "good enough", and needing it so badly that it'd be worth muddling through C++ to get it (especially given the stark contrast of managing concurrency in Go vs C++).
- copperx 12y ago
  Why Go and not Haskell?
  - notduncansmith 12y ago
    I don't know much about Haskell but I suppose it would work as well. I just took an example of a statically typed, compiled language with which I'm familiar and which seems to have a decent amount of momentum.
- waps 12y ago
  > (not even optimized, and it still made the equivalent Node implementation's performance look mediocre by comparison) You're probably not doing it right. You should see a factor 10 or more difference, without optimization. Why ? Because any variable lookup in a dynamic language is always at least O(log N), and the mere fact that it needs looking up at all costs you a lot. So every single statement and expression of a compiled language is going to blow the socks off any interpreted language.
  - flohofwoe 12y ago
    I'm not a fan of dynamic typing, nor am I a compiler expert, but I'm pretty sure this is wrong for (at least) JS engines, which are JIT-compiled down to static machine code and which use automatic type deduction. Only when types on existing variables change all the time it would be a performance problem. If JS code is 10x slower then it's native equivalent it's probably because some slow-path is hit (too many objects created and destroyed, burdening the garbage collector, or too "dynamic code" which causes many recompiles at runtime, or code not to be compiled at all but running through the interpreter..).
innover 12y ago
A friend of mine is recently writing C++ web framework similar to Python Flask. It has many interesting features like compile-time routing URL parameter checking, easy and fast (probably fastest among C++ json libs) json implementation by taking full advantage of C++11. If interested, take look of following code and repository: https://github.com/ipkn/crow/blob/master/example.cpp https://github.com/ipkn/crow/blob/master/example.cpp
- acron0 12y ago
  This actually looks pretty awesome :)
frozenport 12y ago
This could benefit from a template engine like Smarty because graphic design items have an order that is hard to describe in a programming language.

16 points by andreygrehov 12y ago

not quite the same thing, but a few years ago i built a library that would print test results to a web framework (can dynamically add graphs, tests, analytics, etc) Ran an example where i find the pupil of an eye: http://users.ece.cmu.edu/~jsmereka/eye/imgtst2/index.html http://users.ece.cmu.edu/~jsmereka/eye/imgtst2/index.html

acron0 12y ago

Surely, in 2014 we can do better than CppCMS... srv.applications_pool().mount(cppcms::applications_factory<WebSite>()); Not doing us any favours there, at all. C++ is crying out for a bit of 'hip' and there's really no reason, with C++11 now pretty ubiquitous, we can't have some Sinatra-inspired frameworks. What is it that really holds C++ back from being a solid choice for web frameworks?

vinkelhake 12y ago
> C++ is crying out for a bit of 'hip' It is? > What is it that really holds C++ back from being a solid choice for web frameworks? Language wise? Not much. It's more of a library and culture "problem". There's no inherent reason why C++ can't be used for web frameworks.
- waps 12y ago
  C++ would be an absolutely fantastic language if it were allowed to start from scratch library-wise. But that'll never happen.
  - flohofwoe 12y ago
    This is so true. The C++ stdlib has a few nice things (esp in C++11), but the most important part - the container classes - mostly suck (IMHO).
brandonhsiao 12y ago
What is it that really holds C++ back from being a solid choice for web frameworks? Its verbosity. I'll wager that it'll be a long time before a C++ web developer will be able to write faster code than an equally competent Python, Ruby, Haskell, or Clojure web developer.
- nly 12y ago
  The CppCMS blog implementation, according to CLOC, is about 3,200 lines. It supports comments, markdown, multiple database backends, LaTeX formulae, CAPTCHAs, caching, RSS feeds, and has an admin interface. That's a pretty dense result for an MVC framework without any magic. And how do you account for PHP? Oodles of documentation, fast iteration, and swaths of libraries out of the box seem to have trumped basically every other concern, including its absurd verbosity. Backend languages don't and shouldn't matter, especially when most webdev backend is no more sophisticated than your average CLI and you're probably going to end up spending most of your time dicking with CSS and HTML anyway. You could probably count equivalent productivity lost in tens of thousands of lines of C++, just scanning the dizzying array of loonybin.js frameworks for frontend work. I'd gleefully do any backend job in C++ if it meant someone else handing me the database schema and the frontend ready to go.

shmerl 12y ago

That's very interesting, thanks for linking to it. I've never heard of it but it can come handy.

notduncansmith 12y ago

It seems (to me) like if statically typed, compiled languages are your bag, and you want to create web applications, Go is the right choice. I recently finished the MVP for a weekend side project in Go, and I had a lot of fun (coming from a Node.js/Ruby background). I finally understood the draw of static typing (the compiler saved me a ton of time), but I didn't feel limited by the type system, nor encumbered by the syntax. The performance boost was also quite nice (not even optimized, and it still made the equivalent Node implementation's performance look mediocre by comparison). It's hard to imagine needing even more performance, since the Node version still would have been "good enough", and needing it so badly that it'd be worth muddling through C++ to get it (especially given the stark contrast of managing concurrency in Go vs C++).

copperx 12y ago
Why Go and not Haskell?
- notduncansmith 12y ago
  I don't know much about Haskell but I suppose it would work as well. I just took an example of a statically typed, compiled language with which I'm familiar and which seems to have a decent amount of momentum.
waps 12y ago
> (not even optimized, and it still made the equivalent Node implementation's performance look mediocre by comparison) You're probably not doing it right. You should see a factor 10 or more difference, without optimization. Why ? Because any variable lookup in a dynamic language is always at least O(log N), and the mere fact that it needs looking up at all costs you a lot. So every single statement and expression of a compiled language is going to blow the socks off any interpreted language.
- flohofwoe 12y ago
  I'm not a fan of dynamic typing, nor am I a compiler expert, but I'm pretty sure this is wrong for (at least) JS engines, which are JIT-compiled down to static machine code and which use automatic type deduction. Only when types on existing variables change all the time it would be a performance problem. If JS code is 10x slower then it's native equivalent it's probably because some slow-path is hit (too many objects created and destroyed, burdening the garbage collector, or too "dynamic code" which causes many recompiles at runtime, or code not to be compiled at all but running through the interpreter..).

innover 12y ago

A friend of mine is recently writing C++ web framework similar to Python Flask. It has many interesting features like compile-time routing URL parameter checking, easy and fast (probably fastest among C++ json libs) json implementation by taking full advantage of C++11. If interested, take look of following code and repository: https://github.com/ipkn/crow/blob/master/example.cpp https://github.com/ipkn/crow/blob/master/example.cpp

acron0 12y ago
This actually looks pretty awesome :)

frozenport 12y ago

This could benefit from a template engine like Smarty because graphic design items have an order that is hard to describe in a programming language.