On 7/31/2014 6:28 PM, Niall Douglas wrote:
On 31 Jul 2014 at 10:11, Eric Niebler wrote:
On 07/29/2014 05:14 PM, Niall Douglas wrote:
I'm all for Concepts as in compiler enforced ones, and I'll add them to AFIO when and only when C++ gets them. But for documentation they don't help.
Wow, I couldn't disagree more. I can't imagine how the standard algorithms would be specified without the use of concepts like "RandomAccessIterator", for instance. Clustering requirements into meaningful abstractions and assigning them names makes it possible to document library interfaces without an explosion of verbosity and repetition.
Oh I know programmers similar to how you visualise code in your head would agree with you absolutely. But you must remember programmers like me don't see C++ as really in fact having types nor classes nor concepts - I just see methods of programming the compiler to output patterns of assembler code, and I think primarily in terms of chains of assembler instructions. My type of programmer learns just enough of the verbiage to understand C++ Now presentations by programmers such as you (and I haven't failed to learn something new from yours yet), but we'll never think like you any more than you'll think like us.
None of this a bad thing of course, diversity of approach and all. But to me and people like me a RandomAccessIterator is a pointer and is little different to a ForwardIterator. I care about the difference only in so far as I can use it to get the compiler to generate code one way or another according to need. I furthermore care about the difference only in so far as it will get later maintainers and team members to behave one way instead of another. Past that I feel no issue reinterpret casting STL internal types to bypass the type system if that gets me the assembler output I want and doesn't create maintenance debt later.
It's the essential difference between language-focused coders and err ... mongrel coders? I have to admit I'm not sure what to call myself really. Either way, I see ConceptCheck as a half baked feature giving me nothing useful but bloat and complexity and significantly adding mess to documentation and steepening my learning curve. I absolutely can't wait for language support for Concepts, and will use them with vengence when they turn up as they're another great tool for bending the compiler in new ways, but until it's fully baked as a language feature they get in my way. And hence I don't use them personally, and groan every time I'm faced with code by someone who has (no offence intended here, we all have our own personal likes and dislikes, and I entirely understand your opinions on this and respect them, I just don't have those opinions myself).
With all due respect to your super-practical low-level approach I think you must know that you are very much in the minority. Practical programming, as you reflect on above, certainly has its advantages but without knowing what one can do with a programming language I see it as impossible to design robust code that is both understandable and usable to others and effective in accomplishing its goal. I do not think 'concepts', aka largely 'type constraints' as Robert as aptly renamed it in this discussion, is a panacea for every template programming problem. But understanding the 'domain' of what a 'type' entails is just as important as understanding the 'domain' of some parameter in a function call. Without documentation of such things the user of your constructs has no idea what will work and what will not work and programming then becomes and endlessly wasteful game of trial and error. Nor is that really 'language-focused' programming. Its just programming that takes into account that others must usually be able to use what you create else it is worthwhile only to yourself and your own solution to a problem.