Paul, I've argued both sides of this issue to death in the past, so I'm certainly not going to do it again. Suffice it to say that if you cannot fix the defective code (typically, because it is part of the codebase you are not expected to modify -- for example, part of the library headers shipped with your compiler, or a 3rd party library you have to use), and you cannot direct the tool to work around it then you have to throw away one or the other. The real world choice is often in favor of the bad code, not the good tool. I am not saying that it's right, just that it's the reality. Note that Boost libraries (and their developers, which, I understand, means you too :) ) go to great lengths to preserve compatibility with as many compilers as possible, despite sometimes having to work around glaring bugs and/or incompatibilities with the standard. Otherwise the number of Boost users would have been a lot smaller, and irrelevancy is a bigger risk than indirect support of bad practices. This is obviously a matter of balance, but I imagine that the heaviest weight on the opposite side of the scales comes from the expense of supporting the workarounds, not from the fact that those workarounds somehow encourage people to use broken compilers. Programming after all is not an art into itself, it is a process of building software for a specific purpose, and with a whole lot of constraints (budget, schedule, learning curve, irrational preferences of the management -- you name it...). The fewer constraints are violated by a specific tool, the more likely it is to be used. That's all I'm saying... Regards, ...Max...