Boost logo

Boost :

From: Paul A. Bristow (boost_at_[hidden])
Date: 2003-06-10 16:32:11

| -----Original Message-----
| From: boost-bounces_at_[hidden]
| [mailto:boost-bounces_at_[hidden]]On Behalf Of Ed Brey
| Sent: Tuesday, June 10, 2003 2:30 PM
| To: boost_at_[hidden]
| Subject: [boost] Re: Re: RE: Math Constants Formal Review - recap &
| summary
| Paul A. Bristow wrote:
| >>
| >> For example, VC 7.1 discards d1 if it is not referenced, so there is
| >> no issue with paying for what you don't use when using that method on
| >> that compiler.
| >
| > This is good news. What optimisation did you chose?
| /O2
| >> It would be useful to know what compilers do retain
| >> unused constants.
| >
| > But is tiresome to find out, and will keep changing. (and if the
| > scheme becomes widely used, compiler writers will have a strong
| > incentive to make sure it is optimized away.
| Agreed, an active search would be a lot of effort. I passive
| approach may be practical however. My thinking is to start from a
| position that all compilers optimize well. Then when someone says,
| "Sorry, that interface triggers this pessimization on compiler x,"
| just make a note of x and its limitation. This way to don't need to
| look for compiler limitations; news of such will come to you.
| There probably aren't a ton of limitations; so the list may well be
| short, and it can be a big timer saver to know exactly which
| compilers to care about when they get reved, especially if a removal
| of a key limitation eliminates the need for a complex workaround.

Sounds sensible. (I fear the answer to pessimization may be "tough!")


Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK
+44 1539 561830 Mobile +44 7714 33 02 04
Mobile mailto:pabristow_at_[hidden]

Boost list run by bdawes at, gregod at, cpdaniel at, john at