"Daniel Frey" <d.frey@gmx.de> wrote
GCC 3.3.5 says:
[etc]
To sum it up: *Some* examples do work, but T(c) is not a *generic* syntax that works. Thus I went for .get<T>()
Ok. ... but its ugly to write that. Maybe aesthetics shoulnt count but unfortunately they do. And in different contexts you need different invocations.
However IMO it shouldnt be convertible to anything. There needs to be some concept that it models. FWIW I would be content with , float, double long double. IOW numeric types. But ... eg FWIW my version still fails in boost::numeric::interval. This is always going to be the problem when trying to make one type maquerade as another :-(
FWIW, the constants I wrote only look as if they convert to anything. But in the end, you must have an implementation that yields the value. If there is no constant (or explicit mapper) for a type called "fluffy", the compiler complains. Static type checking should be preserved - and is. I tried to avoid magic that leads to surprises, as this immediatly leads to bugs in the real world.
Its tricky to assess this as it wont compile in VC7.1
A 'math constant' is expected to be pretty unexciting, which this doesnt deliver. Maybe if it was repackaged as say a quirky 'smart constant', rather than The std::math_constant it would be more gratefully received.
The constant itself is still simple: two. It should come from some header as well as all other constants you usually need. A normal user should not be concerned with defining constants. The best example is probably still:
template< typename Y > inline typename SI< Y >::quantity idealGasLaw( const typename SI< Y >::pressure& p, const typename SI< Y >::volume& v, const typename SI< Y >::temperature& t ) { using boost::units::si::constants::chemistry::R; return p * v / ( R * t ); }
The constant comes from a header, the user is not bothered with anything else at this point.
Sure the same thing can be done with 'units. Question is though Does the user think its weird? What happens when the user wants to say std::cout << R ; ? std::cout << R.get<double>(); // is not exactly elegant. If I have to go throught this.. why not make the useage consistent and just make the thing a function?
Whatever float-point-type (native or UDT) he uses for Y, the algorithm as well as the constant library itself will be unaffected. You can define algorithm libraries containing the above, unit libraries, constant libraries (that is libraries that yield the constants for a certain use-case, not the library that helps to define these constants (my lib)) and float-point-types independently. A user might need to add some glue to use certain combinations in his projects, although most things for float/double will work out-of-the-box. The most important point is, that the user should never be forced to reinvent the wheel, only assemble some stuff! This is what I consider reuseability.
Unfortunately I cant get this to compile in VC7.1 .
sure .. .... but of course it isnt doable in the language. (BTW the pi * pi stuff is cool !. Sorry... it appears I have been dismissive of that.)
int val = my::pow(9,3,2); eg replaces std::pow( static_cast<double>(9)
With my library, you can make pow(nine,three,two) a constant. Today. Given the ideas I have about constant_<9> nine; etc., this might even work for all integer numbers in the future, although I can't promise anything. If it works, you could also spell it sqrt(pow(nine,two)) or sqrt(nine*nine) - all leading to real constants :)
Yes ... but my_type / two is not as nice as my_type / 2, which is my point. regards Andy Little