shared_ptr - Yes, even non-boosters like this.

regex - pcre

string - stl string

bind - if this is what I think it is, please don't use it. Future maintainers of your code will be grateful.

Having said that, C++ is a large world, and choosing to use these Boost components is perfectly valid.

boost::bind seems more like evidence in the case against C++ than an advertisement for boost.

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.

  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();
  };

If not, the only problem here is that C++ won't let you have a virtual function override that only differs by return type. And since it can't tell that shared_ptr<A> and shared_ptr<B> are related by value_type, it complains (this is the larger point that I granted you earlier). But the type theatrics are hiding a bigger problem....

In this example, you can either fix the type error by making makeOne() return a boost::shared_ptr<A> in all factories (in which case, you really do want a polymorphic interface), or you can make a new function that returns a different pointer type (in which case, you don't). The type system here is doing you a favor, and telling you that your design is bogus -- you shouldn't be creating a polymorphic factory interface that returns different types (because that isn't actually polymorphic, is it?)

This isn't totally academic: I find that in nearly all type-error situations like this one, the real problem can be traced back to sloppy coding.

"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."

There's always a cost to reference counting, and therefore, it's not always appropriate. That said, the only time you should be triggering atomic operations are on pointer copies and allocations. If you're doing allocations per request, kiss your microsecond response time goodbye -- the reference count overhead is the least of your worries. And you can avoid unnecessary pointer copies by passing shared_ptr<> objects by reference. With a small amount of care, it's possible to reduce shared_ptr<> overhead to essentially zero.

Covariant return types are a powerful feature in a language that doesn't support other forms of return type polymorphism. shared_ptrs function so similarly to pointers that it can be surprising when they don't support this behavior. Surprise and capability mismatch with pointers are strikes against shared_ptr. But not sufficient ones to stop me from using them.

No, they're not. One is returning a pointer to A, and the other is returning a pointer to B (which just happens to be a subclass of A). It matters, and just because you can do it with a naked pointer doesn't mean that you should. The problem you've described is a code smell.

If I hand you a pointer to B, you (client code) can do everything that is exposed by B. If I hand you a pointer to A, you can only do the set of things exposed by A. And that's a fundamentally different interface guarantee.

I have a polymorphic type that should be copyable. Because of the limitations of C++ copy constructors and operators, my only option is to expose a virtual method (call it "copy"). The non-smelly semantics we want are such that if you call "copy" on an object, you get an identical copy of the same type. So if you call "copy" on a pointer of type A, you get an A. Call it on a B, you get a B.

The contract itself is polymorphic. It doesn't commit to returning any particular flavor of A.

We can implement this method if we return naked pointers. But if we want to be safe and return a smart pointer, we have to introduce dynamic casting or other worse smells.

Well, yeah...because those semantics are just as smelly as the one you described before. What you describe isn't a copy constructor at all, and trying to make a copy constructor do what you want is a dangerous thing. A "constructor" that takes any subclass of class A and returns an instance of that subclass is inherently brittle: add a new subclass of A, and you've got to update the "constructor" to know about the new type. On top of that, your "constructor" has to introspect into the type to determine what to initialize when, and that's slow.

There are easy ways to get the behavior your want (e.g. make a template function that calls the appropriate class' copy constructor, or -- closest to what you want -- make a template copy constructor function on the class itself), but complaining that you can't make a bog-standard copy constructor do polymorphic construction kind of misses the point.

Here's a better discussion of the problem than I have the space to go into here:

http://www.jaggersoft.com/pubs/oload24.html

But just to clarify: no base class implementation is aware of derived classes in the copying case, so your smell doesn't exist. See Scott Meyers' "virtual copy constructor" snippet half way down the page: http://books.google.com/books?id=azvE8V0c-mYC&lpg=PT159&...

You can't do it that neatly without covariant return types. Ergo, you can't do that while returning safe, smart pointers.

Not using shared_ptr a code smell? If you're not able to keep track of your objects yourself, you should not be using C or C++. It's not that hard like you would like us believe.

Also, apart from the cost of maintaining reference counts, shared_ptr makes an extra allocation for the control block. Unless you take care and use make_shared, you end up with allocations that are twice as slow.

On a cynical side: Boost has become Dave Abrahams' business (1) He (and co.) have a vested interest in making you believe that the Boost-way is "the" way of writing "modern" (as defined by HIM and his followers) C++ code. I just wonder whether he had that much foresight, or just took the chance when he saw the opportunity.

(1) I remember once asking about obtaining slides about fusion from a past BoostCon conference and got a blank "no". Slides were available only to the people who paid to attend the conference.

Yes. It's part of the C++ standard. All rants against Dave Abrahams and Boost aside, not using the standard library to do standard things is a code smell.

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.

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).

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!

There are some good parts of boost. shared_ptr, bind and regex are now in the C++ standard library.

uuid is an interesting example, as it really doesn't have any reason to be 'in' boost. It is a small, self-contained library which (I understand) does one thing very well. In any other language it would just be in the standard package repository. However, for some reason in C++, instead everyone wants to get into this one bundle of packages.

The problem is, because boost is monolithic, the temptation to developers is to start pulling in some boost::spirit, or boost::phoenix. I find these libraries fascinating from the point of view of what can be achieved in C++, but for day to day maintenance they cause serious problems.

The problem (which I could have better articulated) is that the messier, templated parts of boost end up being seen as 'best practice', or libraries that people should use. I wold much prefer something which lets me easily install just uuid, or boost::optional (another great tiny boost library). There are of course various solutions. I could install a stripped-down boost, or just introduce strict coding standards.

(Maybe experience is even the problem. A C++ programmer might suck up a 40 second round trip time, but I bet no PHP or Python programmer would!)

Large C++ projects already tend to suffer from monstrous compile and link times. Anything that increases build times is inherently a bad idea. Iteration time has been THE major issue on every project I've worked on. Sucks up man-hours like nobody's business. All the other C++ junk... borderline irrelevant, by comparison.

I'd say this is only true part of the time. Optimizing for developers' time (thus, payroll cost) is a good idea, but not to the exclusion of other costs. For instance, if you're building a web app that's grown to the point where the business's primary cost is the hardware on which the software runs, it makes sense to make technology decisions with that in mind. Trading some developer efficiency for lower data center costs is perfectly reasonable.

I've long wondered about why doesn't any C++ compiler implement symbol hashing? As in: replace symbol names with symbol hashes (SHA1) in the symbol table, and emit an extra section that maps hashes back to mangled names. Linker could do all of its work using hashes, and would map them back to regular symbol names only when generating the final debug info file.

The OCaml compiler uses hashes for some symbols. It has to have extra discrimination code in the linker to deal with potential collisions, and it can reject valid programs because of this. That's in theory, because I've never seen a program rejected, except for a synthetic program that someone made to demonstrate hash collisions ...

Collision in hashes is of only theoretical interest when you consider SHA1 or SHA256.

I use Boost daily. I absolutely love it. It's wonderful. I could not do my job w/o it. Much of it is in the new C++11 standard too.

I think the Qt people might have something to say about that.

With boost you usually pick and choose and include parts of the (templated) libraries directly into your project directory, so you don't have to embrace it in full.

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.

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.

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.