5 ms·

Some of the negative comments here really anger me, and I feel a need to speak up. Who gives a flying fuck if this tool is the right one for whatever is your i

Some of the negative comments here really anger me, and I feel a need to speak up. Who gives a flying fuck if this tool is the right one for whatever is your individual definition of web development? The fact is that someone had a need for a particular solution and they were kind enough to build it, document it, and show it off here for free. Turning your nose up at this based on language choice just makes you a close-minded fool. Applications for this do in fact exist, and I'm quite pleased that the author was kind enough to post this. On a past project I've had to write my own asynchronous web framework in C based on the wonderful libmicrohttpd. I decided on C because this was a resource limited device on which I was already using every available CPU cycle on a realtime computer vision algorithm and it all was just barely performing within acceptable limits. I needed as tiny a footprint as I could get. I'm in the early stages of a different project which will probably face a similar situation, except on this massive concurrency will be key. I will absolutely be looking into CppCMS when the time comes.

j_baker 13y ago
You know, every time I see one of these types of frameworks the first thing that comes to mind is "Some people are just determined to make C++ look cool again". I mean sure, sometimes you run into a case where you are running computer vision algorithms on an embedded device and have to choose C or C++. But how common are those use-cases really? And why on earth would you want to worry about buffer overflows and memory leaks when you're already worrying about XSS and CSRF attacks? As fast as modern Java is, it just seems unnecessary.
- yati 13y ago
  > And why on earth would you want to worry about buffer overflows and memory leaks Have you written a line of code in modern C++? Know what RAII is? If you use C arrays and char*s in C++, that's your problem - the language provides idioms that are "as safe as" Java.
  - kybernetyk 13y ago
    This. I can count the occasions where I used new/delete (and worried about lifetime of objects) in the last year on one hand. And I'm a full time C++ developer.
  - Skinney 13y ago
    RAII doesn't save you from buffer overflows, or memory leaks when you need an object to live beyond the current scope. C arrays and pointers can still be used on the stack, and are sometimes simply the right tool for the job. While RAII greatly reduces memory leaks and enhances resource-management, it doesn't save you in all cases, which means there still is an overhead and you will still have to worry about it.
  - Skinney 13y ago
    RAII doesn't save you from buffer overflows, or memory leaks when you need an object to live beyond the current scope. C arrays and pointers can still be used on the stack, and are sometimes simply the right tool for the job. While RAII greatly reduces memory leaks and enhances resource-management, it doesn't save you in all cases, which means there still is an overhead and you will still have to worry about it. Java doesn't have Undefined Behaviour, buffer overflows, or memory leaks (not completely true, I'm not counting space leaks here but I hear it's possible to introduce a memory leak by writing a faulty class loader). While C++ does provide idioms for writing safe code, C++ can't remove them, which means you will always have to worry about it. Sometimes the problem isn't actually your code, but the library you're using, which is the case at my job, which again made me miss a safer language :(
    - eatitraw 13y ago
      > RAII doesn't save you from buffer overflows How do other languages solve this problem? > or memory leaks when you need an object to live beyond the current scope. Have you ever heard about smart pointers? They take most pain from dealing with pointers. Managing circular references remains a bit complex though.
      - 13y ago
- tomjen3 13y ago
  C++ is never going to be hip, but as an HTML5 game developer I can't tell you how many times I have wished for the ability to stack allocate objects, or to use RAII. C++ gives you plenty of ways to go harm yourself, but unlike C they are pretty easy to work around. And the nice thing is that for the most part wrong code looks wrong.
- TelmoMenezes 13y ago
  Gah! Enough with the "use-cases" already! They're "uses" or "cases". Why the redundancy? What next, "profit-money"? "Price-point"? Oh wait...
stevelaz 13y ago
I couldn't agree more. Disclaimer, I work mostly in embedded systems. But, still. There's something to be said about being too quick to judge based on the language or tool used to accomplish the job. Every tool has its use and my guess is that plenty of people will use this.
Skinney 13y ago
Why on earth would you use C++ for a massively concurrent app? While I understand using C/C++ for low-memory devices or where deterministic/manual memory handling is important. Concurrency/Paralellism is simply not C/C++, Java's, or any language which relies primarily on locks, cup of tea. If possible, try to make Go work. It's concurrency model is great for massive concurrency.
- SamReidHughes 13y ago
  C++ doesn't rely on locks. You can use whatever you want.
  - Skinney 13y ago
    Hmm. Most of what I've seen uses mutexes and semaphores for synchronization. Do you have actors and/or channels libraries for C++? I recon you do, but how good are they?
    - SamReidHughes 13y ago
      I don't know much about the public actors or channels libraries for C++, since I work on a project that rolled its own green threads system and doesn't have much of a use for channels -- we end up having types that perform fifo enforcement in other ways, and our way of "sending a message" is often popping a green thread that switches itself to the appropriate POSIX thread before doing something, using some sort of fifo enforcement object to rearrange things in the right order at the right time (and then holding a short term userland single-threaded lock -- with no cross-posix-thread synchronization -- to do some atomic business once you get your turn). You could create a channel library that is "as good as" other libraries you'd see, except that they'd use C++ constructors/destructors and you might want a family of channel types depending on ownership semantics -- such as a single-producer single-consumer channel, versus a (less performant) channel with more shared ownership. The state of existing actors or channels libraries is probably dismal. A channels library would need to be rolled together with a specific green threads system, and that's one of the advantages Go or other languages with a canonical green threads implementation has.
mtdewcmu 13y ago
"I'm in the early stages of a different project which will probably face a similar situation, except on this massive concurrency will be key..." I'm a fan of native code, and I use C++ at work and C and C++ on my personal projects. In my last job I was doing web work, writing PHP for Drupal sites. My reaction to CppCMS is just to note that it wouldn't necessarily be easy to create a faster CMS using C++ versus PHP. Drupal sites can be slow as dogs, but the reason has nothing to do with PHP per se. The Drupal codebase is extremely bloated and fairly inefficient in its design, but even worse are the modules that get piled on, and there can easily be well over 100 modules on a site. I've watched the database queries that come out from a real site and it was stunning and appalling to see the volume and the redundancy that occurs on a single page. I was also amazed by the sheer quantity of PHP that gets loaded and parsed (if you're not caching) on a single page. So that tells me that PHP is pretty fast to be able to support that enormous edifice of code. It's not a guarantee that C++ would make you faster than an interpreted language, because the work that goes into generating a webpage plays to the strengths of interpreted languages and away from C++: you'd have to be careful and think through how to handle lots of strings and memory management. A good garbage collector is said to be faster than malloc/new when churning through lots of memory, because it can amortize the work and run on a background thread. I think lots of little strings could especially become a problem unless you planned out a strategy for handling them efficiently. Also, as others have pointed out, a lot of the issues with making a website fast aren't about executing code on the cpu. It wouldn't necessarily be easy to beat something like node.js at handling requests asynchronously, for instance. That stuff can be hard to write. So, I think it would be a good idea to do even a very high performance site in an interpreted web language first, then decide cautiously if there's a way to make it faster by replacing some or all of it with hand-written C++.

