Simon Hill wrote: > Brendon Costa said: >> The author of the template class or container can't know >> what types of exceptions will be thrown from them, so you must define >> them as being able to throw all exceptions (which is how they are >> currently). > Ouch, you have a point. But couldn't you put this round the other way. > Place the onus on the user of the template to comply with the > exception guarantees inside the template. Unfortunately that would > likely cause problems with some existing code. > > ... > > In other words, would you gain more from a tight exception > specification than you'd lose by not being able to do this? > You as an author of a new template class "could" define it the other way.
The issue here is that doing so restricts usage of the generic component. In specific cases this may be desirable, but not for generic components like STL containers or those in boost. For generic components you want to make them as useful as possible. Even if at the time of writing the container you do not foresee that throwing any type of exception is a good idea, users may come up with some way of using it that you just never thought about. I.e. I think the general philosophy is to define only what restrictions are necessary to implement the template, not necessarily what we think constitute good uses of the template at the time we created it. Brendon.