| -----Original Message----- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Ed Brey | Sent: Tuesday, June 10, 2003 2:30 PM | To: [EMAIL PROTECTED] | 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 Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
