March 2007 - Boost - lists.boost.org

[parameter] Lazy binding and operator|| patch
by Daniel Walker 06 Apr '07

06 Apr '07

Hello, Section 3.2.3 of the Boost Parameter Library documentation prescribes a remedy for lazy binding ArgumentPacks directly using the Boost Lambda Library. I encountered some compilation errors when attempting this. The following illustrates the problem. $ g++ -dumpversion 4.1.2 $ cat lazy_binding_errors.cpp #include <iostream> #include <string> #include <boost/lambda/lambda.hpp> #include <boost/parameter.hpp> using namespace boost; using namespace boost::parameter; BOOST_PARAMETER_NAME(s1) BOOST_PARAMETER_NAME(s2) BOOST_PARAMETER_NAME(s3) template <class ArgumentPack> std::string f(ArgumentPack const& args) { std::string const& s1 = args[_s1]; std::string const& s2 = args[_s2]; typename binding< ArgumentPack, tag::s3, std::string >::type s3 = args[_s3 || lambda::ret<std::string>( lambda::var(s1) + lambda::var(s2) ) ]; return s3; } int main() { std::string x = f((_s1="hello,", _s2=" world")); std::cout << x << std::endl; } $ g++ -I./boost lazy_binding_errors.cpp 2>&1 | perl gSTLFilt.pl ... lazy_binding_errors.cpp:24: error: no match for 'operator[]' in 'args[boost ::lambda::operator||( const boost::parameter::keyword<tag::s3> & , const boost::lambda::lambda_functor< ... > & ) ... $ The problem is that both parameter::keyword and the lambda expression have overloads of operator||. Since using lambda expressions in conjunction with parameter::keywords is an intended use case for Boost.Parameter, why not resolve the problem by providing an operator|| specifically for this case? template <class Tag, class Default> aux::lazy_default<Tag, lambda::lambda_functor<Default> > operator||(keyword<Tag> const& key, lambda::lambda_functor<Default> const& default_) { return key.operator||(default_); } The attached patch implements this. Apply with 'patch -p0 < djw_lazy_binding.patch' from the boost root directory. However, after the patch is applied the following errors occur. $ g++ -I./boost lazy_binding_errors.cpp 2>&1 | perl gSTLFilt.pl ... lazy_binding_errors.cpp:24: error: conversion from 'void' to non-scalar type 'string' requested ./boost/boost/parameter/aux_/arg_list.hpp:136: error: return-statement with a value, in function returning 'void' ... $ These errors happen because lazy binding ultimately depends on boost::result_of to deduce the type of the lambda expression, but boost::result_of doesn't handle lambda expressions. This issue can be resolved by applying the two patches I submitted previously. mpl patch: http://tinyurl.com/35x5z5 utility patch: http://tinyurl.com/2h3g7n These patches do not need to be applied in any particular order. Applying all three has the effect of making lazy binding behave more like the description in the documentation. I ran the Boost Parameter Library test suite and everything passed. Let me know if I've misunderstood something or if there's a better way to solve this problem or if you'd like additional documentation/tests. Thanks! Daniel Walker

3 11

[Review] Quantitative Units library review begins today, March 26
by John Phillips 05 Apr '07

05 Apr '07

