>From: "Edward Diener" <[EMAIL PROTECTED]> > "David Abrahams" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Terje Slettebų <[EMAIL PROTECTED]> writes: > > > However, I also understand the concern regarding understanding the > policies > > available, their responsibilities and interaction. Therefore, convenience > > templates like the above could make it easier to use them, while still > > allowing new convenience templates/template typedefs to be made, or new > > policy implementations added. > > > > Having such convenience templates is a bit like having a small > configuration > > DSL on top of the policy-based smart pointer, to use the terminology in > C&E. > > -Sure, and I expected we'd do that. Not to beat this horse to death, > -but I think even that doesn't insulate users from the parameters > -completely. They'll see it in the documentation, and wonder what's > -going on under the covers with all that complexity, and it will be a > -distraction. > > I don't think that is the distraction.
I don't think it would be a problem as a distraction, either, any more than the fact that std::string is a typedef for std::basic_string<char, CharTraits = char_traits<char>, Allocator = allocator<char> > prevents people from using std::string/std::wstring as they are, without knowing or caring about the extra default template parameters. Kevlin Henney has even suggested _not_ hiding the parameterisation with a typedef, and instead use a string template directly, such as string<char> and string<const char> (for immutable strings, may be safely reference counted), or string<wchar_t>, now that we are more used to templates. That specifies clearly the character type used, just like we specify the element type in the standard containers (http://www.cuj.com/experts/1905/henney.htm). As an aside, it might even be possible to extend the language, so that class template parameters may be deduced from an initialiser. In that case, std::string str="Test"; (or std::string<> str="Test";) might create a std::string<const char> (after implicit conversion from const char *), and std::string wstr=L"Test" might create a std::string<const wchar_t>. In other words, leaving the deduction to the compiler, as with function templates. If no initialiser is given, you have to specify the parameter explicitly (or it might default). Granted, std::basic_string may not be such a great example of PBD, as the "policies" are hardly changed. For example Matt Austern has pointed out that in order to do case-insensitive string comparison, it may be better to create a comparison functor, which may be passed to algorithms, rather than changing the character traits. And allocators... well, as Scott Meyers says it in "Effective STL", "Allocators are weird.", :) and the implementation would be free to ignore parts of them. > I wonder if there have been any murmurs in the C++ standard committee about > the system for setting default parameters somehow being changed to solve > this problem, so that a user can override a default without having to > override all preceding ones. I know I have heard suggestions about named > default parameters but that doesn't seem to solve the problem in my mind. > Something clearer and cleaner is needed but I don't know what it is. You may not need named parameters, as most of the time, "canned" versions might be fine. And if you'd like named parameters, you might use something like the named template parameters in the Sandbox. If you want something different from the defaults, you have to specify it, somehow. Regards, Terje _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
