Generalized concept usage in Boost libraries
With Concepts removed from C++Ox, people have been disappointed that this chance of making C++ template code generate better error messages was given up. Yet, there is no need for C++0x concepts in order to achieve this. Indeed, we have Boost.ConceptCheck that already makes things a bit simpler. Plus, by extending it with SFINAE for expressions, which allows to detect whether a type models a concept at compile-time, we get almost the same quality in error messages as with C++0x concepts. It would even allow to do concept-based overloading, but since SFINAE for expressions is not an universally supported feature, code shouldn't rely on that. Should all Boost libraries be modified in order to include concept checking, and should it become part of the programming policy? From what I can see, it seems most libraries don't make use of Boost.ConceptCheck at all.
Mathias Gaunard wrote:
Should all Boost libraries be modified in order to include concept checking, and should it become part of the programming policy? From what I can see, it seems most libraries don't make use of Boost.ConceptCheck at all. I'm all for it. Maybe the problem is that people don't know about BCC. Moreover, libraries from before BCC couldn't have used it ;)
-- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
on Sun Jul 26 2009, joel <joel.falcou-AT-lri.fr> wrote:
Mathias Gaunard wrote:
Should all Boost libraries be modified in order to include concept checking, and should it become part of the programming policy? From what I can see, it seems most libraries don't make use of Boost.ConceptCheck at all.
It is way underutilized. BCCL finds bugs in library code as well as user code. Very powerful.
I'm all for it. Maybe the problem is that people don't know about BCC.
There is the potential to increase compile times. But if we made it possible to switch it on and off, that would mitigate.
Moreover, libraries from before BCC couldn't have used it ;)
It's been around a _long_ time. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
There is the potential to increase compile times. But if we made it possible to switch it on and off, that would mitigate.
What about only enabling concept-checking when a kind of compile-time debug mode is enabled? Would there be a nice way to integrate that with Boost.Build? (since it makes more sense to me to enable if from the bjam invocation directly instead of a Jamfile)
on Mon Jul 27 2009, Mathias Gaunard <mathias.gaunard-AT-ens-lyon.org> wrote:
David Abrahams wrote:
There is the potential to increase compile times. But if we made it possible to switch it on and off, that would mitigate.
What about only enabling concept-checking when a kind of compile-time debug mode is enabled?
That's what I meant. I'm not sure which one I'd want to make the default in this case, on or off.
Would there be a nice way to integrate that with Boost.Build? (since it makes more sense to me to enable if from the bjam invocation directly instead of a Jamfile)
Sure, it'd be easy. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
My personal opinion is that concept-checking should be enabled simply by defining something such as BOOST_ENABLE_CONCEPT_CHECKS before including any boost header; though incorporating optional concept checking needn't be necessary for acceptance..
Mathias Gaunard wrote:
Should all Boost libraries be modified in order to include concept checking, and should it become part of the programming policy? From what I can see, it seems most libraries don't make use of Boost.ConceptCheck at all.
I'll shot a few questions right away. How does it affect compilation times and source code size? How widely is it supported among legacy compilers? Does it introduce any side dependencies? Are there any estimates on how it affects library developing time (based on the amount of code written, for example)? I'm asking because your proposal sounds like an overhaul of Boost libraries and a possible obstacle for getting new libraries into Boost. I, as an upcoming Boost.Log library author, am concerned whether I have to spend extra time and effort to embed Boost.ConceptCheck into my library to get it accepted.
Andrey Semashev wrote:
I'll shot a few questions right away. How does it affect compilation times and source code size? How widely is it supported among legacy compilers? Does it introduce any side dependencies?
According to the documentation, there is no runtime overhead. As for portability, I don't know, but a quick look suggests it supports all compilers. Still, if concept checking was disabled by default, portability or dependency on that library wouldn't be an issue.
Are there any estimates on how it affects library developing time (based on the amount of code written, for example)?
Writing the concepts correctly may be the most difficult (re-using pre-made ones helps); integrating them with code is just a matter of putting a big (arguably ugly) macro instead of the return type.
I'm asking because your proposal sounds like an overhaul of Boost libraries and a possible obstacle for getting new libraries into Boost. I, as an upcoming Boost.Log library author, am concerned whether I have to spend extra time and effort to embed Boost.ConceptCheck into my library to get it accepted.
Even if it eventually gets adopted as a guideline, I'm fairly sure you could still get libraries accepted into Boost if you provide a rationale as to why your library doesn't support it.
participants (5)
-
Andrey Semashev -
Celtic Minstrel -
David Abrahams -
joel -
Mathias Gaunard