Re: [boost] Interest in dimension/unit-checking library?
Geoffrey Romer wrote:
Would there be any interest in a library for attaching units (physical or otherwise) to numeric variables, so that the type system could enforce dimension- and unit-consistency in all calculations, and convert semi-automatically between compatible units?
I'm fairly new to boost, so forgive my late entry into this discussion. I too recognized the need for this kind of library back in the late 90s and wrote this library available on SourceForge: http://tuoml.sourceforge.net/ It's pretty stable and used on several projects (there's a military simulation tool that has standardized on it). I've recently discovered the meta-programming method for dimensional quantities by Scott Meyers: http://se.inf.ethz.ch/~meyer/publications/OTHERS/scott_meyers/dimensions.pdf This inspired me to revisit my library and it is turning out to be a fairly easy conversion. The old library had to explicitly represent each unit combination of interest (e.g., Speed = Length/Time), which is ugly and doesn't allow arbitrary combinations. The new method fixes all this (in fact, it simplifies things to the point where there is no library object file any more -- just headers). A key concept I tried to enforce is that any time the programmer sets or gets a numeric value, the specific units (i.e., Feet, Meters, etc.) must be specified. I don't want any units to be implicit. My library provides ostream formatting for handy printing. I also provide scalar, 2D, and 3D types. For the 2D/3D types, I provide various transformation operators like rotation. For 3D rotations, I provide the option of cosine matrix or unit quaternion. It's been suggested to me that I submit my library to boost. Being new to boost, I'm not sure how complete and tested the code needs to be. Any feedback or suggestions are welcome. Keith.
On Sun, 13 Nov 2005 21:36:38 -0800, Keith Nicewarner wrote
Geoffrey Romer wrote:
Would there be any interest in a library for attaching units (physical or otherwise) to numeric variables, so that the type system could enforce dimension- and unit-consistency in all calculations, and convert semi-automatically between compatible units?
I'm fairly new to boost, so forgive my late entry into this discussion. I too recognized the need for this kind of library back in the late 90s and wrote this library available on SourceForge:
It's pretty stable and used on several projects (there's a military simulation tool that has standardized on it). I've recently discovered the meta-programming method for dimensional quantities by Scott Meyers:
http://se.inf.ethz.ch/~meyer/publications/OTHERS/scott_meyers/dimensions.pdf
This inspired me to revisit my library and it is turning out to be a fairly easy conversion. The old library had to explicitly represent each unit combination of interest (e.g., Speed = Length/Time), which is ugly and doesn't allow arbitrary combinations. The new method fixes all this (in fact, it simplifies things to the point where there is no library object file any more -- just headers).
A key concept I tried to enforce is that any time the programmer sets or gets a numeric value, the specific units (i.e., Feet, Meters, etc.) must be specified. I don't want any units to be implicit. My library provides ostream formatting for handy printing. I also provide scalar, 2D, and 3D types. For the 2D/3D types, I provide various transformation operators like rotation. For 3D rotations, I provide the option of cosine matrix or unit quaternion.
It's been suggested to me that I submit my library to boost. Being new to boost, I'm not sure how complete and tested the code needs to be. Any feedback or suggestions are welcome.
For the submission to be reviewed and accepted, the code will need to be complete and coherent with good documentation. It doesn't have to have every feature that can be imagined, but a useful core. Of course you can post early working versions to the file vault for people to try out and provide feedback. If you haven't already, take a read thru: http://www.boost.org/more/submission_process.htm In the particular case of units, I'll just warn you that there is a trail of broken dreams. There is clearly interest in such a library, but several authors have started and then abandoned. You'll want to have a look thru the mailing lists at some of the discussions we've had over the last 5 years or so. I think Andy Little has come the closest to an actual submission. You can find his library at: http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/index.html Oh, and on the quaternion front, don't forget there's already boost.quaternion - so maybe in a boost proposal it would be best to just use it? http://www.boost.org/libs/math/quaternion/index.html Jeff
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Jeff Garland | Sent: 14 November 2005 12:48 | To: boost@lists.boost.org | Subject: Re: [boost] Interest in dimension/unit-checking library? Perhaps I can just add that there was a significant feeling that a 'meta-units' system that allowed 'User Defined Units' - from which could be created the familiar SI units system, but would also allow more unusual units systems, for example used by the finance world, or really weird like non-relativistic. The ultimate dimension/unit-checking library? We are waiting out to find out if this is possible, which seems likely - and practicable in compile speed, which is less certain. Paul -- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB Phone and SMS text +44 1539 561830, Mobile and SMS text +44 7714 330204 mailto: pbristow@hetp.u-net.com www.hetp.u-net.com
If you're going to take my side of the argument, then I'll have to take yours! To heck with the ultimate library. Just one working library, even SI units only, in boost would be major progress. The ultimate one can come later and should come from the people (like me) who are demanding it. Those of you who have developed physical units only libraries (because that's the only thing you need) should proceed anyway. It's my belief that even such a library will see widespread usage and that this experience will help us develop further enhancements to the library. Paul A Bristow wrote:
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Jeff Garland | Sent: 14 November 2005 12:48 | To: boost@lists.boost.org | Subject: Re: [boost] Interest in dimension/unit-checking library?
Perhaps I can just add that there was a significant feeling that a 'meta-units' system that allowed 'User Defined Units' - from which could be created the familiar SI units system, but would also allow more unusual units systems, for example used by the finance world, or really weird like non-relativistic.
The ultimate dimension/unit-checking library?
We are waiting out to find out if this is possible, which seems likely - and practicable in compile speed, which is less certain.
Paul
Well - I'd be delighted with this too - it's all I'd ever want, but too many Boosters seems not to accept that "The Best is the Enemy of the Good". Paul -- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB Phone and SMS text +44 1539 561830, Mobile and SMS text +44 7714 330204 mailto: pbristow@hetp.u-net.com www.hetp.u-net.com | -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Deane Yang | Sent: 15 November 2005 16:04 | To: boost@lists.boost.org | Subject: Re: [boost] Interest in dimension/unit-checking library? | | If you're going to take my side of the argument, then I'll | have to take | yours! | | To heck with the ultimate library. Just one working library, even SI | units only, in boost would be major progress. The ultimate | one can come | later and should come from the people (like me) who are demanding it. | Those of you who have developed physical units only libraries | (because | that's the only thing you need) should proceed anyway. It's my belief | that even such a library will see widespread usage and that this | experience will help us develop further enhancements to the library. | | > Perhaps I can just add that there was a significant feeling that a | > 'meta-units' system that allowed 'User Defined Units' - | from which could be | > created the familiar SI units system, but would also allow | more unusual | > units systems, for example used by the finance world, or | really weird like | > non-relativistic. | > | > The ultimate dimension/unit-checking library? |
Boosters: I'm hoping someone here might be of help, and enlighten me with some more MPL trickery ... What I'm doing: Have a class MyArray derived from blitz::Array, and among other things, I'm trying to add the operator[] to slice through a multi-dim array ... pretty much have it, with one exception - once I get to applying [] on a 1-dimensional (linear) array, I of course expect a scalar, but therein lies the problem - the compiler also "sees" a 0-dimensional array (not good!), and that's where I run into problems... Brief snippets of code: Please ignore the return by value for the moment - I can clean that up later, not to mention the Boost PP extensions I can add. Below is a cut-down class definition, and method implementation follows. Class Declaration: ------------------ template <typename T, int Rank = 1> class MyArray : public blitz::Array<T, boost::mpl::int_<Rank>::value> { public: // ... methods }; (Partial Listing) Implementation: --------------------------------- template <typename T, int Rank> MyArray<T, Rank> :: Array(const blitz::Array<T, boost::mpl::int_<Rank>::value>& btz ) throw() : blitz::Array<T, boost::mpl::int_<Rank>::value> (const_cast<T *> (btz.data()) , btz.shape() , blitz::duplicateData ) { // Copy Ctor } template <typename T, int Rank> void MyArray<T, Rank> :: getParamList(blitz::TinyVector< boost::variant< blitz::Range , blitz::nilArraySection > , 2 >& plist ) { // Aides us in setting up the parameter list for slicing plist(boost::mpl::int_<0>::value) = blitz::Range::all(); plist(boost::mpl::int_<1>::value) = blitz::nilArraySection(); } /* Now, how do I get T out when Rank == 1, ... compiler complains about seeing a MyArray/blitz::Array of <T, Rank = 0> (, which is not defined for blitz Arrays) */ template <typename T, int Rank> typename boost::mpl::if_ < typename boost::mpl::equal_to < boost::mpl::int_<Rank> , boost::mpl::int_<1> >::type , T , blitz::Array<T, boost::mpl::int_<Rank>::prior::value> >::type MyArray<T, Rank> :: operator[] (const int& index) throw(); { // Slicing // this bit of indirection is useful blitz::TinyVector<boost::variant<blitz::Range, blitz::nilArraySection>, 2> plist; this->getParamList(plist); /* pseudocode: (kind of) **************** return // cast for return type static_cast< (Rank == 1 ? T : MyArray<T, Rank - 1>) > ( // cast _this_ ptr * static_cast<const blitz::Array<T, Rank> *> (this) // the blitz Array parameter list (index, //the param list *boost::get<blitz::Range *or* blitz::nilArraySection>(&plist(0 *or* 1), ... ) ) Sample usage: MyArray<float, 3> arr(btzArray); arr[10]; // gives MyArray<float, 2> out arr[10][2] // gives MyArray<float, 1> out arr[10][2][7] // expect a float to be output ********************/ return static_cast< typename boost::mpl::if_< typename boost::mpl::equal_to< boost::mpl::int_<Rank> , boost::mpl::int_<1> >::type , T , MyArray<T, boost::mpl::int_<Rank>::prior::value> >::type > ((* static_cast<const blitz::Array<T, boost::mpl::int_<Rank>::value> *> (this)) /* the parameter list */ (index, *boost::get< typename boost::mpl::if_< typename boost::mpl::less< boost::mpl::int_<1> , boost::mpl::int_<Rank> >::type , blitz::Range , blitz::nilArraySection >::type > (&plist(boost::mpl::if_< typename boost::mpl::less< boost::mpl::int_<1> , boost::mpl::int_<Rank> >::type , boost::mpl::int_<0> , boost::mpl::int_<1> >::type::value ) ) /* , ... we can extend the parameter list with Boost.PP */ ); ************* (Partial) Compiler Error Messages: --------------------------------- `boost::mpl::algo_::if_<boost::mpl::equal_to<boost::mpl::int_<Rank>, boost::mpl::int_<1> >::type, T, blitz::Array<T, typename boost::mpl::int_<Rank>::prior::value> >::type moe::Array<T, Rank>::operator[](const S&) [with S = int, T = int, int Rank = 1]': arr.cc:172: instantiated from here arr.cc:666: invalid static_cast from type `blitz::Array<int, 0>' to type `int' /usr/local/include/blitz/array/storage.h: In constructor `blitz::GeneralArrayStorage<N_rank>::GeneralArrayStorage() [with int N_rank = 0]': <snip ... more messages> /usr/local/include/blitz/array/storage.h:60: no match for call to `( blitz::TinyVector<int, 0>) (int&)' <snip ... more messages> ******************* So ... can anyone tell me if what I'm trying to do is possible ? Is there some MPL trickery to do it ? The above does work up until I apply the operator[] on a 1-d linear array. Help and ideas would be appreciated. Ah yes, using gcc 3.2.2, and Boost version 1.31 (maybe 1.32) .. downloaded in August 2004 (yes, I know that's ancient - but managment can be a real pain sometimes) P.S. tried to format this message as best I could, hope it's readable. With Thanks, -- Manfred Doudar MetOcean Engineers www.metoceanengineers.com
Manfred Doudar wrote:
/* Now, how do I get T out when Rank == 1, ... compiler complains about seeing a MyArray/blitz::Array of <T, Rank = 0> (, which is not defined for blitz Arrays) */ template <typename T, int Rank> typename boost::mpl::if_ < typename boost::mpl::equal_to < boost::mpl::int_<Rank> , boost::mpl::int_<1> >::type , T , blitz::Array<T, boost::mpl::int_<Rank>::prior::value>
^ Oops typo, should be: MyArray<T, boost::mpl::int_<Rank>::prior::value> ... but nonetheless, the problem remains ...
>::type MyArray<T, Rank> :: operator[] (const int& index) throw(); { // Slicing
"Jeff Garland" wrote
In the particular case of units, I'll just warn you that there is a trail of broken dreams. There is clearly interest in such a library, but several authors have started and then abandoned. You'll want to have a look thru the mailing lists at some of the discussions we've had over the last 5 years or so. I think Andy Little has come the closest to an actual submission. You can find his library at:
http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/index.html
I hope that boost will get its units library eventually . It just needs a lot more work than it appears to! FWIW I have managed to spend some time on creating a boost version of pqs library. It is progress but not complete. This has been greatly helped by Cromwell Enages work on the mpl::math::rational (Thanks Cromwell), which pqs library ( and I think any boost units library) depends on. I presume that Matt Calabrese is also working on his submission, which takes a radically different approach from the sound of it. FWIW I have opted not to use mpl::double for the boost::pqs library yet just because it makes more work( and will increase compile times a lot I think), however I hope that the new version of the library will be more modular that the old one which will make incorporating mpl::double easier later on. The modularity extends to forming the dimensional analysis part of the library in terms of mpl sequence (currently tested with mpl::vector only) to facilitate reuse with non SI unit systems.( The old library has this facility but was done outside mpl, which it seems makes it obscure). No guarantees that I'll finish this soon, but having settled on Cromwells rational at last, at least I seem to have got over the worst part of the conversion to a boost library. Perhaps I should put what I have so far in the boost sandbox. How do I go about applying for write permission? Or is there somewhere else I should put it? BTW I assume that cvs is still in use rather than subversion? On holiday till early December... bye for now. regards Andy Little
--- Andy Little wrote:
It is progress but not complete. This has been greatly helped by Cromwell Enage's work on the mpl::math::rational (Thanks Cromwell)
Anytime.
Perhaps I should put what I have so far in the boost sandbox. How do I go about applying for write permission?
Submit your request with your SourceForge ID in an e-mail to Beman Dawes, Douglas Gregor, or Jeremy Siek.
Or is there somewhere else I should put it?
The Boost Vault is a good alternative. Registration is much simpler, too.
BTW I assume that cvs is still in use rather than subversion?
Yes. Cromwell D. Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
"Cromwell Enage" wrote
The Boost Vault is a good alternative. Registration is much simpler, too.
Right...how would I go about registering for the vault ? FWIW I dont have a Sourceforge ID. Do I need one to register with the vault? regards Andy Little
Andy Little wrote:
"Cromwell Enage" wrote
The Boost Vault is a good alternative. Registration is much simpler, too.
Right...how would I go about registering for the vault ? FWIW I dont have a Sourceforge ID. Do I need one to register with the vault?
Go to the 'Login' page on the vault. It has a 'Register' link. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
"Rene Rivera" wrote
Go to the 'Login' page on the vault. It has a 'Register' link.
Thanks for the Info. I've logged in and created a directory called "Physical Quantities Units". Now just need some content ;-) regards Andy Little
On 11/21/05, Andy Little <andy@servocomm.freeserve.co.uk> wrote:
I presume that Matt Calabrese is also working on his submission, which takes a radically different approach from the sound of it.
Yup, it's still in the works. I'm currently in the process of switching over to using Eric Niebler's Proto library internally for dealing with expression templates (a sublibrary which was used in xpressive), as opposed to the bare-bones expression templates I was developing. As a side note, if any other unit library developers are interested (or anyone else), I recently made a simple metafunction for yielding integral and floating point promotions (4.5 and 4.6), as well as a binary metafunction for yielding the type after usual arithmetic conversions (5p9), both of which are almost essential for elegantly obtaining the return types of common operations on arithmetic types. They're extremely useful for determing the proper return type of common forwarded unary and binary operations of quantities to an underlying arithmetic value type, such as for negation (which implies a promotion) or subtraction (which implies usual arithmetic conversions). If people haven't already developed their own solutions and would like these (already boostified), they are very small and quick to upload. Both just examine compiler behavior to determine the appropriate datatypes. They work with extended types such as long long, and promotion works correctly even with enum types as input. -- -Matt Calabrese
"Matt Calabrese" wrote
Yup, it's still in the works. I'm currently in the process of switching over to using Eric Niebler's Proto library internally for dealing with expression templates (a sublibrary which was used in xpressive), as opposed to the bare-bones expression templates I was developing.
It will be interesting to see this in action! I have my doubts about coupling it too closely to the units library, but I am happy to be proved wrong!
As a side note, if any other unit library developers are interested (or anyone else), I recently made a simple metafunction for yielding integral and floating point promotions (4.5 and 4.6), as well as a binary metafunction for yielding the type after usual arithmetic conversions (5p9),
It might be as well to note that this functionality is provided by Boost.Typeof, however Boost.Typeof can cause very slow compile times. (I hope that Arkadiy Vertleyb and Peder Holt dont take unkindly to that remark!) Because of this my approach is to provide various metafunctions for providing the result type of operations internally in pqs units library, meanwhile registering required types with Boost.Typeof for compatibility with other libraries. I'm not sure how anyone else feels about this, but if the metafunctions ( currently I call them binary_operation, unary_operation and arithmetic_promote) are still required( due to slow compile time of Typeof) then It would be useful to give these functions the same name across libraries. regards Andy Little
On 11/21/05, Andy Little <andy@servocomm.freeserve.co.uk> wrote:
It might be as well to note that this functionality is provided by Boost.Typeof, however Boost.Typeof can cause very slow compile times. (I hope that Arkadiy Vertleyb and Peder Holt dont take unkindly to that remark!)
Yeah, in the case of a unit library, Boost.Typeof can be used directly with arithmetic types on an expression using the desired operations with potentially a bit of an impact on compile times, though the benefit of a more general metafunction arises when enums are introduced (not in reference to a units library), since operators you may be using in the typeof expression may be overloaded, meaning the expression used inside of typeof would have to result in promotion or usual arithmetic conversions without using any overloadable operators, which can be a hassle to deal with. I get around enum operator overloads by just internally using a type extraction mechanism on the result of a function call whose parameter types and result types are based off of the set of types restricted by the possible results of promotion and usual arithmetic conversion as defined by the standard (and including long long and unsigned long long types if the compiler supports them as extensions). This way, promotion happens through the passing of arguments to a function, without any possibility of invoking overloaded operators. As well, since the possible result types are a small, finite set, type extraction can be done quickly and easily. Note though, that these metafunctions are only for arithmetic and enum types (as that is all that the standard defines promotion and usual arithmetic conversions for). Typeof on expressions is still the best solution if you want to provide a way of automatically yielding the result of an arbitrary expression based off of user-defined types. In my library, forwarded operations and results are currently provided through policies, defaulting appropriately for arithmetic types with the aforementioned conversion metafunctions, and defaulting to the intuitive operators and a metafunction encapsulating typeof on those operations for user-defined types. This way, you can get proper automatic results for all arithmetic types without the need for typeof, automatic results with user-defined types when using typeof registration and the default policies, or you can specialize the metafunctions used by the default policies to avoid typeof completely if necessary. The names for the metafunctions I'm using are "promote" and "usual_arithmetic_conversions", since these reflect how they are refered to in the standard. Your "arithmetic_promote" is probably a better name than my "usual_arithmetic_conversions" since it's shorter and has a verb, so I'll make that adjustment. These are really more general purpose than a units library, so would probably best just be in type_traits in exposed anywhere at all. -- -Matt Calabrese
Andy Little <andy@servocomm.freeserve.co.uk> wrote:
It might be as well to note that this functionality [integral and floating point promotions] is provided by Boost.Typeof, however Boost.Typeof can cause very slow compile times.
This should not be the case for such simple types as integrals and floating points, though. In such case the main overhead doesn't come from type encoding/decoding, but rather from the need to pass non-used items through the function boundaries, which is a mauch smaller overhead. Also, it should be easy to factor out yet another macro where one could provide the size of the vector used for encoding (unfortunately, this is a pre-processor constant, and can't be figured out by the typeof library based on the actual type). If this size is set to one, I don't see _any_ overhead. Let me know if this sounds useful. Regards, Arkadiy
Hi Arkadiy, Apologies that I missed this reply before. "Arkadiy Vertleyb" wrote
Andy Little wrote:
It might be as well to note that this functionality [integral and floating point promotions] is provided by Boost.Typeof, however Boost.Typeof can cause very slow compile times.
This should not be the case for such simple types as integrals and floating points, though. In such case the main overhead doesn't come from type encoding/decoding, but rather from the need to pass non-used items through the function boundaries, which is a mauch smaller overhead. Also, it should be easy to factor out yet another macro where one could provide the size of the vector used for encoding (unfortunately, this is a pre-processor constant, and can't be figured out by the typeof library based on the actual type). If this size is set to one, I don't see _any_ overhead.
Let me know if this sounds useful.
My approach to typeof is to use it for anything external to my library, whilst using my own type deduction internally. I expect that other libraries will do the same thing, so I dont know how easy it would be to try to keep track of the number of types in the vector. Only the user could do this and IIRC the idea was to remove as much work for the user as possible. I would for example expect other library authors to use typeof to facilitate use of the tentative boost ( or non-boost) physical quantities types as value_types. On this subject there are several libraries which could then allow the tentative boost physical quantities types as value_types. I think that complex ( ok not boost exactly) and interval , quaternion, as well as perhaps rational ( for bigints at least, but also for rational quantities) could potentially be rewritten this way. I would be interested in the authors or maintainers views on this subject. regards Andy Little
Hi Andy, "Andy Little" <andy@servocomm.freeserve.co.uk> wrote
My approach to typeof is to use it for anything external to my library, whilst using my own type deduction internally.
I don't quite understand why would you want to do this... The typeof was specifically designed for library authors, like yourself, to allow you easily describe your types. This way your users would have the impression that they have typeof for free. If every library author uses his/her own typeof emulation mechanism, not only the effort will be repeated every time, but also types composed from different libraries, such as liba::x<libb::y>, would not be handled... Or did I misinterpret your statement? Maybe you implied that you will use typeof for your library interface, while avoiding it in the implementation? Regards, Arkadiy
Hi Arkadiy, "Arkadiy Vertleyb" wrote
Hi Andy, If every library author uses his/her own typeof emulation mechanism, not only the effort will be repeated every time, but also types composed from different libraries, such as liba::x<libb::y>, would not be handled...
Or did I misinterpret your statement? Maybe you implied that you will use typeof for your library interface, while avoiding it in the implementation?
I guess it was misleading. I am currently wrapping Typeof in a class template template <typename Lhs, typename Op, typename Rhs> struct binary_operation; template <typename Lhs,typename Rhs> struct binary_operation<Lhs, plus, Rhs> // arithmetic types but allowing customisation where is_value_type<Lhs> && is_value_type<Rhs> { typedef BOOST_TYPEOF_TPL( Lhs() + Rhs()) type; }; Now its also possible to use typeof or not as I please via a macro. (It might be useful to find the difference in cvompile times anyawy) Note that its not actually required to use typeof in my own definitions, IOW the interface, but other libraries can use typeof and will work Ok with my library ( types are registered). template <typename Lhs, typename Rhs> where is_quantity<Lhs> && is_quantity<Rhs> typename binary_operation<Lhs,plus,Rhs>::type operator +( Lhs const & lhs, Rhs const & rhs); IOW its not really an interface versus implementation thing really. Does that make any sense? regards Andy Little
Hi Arkadiy,
"Arkadiy Vertleyb" wrote
Hi Andy, If every library author uses his/her own typeof emulation mechanism, not only the effort will be repeated every time, but also types composed from different libraries, such as liba::x<libb::y>, would not be handled...
Or did I misinterpret your statement? Maybe you implied that you will use typeof for your library interface, while avoiding it in the implementation?
I guess it was misleading. I am currently wrapping Typeof in a class template
template <typename Lhs, typename Op, typename Rhs> struct binary_operation;
template <typename Lhs,typename Rhs> struct binary_operation<Lhs, plus, Rhs> // arithmetic types but allowing customisation where is_value_type<Lhs> && is_value_type<Rhs> { typedef BOOST_TYPEOF_TPL( Lhs() + Rhs()) type; };
Now its also possible to use typeof or not as I please via a macro. (It might be useful to find the difference in cvompile times anyawy) Note that its not actually required to use typeof in my own definitions, IOW the interface, but other libraries can use typeof and will work Ok with my library ( types are registered).
template <typename Lhs, typename Rhs> where is_quantity<Lhs> && is_quantity<Rhs> typename binary_operation<Lhs,plus,Rhs>::type operator +( Lhs const & lhs, Rhs const & rhs);
IOW its not really an interface versus implementation thing really. Does
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote that
make any sense?
OK, it does. Regards, Arkadiy
Hi, Regarding using Typeof with compile time libraries such as mpl. mpl doesnt actually deal in types so when I operate on a mpl vector I might get back a mpl::vector7 or something else. Similarly with mpl::math::rational I might get back a mpl::math::rational or a mpl::math::simplified_rational. That makes for a very flakey quantities library unfortunately, because in compliant mode Typeof is totally dependent on implementation changes in these other libraries, and when the compiler crashes because of unregistered types it does so in a huge fashion. Not sure what if anything can be done about it but I'm wondering whether it is worth asking library authors now to provide a mechanism so that user can register their libraries types (that would be eg a mpl::vector +++ anything it might turn into... is that possible or impractical? )without hassle. That would solve my problem I think, but maybe would result in a type registration explosion? Any mechanism that allows use of Typeof without dependencies on implementation details of other libraries would be appreciated! regards Andy Little
Regarding using Typeof with compile time libraries such as mpl. mpl doesnt actually deal in types so when I operate on a mpl vector I might get back a mpl::vector7 or something else. Similarly with mpl::math::rational I might get back a mpl::math::rational or a mpl::math::simplified_rational.
That makes for a very flakey quantities library unfortunately, because in compliant mode Typeof is totally dependent on implementation changes in
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote these
other libraries, and when the compiler crashes because of unregistered types it does so in a huge fashion.
Not sure what if anything can be done about it but I'm wondering whether it is worth asking library authors now to provide a mechanism so that user can register their libraries types (that would be eg a mpl::vector +++ anything it might turn into... is that possible or impractical? )without hassle. That would solve my problem I think, but maybe would result in a type registration explosion?
Registering MPL types is a little less trivial than usual, because MPL generates these types. Accordingly, registrations should also be generated, but then we'd run into the problem with the __LINE__ usage. So, I think this should utilize lower-level typeof macros, which do not use __LINE__, but instead allow for Id to be specified directly.
Any mechanism that allows use of Typeof without dependencies on implementation details of other libraries would be appreciated!
I will try to implement such registrations for mpl::vector[n], as an example. However, I think it's ultimately up to the library authors do decide whether or not to make their libraries typeof-enabled (I would be happy to provide any help on the subject). Regards, Arkadiy
"Arkadiy Vertleyb" wrote ...
I will try to implement such registrations for mpl::vector[n], as an example. However, I think it's ultimately up to the library authors do decide whether or not to make their libraries typeof-enabled (I would be happy to provide any help on the subject).
Types are an implementation detail in mpl , so as I understand it, even if I as a user ,currently register the actual types of the result, then there is no guarantee that they will remain the same in the next version of the library, which makes theoretically for high maintenance unless the library author deals with it instead. I guess its not to bad in practise, but means my quantity library is relying on artefacts of the implementation if I use mpl, and I dont really like that :-( BTW... I guess it might be glaringly obvious, but it might be worth mentioning in the documentation that when the inbuilt error output fails regarding lack of type registration( When pages and pages of template parameters appear) , that using typeid(T).name() will provide useful information on the make-up of a particular type, an alternative aid to finding the particular types that havent been registered. Maybe its too obvious too mention but I forgot about it recently. After I started using this approach it dramatically speeded up my debugging. Finally thanks again for the Typeof library. Despite all my moaning, I think its a great addition to boost :-) regards Andy Little
"Arkadiy Vertleyb" wrote ...
I will try to implement such registrations for mpl::vector[n], as an example. However, I think it's ultimately up to the library authors do decide whether or not to make their libraries typeof-enabled (I would be happy to provide any help on the subject).
Types are an implementation detail in mpl , so as I understand it, even if I as a user ,currently register the actual types of the result, then there is no guarantee that they will remain the same in the next version of the
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote library,
which makes theoretically for high maintenance unless the library author deals with it instead. I guess its not to bad in practise, but means my quantity library is relying on artefacts of the implementation if I use mpl, and I dont really like that :-(
BTW... I guess it might be glaringly obvious, but it might be worth mentioning in the documentation that when the inbuilt error output fails regarding lack of type registration( When pages and pages of template parameters appear) ,
This is one problem. Another problem is that, if somebody else also registers MPL types (which is quite likely due to its popularity), any attempt to use your libs together will result in compile errors due to double MPL registration. That's why I think only library authors should register their types. In case it's not possible (STL, for example) this is done by the typeof library itself. As a (temporary?) workaround, I can suggest you to define your own sequences by deriving them from mpl::vector, register them, and ask your users to use them instead of mpl::vector to supply type sequences to your templates. I am thinking of using this approach with RTL. that
using typeid(T).name() will provide useful information on the make-up of a particular type, an alternative aid to finding the particular types that havent been registered. Maybe its too obvious too mention but I forgot about it recently. After I started using this approach it dramatically speeded up my debugging.
So that you can catch all of them at once instead of one-by-one, as the error messages arrive. Sounds reasonable. Regards, Arkadiy
"Arkadiy Vertleyb" wrote in message
This is one problem. Another problem is that, if somebody else also registers MPL types (which is quite likely due to its popularity), any attempt to use your libs together will result in compile errors due to double MPL registration.
That's why I think only library authors should register their types. In case it's not possible (STL, for example) this is done by the typeof library itself.
Maybe It would be a good idea to think up a common format for library authors to use, such as the name of the Header to include to register the libraries types with Typeof. Then It would be possible for someone other than the library author to add the headers to the relevent libraries . It might be best to add them as subdirectories of the typeof directory, so for example I would look for a "boost/typeof/mpl/vector/register.hpp" header or some such and if not found (ideallly!) write it and submit it with some suitable tests for placing in a subdirectory of libs/typeof/test/.. [..]
So that you can catch all of them at once instead of one-by-one, as the error messages arrive. Sounds reasonable.
In VC7.1 they dont always arrive in the first place ;-) regards Andy Little
"Arkadiy Vertleyb" wrote in message
That's why I think only library authors should register their types. In case it's not possible (STL, for example) this is done by the typeof
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote library
itself.
Maybe It would be a good idea to think up a common format for library authors to use, such as the name of the Header to include to register the libraries types with Typeof. Then It would be possible for someone other than the library author to add the headers to the relevent libraries . It might be best to add them as subdirectories of the typeof directory, so for example I would look for a "boost/typeof/mpl/vector/register.hpp" header or some such and if not found (ideallly!) write it and submit it with some suitable tests for placing in a subdirectory of libs/typeof/test/..
This would make typeof dependent on all the other libraries. I don't think I like this idea... In fact, I know for sure that I don't :-) I believe the registration of a library types should reside inside this library, and tested as a part of this library test.
So that you can catch all of them at once instead of one-by-one, as the error messages arrive. Sounds reasonable.
In VC7.1 they dont always arrive in the first place ;-)
Don't we always get something like: "Type_not_registered_with_typeof_library=xxx<[a few hundred lines here]>" ? Regards, Arkadiy
"Arkadiy Vertleyb" wrote [...]
I believe the registration of a library types should reside inside this library, and tested as a part of this library test.
And if they dont then come the problems. Whether they do or not I need to use it. At least a common format for eg the header name and location in the library-authors directories would help. I'm not expecting any other library authors to add the typeof functionality that I need. I'm happy to do it myself, but there needs to be a way to prevent multiple registrations. That means specifying some common format for everyone to use.
So that you can catch all of them at once instead of one-by-one, as the error messages arrive. Sounds reasonable.
In VC7.1 they dont always arrive in the first place ;-)
Don't we always get something like:
"Type_not_registered_with_typeof_library=xxx<[a few hundred lines here]>" ?
Removing one type registration from my quantities library I stopped the compilation at around 17000 lines of errror code. Whatever was at the top of it was something to do with mpl::size_t<somenumber>. which I had never heard of IOW No we dont ;-) regards Andy Little
"Arkadiy Vertleyb" wrote
[...]
I believe the registration of a library types should reside inside this library, and tested as a part of this library test.
And if they dont then come the problems. Whether they do or not I need to use it. At least a common format for eg the header name and location in the library-authors directories would help. I'm not expecting any other
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote library
authors to add the typeof functionality that I need. I'm happy to do it myself,
Right, but are you willing to _maintain_ this? At the same moment you are adding your registrations, the library author might be changing his types... I think who _does_ the initial work is not as important as who is responsible for keeping it in-sync.
but there needs to be a way to prevent multiple registrations. That means specifying some common format for everyone to use.
So that you can catch all of them at once instead of one-by-one, as
Some authors might prefer to register all their types in a separate file, while others might want to register them in the same header where the types are defined (this may depend on people's expectation of how much longer the typeof emulation is going to be relevant). One (although not perfect) way to avoid multiple registration problem was suggested by David Abrahams some time ago -- to use guards similar to include guards: #ifndef BOOST_MPL_TYPEOF_REGISTERED #define BOOST_MPL_TYPEOF_REGISTERED // register mpl types #endif Now everybody has to agree on the guard name. The ultimate solution would be persuade authors to register their types. the
error messages arrive. Sounds reasonable.
In VC7.1 they dont always arrive in the first place ;-)
Don't we always get something like:
"Type_not_registered_with_typeof_library=xxx<[a few hundred lines here]>" ?
Removing one type registration from my quantities library I stopped the compilation at around 17000 lines of errror code. Whatever was at the top of it was something to do with mpl::size_t<somenumber>. which I had never heard of
IOW No we dont ;-)
That's not good :-( Can you post (or send me directly) the error message the next time you get it? Regards, Arkadiy
Hi Arkadiy, Its late and I'll have to reply on the rest of your post later. Meanwhile enclosed is a small sample of the error output, which happens when I comment out registration for boost::mpl::math::reduced_rational in my registration "Arkadiy Vertleyb" wrote
Can you post (or send me directly) the error message the next time you get it?
Small sample enclosed.( Let me know if you want a bigger portion.) . Hopefully I'll be able to publish the library to the vault within the week, when this may make more sense. I guess that the full error message runs to several Mb. I've never actually let it run to completion. Rather than wading through this stuff I prefer just to use typeid which then reveals the missing type. FWIW typeid in similar situation(Sorry dont know if this is the exact spot the other error occurs) gives class boost::pqs::t1_quantity< struct boost::pqs::meta::abstract_quantity< struct boost::mpl::vector7< struct boost::mpl::math::simplified_rational< struct boost::mpl::integral_c<long,1>, struct boost::mpl::integral_c<long,2> >, struct boost::mpl::int_<0>, struct boost::mpl::int_<0>, struct boost::mpl::int_<0>, struct boost::mpl::int_<0>, struct boost::mpl::int_<0>, struct boost::mpl::int_<0> >, struct boost::mpl::integral_c<int,0> >, struct boost::pqs::meta::quantity_unit< struct boost::mpl::math::simplified_rational< struct boost::mpl::integral_c<long,0>, struct boost::mpl::integral_c<long,1> >, struct boost::mpl::int_<1>, struct boost::mpl::int_<0 > >, double
regards Andy Little begin 666 typeof_opt.txt M+2TM+2TM($)U:6QD('-T87)T960Z(%!R;VIE8W0Z(&)O;W-T7W!Q<RP@0V]N M9FEG=7)A=&EO;CH@1&5B=6<@5VEN,S(@+2TM+2TM#0H-"D-O;7!I;&EN9RXN M+@T*=#%?<75A;G1I='E?=&5S="YC<' -"G5S:6YG(&-O;7!L:6%N="!I;6QE M;65N=&%T:6]N#0IC.EQB;V]S=%QB;V]S=%\Q7S,S7S!<8F]O<W1<='EP96]F M7&5N8V]D95]D96-O9&4N:'!P*#(T*2 Z(&5R<F]R($,R-3 T.B G8F]O<W0Z M.G1Y<&5?;V8Z.F!A;F]N>6UO=7,M;F%M97-P86-E)SHZ96YC;V1E7W1Y<&5? M:6UP;#Q6+%1Y<&5?3F]T7U)E9VES=&5R961?5VET:%]4>7!E;V9?4WES=&5M M/B<@.B!B87-E(&-L87-S('5N9&5F:6YE9 T*(" @(" @("!W:71H#0H@(" @ M(" @(%L-"B @(" @(" @(" @(%8]8F]O<W0Z.G1Y<&5?;V8Z.F!A;F]N>6UO M=7,M;F%M97-P86-E)SHZ96YC;V1E7W1Y<&5?:6UP;#QB;V]S=#HZ='EP95]O M9CHZ8&%N;VYY;6]U<RUN86UE<W!A8V4G.CIE;F-O9&5?='EP95]I;7!L/&)O M;W-T.CIT>7!E7V]F.CI@86YO;GEM;W5S+6YA;65S<&%C92<Z.F5N8V]D95]T M>7!E7VEM<&P\8F]O<W0Z.G1Y<&5?;V8Z.G9E8W1O<C \/BQB;V]S=#HZ<'%S M.CIM971A.CIB:6YA<GE?;W!E<F%T:6]N/&)O;W-T.CIP<7,Z.G0Q7W%U86YT M:71Y/&)O;W-T.CIP<7,Z.F%U>#HZ;&5N9W1H7W1Y<&4P+&)O;W-T.CIP<7,Z M.F%U>#HZ8V]H7W5N:70P+&1O=6)L93XL8F]O<W0Z.G!Q<SHZ;65T83HZ<&]W M+&)O;W-T.CIM<&PZ.FUA=&@Z.G)A=&EO;F%L7V,\:6YT+#$L,CXL=F]I9#XZ M.G)E<W5L=%]T>7!E/CHZ5C L8F]O<W0Z.G!Q<SHZ;65T83HZ86)S=')A8W1? M<75A;G1I='D\8F]O<W0Z.G!Q<SHZ;65T83HZ9&5T86EL.CIA8G-T<F%C=%]Q M=6%N=&ET>5]T;U]P;W=E<CQB;V]S=#HZ<'%S.CIM971A.CIA8G-T<F%C=%]Q M=6%N=&ET>3QB;V]S=#HZ;7!L.CIV96-T;W(\8F]O<W0Z.G!Q<SHZ875X.CIO M;F4L8F]O<W0Z.G!Q<SHZ875X.CIZ97)O+&)O;W-T.CIP<7,Z.F%U>#HZ>F5R M;RQB;V]S=#HZ<'%S.CIA=7@Z.GIE<F\L8F]O<W0Z.G!Q<SHZ875X.CIZ97)O M+&)O;W-T.CIP<7,Z.F%U>#HZ>F5R;RQB;V]S=#HZ<'%S.CIA=7@Z.GIE<F\^ M+&)O;W-T.CIM<&PZ.FEN=%\\,3X^+&)O;W-T.CIM<&PZ.FUA=&@Z.G)A=&EO M;F%L7V,\:6YT+#$L,CX^.CID:6US7W1Y<&4L8F]O<W0Z.G!Q<SHZ;65T83HZ M9&5T86EL.CIA8G-T<F%C=%]Q=6%N=&ET>5]T;U]P;W=E<CQB;V]S=#HZ<'%S M.CIM971A.CIA8G-T<F%C=%]Q=6%N=&ET>3QB;V]S=#HZ;7!L.CIV96-T;W(\ M8F]O<W0Z.G!Q<SHZ875X.CIO;F4L8F]O<W0Z.G!Q<SHZ875X.CIZ97)O+&)O M;W-T.CIP<7,Z.F%U>#HZ>F5R;RQB;V]S=#HZ<'%S.CIA=7@Z.GIE<F\L8F]O M<W0Z.G!Q<SHZ875X.CIZ97)O+&)O;W-T.CIP<7,Z.F%U>#HZ>F5R;RQB;V]S M=#HZ<'%S.CIA=7@Z.GIE<F\^+&)O;W-T.CIM<&PZ.FEN=%\\,3X^+&)O;W-T M.CIM<&PZ.FUA=&@Z.G)A=&EO;F%L7V,\:6YT+#$L,CX^.CIA;F]N>6UO=7-? M:60^.CIT>7!E/CHZ5C L8F]O<W0Z.G!Q<SHZ;65T83HZ9&5T86EL.CIA8G-T M<F%C=%]Q=6%N=&ET>5]T;U]P;W=E<CQB;V]S=#HZ<'%S.CIM971A.CIA8G-T M<F%C=%]Q=6%N=&ET>3QB;V]S=#HZ;7!L.CIV96-T;W(\8F]O<W0Z.G!Q<SHZ M875X.CIO;F4L8F]O<W0Z.G!Q<SHZ875X.CIZ97)O+&)O;W-T.CIP<7,Z.F%U M>#HZ>F5R;RQB;V]S=#HZ<'%S.CIA=7@Z.GIE<F\L8F]O<W0Z.G!Q<SHZ875X M.CIZ97)O+&)O;W-T.CIP<7,Z.F%U>#HZ>F5R;RQB;V]S=#HZ<'%S.CIA=7@Z M.GIE<F\^+&)O;W-T.CIM<&PZ.FEN=%\\,3X^+&)O;W-T.CIM<&PZ.FUA=&@Z M.G)A=&EO;F%L7V,\:6YT+#$L,CX^.CID:6US7W1Y<&4^.CI6,"P-"B @(" @ M(" @(" @(%1Y<&5?3F]T7U)E9VES=&5R961?5VET:%]4>7!E;V9?4WES=&5M M/6)O;W-T.CIM<&PZ.G9E8W1O<C8\8F]O<W0Z.FUP;#HZ=F5C=&]R-3QB;V]S M=#HZ;7!L.CIV96-T;W(T/&)O;W-T.CIM<&PZ.G9E8W1O<C,\8F]O<W0Z.FUP M;#HZ=F5C=&]R,CQB;V]S=#HZ;7!L.CIV96-T;W(Q/&)O;W-T.CIM<&PZ.F%U M>#HZ<F5S;VQV95]B:6YD7V%R9SQB;V]S=#HZ;7!L.CIB:6YD,CQB;V]S=#HZ M;7!L.CIL86UB9&$\8F]O<W0Z.FUP;#HZ:6YS97)T97(\8F]O<W0Z.FUP;#HZ M8VQE87)?:6UP;#QB;V]S=#HZ;7!L.CIA=7@Z.G-E<75E;F-E7W1A9U]I;7!L M/'1R=64L=')U93XZ.G)E<W5L=#)?/&)O;W-T.CIM<&PZ.G9E8W0-"F]R/&)O M;W-T.CIP<7,Z.F%U>#HZ;VYE+&)O;W-T.CIP<7,Z.F%U>#HZ>F5R;RQB;V]S M=#HZ<'%S.CIA=7@Z.GIE<F\L8F]O<W0Z.G!Q<SHZ875X.CIZ97)O+&)O;W-T M.CIP<7,Z.F%U>#HZ>F5R;RQB;V]S=#HZ<'%S.CIA=7@Z.GIE<F\L8F]O<W0Z M.G!Q<SHZ875X.CIZ97)O/CXZ.G1Y<&4^.CIA<'!L>3QB;V]S=#HZ<'%S.CIM M971A.CIA8G-T<F%C=%]Q=6%N=&ET>3QB;V]S=#HZ;7!L.CIV96-T;W(\8F]O M<W0Z.G!Q<SHZ875X.CIO;F4L8F]O<W0Z.G!Q<SHZ875X.CIZ97)O+&)O;W-T M.CIP<7,Z.F%U>#HZ>F5R;RQB;V]S=#HZ<'%S.CIA=7@Z.GIE<F\L8F]O<W0Z M.G!Q<SHZ875X.CIZ97)O+&)O;W-T.CIP<7,Z.F%U>#HZ>F5R;RQB;V]S=#HZ M<'%S.CIA=7@Z.GIE<F\^+&)O;W-T.CIM<&PZ.FEN=%\\,3X^.CID:6UE;G-I M;VX^.CIT>7!E+&)O;W-T.CIM<&PZ.G!U<VA?8F%C:SQB;V]S=#HZ;7!L.CIN M82QB;V]S=#HZ;7!L.CIN83X^.CIO<&5R871I;VX^.CIT>7!E+&)O;W-T.CIM M<&PZ.E\Q+&)O;W-T.CIM<&PZ.F)I;F0Q/&)O;W-T.CIM<&PZ.FQA;6)D83QB M;V]S=#HZ<'%S.CIM971A.CID971A:6PZ.G1I;65S7W)E9'5C93QB;V]S=#HZ M;7!L.CI?+&)O;W-T.CIM<&PZ.FUA=&@Z.G)A=&EO;F%L7V,\:6YT+#$L,CX^ M/CHZ='EP92QB;V]S=#HZ;7!L.CI?,CX^.CIA<'!L>3QB;V]S=#HZ;7!L.CIA M=7@Z.F9O;&1?:6UP;#PT+&)O;W-T.CIM<&PZ.F)E9VEN/&)O;W-T.CIM<&PZ M.G9E8W1O<CQB;V]S=#HZ<'%S.CIA=7@Z.F]N92QB;V]S=#HZ<'%S.CIA=7@Z M.GIE<F\L8F]O<W0Z.G!Q<SHZ875X.CIZ97)O+&)O;W-T.CIP<7,Z.F%U>#HZ M>F5R;RQB;V]S=#HZ<'%S.CIA=7@Z.GIE<F\L8F]O<W0Z.G!Q<SHZ875X.CIZ M97)O+&)O;W-T.CIP<7,Z.F%U>#HZ>F5R;SX^.CIT>7!E+&)O;W-T.CIM<&PZ M.F5N9#QB;V]S=#HZ;7!L.CIV96-T;W(\8F]O<W0Z.G!Q<SHZ875X.CIO;F4L M8F]O<W0Z.G!Q<SHZ875X.CIZ97)O+&)O;W-T.CIP<7,Z.F%U>#HZ>F5R;RQB M;V]S=#HZ<'%S.CIA=7@Z.GIE<F\L8F]O<W0Z.G!Q<SHZ875X.CIZ97)O+&)O M;W-T.CIP<7,Z.F%U>#HZ>F5R;RQB;V]S=#HZ<'%S.CIA=7@Z.GIE<F\^/CHZ M='EP92QB;V]S=#HZ;7!L.CII;G-E<G1E<CQB;V]S=#HZ;7!L.CIC;&5A<E]I M;7!L/&)O;W-T.CIM<&PZ.F%U>#HZ<V5Q=65N8V5?=&%G7VEM<&P\=')U92QT M<G5E/CHZ<F5S=6QT,E\\8F]O<W0Z.FUP;#HZ=F5C=&]R/&)O;W-T.CIP<7,Z M.F%U>#HZ;VYE+&)O;W-T.CIP<7,Z.F%U>#HZ>F5R;RQB;V]S=#HZ<'%S.CIA M=7@Z.GIE<F\L8F]O<W0Z.G!Q<SHZ875X.CIZ97)O+&)O;W-T.CIP<7,Z.F%U M>#HZ>F5R;RQB;V]S=#HZ<'%S.CIA=7@Z.GIE<F\L8F]O<W0Z.G!Q<SHZ875X M.CIZ97)O/CXZ.G1Y<&4^.CIA<'!L>3QB;V]S=#HZ<'%S.CIM971A.CIA8G-T M<F%C=%]Q=6%N=&ET>3QB;V]S=#HZ;7!L.CIV96-T;W(\8F]O<W0Z.G!Q<SHZ M875X.CIO;F4L8F]O<W0Z.G!Q<SHZ875X.CIZ97)O+&)O;W-T.CIP<7,Z.F%U M>#HZ>F5R;RQB;V]S=#HZ<'%S.CIA=7@Z.GIE<F\L8F]O<W0Z.G!Q<SHZ875X M.CIZ97)O+&)O;W-T.CIP<7,Z.F%U>#HZ>F5R;RQB;V]S=#HZ<'%S.CIA=7@Z M.GIE<F\^+&)O;W-T.CIM<&PZ.FEN=%\\,3X^.CID:6UE;G-I;VX^.CIT>7!E M+&)O;W-T.CIM<&PZ.G!U<VA?8F%C:SQB;V]S=#HZ;7!L.CIN82QB;V]S=#HZ M;7!L.CIN83X^.CIS=&%T92QB;V]S=#HZ;7!L.CIB:6YD,CQB;V]S=#HZ;7!L M.CIL86UB9&$\8F]O<W0Z.FUP;#HZ:6YS97)T97(\8F]O<W0Z.FUP;#HZ8VQE M87)?:6UP;#QB;V]S=#HZ;7!L.CIA=7@Z.G-E<75E;F-E7W1A9U]I;7!L/'1R M=64L=')U93XZ.G)E<W5L=#)?/&)O;W-T.CIM<&PZ.G9E8W1O<CQB;V]S=#HZ M<'%S.CIA=7@Z.F]N92QB;V]S=#HZ<'%S.CIA=7@Z.GIE<F\L8F]O<W0Z.G!Q M<SHZ875X.CIZ97)O+&)O;W-T.CIP<7,Z.F%U>#HZ>F5R;RQB;V]S=#HZ<'%S M.CIA=7@Z.GIE<F\L8F]O<W0Z.G!Q<SHZ875X.CIZ97)O+&)O;W-T.CIP<7,Z M.F%U>#HZ>F5R;SX^.CIT>7!E/CHZ87!P;'D\8F]O<W0Z.G!Q<SHZ;65T83HZ M86)S=')A8W1?<75A;G1I='D\#0IB;V]S=#HZ;7!L.CIV96-T;W(\8F]O<W0Z M.G!Q<SHZ875X.CIO;F4L8F]O<W0Z.G!Q<SHZ875X.CIZ97)O+&)O;W-T.CIP M<7,Z.F%U>#HZ>F5R;RQB;V]S=#HZ<'%S.CIA=7@Z.GIE<F\L8F]O<W0Z.G!Q M<SHZ875X.CIZ97)O+&)O;W-T.CIP<7,Z.F%U>#HZ>F5R;RQB;V]S=#HZ<'%S M.CIA=7@Z.GIE<F\^+&)O;W-T.CIM<&PZ.FEN=%\\,3X^.CID:6UE;G-I;VX^ M.CIT>7!E+&)O;W-T.CIM<&PZ.G!U<VA?8F%C:SQB;V]S=#HZ;7!L.CIN82QB M;V]S=#HZ;7!L.CIN83X^.CIO<&5R871I;VX^.CIT>7!E+&)O;W-T.CIM<&PZ M.E\Q+&)O;W-T.CIM<&PZ.F)I;F0Q/&)O;W-T.CIM<&PZ.FQA;6)D83QB;V]S M=#HZ<'%S.CIM971A.CID971A:6PZ.G1I;65S7W)E9'5C93QB;V]S=#HZ;7!L M.CI?+&)O;W-T.CIM<&PZ.FUA=&@Z.G)A=&EO;F%L7V,\:6YT+#$L,CX^/CHZ M='EP92QB;V]S=#HZ;7!L.CI?,CX^/CHZ<W1A=&4P+&)O;W-T.CIM<&PZ.F1E M<F5F/&)O;W-T.CIM<&PZ.F%U>#HZ:71E<E]F;VQD7VEF7VYU;&Q?<W1E<#QB M;V]S=#HZ;7!L.CII=&5R7V9O;&1?:68\8F]O<W0Z.FUP;#HZ=F5C=&]R/&)O M;W-T.CIP<7,Z.F%U>#HZ;VYE+&)O;W-T.CIP<7,Z.F%U>#HZ>F5R;RQB;V]S M=#HZ<'%S.CIA=7@Z.GIE<F\L8F]O<W0Z.G!Q<SHZ875X.CIZ97)O+&)O;W-T M.CIP<7,Z.F%U>#HZ>F5R;RQB;V]S=#HZ<'%S.CIA=7@Z.GIE<F\L8F]O<W0Z M.G!Q<SHZ875X.CIZ97)O/BQV;VED+&)O;W-T.CIM<&PZ.F%R9SPQ/BQB;V]S M=#HZ;7!L.CIP<F]T96-T/&)O;W-T.CIM<&PZ.F%U>#HZ9FEN9%]I9E]P<F5D M/&)O;W-T.CIM<&PZ.FYO=%]E<75A;%]T;SQB;V]S=#HZ;7!L.CI?,2QB;V]S M=#HZ;7!L.CII;G1?/# ^/CX^/CHZ9FER<W1?+'9O:60^.CII=&5R871O<CXZ M.G1Y<&4^.CIA,BQB;V]S=#HZ;7!L.CIA=7@Z.F9O;&1?:6UP;#PT+&)O;W-T M.CIM<&PZ.F)E9VEN/&)O;W-T.CIM<&PZ.G9E8W1O<CQB;V]S=#HZ<'%S.CIA M=7@Z.F]N92QB;V]S=#HZ<'%S.CIA=7@Z.GIE<F\L8F]O<W0Z.G!Q<SHZ875X M.CIZ97)O+&)O;W-T.CIP<7,Z.F%U>#HZ>F5R;RQB;V]S=#HZ<'%S.CIA=7@Z M.GIE<F\L8F]O<W0Z.G!Q<SHZ875X.CIZ97)O+&)O;W-T.CIP<7,Z.F%U>#HZ M>F5R;SX^.CIT>7!E+&)O;W-T.CIM<&PZ.F5N9#QB;V]S=#HZ;7!L.CIV96-T M;W(\8F]O<W0Z.G!Q<SHZ875X.CIO;F4L8F]O<W0Z.G!Q<SHZ875X.CIZ97)O M+&)O;W-T.CIP<7,Z.F%U>#HZ>F5R;RQB;V]S=#HZ<'%S.CIA=7@Z.GIE<F\L M8F]O<W0Z.G!Q<SHZ875X.CIZ97)O+&)O;W-T.CIP<7,Z.F%U>#HZ>F5R;RQB M;V]S=#HZ<'%S.CIA=7@Z.GIE<F\^/CHZ='EP92QB;V]S=#HZ;7!L.CII;G-E M<G1E<CQB;V]S=#HZ;7!L.CIC;&5A<E]I;7!L/&)O;W-T.CIM<&PZ.F%U>#HZ M<V5Q=65N8V5?=&%G7VEM<&P\=')U92QT<G5E/CHZ<F5S=6QT,E\\8F]O<W0Z M.FUP;#HZ=F5C=&]R/&)O;W-T.CIP<7,Z.F%U>#HZ;VYE+&)O;W-T.CIP<7,Z M.F%U>#HZ>F5R;RQB;V]S=#HZ<'%S.CIA=7@Z.GIE<F\L8F]O<W0Z.G!Q<SHZ M875X.CIZ97)O+&)O;W-T.CIP<7,Z.F%U>#HZ>F5R;RQB;V]S=#HZ<'%S.CIA M=7@Z.GIE<F\L8F]O<W0Z.G!Q<SHZ875X.CIZ97)O/CXZ.G1Y<&4^.CIA<'!L M>3QB;V]S=#HZ<'%S.CIM971A.CIA8G-T<F%C=%]Q=6%N=&ET>3QB;V]S=#HZ M;7!L.CIV96-T;W(\8F]O<W0Z.G!Q<SHZ875X.CIO;F4L8F]O<W0Z.G!Q<SHZ M875X.CIZ97)O+&)O;W-T.CIP<7,Z.F%U>#HZ>F5R;RQB;V]S=#HZ<'%S.CIA M=7@Z.GIE<F\L8F]O<W0Z.G!Q<SHZ875X.CIZ97)O+&)O;W-T.CIP<7,Z.F%U M>#HZ>F5R;RQB;V]S=#HZ<'%S.CIA=7@Z.GIE<F\^+&)O;W-T.CIM<&PZ.FEN M=%\\,3X^.CID:6UE;G-I;VX^.CIT>7!E+&)O;W-T.CIM<&PZ.G!U<VA?8F%C M:SQB;V]S=#HZ;7!L.CIN82QB;V]S=#HZ;7!L.CIN83X^.CIS=&%T92QB;V]S M=#HZ;7!L.CIB:6YD,CQB;V]S=#HZ;7!L.CIL86UB9&$\8F]O<W0Z.FUP;#HZ M:6YS97)T97(\8F]O<W0Z.FUP;#HZ8VQE87)?:6UP;#QB;V]S=#HZ;7!L.CIA M=7@Z.G-E<75E;F-E7W1A9U]I;7!L/'1R=64L=')U93XZ.G)E<W5L=#)?/ T* M8F]O<W0Z.FUP;#HZ=F5C=&]R/&)O;W-T.CIP<7,Z.F%U>#HZ;VYE+&)O;W-T M.CIP<7,Z.F%U>#HZ>F5R;RQB;V]S=#HZ<'%S.CIA=7@Z.GIE<F\L8F]O<W0Z M.G!Q<SHZ875X.CIZ97)O+&)O;W-T.CIP<7,Z.F%U>#HZ>F5R;RQB;V]S=#HZ M<'%S.CIA=7@Z.GIE<F\L8F]O<W0Z.G!Q<SHZ875X.CIZ97)O/CXZ.G1Y<&4^ M.CIA<'!L>3QB;V]S=#HZ<'%S.CIM971A.CIA8G-T<F%C=%]Q=6%N=&ET>3QB M;V]S=#HZ;7!L.CIV96-T;W(\8F]O<W0Z.G!Q<SHZ875X.CIO;F4L8F]O<W0Z M.G!Q<SHZ875X.CIZ97)O+&)O;W-T.CIP<7,Z.F%U>#HZ>F5R;RQB;V]S=#HZ M<'%S.CIA=7@Z.GIE<F\L8F]O<W0Z.G!Q<SHZ875X.CIZ97)O+&)O;W-T.CIP M<7,Z.F%U>#HZ>F5R;RQB;V]S=#HZ<'%S.CIA=7@Z.GIE<F\^+&)O;W-T.CIM M<&PZ.FEN=%\\,3X^.CID:6UE;G-I;VX^.CIT>7!E+&)O;W-T.CIM<&PZ.G!U M<VA?8F%C:SQB;V]S=#HZ;7!L.CIN82QB;V]S=#HZ;7!L.CIN83X^.CIO<&5R M871I;VX^.CIT>7!E+&)O;W-T.CIM<&PZ.E\Q+&)O;W-T.CIM<&PZ.F)I;F0Q M/&)O;W-T.CIM<&PZ.FQA;6)D83QB;V]S=#HZ<'%S.CIM971A.CID971A:6PZ M.G1I;65S7W)E9'5C93QB;V]S=#HZ;7!L.CI?+&)O;W-T.CIM<&PZ.FUA=&@Z M.G)A=&EO;F%L7V,\:6YT+#$L,CX^/CHZ='EP92QB;V]S=#HZ;7!L.CI?,CX^ M/CHZ<W1A=&4P+&)O;W-T.CIM<&PZ.F1E<F5F/&)O;W-T.CIM<&PZ.F%U>#HZ M:71E<E]F;VQD7VEF7VYU;&Q?<W1E<#QB;V]S=#HZ;7!L.CII=&5R7V9O;&1? M:68\8F]O<W0Z.FUP;#HZ=F5C=&]R/&)O;W-T.CIP<7,Z.F%U>#HZ;VYE+&)O M;W-T.CIP<7,Z.F%U>#HZ>F5R;RQB;V]S=#HZ<'%S.CIA=7@Z.GIE<F\L8F]O M<W0Z.G!Q<SHZ875X.CIZ97)O+&)O;W-T.CIP<7,Z.F%U>#HZ>F5R;RQB;V]S M=#HZ<'%S.CIA=7@Z.GIE<F\L8F]O<W0Z.G!Q<SHZ875X.CIZ97)O/BQV;VED M+&)O;W-T.CIM<&PZ.F%R9SPQ/BQB;V]S=#HZ;7!L.CIP<F]T96-T/&)O;W-T M.CIM<&PZ.F%U>#HZ9FEN9%]I9E]P<F5D/&)O;W-T.CIM<&PZ.FYO=%]E<75A M;%]T;SQB;V]S=#HZ;7!L.CI?,2QB;V]S=#HZ;7!L.CII;G1?/# ^/CX^/CHZ M9FER<W1?+'9O:60^.CII=&5R871O<CXZ.G1Y<&4L8F]O<W0Z.FUP;#HZ;F$L M8F]O<W0Z.FUP;#HZ;F$L8F]O<W0Z.FUP;#HZ;F$^.CIT>7!E/CHZ:71E;3 L M8F]O<W0Z.FUP;#HZ875X.CIR97-O;'9E7V)I;F1?87)G/&)O;W-T.CIM<&PZ M.F)I;F0R/&)O;W-T.CIM<&PZ.FQA;6)D83QB;V]S=#HZ;7!L.CII;G-E<G1E M<CQB;V]S=#HZ;7!L.CIC;&5A<E]I;7!L/&)O;W-T.CIM<&PZ.F%U>#HZ<V5Q M=65N8V5?=&%G7VEM<&P\=')U92QT<G5E/CHZ<F5S=6QT,E\\8F]O<W0Z.FUP M;#HZ=F5C=&]R/&)O;W-T.CIP<7,Z.F%U>#HZ;VYE+&)O;W-T.CIP<7,Z.F%U M>#HZ>F5R;RQB;V]S=#HZ<'%S.CIA=7@Z.GIE<F\L8F]O<W0Z.G!Q<SHZ875X M.CIZ97)O+&)O;W-T.CIP<7,Z.F%U>#HZ>F5R;RQB;V]S=#HZ<'%S.CIA=7@Z M.GIE<F\L8F]O<W0Z.G!Q<SHZ875X.CIZ97)O/CXZ.G1Y<&4^.CIA<'!L>3QB M;V]S=#HZ<'%S.CIM971A.CIA8G-T<F%C=%]Q=6%N=&ET>3QB;V]S=#HZ;7!L M.CIV96-T;W(\8F]O<W0Z.G!Q<SHZ875X.CIO;F4L8F]O<W0Z.G!Q<SHZ875X M.CIZ97)O+&)O;W-T.CIP<7,Z.F%U>#HZ>F5R;RQB;V]S=#HZ<'%S.CIA=7@Z M.GIE<F\L8F]O<W0Z.G!Q<SHZ875X.CIZ97)O+&)O;W-T.CIP<7,Z.F%U>#HZ M>F5R;RQB;V]S=#HZ<'%S.CIA=7@Z.GIE<F\^+&)O;W-T.CIM<&PZ.FEN=%\\ M,3X^.CID:6UE;G-I;VX^.CIT>7!E+&)O;W-T.CIM<&PZ.G!U<VA?8F%C:SQB M;V]S=#HZ;7!L.CIN82QB;V]S=#HZ;7!L.CIN83X^.CIO<&5R871I;VX^.CIT M>7!E+&)O;W-T.CIM<&PZ.E\Q+&)O;W-T.CIM<&PZ.F)I;F0Q/&)O;W-T.CIM M<&PZ.FQA;6)D83QB;V]S=#HZ<'%S.CIM971A.CID971A:6PZ.G1I;65S7W)E M9'5C93QB;V]S=#HZ;7!L.CI?+&)O;W-T.CIM<&PZ.FUA=&@Z.G)A=&EO;F%L M7V,\:6YT+#$L,CX^/CHZ='EP92QB;V]S=#HZ;7!L.CI?,CX^.CIA<'!L>3QB M;V]S=#HZ;7!L.CIA=7@Z.F9O;&1?:6T-"G!L/#0L8F]O<W0Z.FUP;#HZ8F5G M:6X\8F]O<W0Z.FUP;#HZ=F5C=&]R/&)O;W-T.CIP<7,Z.F%U>#HZ;VYE+&)O M;W-T.CIP<7,Z.F%U>#HZ>F5R;RQB;V]S=#HZ<'%S.CIA=7@Z.GIE<F\L8F]O M<W0Z.G!Q<SHZ875X.CIZ97)O+&)O;W-T.CIP<7,Z.F%U>#HZ>F5R;RQB;V]S M=#HZ<'%S.CIA=7@Z.GIE<F\L8F]O<W0Z.G!Q<SHZ875X.CIZ97)O/CXZ.G1Y M<&4L8F]O<W0Z.FUP;#HZ96YD/&)O;W-T.CIM<&PZ.G9E8W1O<CQB;V]S=#HZ M<'%S.CIA=7@Z.F]N92QB;V]S=#HZ<'%S.CIA=7@Z.GIE<F\L8F]O<W0Z.G!Q M<SHZ875X.CIZ97)O+&)O;W-T.CIP<7,Z.F%U>#HZ>F5R;RQB;V]S=#HZ<'%S M.CIA=7@Z.GIE<F\L8F]O<W0Z.G!Q<SHZ875X.CIZ97)O+&)O;W-T.CIP<7,Z M.F%U>#HZ>F5R;SX^.CIT>7!E+&)O;W-T.CIM<&PZ.FEN<V5R=&5R/&)O;W-T M.CIM<&PZ.F-L96%R7VEM<&P\8F]O<W0Z.FUP;#HZ875X.CIS97%U96YC95]T M86=?:6UP;#QT<G5E+'1R=64^.CIR97-U;'0R7SQB;V]S=#HZ;7!L.CIV96-T M;W(\8F]O<W0Z.G!Q<SHZ875X.CIO;F4L8F]O<W0Z.G!Q<SHZ875X.CIZ97)O M+&)O;W-T.CIP<7,Z.F%U>#HZ>F5R;RQB;V]S=#HZ<'%S.CIA=7@Z.GIE<F\L M8F]O<W0Z.G!Q<SHZ875X.CIZ97)O+&)O;W-T.CIP<7,Z.F%U>#HZ>F5R;RQB M;V]S=#HZ<'%S.CIA=7@Z.GIE<F\^/CHZ='EP93XZ.F%P<&QY/&)O;W-T.CIP M<7,Z.FUE=&$Z.F%B<W1R86-T7W%U86YT:71Y/&)O;W-T.CIM<&PZ.G9E8W1O M<CQB;V]S=#HZ<'%S.CIA=7@Z.F]N92QB;V]S=#HZ<'%S.CIA=7@Z.GIE<F\L M8F]O<W0Z.G!Q<SHZ875X.CIZ97)O+&)O;W-T.CIP<7,Z.F%U>#HZ>F5R;RQB M;V]S=#HZ<'%S.CIA=7@Z.GIE<F\L8F]O<W0Z.G!Q<SHZ875X.CIZ97)O+&)O M;W-T.CIP<7,Z.F%U>#HZ>F5R;SXL8F]O<W0Z.FUP;#HZ:6YT7SPQ/CXZ.F1I M;65N<VEO;CXZ.G1Y<&4L8F]O<W0Z.FUP;#HZ<'5S:%]B86-K/&)O;W-T.CIM M<&PZ.FYA+&)O;W-T.CIM<&PZ.FYA/CXZ.G-T871E+&)O;W-T.CIM<&PZ.F)I M;F0R/&)O;W-T.CIM<&PZ.FQA;6)D83QB;V]S=#HZ;7!L.CII;G-E<G1E<CQB M;V]S=#HZ;7!L.CIC;&5A<E]I;7!L/&)O;W-T.CIM<&PZ.F%U>#HZ<V5Q=65N M8V5?=&%G7VEM<&P\=')U92QT<G5E/CHZ<F5S=6QT,E\\8F]O<W0Z.FUP;#HZ M=F5C=&]R/&)O;W-T.CIP<7,Z.F%U>#HZ;VYE+&)O;W-T.CIP<7,Z.F%U>#HZ M>F5R;RQB;V]S=#HZ<'%S.CIA=7@Z.GIE<F\L8F]O<W0Z.G!Q<SHZ875X.CIZ M97)O+&)O;W-T.CIP<7,Z.F%U>#HZ>F5R;RQB;V]S=#HZ<'%S.CIA=7@Z.GIE M<F\L8F]O<W0Z.G!Q<SHZ875X.CIZ97)O/CXZ.G1Y<&4^.CIA<'!L>3QB;V]S M=#HZ<'%S.CIM971A.CIA8G-T<F%C=%]Q=6%N=&ET>3QB;V]S=#HZ;7!L.CIV M96-T;W(\8F]O<W0Z.G!Q<SHZ875X.CIO;F4L8F]O<W0Z.G!Q<SHZ875X.CIZ M97)O+&)O;W-T.CIP<7,Z.F%U>#HZ>F5R;RQB;V]S=#HZ<'%S.CIA=7@Z.GIE M<F\L8F]O<W0Z.G!Q<SHZ875X.CIZ97)O+&)O;W-T.CIP<7,Z.F%U>#HZ>F5R M;RQB;V]S=#HZ<'%S.CIA=7@Z.GIE<F\^+&)O;W-T.CIM<&PZ.FEN=%\\,3X^ M.CID:6UE;G-I;VX^.CIT>7!E+&)O;W-T.CIM<&PZ.G!U<VA?8F%C:SQB;V]S M=#HZ;7!L.CIN82QB;V]S=#HZ;7!L.CIN83X^.CIO<&5R871I;VX^.CIT>7!E M+&)O;W-T.CIM<&PZ.E\Q+&)O;W-T.CIM<&PZ.F)I;F0Q/&)O;W-T.CIM<&PZ M.FQA;6)D83QB;V]S=#HZ<'%S.CIM971A.CID971A:6PZ.G1I;65S7W)E9'5C M93QB;V]S=#HZ;7!L.CI?+&)O;W-T.CIM<&PZ.FUA=&@Z.G)A=&EO;F%L7V,\ M:6YT+#$L,CX^/CHZ='EP92QB;V]S=#HZ;7!L.CI?,CX^/CHZ<W1A=&4Q+&)O M;W-T.CIM<&PZ.F1E<F5F/&)O;W-T.CIM<&PZ.F%U>#HZ:71E<E]F;VQD7VEF M7V9O<G=A<F1?<W1E<#QB;V]S=#HZ;7!L.CIA=7@Z.FET97)?9F]L9%]I9E]N M=6QL7W-T97 \8F]O<W0Z.FUP;#HZ875X.CIE<75A;%]I;7!L/&)O;W-T.CIM M<&PZ.G9E8W1O<CQB;V]S=#HZ<'%S.CIA=7@Z.F]N92QB;V]S=#HZ<'%S.CIA <=7@Z.GIE<F\L8F]O<W0Z.G!Q<SHZ875X.CH-"@`` ` end
Hi Andy,
Small sample enclosed.( Let me know if you want a bigger portion.) .
Thanks, this one is fine -- no bigger portion is needed. I looked at it this mornimg at home, and decided to deal with it at work. Unfortunately, my work mail client has removed the attachement as unsafe (how the txt file can be considered unsafe -- I have no idea). Futhermore, when using the web interface, the attachment appears at the end of the message, but is unreadable. So I will look at it later, when back home. Regards, Arkadiy
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote
Small sample enclosed.( Let me know if you want a bigger portion.) .
c:\boost\boost_1_33_0\boost\typeof\encode_decode.hpp(24) : error C2504: 'boost::type_of::`anonymous-namespace'::encode_type_impl<V,Type_Not_Register ed_With_Typeof_System>' : base class undefined with [ V=[...], Type_Not_Registered_With_Typeof_System=boost::mpl::vector6<... ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This complain about mpl::vector6 not registered. Regards, Arkadiy
"Arkadiy Vertleyb" wrote in message
"Andy Little" wrote
Small sample enclosed.( Let me know if you want a bigger portion.) .
c:\boost\boost_1_33_0\boost\typeof\encode_decode.hpp(24) : error C2504: 'boost::type_of::`anonymous-namespace'::encode_type_impl<V,Type_Not_Register ed_With_Typeof_System>' : base class undefined with [ V=[...], Type_Not_Registered_With_Typeof_System=boost::mpl::vector6<... ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This complain about mpl::vector6 not registered.
That is true , but the error message is not correct. In my typeof registration I have registered vector6 with Typeof. This is not the registration that is lacking. I guess that VC7.1 goes off the rails somewhere close by but, fact is that the error message is pointing to the wrong place on this occasion. FWIW I dont really see this as a problem for Typeof, which does provide good diagnostics in simpler cases. I am just pointing out that, when the error-checking is not helping as in the above case, then an alternative approach is to use Typeid to find out what types your type is made up of. This is particularly useful with e.g. mpl both because types are likely to be complicated and because its not always possible to know the exact mpl type your type is made of. regards Andy little
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote
"Arkadiy Vertleyb" wrote in message
"Andy Little" wrote
Small sample enclosed.( Let me know if you want a bigger portion.) .
c:\boost\boost_1_33_0\boost\typeof\encode_decode.hpp(24) : error C2504:
'boost::type_of::`anonymous-namespace'::encode_type_impl<V,Type_Not_Register
ed_With_Typeof_System>' : base class undefined with [ V=[...],
Type_Not_Registered_With_Typeof_System=boost::mpl::vector6<...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This complain about mpl::vector6 not registered.
That is true , but the error message is not correct. In my typeof registration I have registered vector6 with Typeof. This is not the registration that is lacking. I guess that VC7.1 goes off the rails somewhere close by but, fact is that the error message is pointing to the wrong place on this occasion.
I am puzzled... Is it possible for you to send me the source code that causes the problem?
FWIW I dont really see this as a problem for Typeof, which does provide good diagnostics in simpler cases. I am just pointing out that, when the error-checking is not helping as in the above case, then an alternative approach is to use Typeid to find out what types your type is made up of. This is particularly useful with e.g. mpl both because types are likely to be complicated and because its not always possible to know the exact mpl type your type is made of.
I am not arguing against using typeid, and I'll see how to add this to documentation... I just want to figure out why the diagnostic is not correct. It puzzles me, because vc71 is my primary compiler, and I never noticed this problem before. Regards, Arkadiy
Hi Arkadiy, "Arkadiy Vertleyb" wrote
I am puzzled... Is it possible for you to send me the source code that causes the problem?
I uploaded the current work on pqs for boost into the vault . It is in 'Physical Quantites Units' subdirectory under the name 'pqs_3_0_0.zip'. Note that it depends on 'mpl_math.zip' also, for boost::mpl::math::rational et al. Note Well! ... I had to modify <boost/mpl/aux_/has_type.hpp> to get the tests to compile in boost_1_33_0. Not tried in later versions The modified version of has_type.hpp, is in the "boost/ mpl.aux_" directory in this package. Thanks to Terje Slettebø for the has_member_type functionality used to sort this out. To reproduce the error in my previous posts: In <boost/pqs/config.hpp> uncomment #define BOOST_TYPEOF_COMPLIANT near end of file In <boost/pqs/typeof_register.hpp> comment out BOOST_TYPEOF_REGISTER_TEMPLATE(boost::mpl::math::simplified_rational, 2); Then compile <libs/test/t1_quantity.cpp> Of course It might be best to compile as is first , just to check the library compiles Ok! (Only tested in VC7.1 so far) FWIW theres a vcproj in "libs/pqs/test/visualcpp/" regards Andy Little
"Arkadiy Vertleyb" <vertleyb@hotmail.com> wrote
I will try to implement such registrations for mpl::vector[n], as an example. However, I think it's ultimately up to the library authors do decide whether or not to make their libraries typeof-enabled (I would be happy to provide any help on the subject).
Here it is (tested only with vc71, BOOST_TYPEOF_COMPLIANT mode). I will have to add one macro to the typeof lib (marked in the source below): ============================ #define BOOST_TYPEOF_COMPLIANT #include <boost/typeof/typeof.hpp> #include <boost/mpl/vector.hpp> // this is to be added to the typeof lib #define BOOST_TYPEOF_REGISTER_TEMPLATE_EXPLICIT_ID(Name, Params, Id)\ BOOST_TYPEOF_REGISTER_TEMPLATE_IMPL(\ Name,\ BOOST_TYPEOF_MAKE_OBJS(BOOST_TYPEOF_TOSEQ(Params)),\ BOOST_PP_SEQ_SIZE(BOOST_TYPEOF_TOSEQ(Params)),\ Id) ////////////////// #define REGISTER_ONE(z, n, Group)\ BOOST_TYPEOF_REGISTER_TEMPLATE_EXPLICIT_ID(\ boost::mpl::vector, n, Group + n - 1) #define REGISTER_ONE_NUMBERED(z, n, Group)\ BOOST_TYPEOF_REGISTER_TEMPLATE_EXPLICIT_ID(\ boost::mpl::vector ## n, n, Group + n - 1) #include BOOST_TYPEOF_INCREMENT_REGISTRATION_GROUP() // to minimize the size of encoding vector, // register with every possible number of parameters (0 - 10) BOOST_TYPEOF_REGISTER_TYPE(boost::mpl::vector<>) BOOST_PP_REPEAT_FROM_TO(1, 10, REGISTER_ONE, BOOST_TYPEOF_UNIQUE_ID()) // since we registered more than one template in one line, // UNIQUE_ID is no longer valid with this registration group #include BOOST_TYPEOF_INCREMENT_REGISTRATION_GROUP() BOOST_TYPEOF_REGISTER_TYPE(boost::mpl::vector0<>) BOOST_PP_REPEAT_FROM_TO(1, 10, REGISTER_ONE_NUMBERED, BOOST_TYPEOF_UNIQUE_ID()) int main() { boost::mpl::vector1<boost::mpl::vector<int, boost::mpl::vector0<> > > v; typedef BOOST_TYPEOF(v) v_type; return 0; }
"Arkadiy Vertleyb" <vertleyb@hotmail.com> wrote in message news:dof2en$6r4$1@sea.gmane.org...
"Arkadiy Vertleyb" <vertleyb@hotmail.com> wrote
I will try to implement such registrations for mpl::vector[n], as an example. However, I think it's ultimately up to the library authors do decide whether or not to make their libraries typeof-enabled (I would be happy to provide any help on the subject).
Here it is (tested only with vc71, BOOST_TYPEOF_COMPLIANT mode). I will have to add one macro to the typeof lib (marked in the source below):
Thats great! Question is now, where to put this in boost directory tree and what to call it. regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote
"Arkadiy Vertleyb" <vertleyb@hotmail.com> wrote
I will try to implement such registrations for mpl::vector[n], as an example. However, I think it's ultimately up to the library authors do decide whether or not to make their libraries typeof-enabled (I would be happy to provide any help on the subject).
Here it is (tested only with vc71, BOOST_TYPEOF_COMPLIANT mode). I will have to add one macro to the typeof lib (marked in the source below):
Thats great!
Question is now, where to put this in boost directory tree and what to call it.
And the answer is: nowhere for now :) Because I can't code it properly without relying on internal details of MPL. Note I registered templates up to vector10<>. But only Aleksey knows how many of them should be registered, and under which circumstances. This is related to BOOST_MPL_LIMIT_VECTOR size, and which headers are actually included, such as vector30.hpp or vector40.hpp... So this is just an _example_ of what to do on the typeof part. What to do on MPL part -- I can only guess. That's why I think such registrations should be ultimately maintained by the library authors. Regards, Arkadiy
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
Hi,
Regarding using Typeof with compile time libraries such as mpl. mpl doesnt ...
http://www.boost.org/more/discussion_policy.htm#quoting. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (11)
-
Andy Little -
Arkadiy Vertleyb -
Cromwell Enage -
David Abrahams -
Deane Yang -
Jeff Garland -
Keith Nicewarner -
Manfred Doudar -
Matt Calabrese -
Paul A Bristow -
Rene Rivera