4 ms·

> Most of Boost is a horrible templated mess. Are you just saying you find the implementation distasteful? I don't find using the templated boost stuff problem

> Most of Boost is a horrible templated mess. Are you just saying you find the implementation distasteful? I don't find using the templated boost stuff problematic. Most of the time you just cargo cult examples from the documentation and all's good, but then you have great flexibility should you need it.

tptacek 15y ago
"Most of the time you just cargo cult examples from the documentation". Yes. This.
- rubashov 15y ago
  That's how any API is used 90% of the time.
  - tptacek 15y ago
    Disagree. And, tip: don't say that at a job interview.
    - rubashov 15y ago
      Tip: don't be a glib, smug prick on a date. Please enunciate why something like asio is evil. You review the documentation and examples and the outlined primary use cases "just work". But you can dive in and do really complicated things.
      - tptacek 15y ago
        I don't think any of Boost is "evil", and I haven't mentioned asio --- asio came out after I was done using Boost. But I agree with you that a lot of C++ code works because it's part of a cargo-cult culture, not because the interfaces themselves are particularly well- thought- out.
jules 15y ago
> you just cargo cult examples from the documentation This mindset, and libraries that are basically only usable in that way if you don't want to invest months of your time are the bane of programming. Library writers, please: 1. Design the API by thinking about how it will be used, not how it will be implemented. 2. Make sure that your publicly exposed interface can be specified simply. If your specification is anywhere near as complex as the code implementing it you know you're doing something wrong; your library is not reducing complexity.
- rubashov 15y ago
  The complicated parts of boost where this is what you end up doing are really more like libraries for library writers. You'd almost certainly wrap something like Boost.Geometry for your specific needs. It's made with flexibility as the goal. So it's really not the problem you're presenting. The alternative is dozens of different half-baked libraries for specific use cases.

tptacek 15y ago

"Most of the time you just cargo cult examples from the documentation". Yes. This.

rubashov 15y ago
That's how any API is used 90% of the time.
- tptacek 15y ago
  Disagree. And, tip: don't say that at a job interview.
  - rubashov 15y ago
    Tip: don't be a glib, smug prick on a date. Please enunciate why something like asio is evil. You review the documentation and examples and the outlined primary use cases "just work". But you can dive in and do really complicated things.
    - tptacek 15y ago
      I don't think any of Boost is "evil", and I haven't mentioned asio --- asio came out after I was done using Boost. But I agree with you that a lot of C++ code works because it's part of a cargo-cult culture, not because the interfaces themselves are particularly well- thought- out.

jules 15y ago

> you just cargo cult examples from the documentation This mindset, and libraries that are basically only usable in that way if you don't want to invest months of your time are the bane of programming. Library writers, please: 1. Design the API by thinking about how it will be used, not how it will be implemented. 2. Make sure that your publicly exposed interface can be specified simply. If your specification is anywhere near as complex as the code implementing it you know you're doing something wrong; your library is not reducing complexity.

rubashov 15y ago
The complicated parts of boost where this is what you end up doing are really more like libraries for library writers. You'd almost certainly wrap something like Boost.Geometry for your specific needs. It's made with flexibility as the goal. So it's really not the problem you're presenting. The alternative is dozens of different half-baked libraries for specific use cases.