Julian Gonggrijp wrote:
Robert Ramey wrote:
[Noticing that the Boost Concept Check library (BCCL) is not used as much as one might expect from the documentation, however starting to appreciate the value of concepts, and wondering whether there is really a discrepancy between the value of concepts and the extent of the adoption of the BCCL.]
If this isn't a good abstract of your email, please say so.
good enough.
Assuming it's good enough: I wondered about this too. I'll share my personal conclusions with you and hope it helps. For a start, I think the most important purpose of concepts is documentation. You define your concept once, at least in natural language and optionally also through the BCCL formalisms, and after that you can use just a single word again and again to refer to an entire set of operations that should be supported, as well as their semantics. If you adopt this view, it's not so strange for a library to use concepts in the documentation (verbally) but not in the code (as compile-time checks).
I would like to be able to trivially verify that the code and the documention are exactly in sync. It seems to be that BCCL should be able to do this. That is the macros are pretty easy to read and can be easily verified to match the documentation. This is one of the major attractions of using concepts to me.
A secondary value of concepts is that they can make compiler errors more readable. Because the BCCL was developed (almost?) entirely for this purpose, from its documentation it may seem a bit like improving compiler errors is the primary purpose of concepts in general.
To me this is also important
I think the use of the BCCL (contrary to the use of concepts for documentation) can also have disadvantages, i.e. in terms of maintainability and readability of the code.
Hmmm, to me, they don't make the code less readable. In fact, it's the opposite to me. It's like putting in a comment that the compiler understands.
Note, that most (if not all) Boost libraries that don't use the BCCL still use concepts in the names of template arguments or in comments as a form of within-code documentation. For example, I'm quite sure I've seen this in the Boost.Random and the Boost.MinMax header files.
This is the crux of my question. If they work as advertised, I see no downside to using them - especially if you're going to structure your documentation to use them. I'm asking other library authors why they haven't used them. FYI, I know why I didn't use them - it's easy: I didn't understand the concept when I wrote the serialization library. Robert Ramey