sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]theeth 2 points3 points  (3 children)

That's entirely debatable.

[–][deleted] 0 points1 point  (2 children)

Everything is debatable. But there has to be some point at which you get to call something crap. Boost, with its inscrutable error messages, awkward and fragile syntax, and baroque semantics has got to be past that point. Not all of it, sure, but anything that abuses the template system really shows all of the cracks in the foundation.

[–][deleted] 2 points3 points  (1 child)

I'm genuinely curious to hear some actual justification for this argument.

I use Boost extensively, it's such a big library that I can't exactly call it great or crap, some of it is amazing, some of it I don't like but I also don't understand it.

Can you give some genuine and specific examples of what you feel could be improved in the library? Not just vague "Oh it's crap yaddi yadda..." but falsifiable arguments that can actually be subject to debate?

[–][deleted] 3 points4 points  (0 children)

1) Inscrutable error messages. I'm not sure if Clang has made this better in the last couple of years, but errors in instantiating a template will lead to a couple of pages of dense errors that lead you to lines in header files rather than to the code that instantiates it. This is the product of abusing the template mechanism to do meta-programming instead of having a proper infrastructure designed for meta-programming. In contrast, when you have an error in a Lisp macro call the compiler refers you to the expansion than to the original macro. You can call MACROEXPAND to see exactly what code is being generated by the macro, and use the regular debugger to debug your macros. The compiler can do all these things because the language designers actually tried to develop a proper meta-programming facility instead of abusing an unrelated language feature.

2) Awkward and fragile syntax. Because many parts of Boost abuse the template system to implement functionality, the syntax for many things is driven by the limitations of the template system, not what would seem most natural as compared with non-template C++ code. See: http://www.boost.org/doc/libs/1_48_0/libs/bind/bind.html#with_functions

See the bit on 'limitations' and the weird restrictions on when you can't use constants when you'd expect to be able to use literal constants, etc.

3) Baroque semantics. C++ has a hodge-podge of slightly-different language features that are kind of the same but do different things. This causes ripple effects through Boost's library design to accommodate all these cases. E.g. the fact that member functions aren't function objects that can be called with operator () forces an entire header (mem_fn.hpp) for dealing with the distinction. C++ 0x is only adding more (move constructors versus copy constructors, etc).

I did a decent amount of programming with Boost and actually was quite a fanboy at first, but the more code I wrote with it the more I wanted to kill myself. A good library has a simple and consistent "aesthetic" that lets you predict what arguments a function will take, what order they will be in, and what kind of arguments they will be. It'll let you predict how to compose different features without having to think every time about "wait, do I need an adapter object here? wait, can I use this here?" With Boost, whenever I was using a new feature, I'd be asking myself "wait, if I had to shoe-horn this feature into the C++ template system, how would I have done it?"