David Abrahams wrote:
Daniel Frey <d.frey@gmx.de> writes:
Thorsten Ottosen wrote:
"Paul A Bristow" <boost@hetp.u-net.com> wrote in message news:001501c40795$ce631ce0$0c010101@hetp3...
From a very quick study of this, this radical proposal avoids nasty brackets "pi()" by adding a new C++ keyword implicit to make "pi" have the same effect.
Considering what Daniel can do, I don't think the math constant part of the proposal brings anything.
Basically, I agree. When I sorted out the VC-issues and finished the documentation, I'll have a deeper look at the ICF-proposal and post some comments to csc++. FWIW, my gut feeling is that the proposal it not worth the trouble.
However: I can do many, but not all things proposed. There is one thing (syntax) that I cannot do but that I like very much:
pi<T>
In my constant library, this is spelled 'pi.get<T>()'. Alternatives that don't work: 'static_cast<T>(pi)', 'T(pi)', 'pi.operator T()'. If anyone has a cool idea how this can be improved, let me know :)
get<T>(pi)
Good idea, I'll think about this one.
Why doesn't
T(pi)
Because T can have multiple ctors (taking i.e. float, double, long double and thus making the conversion ambiguous - I can't control that from inside pi, the T is not exactly forwarded to pi's type when asked for a conversion). The second reason is that it limits the result to T. When I have a unit library, this is not acceptable, as get<T> provides some magic: get<double>(G) returns a combination of a double value plus the appropriate unit, not a plain double. This is the basic problem of all the alternatives I mentioned: I don't have the freedom to modify the returned type, but this is an essential feature I need. Regards, Daniel -- Daniel Frey aixigo AG - financial solutions & technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de