Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Crow – C++ Microframework for Web, inspired by Python Flask

github.com

Post reply on HN
Print view View original

51–60 of 65 posts

Re: Crow – C++ Microframework for Web, inspired by Python Flask

#51

Post by Iftheshoefits »

frankzinger wrote: post #48
mattgreenrocks wrote: post #45

Earlier quoted context omitted.

It may seem unusual because you haven't seen it, but header-only libraries are perfectly valid for small, focused libraries.

How do you justify mass recompilations for every minor version bump or bugfix to your users?

Just a couple of points.

1. It is an error to couple this library closely enough to the rest of a project's code to cause the condition you note to exist. This kind of library is best used in a small project or as part of the implementation of a user-defined abstraction interface (an abstraction specific to his project's use cases that would not make sense being included in the library code). A small project will compile quickly anyway, and the second kind of project will only need to be compiled if the abstraction's interface changes.

2. C++ compile times aren't that bad. I won't argue that it's not bad in large code bases: it indeed becomes atrocious when the codebase becomes large and spread out over a large number of compilation units (or when coupling is excessive).

Re: Crow – C++ Microframework for Web, inspired by Python Flask

#53

Post by plorkyeran »

frankzinger wrote: post #48
mattgreenrocks wrote: post #45

Earlier quoted context omitted.

It may seem unusual because you haven't seen it, but header-only libraries are perfectly valid for small, focused libraries.

How do you justify mass recompilations for every minor version bump or bugfix to your users?

C++ makes maintaining ABI compatibility quite difficult, so in practice libraries with a C++ interface tend to default to requiring that anyway.

Re: Crow – C++ Microframework for Web, inspired by Python Flask

#54

Post by oscargrouch »

przemoc wrote: post #19

C++ _micro_framework using boost. Just couldn't resist to notice that. ;) (I know that boost consists of many libraries, many of them are header only, etc. so using them doesn't necessarily result in terrible bloat.) Will have a proper look at it later.

Im not coding much C++ lately, but i think if someone just pick some basic(base, ipc, net, etc..) parts of chromium and create a redistributable library with it.. it would be a very sane and powerful competitor to boost when you are coding in C++ 03..

Re: Crow – C++ Microframework for Web, inspired by Python Flask

#55

Post by tpush »

frankzinger wrote: post #23
Mr_P wrote: post #16

Earlier quoted context omitted.

Header-only libraries have several advantages (see http://en.wikipedia.org/wiki/Header-only ). Most-notably, they are dead-simple to include with a project, as opposed to having to separately build and link to a shared-library.

Yeah but usually "header-only" implies templates, of which there seems to be little in this case. Without templates there's little point in putting everything in headers because all the code becomes inline. Inlining everything is bad because: - it makes the binary much bigger. - the smallest code change forces library users (applications) to be recompiled. For libraries it's usually better to go to the other extreme:…

I'd even argue that, with an LTO-optimizing compiler (e.g. clang -flto), writing functions inline is basically obsolete. In my case clang/llvm is very much able to inline code across object file boundaries, even capable of analyzing function-pointer assigments and inline the respective functions.

Re: Crow – C++ Microframework for Web, inspired by Python Flask

#56

Post by sdab »

mappu wrote: post #22

Today i learned constexpr, enum class, and operator "". Thank you. The full trie implementation caught my eye, are there no suitable alternatives in std or boost? Mixed tabs and spaces (?) cause strange display in github in json.h from 555 through 670 or so. Also at the start of json.h it seems a shame to repeat __builtin_expect rules, how about #if defined() || ?

huh, never seen operator "". Seems to be a c++11 feature.

[1] helped me understand it a bit, but Im not sure I see a compelling use case. Does it just provide a shorthand for calling functions on primitive types (and strings) or have I misunderstood? While requiring less characters might it not decrease readability?

1. http://en.cppreference.com/w/cpp/language/user_literal

Re: Crow – C++ Microframework for Web, inspired by Python Flask

#57

Post by SomeCallMeTim »

mike-cardwell wrote: post #44
mox1 wrote: post #43

Earlier quoted context omitted.

If all of this is happening in it's own thread (and there's probably 1 thread per connection), why add the overhead and complexity of something like this?

I've looked at his code and that is not how it works. It uses boost::asio. You specify how many io_service threads to run. It is not 1 thread per connection. You could easily have 10000 connections spread across 4 threads for example. The threads that handle the connections are the same threads which run the callbacks. You wouldn't want threads being blocked by callbacks that take a long time to run. You'd want to pa…

It's important to note that requiring 10000+ real threads would be a huge limitation, performance-wise. At that scale you end up with a lot of overhead from process switching.

The difference is a big reason why Apache 2.2 would slow to a crawl and eat up gigabytes of RAM at 100% processor utilization on the same load that Nginx could handle with 10Mb of RAM and 20% processor utilization. [1] (I understand more recent versions of Apache now support polling [2].)

[1] See, for example, this explanation: http://stackoverflow.com/questions/2583350/is-epoll-the-esse...

[2] https://httpd.apache.org/docs/2.4/mod/event.html

Re: Crow – C++ Microframework for Web, inspired by Python Flask

#58

Post by frankzinger »

plorkyeran wrote: post #53
frankzinger wrote: post #48

Earlier quoted context omitted.

How do you justify mass recompilations for every minor version bump or bugfix to your users?

C++ makes maintaining ABI compatibility quite difficult, so in practice libraries with a C++ interface tend to default to requiring that anyway.

Yes, it's difficult by default, but the solution is https://en.wikipedia.org/wiki/Opaque_pointer and it is quite well-known in the C++ world.

Re: Crow – C++ Microframework for Web, inspired by Python Flask

#59

Post by frankzinger »

Iftheshoefits wrote: post #51
frankzinger wrote: post #48

Earlier quoted context omitted.

How do you justify mass recompilations for every minor version bump or bugfix to your users?

Just a couple of points. 1. It is an error to couple this library closely enough to the rest of a project's code to cause the condition you note to exist. This kind of library is best used in a small project or as part of the implementation of a user-defined abstraction interface (an abstraction specific to his project's use cases that would not make sense being included in the library code). A small project will com…

> 1. It is an error to couple this library closely enough to the rest of a project's code to cause the condition you note to exist.

Any compilation unit (source file/module) which calls a function in this library will have to be recompiled if any of the called functions change which means that your application will also have to be re-linked. There's just no way of getting around that.

Re: Crow – C++ Microframework for Web, inspired by Python Flask

#60

Post by shanemhansen »

ipkn wrote: post #47
mike-cardwell wrote: post #33

The way your routes work mean that a response is expected to be immediately generated and returned. It would be much nicer if a response object was passed to the callback and you could return immediately from the callback, but send a response independently, when you are ready. Kind of like this: CROW_ROUTE(app, "/about") ([](Response res){ res.send("About Crow example"); }); Why you might ask? So you can do this: CRO…

I agree that allowing implementing long polling with crow is important, just I didn't know a good way to do that. Your suggestion is big help. I think supporting both way is better if there is a enough explanation. I don't want to drop a simpler way to do the same job. CROW_ROUTE(app, "/about") ([](){ return "About Crow example"; }); CROW_ROUTE(app, "/about") ([](Response res){ res.send("About Crow example"); });

^this is exactly how twisted implements their web resources.
Post reply on HN