Re: [boost] numeric_cast issue

From: Andreas Grosam (agrosam_at_[hidden])
Date: 2002-08-10 07:42:58

Hi Fernando,

Thank you very mutch for the immediate reply!

First I want to mention that I'm new to the boost mailing list - so I need first to figure out what "MPL" means ;) ... aha means "meta programming L... hmm library?? That wired things like "typelists", recursive templates, compiletime evaluations, etc....?

On Samstag, 10. August 2002, Fernando Cacciola <fcacciola_at_[hidden]> wrote:
>Hi Andreas,
>
>Some time ago I implemented a replacement for numeric_cast<> that correctly
>handles some known problems (though this one seems compiler
>specific).

The compiler was Metrowerks on MacOS (which is very close to the standard) - but, besides the mentioned issue - I realized that the current numeric_cast<> could also be optimized a lot for special cases...

Well, the current test suit for testing numeric_cast (file cast_test.cpp) isn't sufficient to detect this issue (Metrowerks compiler dosn't fail). So, can we be sure - looking at the boost "compiler status site" - that other compilers would behave "unambiguous and correct"? More concrete: what does other compilers/platforms output when running my simple test program?

Where "unmabiguous and correct" means what is an explicitly defined behavior according to the standard and what is NOT left implementation defined - and even not left "undefined". 
(It shall not be left implementation defined - otherwise the source needs conditional compilation flags and thus treating each concrete compiler differently. So, when assuming the current implementation of numeric_cast is based on a well defined unambiguous behavior of a compiler - then a compiler not evaluating the correct result would not behave according the standard.)

>
>I was about to submit it for formal review but I run out of time and it
>needed documentation.
>
>Then Bjorn Karlsson worked with me on the documentation, but along the way,
>as a result of our interchange, the replacement grown into a "numeric
>conversion library", featuring highly-optimized code, support for
>user-defined-types, customizable error handling and rounding mode control
>for float to integer conversions.

Sounds great!

Would this be possible:?
class MyDecimal {...}
MyDecimal x = numeric_cast<MyDecimal>(1.234);
(where MyDecimal has fixed precision and scale, should be rounded propperly and should throw an exception on oveflow or underflow.)

As I know, the current implementation wouldn't work with types which are not specialized for the traits class numeric_limits<>.

>
>The code is right now up and running (in real world applications), and the
>documentation in nearly complete.
>
>I was just waiting for MPL to be finally released since the implementation
>uses some basic meta-programming, which is currently supplied by my own
>overlapping meta programming tools, and which might not work well on other
>compilers.

Fortunately, I don't use VC++ ;)
 
>
>If you need this right now, I can give you the code, test and docs
>privately. If you have any problem with your compiler due to the
>meta-programming stuff I can help you out. The test checks signed to
>unsigned conversions specifically so you can verify if it works
>now.
>
>The library comes with a black-box replacement for numeric_cast; so you
>don't need to worry about its new features if you don't want
>to.

That's really great! (Getting the optimizations for free :))
I would appreciate it if I could test it. Then I also could report you my troubles - if any, helping you to make it portable (at least for Metrowerks).

Would it be possible to send it per mail? Or is it available somewhere on the boost site?

Thanks in advance.

Andreas Grosam

>
>Fernando Cacciola
>Sierra s.r.l.
>fcacciola_at_[hidden]
>www.gosierra.com
>
>
>
>