From: Paul A Bristow (pbristow_at_[hidden])
Date: 2008-02-17 13:35:43
>[mailto:boost-bounces_at_[hidden]] On Behalf Of Bruno Lalande
>Sent: 17 February 2008 17:04
>Subject: Re: [boost] [Boost] Compile-time power of a run-time base
>Here is a new version of the pow.hpp file with updated tests
>and docs. It
>nows handles errors using the Boost.Math overflow error
>policy, and uses
>promote_args to determine the return type.
>I've tested it on the same platforms as before, BUT it no
>with gcc-2.95.4. The first reason was that policy.hpp includes
>gcc 2.95 doesn't have so I replaced it by <boost/limits.hpp>
>and it worked,
>but some other Boost files include other headers that are also
>for instance, included in lcast_precision.hpp). Is the support for that
Not by me ;-) I would not spend time on this outdated compiler. Surely people who really want to use a compile tile pow will be
using more modern compilers?
Docs might provide a reference or few. I found
by a very quick Google
I'm sure we should give Knuth his due for having done everything before we even thought of it ;-)
D.E. Knuth, The Art of Computer Programming, Vol. 2: seminumerical Algorithms, 2nd ed. Addison-Wesley, Reading, MA, 1981.
I think occurrence has two cs and two r as well ;-)
Would the words 'compile-time integer integral power' ensure that this doucmentation pops up when Googling?
(Would the expression 'known at compile time' be clearer than 'known in advance'?)
Should there be a less formal description of the user interface - perhaps simplified from the two actual templates in pow.hpp? It
looks more complicated than it really is in pow.hpp.
Would what I might call a 'demo' program show its use more simply for novices than the formal test ? It could show use of policies
- something that may frighten some users - it did me at first ;-) It could show how especially useful is using try/catch is with
--- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk