Hi again, pqs-1-00-03-boosted is available on the files section: http://groups.yahoo.com/group/boost/files/pqs/pqs-1-00-03-boost.ZIP This version is designed for inclusion in the boost library tree. and uses the namespace boost::pqs, where previous versions used physical-quantities. Tested on VC7.1 and gcc3.2. Currently I am working on complex physical-quantities which require a large number of operator overloads, and cant be achieved without violating the standard. 26.2.6.(See the q_complex.cpp and complex_example.cpp in examples for details of whats done so far in complex area.) Does pqs use mpl? Some but not much. I have had difficulties using mpl in this context. Which is basically to construct the return types of operators. I have found that this type of thing does the job in a scaleable manner: binary_operation<A,Op,B>. This computes a type and has a solitary result_type member which can be used with result_of. It also scales rather well and has come in very useful for complex physical-quanity definitions as well as my abstract_pq type. (see boost/pqs/class_template/abstract_identity/abstract_pq/abstract_pq.hpp in the distro for example of economies gained by this approach). Defining binary_operation<A,Op,B> for two types also automatically enables use of the binary_operator functors.(See boost/pqs/operators/binary_operators.hpp in the distro for details on this.) Major changes based on boost feedback 1) The namespace in this version has changed from physical_quantities to boost::pqs. 2) A tag mechanism has been added to distinguish (say) torque from energy. This works simply at the output level. See examples/torque_from_energy.cpp for more details. I still do not consider the library to be stable yet.(There may be a need for yet another tag in the units) I dont have any tests included, and the docs need a lot of work. At the moment it is still just for fun. regards Andy little
pqs-1-00-03-boost Bugs list 1) In "boost/pqs/operations/det_delog.hpp" One specialisation of struct boost::pqs::detail::delog fails to deduce correct pow function to call. fix: At line 145 in "boost/pqs/operations/det_delog.hpp" replace the original code: static result_type get() { static typename return_traits::body_constant_type val = std::pow(of_quantity::exponent_base, static_cast<value_type>(Nume) / static_cast<value_type>(Denom) ); return val; } with: static result_type get() { static typename return_traits::body_constant_type val = std::pow(static_cast<value_type>(of_quantity::exponent_base), static_cast<value_type>(Nume) / static_cast<value_type>(Denom) ); return val; } regards Andy Little
I believe some parts of pqs may be just what I need for some other purposes. I'm really interested in binary_operation. Code to infer return type of arithmetic operations is useful for other purposes, particularly since it appears to include std::complex. There seems to be absolutely no documentation, and I am no expert. I hope you will find some time to at least put some comments in the code. I would love to try it out, but at this point I'm pretty clueless.
I believe some parts of pqs may be just what I need for some other
"Neal D. Becker" <ndbecker2@verizon.net> wrote in message news:c3473o$sur$1@sea.gmane.org... purposes.
I'm really interested in binary_operation. Code to infer return type of arithmetic operations is useful for other purposes,
binary_operation part was originally a utility for physical_quantities but as you say I think it has potential to be useful in other ways. I think it ties in with the whole result_of, typeof decl_type, promotion... debate.OTOH I think there are similar moves afoot by others in the same area. binary_operation <A,Op,B> should by design have a single result_type member ,IOW it differs from the boost::mpl:plus etc in that there is no value member, It is a type computation only,(the fact that some specialisations in pqs have other members is due to my sloppy coding). This means that it can be used symmetrically for inbuilt and UDTs. And of course it is specifically designed to provide the result_type for operators. In use: binary_operation <A,std:plus,B>::result_type operator +(A,a, B b); Note the template template param looks fancy but is Just used as an operator token. Could as easy be an enum... however the binary_functions are available in std without adding other global bits and pieces so seem appropriate.. though some are missing. It is also directly compatibile with result_of, e.g as alternative to above: result_of<binary_operation<A,std::plus,B> >::type operator +(A,a, B b); The definition of binary_operation in "boost/pqs/meta/binary_operation.hpp" is designed for inbuilt types. Some meta-programming is used in there to decide the return type of the operation. So == returns bool etc. The information on operators is in "boost/pqs/operators/binary_operator_traits.hpp" which assigns an expression-family (multiplicative,assignment, logical_or etc) to each operator. The enums for expression family are defined in boost/pqs/operators/binary_operator_parameters.hpp". based on the names in C ++ grammar. In the pqs implementation the type of the return type for inbuilt types for +-,* etc is found using an arithmetic_promote<A,B>::type function, based on Alexei Gurtovois promotion_traits.hpp header (in files section). It may also be possible to use Joel de Guzmanns type-deduction.hpp header, but I havent experimented with this. During my own development errors have frequently resulted in an error message in the primary binary_operation definition which suggests I could make much better use of this... somehow. This is very much a first try. The implementation is very basic. Once binary_operation<a,Op,B> is specialised for a UDT pair (and the operator functions defined) the secondary benefit is that the functor binary_operator<A,Op,B>()(a, b) is also defined, as well as the functor operator_plus<A,B>()(a,b), (etc) which is a user level derived version.(definitions in "boost/pqs/operators/binary_operators.hpp"). As yet I havent made much use of these but because Op can be a template param , may be useful.
particularly since it appears to include std::complex.
Yes..std::complex for udts is ....err..hmm Fun :-). for physical_quantities it is even more fun. I have done a quick blast through some of the operators. At this stage I should think my implementation is a long way from optimal, ie there may be a more concise way to achieve it. As I hope you can appreciate from the above, I am still very much in middle of coding complex so still figuring out best way to do it. when I'm done I will see how/if it can be generally applied
There seems to be absolutely no documentation, and I am no expert. I hope you will find some time to at least put some comments in the code.
Thanks for the feedback and Apologies..I take the point and will try to add some more useful comments in the code. regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote
I believe some parts of pqs may be just what I need for some other
"Neal D. Becker" <ndbecker2@verizon.net> wrote purposes.
[snip]
particularly since it appears to include std::complex.
reviewing my work for binary_operation with regard to complex. I think that the following covers it as far as the definition goes. Not tested thoroughly but appears to cover all including inbuilts etc... (Yes that means I can remove a lot of unnecessary specialisations from pqs/complex.. :-) ). Should also bring in functors as described previously regards Andy Little ---------------------------------- #ifndef GENERIC_COMPLEX_BINARY_OPERATION_HPP_INCLUDED #define GENERIC_COMPLEX_BINARY_OPERATION_HPP_INCLUDED #include "boost/pqs/meta/binary_operation.hpp" #include <complex> /* specialisation of binary_operation<std::complex<T>,Op,std::complex<T> > */ namespace boost{namespace pqs{ namespace meta{ template< typename Value_typeL, template <typename> class Op, typename Value_typeR > struct binary_operation< typename std::complex< Value_typeL >, Op, typename std::complex< Value_typeR > >{ typedef typename std::complex< typename binary_operation< Value_typeL, Op, Value_typeR >::result_type > result_type; }; }}}//boost::pqs::meta #endif
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote
I believe some parts of pqs may be just what I need for some other
"Neal D. Becker" <ndbecker2@verizon.net> wrote purposes.
[snip]
particularly since it appears to include std::complex.
reviewing my work for binary_operation with regard to complex. I think
the following covers it as far as the definition goes. Not tested
that thoroughly Oops nearly... I think following does the job( required complex,Op,value_type and value_type,Op,complex too)
regards Andy Little
----------------------------------
#ifndef GENERIC_COMPLEX_BINARY_OPERATION_HPP_INCLUDED #define GENERIC_COMPLEX_BINARY_OPERATION_HPP_INCLUDED #include "boost/pqs/meta/binary_operation.hpp" #include <complex> namespace boost{namespace pqs{ namespace meta{ template< typename Value_typeL, template <typename> class Op, typename Value_typeR > struct binary_operation< typename std::complex< Value_typeL >, Op, typename std::complex< Value_typeR > >{ typedef typename std::complex< typename binary_operation< Value_typeL, Op, Value_typeR >::result_type > result_type; }; template< typename Value_typeL, template <typename> class Op, typename Value_typeR > struct binary_operation< typename std::complex< Value_typeL >, Op, Value_typeR >{ typedef typename std::complex< typename binary_operation< Value_typeL, Op, Value_typeR >::result_type > result_type; }; template< typename Value_typeL, template <typename> class Op, typename Value_typeR > struct binary_operation< Value_typeL, Op, typename std::complex< Value_typeR > >{ typedef typename std::complex< typename binary_operation< Value_typeL, Op, Value_typeR >::result_type > result_type; }; }}}//boost::pqs::meta #endif
"Neal D. Becker" <ndbecker2@verizon.net> writes:
I believe some parts of pqs may be just what I need for some other purposes. I'm really interested in binary_operation. Code to infer return type of arithmetic operations is useful for other purposes, particularly since it appears to include std::complex.
As I've pointed out in the past, Joel de Guzman has posted what I believe to be the definitive implementation of this return type deduction facility. Lost my connection at the moment, but it should be findable through the usual boost archives. Look for a thread titled "limited form of type deduction" and http://tinyurl.com/ofqf. In the sandbox, see boost/utility/type_deduction.hpp. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
The following message is a courtesy copy of an article that has been posted to gmane.comp.lib.boost.devel as well.
"Neal D. Becker" <ndbecker2@verizon.net> writes:
I believe some parts of pqs may be just what I need for some other purposes. I'm really interested in binary_operation. Code to infer return type of arithmetic operations is useful for other purposes, particularly since it appears to include std::complex.
As I've pointed out in the past, Joel de Guzman has posted what I believe to be the definitive implementation of this return type deduction facility. Lost my connection at the moment, but it should be findable through the usual boost archives. Look for a thread titled "limited form of type deduction" and http://tinyurl.com/ofqf. In the sandbox, see boost/utility/type_deduction.hpp.
http://tinyurl.com/ofqf is a dead link. Here are some fresh links: http://tinyurl.com/yrotd http://tinyurl.com/2v7g6 Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
"Neal D. Becker" <ndbecker2@verizon.net> writes:
I believe some parts of pqs may be just what I need for some other
"David Abrahams" <dave@boost-consulting.com> wrote purposes.
I'm really interested in binary_operation. Code to infer return type of arithmetic operations is useful for other purposes, particularly since it appears to include std::complex.
As I've pointed out in the past, Joel de Guzman has posted what I believe to be the definitive implementation of this return type deduction facility.
Rather than being used to *infer* the type of the result of an operation binary_operation is actually used to construct the type of the result . In the pqs case all the result types fall into the "black hole" category in type-deduction.hpp. One use of binary_operation is to construct the return type of operator#(a,b). ie we cant do this in UDT: typeofwidget( Ta ()+ Tb () ) operator + (Ta a, Tb b); else we get the egg and chicken situation: The result type must be previously available by another mechanism I think for UDT The major work in pqs is the operator definitions. In pqs each physical quantity is composed of three parts. value_type (ie int double etc), abstract phsyical quantity (ie length time etc) and units(eg. mm, J etc). binary_operation for a physical quantity is constructed from binary_operations on these parts in a modular fashion. I have found the paramaterisation of the operation istelf useful in reducing the number of specialisations required. As I understood it result_of was once upon a time to be the official result_type candidate(N1454), which by default looks for a result_type member in its argument. With that in mind binary_operation<A,Op,B> has( should have) a single result_type member, hence: result_of<binary_operation<A,Op,B> >::type works out of the box. of course ideally one would do: result_of<A,Op,B>::type ... but that is another story However if type-deduction.hpp is now to become the official method then there is no problem (but much more work) to make it compatible: template<...> struct result_of_plus<MyTypeFirst<...>,MyTypeSecond<...> >{ typedef typename binary_operation< MyTypeFirst<..>, std::plus, // used as a token MyTypeSecond<..> >::result_type type; }; IOW type-deduction.hpp (and result_of) is a higher level construct than binary_operation. They dont do the same thing. regards Andy Little
participants (4)
-
Andy Little -
David Abrahams -
Joel de Guzman -
Neal D. Becker