4 ms·

Well, off the top of my head - and I may be missing some of the awesomeness of boost: shared_ptr - Yes, even non-boosters like this. regex - pcre string - st

• astral303 15y ago
  Anyone care to elaborate on the evils of boost::bind? Maybe from experience? I used boost::bind and boost::function in VC6 code of all places and I thought that the resulting code turned out to be pretty decent (I think newer compilers let you use slightly less verbose syntax), and I really liked having the functionality of being able to pre-bind certain arguments. For example, I had a menu item click handler that I was able to bind a call to a unary method, but with different parameters. I thought the resulting code was simpler overall (and easier to refactor).
  • asher 15y ago
    Well IIRC it was a tempting way to replace for-loops with direct list operations ala Python, Ruby etc. But the amount of syntactic noise and cognitive load seemed too much for the added leverage. Our code had sufficient complexity that I didn't want one more oddity (as many would see it) to explain. But for a small team, or a team that's all on the same page, maybe it's good. Sorry to say there's no dramatic story of code explosion here!
    • FooBarWidget 15y ago
      I wouldn't use it for for-loops either, but man, boost::bind is so handy when compiled with boost::function! I used to use function pointers and 'void *userData'. If I wanted to pass additional data to the function then I have to allocate a structure and not forgetting to free it later which resulted in a lot of boilerplate code.
• tptacek 15y ago
  And maybe they shouldn't like shared_ptr so much! It's a source of memory lifecycle bugs; everything touched by shared_ptr needs to be under the shared_ptr regime or carefully bridged to it. boost::bind seems more like evidence in the case against C++ than an advertisement for boost.
  • timr 15y ago
    "everything touched by shared_ptr needs to be under the shared_ptr regime or carefully bridged to it" Well, yes. That's sort of the point. You can write old-style C++, or your can write modern C++, but the library designers are trying to make you think carefully when you're doing both, because that is a source of memory lifecycle bugs. Using the boost (now standard) pointers universally tends to dramatically reduce the chances of memory-related bugs in C++ code. Not using shared_ptr is a code smell. Sometimes you have to do it, but if you're avoiding the use of the smart pointer classes in blue sky code, you're doing something wrong.
    • tptacek 15y ago
      This breaks down as soon as you have to integrate 3rd party code.
      • timr 15y ago
        It doesn't "break"...you just have to think about what you're doing. Which, again, is the point. If some external code is passing you pointers, then using shared_ptr is exactly the wrong thing to do, because you (presumably) don't own the memory. And if you do own the memory, there's no problem putting it in a shared_ptr. The fact that you can't blindly stuff everything into a shared_ptr is a feature, not a bug.
    • alexgartrell 15y ago
      The main thing that sucks about shared_ptr's is that they break C++'s limited support for covariance. For example class A { ... }; class B : public A { ... }; // Totally works class AFactory { public: virtual A* makeOne(); } class BFactory : public AFactory { public: virtual B* makeOne(); } // totally doesn't class SharedAFactory { public: virtual boost::shared_ptr<A> makeOne(); }; class SharedBFactory { public: virtual boost::shared_ptr<B> makeOne(); }; Also, from a performance perspective, locking the memory bus to do atomic operations on a shared_ptr totally blows when you're expected to turn a request around in a few microseconds.