23.6. Template Constructors: Coda

So where are we? Argument proxies are a perfectly good solution technically, but they are counter to the C++ ethos, whereby types, even those obtained by the parameterization of templates, should present a simple and robust interface and should manage things on behalf of their users. Requiring users of your templates to know when and where to use argument proxies is not practicable, so this technique is useful only in extreme cases in well-managed contexts.

That leaves us with targeting argument types. It can hardly be considered a good solution, but it's preferable to forcing all composite types to be default constructed. Ever heard of RAII? The combinatorial problem is a pain, but it's a write-once thing, so I guess we can't complain (apart from those extended compilation times). These things are easily done with scripting langauges.

One thing I should point out, if it's not already obvious: The problem of passing arguments through templates is not limited to constructors. It's just that we don't usually need to provide forwarding functions for nonconstructor methods. The only time when this is an issue is when using nonpublic inheritance, which is unlikely to be encountered with bolt-ins and similar generic templates.

This is one of the few issues covered in this book where we're really just going to have to kill time until the standards committee decrees sensible behavior, and compiler vendors implement it, as the solutions discussed here are, at best, partial. Hmm, maybe I'll send my favorite vendors some more e-mails.