At Mon, 04 Oct 2010 00:39:41 +0100, Mathias Gaunard wrote:
On 28/09/2010 19:14, David Abrahams wrote:
Just for the record, I wrote the current implementation of Boost.ConceptCheck, so I do understand how it works.
My bad, please excuse my crude inaccurate explanation then.
No problem at all; just trying to save time.
The current system isn't dumb for C++03; it's the best you can do for many checks. There's no way to check for copy-constructibility, for example, without causing a compile-time error when the check fails.
SFINAE extended to expressions works in C++03 too, albeit it is not a mandatory feature and was implemented in most compilers only recently. (GCC didn't support it before mostly due to mangling issues)
That is not "works in C++03," that's "some C++03 compilers have an extension for it." I tried this with gcc 4.5.1 and it still couldn't detect copyability without causing an error: ----- template <unsigned> struct fu {}; template <class T> T make(); template <class T> char* copyable(T*, fu< sizeof(T(make<T>())) >* = 0); int copyable(...); struct X { private: X(X const&); }; char* test0 = copyable((int*)0); // works, proving int is copyable int test1 = copyable((X*)0); // I get an error here -----
which would allow to actually test whether the concept is being modeled or not without causing a hard error, which would be priceless in order to hugely improve the error messages.
I'm not convinced it would be a _huge_ improvement. You might be able to get rid of one level of instantiation stack, but AFAICT that's not a huge difference.
From my own experience using ConceptCheck, you still get a lot of unwanted errors.
The question is whether it's possible to do much better.
Unfortunately, without real concepts we may not be able to do better, because the pseudo-signature approach inserts type conversions that we'd have to write by hand. Now here's an interesting thought: write a library using TMP that generates "concept wrappers" that will force the necessary conversions. Would require heavy use of rvalue references to avoid needless copies. Hmm...
A crazy idea if you want to be TMP-heavy: maybe you could represent the valid expressions with Proto and infer an archetype from these.
This could provide better syntax than the "operator_increment" thing you suggested in some other part of the thread.
I'm not sure we can do much better with proto unless we have decltype.
Depends what you think the question is. IMO if we're going to talk about a library redesign for BCCL it should consider whether we can express concepts more effectively.
But is someone thinking and actively working on a nice universal solution?
Dunno.
Also, while time is spent thinking of that, the problem of bad error messages keeps on affecting more code.
Feel free to make incremental improvements, if you think you can.
Maybe that's all you're talking about, but it's never been all I'm talking about. Personally I'm not interested in a discussion that doesn't at least attempt to address the other half of the problem.
I didn't realize you shifted the original argument that much.
Since I started the original argument, don't I get to decide what counts as a shift?
Surely the couple of successive messages that gave no more explanations than "try it and you will see that approach is wrong" didn't help clarifying that up.
Sorry, been too busy to go into detail. -- Dave Abrahams BoostPro Computing http://www.boostpro.com