Re: [boost] Boost Units library preview
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Ben Strasser Sent: Friday, September 01, 2006 9:15 AM To: boost@lists.boost.org Subject: Re: [boost] Boost Units library preview
I'm having a serious problem with facets and if I don't find a solution for it facets are definately out of the game.
Several unit types can describe the same unit. For example unit<quantity<length, 1, mass, 1> > is the same as unit<quantity<mass, 1, length, 1> > but when it comes to types they are different.
Why do you use the word 'unit' in these examples? I don't see any units in there. A unit is a standard of measure. A meter is a unit. Mass and length are dimensions.
The unit code can cope with this. facets on the other hand requier an exact type to be able to use unit specific facets.
I only see 3 possible solutions:
1) Add a facet for each permutation of the base quantities (= length & time_ here). This is only acceptable for small quantities because the number of combinations grows too fast. Also I don't like the idea of spamming the locale objects full.
2) Make the quantity lists sortable and only look up the sorted versions in the locale objects. The problem is that for this I need some smaller-as meta function to define the order. Unfortuately I have no idea on how to generate a default one (typeid unfortuately only return runtime objects).
If you look at the proposed Boost Units library, the base dimensions are implemented in such a way (with a rank) that allows them to be normalized (e.g. sorted). Eric.
Eric Lemings <lemings <at> roguewave.com> writes:
unit<quantity<length, 1, mass, 1> > unit<quantity<mass, 1, length, 1> >
Why do you use the word 'unit' in these examples? I don't see any units in there. A unit is a standard of measure. A meter is a unit. Mass and length are dimensions.
The first template parameter describes the quantity that is measured and the second parameter controls how many of that quantity. If the second one is omitted then it is assumed that there is only one way (used) to measure that quantity.
After a multi-year hiatus, the continued discussion on the boost mailing list regarding dimensional analysis and units/quantities, the recent review and rejection of Andy Little's Quan library, and a certain compulsive masochistic need to work on tangential projects at odd intervals has inspired me to dust off the old code and add a significant amount of documentation elucidating the design and implementation of my take on the units issue. For better or worse, Andy and I have significant differences in the way we have approached this problem and, it seems, in our desires/requirements for such a library. The library code that has been uploaded to the Units folder in the vault as mcs_units.zip is a somewhat revamped version of what was previously known as YAnL (Yet Another units Library), now mcs::units. In a testament to the design and stability of MPL, essentially no changes were needed in the metaprogramming code that deals with dimension lists. However, compilation times seem much better, probably because the compiler makers have been catching on to the value of MPL and metaprogramming techniques. In any case, I'd be delighted to get any concrete, constructive input on design, implementation, performance and any other relevant issues. I'm hoping that we're converging by iteration here, and not stuck in a limit cycle...
unit<quantity<length, 1, mass, 1> > unit<quantity<mass, 1, length, 1> >
Why do you use the word 'unit' in these examples? I don't see any units in there. A unit is a standard of measure. A meter is a unit. Mass and length are dimensions. The first template parameter describes the quantity that is measured and the second parameter controls how many of that quantity. If the second one is omitted then it is assumed that there is only one way (used) to measure that quantity.
I address this issue by representing single dimensions as a pair of a unit tag and a static_rational exponent. The tag type provides an ordinal value that can be used for compile time sorting of the full type list for composite dimensions. The code that does this is primarily in dimension_tag.hpp and dimension.hpp; documentation is in the usual place. Cheers, Matthias ---------------------------------------------------------------- Matthias Schabel, Ph.D. Assistant Professor, Department of Radiology Utah Center for Advanced Imaging Research 729 Arapeen Drive Salt Lake City, UT 84108 801-587-9413 (work) 801-585-3592 (fax) 801-706-5760 (cell) 801-484-0811 (home) matthias dot schabel at hsc dot utah dot edu ----------------------------------------------------------------
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Matthias Schabel | Sent: 04 September 2006 06:45 | To: boost@lists.boost.org | Subject: Re: [boost] Boost Units library preview | | After a multi-year hiatus, it is good to see this interesting proposal refined and documented. 1 It would be helpful to avoid having to build everything to see the output. So it would be nice to have sample output appended as a long comment /* Output is: ..... */ (For those using MSVC, I find that Gennediy's suggestion in Boost.Test is most helpful: For Microsoft IDE, add to the project configuration properties a Build Events, Post-BuildEvent, Command line: "$(TargetDir)$(TargetName).exe" Description: Autorun "$(TargetDir)$(TargetName).exe" This means you can simply copy and post from the Output Windows onto the .cpp demo file. (and also perhaps individual outputs as inline comments cout << length << endl; // "2.0 m") 3 A quick failed attempt to build suggests that the folder /utility is missing? 4 I also note the license is not Boost - this would of course be essential, but hopefully only requires some editing. 5 Meantime I am RTFM ;-) Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
Hi Paul,
| After a multi-year hiatus,
it is good to see this interesting proposal refined and documented.
Thanks for the support - I think we'd all like to have a functional units library. The Darwinian model for open source obviously works best when there's some competition...
1 It would be helpful to avoid having to build everything to see the output.
So it would be nice to have sample output appended as a long comment
I've added comments with the expected output to the end of the source files.
3 A quick failed attempt to build suggests that the folder /utility is missing?
Sorry - everything but unit_example_1.cpp should compile as is. I was including a utility header that demangles gcc typenames to make them somewhat more readable. I'm attaching a fixed version of unit_example_1.cpp and a new header utility.hpp to be put in the mcs/units directory that factors out the demangling code. Demangling only works on gcc at this point, FYI.
4 I also note the license is not Boost - this would of course be essential, but hopefully only requires some editing.
Naturally, if and when we get to the point where that matters, I'm happy to change it.
5 Meantime I am RTFM ;-)
Fixes are in the Vault - I've also separated out the files into documentation and source to let me update them separately. Please keep the feedback coming... Cheers, Matthias
Paul A Bristow wrote:
3 A quick failed attempt to build suggests that the folder /utility is missing?
I also cannot build the tests. There are at least two problems: 1) The #include directives inside the test code assume that the directory "units" is inside a directory called "mcs". So I created the directory "mcs" and moved "units" into it. 2) There is at least one #include directive that refers to the directory "mcs/utility", and it tries to include a header file called "type_traits.hpp", which is a file that I do not see in the distribution.
I also cannot build the tests. There are at least two problems:
1) The #include directives inside the test code assume that the directory "units" is inside a directory called "mcs". So I created the directory "mcs" and moved "units" into it.
Right - believe it or not, this is included in the main page of the documentation, in the "Installation" section...
2) There is at least one #include directive that refers to the directory "mcs/utility", and it tries to include a header file called "type_traits.hpp", which is a file that I do not see in the distribution.
This is fixed by the two files I attached in the previous message - in any case, I believe the only dependency on <mcs/utility/type_traits.hpp> is in unit_test_1.cpp, so the other four tests should work... Keep it coming... M
Matthias Schabel wrote:
I also cannot build the tests. There are at least two problems:
1) The #include directives inside the test code assume that the directory "units" is inside a directory called "mcs". So I created the directory "mcs" and moved "units" into it.
Right - believe it or not, this is included in the main page of the documentation, in the "Installation" section...
I didn't see that. But wouldn't it make sense for you to just distribute everything with units already inside a directory called "mcs"?
2) There is at least one #include directive that refers to the directory "mcs/utility", and it tries to include a header file called "type_traits.hpp", which is a file that I do not see in the distribution.
This is fixed by the two files I attached in the previous message - in any case, I believe the only dependency on <mcs/utility/type_traits.hpp> is in unit_test_1.cpp, so the other four tests should work...
Not. unit_test_4.cpp and unit_test_5.cpp have the same dependency. Other observations: 1) unit_test_1.cpp depends on the boost.regex library. (Some of us have never built the boost.regex library. My solution is just to skip unit_test_1.cpp for now.) 2) The unit tests appear to build using gcc 3.4.4, but not with VC8.0. I get the following: unit_example_2.cpp C:\Program Files\Microsoft Visual Studio 8\VC\INCLUDE\iterator(589) : error C2872: 'size_t' : ambiguous symbol could be 'predefined C++ types (compiler internal)(19) : unsigned int size_t' or '..\..\..\..\boost\boost/mpl/aux_/integral_wrapper.hpp(81) : boost::mpl::size_t' C:\Program Files\Microsoft Visual Studio 8\VC\INCLUDE\iterator(730) : see reference to class template instantiation 'stdext::checked_array_iterator<_Iterator>' being compiled C:\Program Files\Microsoft Visual Studio 8\VC\INCLUDE\iterator(589) : error C2872: 'size_t' : ambiguous symbol could be 'predefined C++ types (compiler internal)(19) : unsigned int size_t' or '..\..\..\..\boost\boost/mpl/aux_/integral_wrapper.hpp(81) : boost::mpl::size_t' C:\Program Files\Microsoft Visual Studio 8\VC\INCLUDE\iterator(589) : error C2872: 'size_t' : ambiguous symbol could be 'predefined C++ types (compiler internal)(19) : unsigned int size_t' or '..\..\..\..\boost\boost/mpl/aux_/integral_wrapper.hpp(81) : boost::mpl::size_t' C:\Program Files\Microsoft Visual Studio 8\VC\INCLUDE\iterator(589) : error C2872: 'size_t' : ambiguous symbol could be 'predefined C++ types (compiler internal)(19) : unsigned int size_t' or '..\..\..\..\boost\boost/mpl/aux_/integral_wrapper.hpp(81) : boost::mpl::size_t' C:\Program Files\Microsoft Visual Studio 8\VC\INCLUDE\iterator(602) : error C2872: 'size_t' : ambiguous symbol could be 'predefined C++ types (compiler internal)(19) : unsigned int size_t' or '..\..\..\..\boost\boost/mpl/aux_/integral_wrapper.hpp(81) : boost::mpl::size_t' C:\Program Files\Microsoft Visual Studio 8\VC\INCLUDE\iterator(728) : error C2872: 'size_t' : ambiguous symbol could be 'predefined C++ types (compiler internal)(19) : unsigned int size_t' or '..\..\..\..\boost\boost/mpl/aux_/integral_wrapper.hpp(81) : boost::mpl::size_t' C:\Program Files\Microsoft Visual Studio 8\VC\INCLUDE\iterator(729) : error C2872: 'size_t' : ambiguous symbol could be 'predefined C++ types (compiler internal)(19) : unsigned int size_t' or '..\..\..\..\boost\boost/mpl/aux_/integral_wrapper.hpp(81) : boost::mpl::size_t'
I also cannot build the tests. There are at least two problems:
1) The #include directives inside the test code assume that the directory "units" is inside a directory called "mcs". So I created the directory "mcs" and moved "units" into it.
Right - believe it or not, this is included in the main page of the documentation, in the "Installation" section...
I didn't see that. But wouldn't it make sense for you to just distribute everything with units already inside a directory called "mcs"?
OK, this is done in the new mcs_units archive.
2) There is at least one #include directive that refers to the directory "mcs/utility", and it tries to include a header file called "type_traits.hpp", which is a file that I do not see in the distribution.
This is fixed by the two files I attached in the previous message - in any case, I believe the only dependency on <mcs/utility/type_traits.hpp> is in unit_test_1.cpp, so the other four tests should work...
Not. unit_test_4.cpp and unit_test_5.cpp have the same dependency.
These files didn't actually depend on the header anyway, but it has been fixed.
Other observations: 1) unit_test_1.cpp depends on the boost.regex library. (Some of us have never built the boost.regex library. My solution is just to skip unit_test_1.cpp for now.)
If you don't #define MCS_USE_DEMANGLING, this should not happen now. Code outputting typename information will then just output the mangled name instead (typeid(var).name()), which is not super helpful, generally speaking...
2) The unit tests appear to build using gcc 3.4.4, but not with VC8.0. I get the following:
unit_example_2.cpp C:\Program Files\Microsoft Visual Studio 8\VC\INCLUDE\iterator(589) : error C2872: 'size_t' : ambiguous symbol could be 'predefined C++ types (compiler internal)(19) : unsigned int size_t' or '..\..\..\..\boost\boost/mpl/aux_/integral_wrapper.hpp (81) : boost::mpl::size_t'
This looks like a symbol collision caused because I had a "using namespace boost::mpl;" at the top of the dimension.hpp file. I moved this inside the boost::units scope - maybe that will help. I'd rather not have to explicitly specify the namespace for every MPL call as that will make the code hard to read, but if this problem is not easy to work around on VC++, I may have to do it anyway... Thanks for the input - M
Matthias Schabel wrote:
I didn't see that. But wouldn't it make sense for you to just distribute everything with units already inside a directory called "mcs"?
OK, this is done in the new mcs_units archive.
Thank you.
I believe the only dependency on <mcs/utility/type_traits.hpp> is in unit_test_1.cpp, so the other four tests should work... Not. unit_test_4.cpp and unit_test_5.cpp have the same dependency.
These files didn't actually depend on the header anyway, but it has been fixed.
Yes. Thank you.
Other observations: 1) unit_test_1.cpp depends on the boost.regex library. (Some of us have never built the boost.regex library. My solution is just to skip unit_test_1.cpp for now.)
If you don't #define MCS_USE_DEMANGLING, this should not happen now.
I am not #defining MCS_USE_DEMANGLING, but VC++8.0 tries to link to the boost regex library. Can this be fixed?
2) The unit tests appear to build using gcc 3.4.4, but not with VC8.0.
The latest version of the examples builds and runs with VC8.0 (except unit_example_1, because I have not tried to build the boost regex library). In many ways your library looks nice, but I need to check out Ben's more carefully too.
Other observations: 1) unit_test_1.cpp depends on the boost.regex library. (Some of us have never built the boost.regex library. My solution is just to skip unit_test_1.cpp for now.)
If you don't #define MCS_USE_DEMANGLING, this should not happen now.
I am not #defining MCS_USE_DEMANGLING, but VC++8.0 tries to link to the boost regex library. Can this be fixed?
Sorry - I should have been more clear; I inserted a #define MCS_USE_DEMANGLING in unit_test_1.cpp. If you comment it out, that should eliminate the boost::regex dependency... N.B. if you look too closely at this example, there are a couple of errors - not in the code, but in the type definitions...missing a minus sign in the time dimension of energy...I'll have them fixed in the next release, which will also eliminate the demangling option unless you're using g++. Also, for the next release I'll have a version that allows arbitrary binary operations between quantities (limited, of course, by the operations supported by the underlying value_type) that deduces return type using typeof. That is, for some arbitrary value types X and Y for which (warning pseudocode ahead) Z operator+(X x,Y y) is defined quantity<Z> operator+(quantity<X> x,quantity<Y> y) will work and behave as expected... Currently this feature will only work on gcc or other compilers that have already implemented typeof, but I'm hoping that it will just be ignored on other platforms as long as the code doesn't actually call operators with two different types, assuming I've written the type conversion helpers right... Eventually I'll look into Boost.Typeof, if there's enough interest. For the most part, this feature is probably just a curiosity for the average programmer, but it's a good test and allows more interesting algebras to be associated with units...my demo code (mostly functional except for power<N>/root<N>) is for a scaled value type (something like Andy Little does internally) that carries with the value type a base/exponent pair, so you could write values in scientific notation like this : 5.67 x 10^7 -> scaled_value<float,scale<10,7> >(5.67) svalue; Here, if you multiply this by itself, you get a new type: svalue*svalue -> scaled_value<float,scale<10,14> >(5.67*5.67) It's amusing and might actually be useful...
2) The unit tests appear to build using gcc 3.4.4, but not with VC8.0.
The latest version of the examples builds and runs with VC8.0 (except unit_example_1, because I have not tried to build the boost regex library).
That's good news - I don't have a Windows box, so I can't check this myself...
In many ways your library looks nice, but I need to check out Ben's more carefully too.
Thanks. In all honesty, I would be happy to collaborate on this with others who are interested and have a compatible paradigm - I don't really have much experience dealing with issues such as IO facets, etc..., and there are a number of issues surrounding IO and serialization that probably need to be thought about and addressed. Obviously, because units are defined at compile time input will be restricted to cases where the type is known anyway, so it doesn't seem like there's really much point in parsing unit input (for this library - clearly, a runtime units library would want to do that...). Anyway, I appreciate the feedback... Matthias
Matthias Schabel wrote:
That is, for some arbitrary value types X and Y for which (warning pseudocode ahead)
Z operator+(X x,Y y)
is defined
quantity<Z> operator+(quantity<X> x,quantity<Y> y)
will work and behave as expected...
I need this feature!
That is, for some arbitrary value types X and Y for which (warning pseudocode ahead)
Z operator+(X x,Y y)
is defined
quantity<Z> operator+(quantity<X> x,quantity<Y> y)
will work and behave as expected...
I need this feature!
If you want to be at the bleeding edge, you can give it a try. I've uploaded this code as Vault/Units/mcs_units_hetero_op.zip. I think it should work on non-g++ compilers (but _without_ heterogenous operator functionality), but no guarantees. Everything except power<N> and root<N> seems to work for me. Try unit_example_6.cpp to get a feel for it... Cheers, Matthias
Deane, Paul, and any others who have had the time to play with the mcs::units code/documentation - In the hopes of getting some traction on a discussion of requirements for a boostified dimensional analysis/units library, do you have any comments on the interface/design/implementation/functionality. What features are missing that would be desirable? Are there other issues that should be addressed in the library. Is it worth expending the effort to prepare it for Boost review? Is the documentation adequate? What else would need to be done to get the library Boost ready (other then license changes)? Any input would be welcome. Matthias
That is, for some arbitrary value types X and Y for which (warning pseudocode ahead)
Z operator+(X x,Y y)
is defined
quantity<Z> operator+(quantity<X> x,quantity<Y> y)
will work and behave as expected...
I need this feature!
If you want to be at the bleeding edge, you can give it a try. I've uploaded this code as Vault/Units/mcs_units_hetero_op.zip. I think it should work on non-g++ compilers (but _without_ heterogenous operator functionality), but no guarantees. Everything except power<N> and root<N> seems to work for me. Try unit_example_6.cpp to get a feel for it...
Cheers,
Matthias
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/ listinfo.cgi/boost
"Matthias Schabel" <boost@schabel-family.org> wrote
Deane, Paul, and any others who have had the time to play with the mcs::units code/documentation -
What features are missing that would be desirable?
Most of the features in Quan... http://quan.sourceforge.net/quan_matters/doc/html/index.html regards Andy
"Matthias Schabel" <boost@schabel-family.org> wrote in message news:7B1005D5-BA60-42B6-A7CC-BA885445B56A@schabel-family.org...
Deane, Paul, and any others who have had the time to play with the mcs::units code/documentation -
In the hopes of getting some traction on a discussion of requirements for a boostified dimensional analysis/units library, do you have any comments on the interface/design/implementation/functionality. What features are missing that would be desirable? Are there other issues that should be addressed in the library. Is it worth expending the effort to prepare it for Boost review?
Yes. It uses MPL so thta's all you need really. Go for it. regards Andy Little
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Matthias Schabel | Sent: 13 September 2006 20:49 | To: boost@lists.boost.org | Subject: Re: [boost] Boost Units feedback | | Deane, Paul, and any others who have had the time to play with the | mcs::units code/documentation - | | In the hopes of getting some traction on a discussion of | requirements | for a boostified dimensional analysis/units library, do you | have any | comments on the interface/design/implementation/functionality. What | features are missing that would be desirable? Are there | other issues | that should be addressed in the library. Is it worth expending the | effort to prepare it for Boost review? Is the documentation | adequate? | What else would need to be done to get the library Boost | ready (other | then license changes)? | | Any input would be welcome. I'm sorry I have been away and haven't been able to reply to this before. I'm also sorry that I really haven't got a grip on the relevant merits of the various attempts at the units and dimensions problem, nor do I see having time or neurons enough to do so. All that I am certain is that it is they really important nuts to crack with enormous practical utility and benefit. The detailed requirements are difficult to agree, let alone define. For me, just getting the SI units (and dimension checking) to work would be a massive step forward. But there are others who live in a different time-sapce continuum ;-) making mission creep difficult to avoid. I see a chicken and egg problem - what is really needed is a group of real-life users, preferably in a reasonable range of problem domains, but not necessarily including relativistic ones, who are happy that it meets their requirements. But until it is a Boost library, they are reluctant to even try it. So I am sorry that I can't give you anything but encouragement to keep working. For me, it is many more examples and users that would sell it. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
"Paul A Bristow" <pbristow@hetp.u-net.com> wrote in message news:E1GPJQl-0005uW-2D@he304war.uk.vianw.net...
The detailed requirements are difficult to agree, let alone define. For me, just getting the SI units (and dimension checking) to work would be a massive step forward.
I am now starting to find this attitude of publicly ignoring my work, especially while many of the *Units* efforts are privately borrowing ideas from it downright offensive. http://www.sourceforge.net/projects/quan regards Andy Little
Andy Little wrote:
I am now starting to find this attitude of publicly ignoring my work, especially while many of the *Units* efforts are privately borrowing ideas from it downright offensive.
I just want to make clear to everyone that I am currently publicly ignoring *all* dimension/units/quantity libraries, because, as always, I am overwhelmed by other things. I can't speak to the "privately borrowing" since I have no Units effort of my own.
"Deane Yang" <deane_yang@yahoo.com> wrote in message news:eemc7q$h24$1@sea.gmane.org...
Andy Little wrote:
I am now starting to find this attitude of publicly ignoring my work, especially while many of the *Units* efforts are privately borrowing ideas from it downright offensive.
I just want to make clear to everyone that I am currently publicly ignoring *all* dimension/units/quantity libraries, because, as always, I am overwhelmed by other things.
Well, I am certainly not ignoring the issue. The primitives (IOW fixed_quantity) in Quan are working very nively thankyou very much. As for non physical units, the only one touted so far is money, but as I repeat **again** money isnt a physical quantity. AFAICS money is a numeric after all money ^2 is just more money ain't it, and that can be plugged in very easily thankyou very much ( for a similar quasi-numeric type see the angles in Quan), though perhaps it's more fun to just gas about it... And Quan is well on the way to having some matrix classes, for matrices of arbitrary dimensions and with a useful level of optimisation. Using fusion it is possible to make matrices of arbitrary dimensions and so one can implement vectors( tuples) as 1 x N matrices (row vectors) or N *1 vectors ( column vectors) using the same scheme, which means they will automatically be compatible and type safe with the matrices. http://www.sourceforge.net/projects/quan The serious solution for type safe physical quantities in C++. regards Andy Little
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Andy Little | Sent: 18 September 2006 15:48 | To: boost@lists.boost.org | Subject: Re: [boost] Boost Units feedback | | I am now starting to find this attitude of publicly ignoring | my work, especially | while many of the *Units* efforts are privately borrowing | ideas from it downright offensive. | | http://www.sourceforge.net/projects/quan | | regards | Andy Little I'm very sorry that you found this offensive - it wasn't intended - and you may remember that I supported your proposal at the recent review. I was only saying that I personally didn't feel the essential requirements should not be set too high. Your considerable and commendable efforts on this project meet the same chicken and egg problem - I feel that you haven't yet got a reasonably representative base of reasonably contented users - and I suspect that an important reason for this is that it isn't a Boost library yet. How to solve this conundrum, I just don't know. Another important difficulty is lack of agreement over the scope of the project(s), as recent long discussions have shown. Nor the compile time cost that can be endured. I wish your project well, hope you get lots more real-life users, and I trust that others will take care to acknowledge your substantial contribution. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
"Paul A Bristow" <pbristow@hetp.u-net.com> wrote in message news:E1GPLYr-0004OO-3Z@he304war.uk.vianw.net...
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Andy Little | Sent: 18 September 2006 15:48 | To: boost@lists.boost.org | Subject: Re: [boost] Boost Units feedback | | I am now starting to find this attitude of publicly ignoring | my work, especially | while many of the *Units* efforts are privately borrowing | ideas from it downright offensive. | | http://www.sourceforge.net/projects/quan | | regards | Andy Little
I'm very sorry that you found this offensive - it wasn't intended - and you may remember that I supported your proposal at the recent review. I was only saying that I personally didn't feel the essential requirements should not be set too high.
Your considerable and commendable efforts on this project meet the same chicken and egg problem - I feel that you haven't yet got a reasonably representative base of reasonably contented users - and I suspect that an important reason for this is that it isn't a Boost library yet. How to solve this conundrum, I just don't know.
To be honest I am not expecting a huge number of contented users just now. Firstly and most importantly Quan is as stated in the docs only in Alpha status and there is a big warning that the library isnt yet intended to be stable. There has been a huge interface change between version 01 and version 02. I was somewhat reluctant to do as I know that users won't appreciate it. PQS in the past had way too many interface changes too. Secondly the Quan mailing list is knackered, always has been and I suspect always will be. At some stage I hope to move the project off sourceforge. Anyway if you are using that as a popularity guage then don't bother. Recently I think most download have been CVS, but again the stats for that are as they always have been and I guess always will be "currently unavailable". I'm sorry to say that I think that somebody *important* for whatever reason just doesnt want my library in Boost, and so the above just now sounds to me is just the next reason that is being touted as a way to keep it out. OTOH there is a need for something like Quan, but nothing in the Units directory yet comes close to Quan. (I would be very happy if anything did...)
Another important difficulty is lack of agreement over the scope of the project(s), as recent long discussions have shown. Nor the compile time cost that can be endured.
Obviously that second remark re compile time is not from actual experience of downloading and trying out my library, and that Really annoys me! Please make judgements about Quan based on testing , not on myths or the compile time performance of other Units libraries. regards Andy Little
Making progress - got example1 to work, but needed #if defined (_MSC_VER) # pragma warning(push) # pragma warning(disable: 4100) // 'source' : unreferenced formal parameter #endif to avoid a blizzard of warning messages. I suspect you could avoid this by putting comments around source thus: /* source */ which leaves it documented but not unused. Might be helpful to enable demangling only if gcc? (Doubt if Borland is up to the mpl part?) Example 2 still doesn't work (as noted by Deane). Do you need a using boost::mpl::size_t;? to resolve the ambiguity? Or some using namespace boost::mpl; inside functions? Haven't delved into this - angels fear to tread ;-) Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
Making progress - got example1 to work, but needed
#if defined (_MSC_VER) # pragma warning(push) # pragma warning(disable: 4100) // 'source' : unreferenced formal parameter #endif
to avoid a blizzard of warning messages.
As I mentioned earlier, I don't have access to a current Visual C++ compiler, but I'm happy to add relevant warning suppressing #pragmas...sounds like it doesn't like me naming arguments in template declarations...
Might be helpful to enable demangling only if gcc? (Doubt if Borland is up to the mpl part?)
I've put two preprocessor switches in the utility.hpp header that should allow you to have more fine-grained control over the use of and method for demangling : if the source file has a #define MCS_USE_DEMANGLING, the standard C++ ABI demangler is used, while #define MCS_USE_BOOST_REGEX_DEMANGLING uses both the standard demangler and boost.regex to clean up the resulting mpl typenames to make them a bit easier to read. In any case, this stuff is probably only interested to people who are interested in the guts of the dim analysis code, since it is all hidden by the unit/quantity classes... Anyway, you can replace the utility.hpp header in mcs/units with the attached one, then comment out the #define at the top of unit_example_1.hpp to eliminate demangling completely. Does anyone know if GCC is the only compiler to support demangling? If it is, I will just put all the demangling stuff inside the #ifdef __GNUC__ as Paul suggests...
Example 2 still doesn't work (as noted by Deane).
Deane's last post indicated that he now had all tests running...am I wrong, Deane?
Do you need a using boost::mpl::size_t;? to resolve the ambiguity?
I think it's the opposite problem - the cxxabi.h header has a bunch of references to size_t that aren't qualified with std::. Anyway, I think the problem went away (again, per Deane) when I moved my using namespace boost::mpl; inside the boost::units namespace. Again, please correct me if I'm wrong... Thanks for the input. Matthias
Matthias Schabel wrote:
Making progress - got example1 to work, but needed
#if defined (_MSC_VER) # pragma warning(push) # pragma warning(disable: 4100) // 'source' : unreferenced formal parameter #endif
to avoid a blizzard of warning messages.
I'm impressed. Example 1 is the only one I can't get to work.
Example 2 still doesn't work (as noted by Deane).
Deane's last post indicated that he now had all tests running...am I wrong, Deane?
No. You're right. I've got all examples except #1 working.
I think it's the opposite problem - the cxxabi.h header has a bunch of references to size_t that aren't qualified with std::. Anyway, I think the problem went away (again, per Deane) when I moved my using namespace boost::mpl; inside the boost::units namespace. Again, please correct me if I'm wrong...
Again, that's right. The problem disappeared in the latest version. Deane
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Matthias Schabel | Sent: 05 September 2006 19:04 | To: boost@lists.boost.org | Subject: Re: [boost] Boost Units library preview | | > Making progress - got example1 to work, but needed | > | > #if defined (_MSC_VER) | > # pragma warning(push) | > # pragma warning(disable: 4100) // 'source' : | unreferenced formal | > parameter | > #endif | > | > to avoid a blizzard of warning messages. | | As I mentioned earlier, I don't have access to a current Visual C++ | compiler, but I'm happy to add relevant warning suppressing | #pragmas...sounds like it doesn't like me naming arguments in | template declarations... Yes, somehwat annoyingly, but easily cured by commenting it out /* source */ (or deleting, but then the helpful documentation is lost, so not my preference). A Minor isse but a minor thing to cure. | > Do you need a using boost::mpl::size_t;? to resolve the ambiguity? | | I think it's the opposite problem - the cxxabi.h header has a bunch | of references to size_t that aren't qualified with std::. Anyway, I | think the problem went away (again, per Deane) when I moved | my using | namespace boost::mpl; inside the boost::units namespace. Again, | please correct me if I'm wrong... John Maddock has used using namespace std; WITHIN the function scope to overcome what I think was the same widespread problem in math distributions with not finding pow in namespace std. However, I am on holiday for 10 days, so I can't test for you now. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
Matthias Schabel wrote:
After a multi-year hiatus, the continued discussion on the boost mailing list regarding dimensional analysis and units/quantities, the recent review and rejection of Andy Little's Quan library, and a certain compulsive masochistic need to work on tangential projects at odd intervals has inspired me to dust off the old code and add a significant amount of documentation elucidating the design and implementation of my take on the units issue.
Thank God for masochists!
Matthias Schabel <boost@schabel-family.org> writes:
However, compilation times seem much better, probably because the compiler makers have been catching on to the value of MPL and metaprogramming techniques.
Hmm, that sounds unlikely to me. When was your previous impression of the compilation time formed, and what compilers have you been using? -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (7)
-
Andy Little -
Ben Strasser -
David Abrahams -
Deane Yang -
Eric Lemings -
Matthias Schabel -
Paul A Bristow