Hacker News Reader

Comment by rburhum | Hacker News Reader

We implemented our own client using libwebsockets (https://libwebsockets.org/trac/libwebsockets). Our main rationale, was that we use the 95% of the same codebase for iOS/Android/Win/OSX/Linux.

I got curious about this library, but the boost dependency is an immediate "oh hell no". Even more so now that we have good C++11 features across the board and so the boost dependency is something we avoid like the plague (we used to have it and C++11 support was a god-sent that enabled us to get rid of boost).

Nice to see more C++ libraries here though.

View on HN

> but the boost dependency is an immediate "oh hell no".

So forgive me because I'm pretty new to C++ (well I knew it semi decently 12 years ago; trying to relearn now) but most of the C++ developers I know love boost especially for asio since most tcp libs seem to be very old. What is the reason it makes you go "oh hell no"?

If you don't care about speed, Berkeley sockets (bind, listen, accept, etc.) are just fine and very easy to deal with.

If you do care about speed, you should be banging against the operating system's provided tools anyways (IOCP on Windows, kqueue on BSD, epoll on Linux, etc.).

If it's abstraction you care about, you shouldn't be doing networking with raw TCP anyways, and should just use zmq, nanomsg, or whatever, and not drag in the entire clown car of boost.

> not drag in the entire clown car of boost.

As far as I can tell you can just import what you want and not have to bring in the entire boost library to use asio. Is that not correct?

This weekend I tried to bring in boost format. I tried to bring in JUST format, but nope... exceptions, and config, and a bunch of other stuff... Fifteen libraries, maybe?

asio specifically is available in a standalone version that does not depend on any other boost libraries.

Boost's asio has backends (reactors) for IOCP, kqueue, etc. The whole point is you write to one interface and take advantage of their performance.

10 years ago for me it was because it was really hard to get it to compile. I might get it setup on my cygwin install or my linux but have trouble compiling it on both. I was able to get mozilla compiling faster/easier then boost... It's probably improved a lot since then, but back then if you had asked me to use boost I'd be rather upset as well... I think now days at least on linux there are packages for boost so it's not bad at all and also homebrew for mac so that's exciting.

`but the boost dependency is an immediate "oh hell no"`

If this were a C++11 and standalone ASIO dependency would that change your mind? If it is a specific issue with ASIO, what sort of network transport would you want to see used for something like this (there is no network library in C++11)?

Yes, it would change my mind if all the dependencies are easy to compile and work cross-platform (Android/iOS/OSX/Linux/Windows) without a problem.

> the boost dependency is an immediate "oh hell no"

Can you expand on that?

Boost makes you enter header and linking hell. I'm talking "an entire day to figure out how to include that in your makefile and why the fuck doesn't it link correctly" level hell.

You can also count on having 10MB+ of libraries to distribute if you use the entire boost lib (which, let's be honest, will be the case 90% of the time because people can't bother with cherrypicking features)

And just pray that you don't need to recompile boost because you're in for a fun few hours of wasted compilation because it fails at 80% because of <cryptic boost message>

This is what I find most surprising about C++. Apparently including a single library as a dependency takes large amounts of effort. The end result seems to be that developers avoid using dependencies and resort to rewriting large amounts of code.

If you contrast this with, say, Node.js, you could simply do "npm install boost --save-dev" and "var boost = require('boost');".

Nobody seems to use C++ package managers either, and the typical reply is to use the package manager of the operating system. But since that's not platform neutral there's a lot of wasted effort of maintaining multiple instructions to install the library. And Windows instructions typically require non-trivial amount of manual work, often even setting up weird environment variables pointing to various locations.

And then you want to build for 32bit instead of 64b and there's more manual work.

I would have imagined that this would be a solved problem by now.

Hmm, granted I'm very new to boost and to C++ in general because I'm relearning it but a couple of nights ago I grabbed boost, compiled from source and tried out an asio example and it all seemed to work pretty easily. Maybe I need to get into more complex projects to see how bad it gets (which is worry-some since I'm essentially a newbie and don't want to waste my time learning something that won't be useful later (or just painful)).

> And just pray that you don't need to recompile boost because you're in for a fun few hours of wasted compilation because it fails at 80% because of <cryptic boost message>

It took my lowest spec MacBook Air about 15-20 minutes to compile from source. Does it normally take hours for you?

Of course, boost is not as hard as some grumpy oldtimers make you believe. Anyone who refuses to use the massive amounts of tested, reliable code that is boost because 'it's too hard to install', should be banned from any real-world project for severe NIH syndrome.

>grumpy oldtimers

I wish I was a grumpy oldtimer, but I'm more of a dirty youngun'.

Note that I didn't say "don't use boost". Boost is amazing and you should use it if it saves you time. It's just that initial setup may be... let's say interesting.

This... Boost will ruin your compile times. I'm addicted to instant compilation so I avoid template hell.

They were referring to compile times to build boost itself, not of their own projects. On most Linux distros, there are binaries already available so that's not a problem; yes with brew on OSX it takes a long time but you don't do it that often.

Of course template-heavy, header-only libraries will increase compile time, but not insanely so. I try to be careful about including boost's ease-of-use headers which pull in everything and keep it limited to what I really need from a given sub-project.

Most of what I use from boost is in C++11, except asio, but the same principals apply.

Bingo.

Reply on news.ycombinator.com