The review for the Quantitative Units library, submitted by Matthias Schabel and Steven Watanabe begins today, March 26 and ends April 4. From the documentation: The Boost.Units library is a C++ implementation of zero runtime overhead compile-time dimensional analysis in a general and extensible manner, treating it as a generic metaprogramming problem. Support for units and quantities (defined as a unit and associated value) for arbitrary unit system models and arbitrary value types is provided, as is a general facility for unit conversions enabling fine-grained control over conversion. Complete SI and CGS unit system models are provided, along with systems for angles measured in degrees, gradians, and radians. A small subset of the SI system including only length, mass, and time is developed in the examples as a demonstration of the relative ease of adding new unit systems and the extensibility of the library architecture. In this review, the authors and I expect that there will be active discussions on two topics. In every review there is a discussion of the quality of the library implementation and documentation, and it is obviously expected and desired here. Also, since this library is specifically designed as a compile time library with no attempt to provide unit conversions or other runtime facilities it is expected that the review will include an active thread on whether this is the correct design decision. In specific, this is a different approach than that taken by Andy Little's submission of last year. Because some people will be more interested in one or another of these two discussions, I request that everyone clearly marks comment topics to show which they are discussing. This will also improve Matthias' and Steven's ability to respond usefully and my ability to produce review results and recommendations that accurately reflect the desires of the boost community. In general, please include the following in your review. Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. Here are some questions you might want to answer in your review: • What is your evaluation of the design? • What is your evaluation of the implementation? • What is your evaluation of the documentation? • What is your evaluation of the potential usefulness of the library? • Did you try to use the library? With what compiler? Did you have any problems? • How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? • Are you knowledgeable about the problem domain? And finally, every review should answer this question: • Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Review comments can be sent to the developer list, the user list, or directly to me if you don't wish to comment publicly. Thank you in advance for your time and work in this review. John Phillips Review Manager

8 17

[mpl] has_template_xxx patch
by Daniel Walker 05 Apr '07

05 Apr '07

Hello, I would like a Metafunction similar to the one created by BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF but that would detect nested template members rather than nested typedefs and classes. It would allow you to do something like the following: #include <utility> #include <boost/mpl/assert.hpp> #include <boost/mpl/has_template_xxx.hpp> #include <boost/utility/result_of.hpp> // Create has_template_result to detect nested members like // template<class T> struct result {}. // The first macro argument is the member name and the second argument // is the number of template parameters. BOOST_MPL_HAS_TEMPLATE_XXX_TRAIT_DEF(result, 1) struct pair_maker { template<typename F> struct result; template<typename F, typename Arg0, typename Arg1> struct result<F(Arg0, Arg1)> { typedef std::pair<Arg0, Arg1> type; }; template<typename Arg0, typename Arg1> typename result<pair_maker(Arg0, Arg1)>::type operator()(Arg0 a0, Arg1 a1) const { return std::make_pair(a0, a1); } }; int main() { using namespace boost; typedef char value_type; BOOST_MPL_ASSERT(( has_template_result< pair_maker, pair_maker(value_type, value_type) > )); typedef result_of< pair_maker(value_type, value_type) >::type result_type; value_type x, y; pair_maker f; result_type result = f(x, y); } The attached patch implements this. Apply with 'patch -p0 < djw_has_template.patch' from the boost root directory. It's based on the implementation of BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF and works basically the same way. The patch creates two files boost/mpl/has_template_xxx.hpp and boost/mpl/aux_/config/has_template_xxx.hpp. Similarly to has_xxx, when the maco BOOST_MPL_CFG_NO_HAS_TEMPLATE_XXX is defined the has_template_xxx::value is always false or a user supplied default. At this time, I'm unable to write all the various compiler workarounds that boost/mpl/has_xxx.hpp includes. BOOST_MPL_CFG_NO_HAS_TEMPLATE_XXX is defined for every workaround mentioned in boost/mpl/has_xxx.hpp. I've tested it with gcc 3.3, 3.4, 4.0, and 4.1 and it seems to work fine. If there's any interest, let me know and I'll supply documentation and tests. Thanks! Daniel Walker

7 22

units review
by Noah Roberts 03 Apr '07

03 Apr '07

