Boost logo

Boost :

Subject: Re: [boost] [metagraph]
From: Abel Sinkovics (abel_at_[hidden])
Date: 2012-02-02 16:09:03


Hi Nick/Gordon,

> Compile-time exception propagation is certainly an interesting
> concept, especially considering how poorly compilers do reporting
> errors for metaprogramming. I actually stumbled across the metatest
> suite from the same group of libraries not long ago, and it's good
> stuff. However, I think if we did incorporate it, we'd need a way to
> make it optional, since there will likely always be people who don't
> want to pay the extra cost for using exceptions. To enable errors, I
> don't see how we could get around requiring the do / let notation for
> propagating monads, but perhaps a little preprocessor magic could
> disable them? I'll have to think on that.

The do and let notations are general tools for monads - if you need
exception propagation only, there is another utility for that in
metamonad: the try_ template
(http://abel.web.elte.hu/mpllibs/metamonad/try_.html). Instead of writing

template <class T1, ..., class Tn>
struct my_metafunction : body {};

you write

template <class T1, ..., class Tn>
struct my_metafunction : try_<body> {};

and it instruments body to propagate errors. As an example demonstrating
its usage you can take a look at
https://github.com/sabel83/mpllibs/blob/master/libs/metamonad/example/min/min.hpp.

To support the use case when people don't want to pay for exception
propagation, I can extend metamonad the following way: when a macro (eg.
DISABLE_TMP_EXCEPTIONS) is defined, try_ becomes the identity
metafunction. In that case it will have a minimal cost (1 extra
instantiation). What do you think?

Regards,
   Abel


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk