The Boost Virus

Why is everyone so fucking inclined to use Boost?
Why do you need to add a fuck ton of dependencies on your small toy programs?

Can't you just stick with vanilla C++ and do us all a favor?

If there's anything I'm never installing for a project? It's boost.

>>39
It's "lo and behold," you degenerate illiterate.

>>39,41
It's a reddit quality idiom either way, just like "Enter React.js".

Boost is just a natural, cancerous extension of the tentacle monster called STL.

C++ gives rise to powerful abstractions, which come at a high cost - as Linus called it, "spooky action at a distance". This is why a lot of people have agreed to treat it all as a black box, to even keep track of it all. Custom standard libraries are impossible for readable code, as potential audience would have to learn everything that happens underneath from scratch.

Note that OO itself isn't the devil, it's the sheer complexity of low level C++ you're forced to use with C++ OO.

This prompts contrarians to NIH their shit. To stop that, STL and Boost were invented. Have you ever worked with STL/Boost "free" codebase? Those tend to have NIH stdlibs just straight broken and ill conceived. Of course STL has its plan9 unicorns too ("better, but the predecessor is good enough so we use that") - for example QT, or even WTF.

Third route is to just treat C++ as C with classes and ignore most of its problematic features (references, scoped destructors, templating, operator overloading...) so that rules stay basically the same as with C - code can be read more or less intuitively, top down, procedural fashion, with minimum of hidden side effects. Then C++ becomes a convenient syntactic sugar.

If you want less broken OO language for system programming, just use something designed with that in mind. Go, Rust...

>>43

C++ gives rise to powerful abstractions.

No, C++ gives rise to very constrained abstractions. The way you abstract and the tools you use to do so are railroaded by the fear of computational cost of the C++ designers. The only way to get anything semi-abstract out of it is with the template explosion of STL and Boost, or large amounts of manually added runtime code. I would not call this "powerful" in comparison to the rest of the field.

>>4
Seem like Crystal is the right choice

>>44

in comparison to the rest of the field.

Agreed. The frankenmonster C legacy is somewhat unfortunate, in combination with weird degrees of freedom to accomodate it. However what else is actually out there integrating with C, directly at semantic level, ie not as mere FFI.

>>45
Crystal is really cute, owing much to orthogonal design of ruby OO. Still in its infancy, also needs a proper GC (or even better, rc).

Already using it to port some slow ruby tools.

>>46
What C++ did with C hardly qualifies as integration, but its particular brand of integration was not as much a mistake in the particular instance of C++ as it was in general. The question is not "What else integrates™ C?" — it's "Why the hell would I want to integrate™ C?". If you want something that is fundamentally different from C, don't mix it with C, full stop.

If you want something that is fundamentally different from C, don't mix it with C, full stop.

Yet binding generator libraries consistently try (sometimes poorly). Ever had to deal with boost-python?

Clearly there is some demand to directly bridge code. LuaJIT-like FFIs are somewhat popular for this reason, as it exposes direct view of C namespace to the host language without need to actually re-declare the import C arity/structs using some special, host-specific facilities. Sadly this works only on clear ABI boundaries. If you want macro support, you have to pull in the whole shebang and stay syntactically compatible, just like C++ does.

>>48
Binding generators are no languages and macros in an API are shit for exactly this reason. What the fuck are you even talking about?

Forget about binding to libraries, every major OS and almost all minor OSes expose their system API in C, and assume an application-side libc dependency. That's the fundamental bullshit about computing.

>>50
People are stuck with C because the majority of today's PL researchers focus on ``lambda calculus with $type_system'' instead of creating better languages for programmers to use.

| Crystal is really cute, owing much to orthogonal design of ruby OO.

I'm using it to implement some algorithm for project euler. It's pretty fun compare to C/C++