What is your evaluation of the design? For a first iteration it's good. There is room for improvement but I think use needs to guide that. However, I feel that the library should use MPL standard operators instead of creating new ones. This has been discussed and deemed impossible but it is not. What is your evaluation of the implementation? It seems to be slower to compile than competitors by quite a margin. On the other hand, this library is more generic and can handle arbitrary dimensions. What is your evaluation of the documentation? More instruction on what constitutes a unit and quantity so that a developer may override these concepts and use them with the library. What is your evaluation of the potential usefulness of the library? It would be more useful with runtime conversions. I don't believe static conversions will be that useful. Did you try to use the library? I played with it, I did not use it in any real project. With what compiler? MSVC 8 and g++ Did you have any problems? With optimizations on full the library performed almost as well as a double. Next to 0 overhead but not quite. Without these optimizations it performed quite poorly, which could make debugging difficult. I could not find enough optimizations with the Microsoft compiler to make this library usable; 0 overhead was definitely not 0 overhead. Compilation overhead could be a bear for large projects. How much effort did you put into your evaluation? About 10 hours in which I tested various performance issues and tried to use it in various ways I need it to work. It performs moderately well but unless I can find the correct switches for the MS compiler it won't be useful to me. It also doesn't do everything I need and even after digging through the implementation I am not sure it will be useful or easy to even extend it. Are you knowledgeable about the problem domain? I do not work in a real time project where precision is of utmost importance; in fact we often round values. I work in fluid flow analysis, which is true scientific computing in the sense that it is a set of "close enough" guesses to predict the real world with a fairly high degree of certainty. This needs to be fast, so can't pay the expense of constant conversions, but doesn't have the same needs as some of the issues that have come up in discussion. Do you think the library should be accepted as a Boost library? I do not believe it meets the need of a wide enough audience, no.

4 13

[Attention] BBv2 Python Build Support
by David Abrahams 03 Apr '07

03 Apr '07

******************************************************************** *** The Boost release has been waiting on this; I would *really* *** *** appreciate it if people would take a little time to test it. *** ******************************************************************** I've just checked into the RC_1_34_0 branch most of the support for building and testing Python extensions and Boost.Python in BBv2. It took me over a week, and it's almost completely revamped. In case you're wondering, yes, it was necessary. Support for Windows, Darwin, and Cygwin was essentially nonexistent or broken. If it was working for you on any of these platforms, you were probably getting "lucky." I would appreciate it if those who can test this would invoke bjam with --debug-configuration, and look at the output to make sure the python configuration stuff looks sensible. Here's the new comment on python.init: # Initializes the Python toolset. Note that all parameters are # optional. # # - version -- the version of Python to use. Should be in Major.Minor # format, for example 2.3. Do not include the subminor version. # # - cmd-or-prefix: Preferably, a command that invokes a Python # interpreter. Alternatively, the installation prefix for Python # libraries and includes. If empty, will be guessed from the # version, the platform's installation patterns, and the python # executables that can be found in PATH. # # - includes: the include path to Python headers. If empty, will be # guessed. # # - libraries: the path to Python library binaries. If empty, will be # guessed. On MacOS/Darwin, you can also pass the path of the # Python framework. # # - condition: if specified, should be a set of properties that are # matched against the build configuration when Boost.Build selects a # Python configuration to use. # # Example usage: # # using python : 2.3 ; # using python : 2.3 : /usr/local/bin/python ; # You can set up your user-config.jam so a bjam built under Windows will can build/test both windows and cygwin python extensions. Just pass <target-os>cygwin in the "condition" parameter to "using python..." for the cygwin python installation. using python ; # windows installation using python : : /usr/bin/python2.5 : : : <target-os>cygwin ; when you put target-os=cygwin in your build request, it should build with the cygwin version of python: bjam target-os=cygwin toolset=gcc This is supposed to work the other way, too (targeting windows python with a cygwin bjam) but it seems as though the code in the compiler toolsets for building that way is broken (i.e., it's not a python-specific problem). What's still broken =================== 1. When targeting Cygwin, PYTHONPATH setup information is not properly passed from Python extension targets to test targets, because the information is getting attached to an import library (one we don't even need to generate) instead of the shared library. This affects one test (builtin_converters) in the Boost.Python test suite. We're waiting on Vladimir Prus to fix that one. I hope he'll be able to do that in the next few days. 2. There's no support for debug-python builds (the ones that require the trailing "_d" in the executable and extension module names -- see http://boost.org/libs/python/doc/building.html#variants) I think I can implement that tomorrow. If you got this far in the message, thank you *very* much for your attention :) -- Dave Abrahams Boost Consulting www.boost-consulting.com

5 9

