Ábel Sinkovics wrote:
Hi,
The problem is that errors point to code that is deep within the library's implementation, or worse, the implementations of helper libraries used by the library. To understand the error, the user has to look at the library's implementation. The user shouldn't have to do that - understanding the implementation of a library should not be a prerequisite for using it.
...
So far we've only been using it for improving error messages coming from template metafunctions. Cases where they can't be easily and clearly separated from runtime code haven't been addressed yet.
This solution is part of a library implementing monads in C++ template metaprogramming. Documentation: http://abel.web.elte.hu/mpllibs/metamonad/index.html Source code: https://github.com/sabel83/mpllibs/tree/master/libs/metamonad Note that there are only a few examples so far.
I've been poking around haskel/C++/monads just out of curiousity for some time. Can't say I've really made much progress understanding it all. But I did find your links very intriguing. In my own work, I've come to rely on Boost.ConceptChecks (BCC) to short circuit the error list. Also, after one becomes familiar with it it is very easy to use. It's basically a free compile time assertion to check metafunction arguments. Robert Ramey
Regards, Abel
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost