At Mon, 27 Sep 2010 23:27:36 +0100, John Bytheway wrote:
On 27/09/10 17:56, David Abrahams wrote:
P.S. I'm not claiming concepts can't be described via valid expressions; I'm claiming it's the wrong approach, for reasons that should become evident to anyone who *actually does the exercise*.
I did do the exercise, so SPOILERS ahead for those who have not.
I'm still not sure what your point is. I conjecture that the issue to which you were trying to draw attention was something to do with operator! and bool conversions.
In particular I note that the libstdc++ implementation of find_if uses !bool(__pred(*__first)) rather than simply !__pred(*__first), which suggests this distinction is (at least potentially) important in practice.
Good! You're in exactly the right neighborhood. And depending on the valid expressions you came up with for constraints, there may be more problems of exactly that nature in that algorithm. I can't see your work, so I don't know.
Presumably the concept modelled by the predicate merely asserts that its return type is convertible to bool (certainly that's all I had in mind), and in principle !__pred(*__first) is undefined behaviour with respect to the concept.
"Undefined behavior" isn't quite the right word; the concept constraint would prevent the template body from compiling.
Is your point that an archetype based on valid expressions would fail to detect the flaw in the naive implementation of find_if, but that an archetype based on member definitions would catch it?
[Those things you're calling member definitions are actually called pseudo-signatures. They don't (only) define members.] Well, no. The flaw isn't in the implementation of find_if; it's in the actual concept requirements imposed by the "valid expression" form of the concept definition. Any concept mechanism that doesn't allow you to write a straightforward find_if is broken. My point is that using valid expressions makes it hard, if not impossible, to write a clean implementation of even the most elementary algorithms. (IIRC they also make it really easy to fail to satisfy those requirements in baffling ways, but I can't come up with an example offhand). They also tend to gloss over associated types that you eventually want. I wish I could call forth all the clear insights about this that I had when we were fighting the concepts battles. I'll let you know if anything comes back to me. -- Dave Abrahams BoostPro Computing http://www.boostpro.com