Guid library
by Andy 03 Apr '07

03 Apr '07

I have uploaded a new version to the Boost Vault. It is now a header only library. It can be downloaded (guid_v6.zip) at: http://www.boost-consulting.com/vault/ or direct download link: http://www.boost-consulting.com/vault/index.php? action=downloadfile&filename=guid_v6.zip&directory=& Andy Tompkins

3 4

Re: [boost] [Review] Quantitative units - compile time vs runtime
by Martin Schulz 03 Apr '07

03 Apr '07

Hello everybody, my background is in software development for scientific and engineering computing, facing complex applications in industry. Therefore, I may take the opposite stand here. For fairness, I must add that I am somewhat from the competion, as I have started my own little (not yet upgrown) project in this area. Practically speaking, when developing such a technically minded piece of software, approximately 30% of the development effort goes into the computation kernel whereas the remaining 70% of the effort goes to the overall infrastructure, business layer, presentation layer (batch, gui, api,..), interoperability, productizing etc. It is sad to say, but such is life. The proposed solution is only targeted towards the compuation kernels. As a matter of fact, you have to ensure that the right things get in, and the right things get out there. What happens inside however is a completely different story. Once you know for sure what you got, you'll take a pencil and a piece of paper and you write down what you're going to implement. Once you are sure what you are doing, you go and implment it (using plain dimensionless floating point arithmetic). That worked well for over 50 years now. While a template-based solution might seem appealing and might even be applicable in some cases, there are many others where it is not: Consider for example solving an ordinary differential equation: A mechanical system described by locations and velocities, the excitation given by some forces depending on various factors. As long as you restrict yourself to explicit time integration, you may get around with type-encoded units. For implicit schemes, however, you will have to solve linear or nonlinear systems of equations, with various unknowns of different physical quantities (aka types) in a single vector (locations and velocities in the above case). This is not possible in C++ and thus the point where the approach by this library does no more hold. You can apply some fancy transforms beforehand to basically make all numbers dimensionless, but then you dont need a unit library anyway. Similar situations occur in all kind of fluid dynamics, finite difference, finite element codes, dynamic simulation codes and the like. I feel a far stronger need for a physical unit library in two other parts: Namely the business locgic and the presentation layer. A) The business logic is about intermediate storage of compuation results for the use by other parts of the software, probably written by other people, at other times, in other locations. Here you have to ensure that the units _really_ match in every possible case. And there are lots of cases possible. If they do not match, a conversion is usually acceptable, as it does not happen over and over again. We also talk about serialisation aspects here. Language dependend output (as suggested for future development in the documentation) to files is an absolute no-go: Otherwise the file saved by one engineer will not be able to get read by his collegue, only because they do not have the same language setting. Furthermore, many times, you do not know wile writing the software, what kind of quantity you actually handle. This is not so true for compuation kernels but more for backend storage that abstractly handles results of one computation over to some other computation, some postprocessing tools or the like. Nevertheless correct unit handling is indispensable. B) The presentation layer consists of everthing that is visible to the user, namely the GUI or the like. People in academics can hardly imagine what expectations engineers might have towards the units of their data. (Before entering industry, I was no exception to that rule :-) ) This is partly due to historical reasons; the choice of units in the presentation layer may vary by corporate guidelines, personal preference, professional background of the user or geographical location. If you want to get around with a single piece of code then, you cannot live with a fixed units for the quantities in your program. (The presentation layer, that is -- computation kernels are another story.) As another example, consider simply a nifty small graph plotting widget. Clearly enough, this widget must handle whatever unit may arrive. Furthermore, users may decide to add or multiply some channels or combine them by some other means. Therefore the arithmetic operations for units are necessary at the runtime of the program. All together, the library does not fit my need or those of my present or previous coworkers. As mentioned, there are severe obstacles for the application where it could be deployed and it does not help where the real problems are. In my opinion, it simply does not go far enough. Template-based solutions are known for many, many years by now (the book of Barton&Nackman is the oldest I personally know of) but have not been widely adopted until now. In my opinion, this is not so much due to the lack of compiler support but because the template-based approach can only be applied to some small portion to the issue, and thus can only be a minor (though not so unimportant) building block of a solution. I like the notion of a unitsystem as a mean of choice for the internal represenation of the quantities (and have already taken that idea to my own project). On the other hand: the length of my desk is a physical quantity that exists independently of the unit it is expressed in. The numerical value of that quantity is only fixed for a given unitsystem but this is an implementation detail, not a principal thought or definition. Thus I find the definition "A quantity is defined as a value of an arbitrary value type that is associated with a specific unit." somewhat irritating. Some more details: ------------------ The author mentiones the problem to distinguish the units for energy and torque. Both quantities result as a product of a length and a force but have completly different physical meanings. When reading the documentation, I got the impression that these two should be distinguishable somehow, but the author does not tell us of what type the product (2*meter)*(5*Newton) should actually be and how a compiler should tell the difference. I got the impression that the intent of the following code is not so obvious: quantity<force> F(2.0*newton); std::cout << "F = " << F << std::endl; The author states that the intent is obviously F = 2 m kg s^(-2); In contrast to the author, I personally would naturally expect something like: F = 2.0[N] This issue is not half as superficial as it might seem at first glance. In fact that is what the whole presentation layer stuff is all about. I have yet to see any stringend need for rational exponents. They rather obscure the physical meaning of certain terms, imho. To define all possible conversions of n unitsystems, you'll need about O(n*n) helper structs to be defined. I may be overlooking some more elaborated automatism, though. However, we are likely to face a larger number of unitsystems as already the conversion of "cm" in "m" requires different systems. The handling of temperatures (affine units in general) is correct but not very practical. The executive summary: ---------------------- * What is your evaluation of the design? I am strongly missing concepts that help to create additional functionality instead of "only" error avoidance. To me the semantics of quantities or units is not clear, and does not conform well with the one of the NIST (National Institute of Science and Technology: http://physics.nist.gov/cuu/Units/introduction.html) * What is your evaluation of the implementation? >From the technical aspects, this library looks probably good. My objections focus on the semantic level. * What is your evaluation of the documentation? The documentation looks very good, though the "quick start" and the following pages is too much about the internal implementation and not helpfull enough for those people that simply want to use the library. * What is your evaluation of the potential usefulness of the library? In the current form, it is no of direct use for me. I am sorry to say that. Basically it is what is was originally written for: "An example of generic programming for dimensional analysis for the Boost mailing list". It was not designed with focus on the problems of realistic large scale scientific and engineering C++-programming. Nevertheless I already took ideas from it. * Did you try to use the library? With what compiler? Did you have any problems? I briefly compiled some examples and tried to extend them. I had no technical difficulties using VC8. Rather had to struggle to find syntactically how I should do the things I wanted to. But that would be only a minor documentation issue. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I thouroughly read the documentation, thought deeply about it, and briefly played around with the implementation. * Are you knowledgeable about the problem domain? Yes, definitely. I am working on that topic for about 2 years now, analyzed our existing solutions, held meetings with different coworkers about the strengths and weaknesses of their existing solutions, evaluated some other existing libraries. Because all were unsatisfactory, I finally started to go for my own solution few months ago. * Do you think the library should be accepted as a Boost library? No, I dont think this library should be accepted as it is. I am sorry. I apologize as well for the lengthy mail, but I hope my requirements get clearer that way. Yours, Martin Schulz. -- Dr. Martin Schulz (schulz(a)synopsys.com) Software Engineer Sigma-C Software AG / Synopsys GmbH, Thomas-Dehler-Str.9, D-81737 Munich, Germany Phone: +49 (89) 630257-79, Fax: -49 http://www.synopsys.com