j_baker 13y ago

You know, every time I see one of these types of frameworks the first thing that comes to mind is "Some people are just determined to make C++ look cool again". I mean sure, sometimes you run into a case where you are running computer vision algorithms on an embedded device and have to choose C or C++. But how common are those use-cases really? And why on earth would you want to worry about buffer overflows and memory leaks when you're already worrying about XSS and CSRF attacks? As fast as modern Java is, it just seems unnecessary.

yati 13y ago
> And why on earth would you want to worry about buffer overflows and memory leaks Have you written a line of code in modern C++? Know what RAII is? If you use C arrays and char*s in C++, that's your problem - the language provides idioms that are "as safe as" Java.
- kybernetyk 13y ago
  This. I can count the occasions where I used new/delete (and worried about lifetime of objects) in the last year on one hand. And I'm a full time C++ developer.
- Skinney 13y ago
  RAII doesn't save you from buffer overflows, or memory leaks when you need an object to live beyond the current scope. C arrays and pointers can still be used on the stack, and are sometimes simply the right tool for the job. While RAII greatly reduces memory leaks and enhances resource-management, it doesn't save you in all cases, which means there still is an overhead and you will still have to worry about it.
- Skinney 13y ago
  RAII doesn't save you from buffer overflows, or memory leaks when you need an object to live beyond the current scope. C arrays and pointers can still be used on the stack, and are sometimes simply the right tool for the job. While RAII greatly reduces memory leaks and enhances resource-management, it doesn't save you in all cases, which means there still is an overhead and you will still have to worry about it. Java doesn't have Undefined Behaviour, buffer overflows, or memory leaks (not completely true, I'm not counting space leaks here but I hear it's possible to introduce a memory leak by writing a faulty class loader). While C++ does provide idioms for writing safe code, C++ can't remove them, which means you will always have to worry about it. Sometimes the problem isn't actually your code, but the library you're using, which is the case at my job, which again made me miss a safer language :(
  - eatitraw 13y ago
    > RAII doesn't save you from buffer overflows How do other languages solve this problem? > or memory leaks when you need an object to live beyond the current scope. Have you ever heard about smart pointers? They take most pain from dealing with pointers. Managing circular references remains a bit complex though.
    - 13y ago
tomjen3 13y ago
C++ is never going to be hip, but as an HTML5 game developer I can't tell you how many times I have wished for the ability to stack allocate objects, or to use RAII. C++ gives you plenty of ways to go harm yourself, but unlike C they are pretty easy to work around. And the nice thing is that for the most part wrong code looks wrong.
TelmoMenezes 13y ago
Gah! Enough with the "use-cases" already! They're "uses" or "cases". Why the redundancy? What next, "profit-money"? "Price-point"? Oh wait...

stevelaz 13y ago

I couldn't agree more. Disclaimer, I work mostly in embedded systems. But, still. There's something to be said about being too quick to judge based on the language or tool used to accomplish the job. Every tool has its use and my guess is that plenty of people will use this.

Skinney 13y ago

Why on earth would you use C++ for a massively concurrent app? While I understand using C/C++ for low-memory devices or where deterministic/manual memory handling is important. Concurrency/Paralellism is simply not C/C++, Java's, or any language which relies primarily on locks, cup of tea. If possible, try to make Go work. It's concurrency model is great for massive concurrency.

SamReidHughes 13y ago
C++ doesn't rely on locks. You can use whatever you want.
- Skinney 13y ago
  Hmm. Most of what I've seen uses mutexes and semaphores for synchronization. Do you have actors and/or channels libraries for C++? I recon you do, but how good are they?
  - SamReidHughes 13y ago
    I don't know much about the public actors or channels libraries for C++, since I work on a project that rolled its own green threads system and doesn't have much of a use for channels -- we end up having types that perform fifo enforcement in other ways, and our way of "sending a message" is often popping a green thread that switches itself to the appropriate POSIX thread before doing something, using some sort of fifo enforcement object to rearrange things in the right order at the right time (and then holding a short term userland single-threaded lock -- with no cross-posix-thread synchronization -- to do some atomic business once you get your turn). You could create a channel library that is "as good as" other libraries you'd see, except that they'd use C++ constructors/destructors and you might want a family of channel types depending on ownership semantics -- such as a single-producer single-consumer channel, versus a (less performant) channel with more shared ownership. The state of existing actors or channels libraries is probably dismal. A channels library would need to be rolled together with a specific green threads system, and that's one of the advantages Go or other languages with a canonical green threads implementation has.

mtdewcmu 13y ago

"I'm in the early stages of a different project which will probably face a similar situation, except on this massive concurrency will be key..." I'm a fan of native code, and I use C++ at work and C and C++ on my personal projects. In my last job I was doing web work, writing PHP for Drupal sites. My reaction to CppCMS is just to note that it wouldn't necessarily be easy to create a faster CMS using C++ versus PHP. Drupal sites can be slow as dogs, but the reason has nothing to do with PHP per se. The Drupal codebase is extremely bloated and fairly inefficient in its design, but even worse are the modules that get piled on, and there can easily be well over 100 modules on a site. I've watched the database queries that come out from a real site and it was stunning and appalling to see the volume and the redundancy that occurs on a single page. I was also amazed by the sheer quantity of PHP that gets loaded and parsed (if you're not caching) on a single page. So that tells me that PHP is pretty fast to be able to support that enormous edifice of code. It's not a guarantee that C++ would make you faster than an interpreted language, because the work that goes into generating a webpage plays to the strengths of interpreted languages and away from C++: you'd have to be careful and think through how to handle lots of strings and memory management. A good garbage collector is said to be faster than malloc/new when churning through lots of memory, because it can amortize the work and run on a background thread. I think lots of little strings could especially become a problem unless you planned out a strategy for handling them efficiently. Also, as others have pointed out, a lot of the issues with making a website fast aren't about executing code on the cpu. It wouldn't necessarily be easy to beat something like node.js at handling requests asynchronously, for instance. That stuff can be hard to write. So, I think it would be a good idea to do even a very high performance site in an interpreted web language first, then decide cautiously if there's a way to make it faster by replacing some or all of it with hand-written C++.