On 1/27/04 7:39 PM, "Howard Hinnant" <hinnant@twcny.rr.com> wrote:
On Jan 27, 2004, at 11:06 AM, Peter Dimov wrote:
Need to be? No. But I still like it. <shrug> I was convinced because that's how a newbie expected it to work.
I'm starting to not like it. :-) The problem is:
template<class X> void f(S_ptr<X> px);
where f doesn't support arrays. A reasonably common occurence. S_array<> doesn't match, but S_ptr<T[]> does. The author of f would need to learn about enable_if to prevent array pointers from being passed to f. This is not good, although the exact degree of not-goodness is somewhat debatable.
I understand your hesitation. But I'm not yet seeing a concrete case to support it.
There are two situations to analyze here:
1. Client writes:
template<class X> void f(S_ptr<X> px);
and intends to catch only pointers to single objects, and does not want to deal with pointers to arrays.
2. Client writes:
template<class X> void f(S_ptr<X> px);
and intends to catch pointers to both single objects and array objects.
In case 1, learning about enable_if is not necessarily a bad thing. Indeed, a significant portion of the standard headers would be much better behaved today if we (as a community) had better understood the value of restricted templates, how to implement them, and the dangers of templates with unrestricted syntax, but restricted semantics. For example: [TRUNCATE]
If the solution to the "S_ptr<X[]>" idiom is to study up some more on other C++ idioms, then I think that we have a Big Red Flag that something is wrong with the new idiom. There are two things I read about in GUI programming: 1. Don't make a big deal of differentiating things that are similar. 2. Don't hide differences that matter. The C++ committee screwed up [2] with std::vector<bool>. I don't want another screw-up introduced, especially if it's more insidious and deliberate. (i.e. We should let this idiom die.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com