5 23

units: review
by Lewis Hyatt 02 Apr '07

02 Apr '07

-What is your evaluation of the design? It makes sense to me to have a rigid compile-time system for this, the design is simple and very intuitive. I was able to use the basic unit conversions without even reading the docs, and everything shows up just where you expect it. The library does require a lot of typing, but this is going to automatically go away once the auto keyword becomes standard. I do disagree with previous comments on the evilness of the mutating value() method. In particular, if the unit base is a user-defined type, then there is no other way for the user to access the contained object's member functions, so I don't see how you can get away without having value(). (As a reasonable example, you might want to use units with a boost::rational<int> data type, but without a mutating value(), you can't call boost::rational<int>::assign() anymore). I think this deficiency would cause people either to not use units, or to use a quantity<Q, boost::reference_wrapper<T> > instead, which is annoying and suffers from the same dangers anyway. Also, quantity<> should pass through operator++ and operator-- in addition to the other arithmetic operators. I was surprised to find that the prefixes kilo, mega, etc, are in namespace SI. They are equally useful for CGS and for user defined systems; perhaps they should be in a new namespace boost::units::prefix, since they are just static constants? Also, I was surprised that units/systems/si/prefixes.hpp was not included by units/systems/si.hpp, since I thought that was going to be a "catch-all" header. -What is your evaluation of the implementation? I didn't look in a lot of detail, enough to tell that there is good re-use of Boost metaprogramming libraries, etc, and the code seems easy to follow. It compiles in a reasonable amount of time. One thing I noticed is that the code does not use BOOST_STATIC_CONSTANT. Is this under the assumption that compilers which need BOOST_STATIC_CONSTANT won't compile the code anyway? That's probably correct I guess. I was surprised by the following behavior: #include <iostream> #include <boost/units/io.hpp> #include <boost/units/systems/si.hpp> #include <boost/units/systems/cgs.hpp> #include <boost/units/systems/si/prefixes.hpp> using namespace boost::units; int main() { quantity<CGS::force> F0 = 20 * CGS::dyne; quantity<SI::force> F1 = quantity_cast<SI::force>(F0); quantity<SI::force> F2 = quantity_cast<SI::force>(20 * CGS::dyne); quantity<SI::force> F3(F0); //quantity<SI::force> F4 = F0; //quantity<SI::force> F5(20 * CGS::dyne); //quantity<SI::force> F6 = 20 * CGS::dyne; std::cout << F1 << '\n' << F2 << '\n' << F3 << '\n'; } Firstly, I would have expected all 6 initializations of F1-F6 to do exactly the same thing. The last three do not compile at all, though. I think it is particularly surprising that there is a difference between F3 and F4. Most users are used to these two syntaxes being absolutely identical in meaning. I haven't looked at the implementation in detail, I'm just pointing out that this is a surprising feature. Also problematic is F2, which does compile, albeit with a warning, but then does the wrong thing at run time. The output of this program is: 1e-05 m kg s^(-2) 0 m kg s^(-2) 1e-05 m kg s^(-2) This appears to be related to the fact that in the initialization of F0, there is an implicit conversion from the int (20) to double. If I change the int to a double (20.) , then the code compiles without warnings and does the right thing. Similarly, changing the int to a double allows F5 to compile, but again, the equivalent-looking F6 does not. BTW, the warning issued by gcc is: ../../../boost/units/conversion.hpp: In static member function `static boost::units::quantity<boost::units::unit<Dim1, boost::units::homogeneous_system<S2> >, Y> boost::units::conversion_helper<boost::units::quantity<boost::units::unit<Dim1, boost::units::homogeneous_system<S> >, Y>, boost::units::quantity<boost::units::unit<Dim1, boost::units::homogeneous_system<S2> >, Y> >::convert(const boost::units::quantity<boost::units::unit<Dim1, boost::units::homogeneous_system<S> >, Y>&) [with S1 = boost::units::CGS::system_tag, S2 = boost::units::SI::system_tag, Dim1 = boost::units::force_type, Y = int]': ../../../boost/units/quantity.hpp:91: instantiated from `boost::units::quantity<Unit, Y>::quantity(const boost::units::quantity<boost::units::unit<Dim2, System2>, YY>&, typename boost::disable_if<typename boost::units::is_implicitly_convertible<boost::units::unit<Dim2, System2>, boost::units::unit<typename boost::units::get_dimension<T>::type, typename boost::units::get_system<T>::type> >::type, void>::type*) [with System2 = boost::units::CGS::system, Dim2 = boost::units::force_type, YY = int, Unit = boost::units::unit<boost::units::force_type, boost::units::SI::system>, Y = int]' ../../../boost/units/quantity.hpp:360: instantiated from `boost::units::quantity<boost::units::unit<Dim, System>, X> boost::units::quantity_cast_helper<boost::units::unit<Dim, System>, boost::units::quantity<Unit2, X> >::operator()(const boost::units::quantity<Unit2, X>&) [with X = int, System = boost::units::SI::system, Dim = boost::units::force_type, Unit2 = boost::units::unit<boost::units::force_type, boost::units::CGS::system>]' ../../../boost/units/quantity.hpp:378: instantiated from `typename boost::units::quantity_cast_helper<X, Y>::type boost::units::quantity_cast(const Y&) [with X = boost::units::SI::force, Y = boost::units::quantity<boost::units::unit<boost::units::force_type, boost::units::CGS::system>, int>]' t.cpp:14: instantiated from here ../../../boost/units/conversion.hpp:52: warning: passing `double' for converting 1 of `static boost::units::quantity<Unit, Y> boost::units::quantity<Unit, Y>::from_value(const Y&) [with Unit = boost::units::unit<boost::units::force_type, boost::units::SI::system>, Y = int]' -What is your evaluation of the documentation? The large number of examples is excellent. The documentation needs a lot more substance to it, particularly explaining surprising features of implicit conversions. -What is your evaluation of the potential usefulness of the library? I can see it being very useful. I myself am considering using it in the near future. One concern I have, is that I use a lot of C++ wrappers over legacy C libraries such as CLAPACK and ATLAS. I would still be able to use boost::units, provided I could count on sizeof(quantity<Q,T>) == sizeof(T), so that an array of quantitity<Q,T> would look the same in memory as an array of T. I doubt you would find any compiler where this is not the case, but it would be nice if the library could offer some sort of guarantee, since the standard doesn't, or at least comment on this issue in the docs. Another convenient option would be to put a static assert in the definition of quantity<> that the user could turn on via a #define if they want to be sure of this. -Did you try to use the library? With what compiler? Did you have any problems? The compile of cmath fails on gcc 3.4.4 on cygwin/MinGW and on gcc 3.4.6 on Linux because of undefined symbol __builtin_signbit in detail/cmath_gnu_impl.hpp line 195. This prohibits eg compilation of unit_example_11.cpp There are also a few source files missing terminating newlines, which produces a warning on some compilers. The library does not compile on earlier gcc versions as I mentioned in an earlier email, but this is not surprising. Other than cmath, the library compiled fine on gcc 3.4.{4,6} and 4.0.2. gcc 3.4.{4,6} was not able to optimize the runtime overhead entirely away. Without optimizations, the supplied timing example was about 10 times slower compared to the non-unit version. With optimization, it was only about 20% slower. On gcc 4.0.2, with optimization it was the same speed. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Played around with it for a couple hours, didn't put in a lot of time reading the actual implementation. -Are you knowledgeable about the problem domain? Yes, I am knowledgeable about units/dimensional analysis. - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Yes, I think this library is a good and useful example of compile-time programming, and it should be accepted. I do have some concerns about the implicit conversions and initialization issues, but I think they probably just stem from my lack of understanding of some implementation issues, which means that improved docs would probably suffice to take care of them. I do think the one issue I mentioned above (the combination of quantity_cast and a conversion from int to double producing incorrect runtime behavior) qualifies as a bug, perhaps compiler-specific? -Lewis

12 56

[Report] 67 regressions on RC_1_34_0 (2007-03-30)
by Douglas Gregor 02 Apr '07

02 Apr '07

Boost Regression test failures Report time: 2007-03-30T05:25:01Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… 67 failures in 2 libraries parameter (4) python (63) |parameter| python_test: gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.1_sunos_i86pc gcc-cygwin-3.4.4 |python| andreas_beyer: gcc-4.1.1_sunos_i86pc args: gcc-4.1.1_sunos_i86pc auto_ptr: gcc-4.1.1_sunos_i86pc back_reference: gcc-4.1.1_sunos_i86pc bases: gcc-4.1.1_sunos_i86pc ben_scott1: gcc-4.1.1_sunos_i86pc bienstman1: gcc-4.1.1_sunos_i86pc bienstman2: gcc-4.1.1_sunos_i86pc bienstman3: gcc-4.1.1_sunos_i86pc builtin_converters: gcc-4.1.1_sunos_i86pc callbacks: gcc-4.1.1_sunos_i86pc const_argument: gcc-4.1.1_sunos_i86pc crossmod_exception: gcc-4.1.1_sunos_i86pc crossmod_opaque: gcc-4.1.1_sunos_i86pc data_members: gcc-4.1.1_sunos_i86pc defaults: gcc-4.1.1_sunos_i86pc dict: gcc-4.1.1_sunos_i86pc docstring: gcc-4.1.1_sunos_i86pc enum: gcc-4.1.1_sunos_i86pc exception_translator: gcc-4.1.1_sunos_i86pc exec-dynamic: gcc-4.1.1_sunos_i86pc extract: gcc-4.1.1_sunos_i86pc implicit: gcc-4.1.1_sunos_i86pc injected: gcc-4.1.1_sunos_i86pc iterator: gcc-4.1.1_sunos_i86pc keywords: gcc-4.1.1_sunos_i86pc list: gcc-4.1.1_sunos_i86pc long: gcc-4.1.1_sunos_i86pc map_indexing_suite: gcc-4.1.1_sunos_i86pc minimal: gcc-4.1.1_sunos_i86pc multi_arg_constructor: gcc-4.1.1_sunos_i86pc nested: gcc-4.1.1_sunos_i86pc numpy: gcc-4.1.1_sunos_i86pc object: gcc-4.1.1_sunos_i86pc opaque: gcc-4.1.1_sunos_i86pc operators: gcc-4.1.1_sunos_i86pc pearu1: gcc-4.1.1_sunos_i86pc pickle1: gcc-4.1.1_sunos_i86pc pickle2: gcc-4.1.1_sunos_i86pc pickle3: gcc-4.1.1_sunos_i86pc pickle4: gcc-4.1.1_sunos_i86pc pointee: gcc-4.1.1_sunos_i86pc pointer_type_id_test: gcc-4.1.1_sunos_i86pc pointer_vector: gcc-4.1.1_sunos_i86pc polymorphism: gcc-4.1.1_sunos_i86pc polymorphism2: gcc-4.1.1_sunos_i86pc polymorphism2_auto_ptr: gcc-4.1.1_sunos_i86pc properties: gcc-4.1.1_sunos_i86pc raw_ctor: gcc-4.1.1_sunos_i86pc return_arg: gcc-4.1.1_sunos_i86pc shared_ptr: gcc-4.1.1_sunos_i86pc slice: gcc-4.1.1_sunos_i86pc staticmethod: gcc-4.1.1_sunos_i86pc stl_iterator: gcc-4.1.1_sunos_i86pc str: gcc-4.1.1_sunos_i86pc test_pointer_adoption: gcc-4.1.1_sunos_i86pc try: gcc-4.1.1_sunos_i86pc tuple: gcc-4.1.1_sunos_i86pc upcast: gcc-4.1.1_sunos_i86pc vector_indexing_suite: gcc-4.1.1_sunos_i86pc virtual_functions: gcc-4.1.1_sunos_i86pc voidptr: gcc-4.1.1_sunos_i86pc wrapper_held_type: gcc-4.1.1_sunos_i86pc

4 4

Boost Logging library
by JD 01 Apr '07

01 Apr '07

Hello, It's been a while since John Torjo remove his logging library from review. A logging library would be very useful and I was wondering if John plans to submit his library to review again or if someone else is working on another logging library for boost ? Jean-Daniel

4 4