Some developers do, some developers don't (in games and elsewhere). It depends on what the needs/requirements of those developers are, and what existing technology they have to leverage.

The SC++L is often given the same treatment, and people often wonder the same thing you are wondering about it, too. Most of the reasons are similar, for example:

• A developer may already have an in-house library of functionality that provides the same services that the SC++L or Boost provides. Such in-house libraries were often written long ago, when implementation support for the SC++L was weak and Boost was basically non-existent, so they more-or-less had to be written. In this scenario, it's usually not really worth transitioning away from the in-house functionality -- it would be a major porting effort that would destabilize a lot of code, and provide almost no benefit.

• A developer may be working on platforms where compiler support for the advanced C++ techniques leveraged by Boost are not well supported, such that the Boost code doesn't compile at all or performs quite poorly. This applies to the SC++L as well, although much less so these days.

• Boost and the SC++L are general purpose, and while that is fine and good for most applications, sometimes a developer has specific needs that can be better addressed by more specialized containers.

I think the above are two reasonable reasons, although there are certainly others. You have to be careful though because many reasons for avoiding Boost/SC++L/whatever boil down to "not invented here" syndrome, which can be an indication that the reason isn't very well grounded in practical realities.

Also remember that the needs of a large-ish studio are usually very different from the needs of an individual developer. For example, an individual developer probably has less legacy code floating around to maintain and so perhaps porting from a home-grown version of the Boost or SC++L functionality will not be as big of a time sink and will save that developer from having to maintain that code as extensively in the future -- thus invalidating my first bullet point.

In the end, it is all about evaluating your requirements and time investiture against your desired goal and determining which option meets your needs the best. Developers who aren't using Boost/SC++L have usually done so and reached that conclusion -- perhaps you will too, and perhaps not.

Some developers do, some developers don't (in games and elsewhere). It depends on what the needs/requirements of those developers are, and what existing technology they have to leverage.

C++'s standard library is often given the same treatment, and people often wonder the same thing you are wondering about it, too. Most of the reasons are similar, for example:

• A developer may already have an in-house library of functionality that provides the same services that the standard library or Boost provides. Such in-house libraries were often written long ago, when implementation support for the standard library was weak and Boost was basically non-existent, so they more-or-less had to be written. In this scenario, it's usually not really worth transitioning away from the in-house functionality -- it would be a major porting effort that would destabilize a lot of code, and provide almost no benefit.

• A developer may be working on platforms where compiler support for the advanced C++ techniques leveraged by Boost are not well supported, such that the Boost code doesn't compile at all or performs quite poorly. This applies to the standard library as well, although much less so these days.

• Boost and the language's standard library are general purpose, and while that is fine and good for most applications, sometimes a developer has specific needs that can be better addressed by more specialized containers.

I think the above are two reasonable reasons, although there are certainly others. You have to be careful though because many reasons for avoiding Boost, the standard libraries, or whatever boil down to "not invented here" syndrome, which can be an indication that the reason isn't very well grounded in practical realities.

Also remember that the needs of a large-ish studio are usually very different from the needs of an individual developer. For example, an individual developer probably has less legacy code floating around to maintain and so perhaps porting from a home-grown version of the Boost or standard library functionality will not be as big of a time sink and will save that developer from having to maintain that code as extensively in the future -- thus invalidating my first bullet point.

In the end, it is all about evaluating your requirements and time investiture against your desired goal and determining which option meets your needs the best. Developers who aren't using Boost or the standard library have usually done so and reached that conclusion -- perhaps you will too, and perhaps not.