- Boost - lists.boost.org

[preprocessor] Problem with Comeau 4.3.9 Beta
by Emil Dotchevski 06 Apr '07

06 Apr '07

There is a boost::function problem when building with Como 4.3.9 Beta. The problem is related to Boost Preprocessor, and the workaround I found is to -DBOOST_PP_CONFIG_FLAGS()=(BOOST_PP_CONFIG_EDG()). Emil Dotchevski

1 0

[filesystem] Problem with Comeau 4.3.9 Beta
by Emil Dotchevski 06 Apr '07

06 Apr '07

I get compile errors in path.cpp, std::mbstate_t is undefined. Adding #include <cwchar> at the top of path.cpp solves this problem. Emil Dotchevski

1 0

[Sorting] Old sorting library in sandbox
by Sam Schetterer 06 Apr '07

06 Apr '07

Hello. I just looked in sandbox, and saw that there is a project called linear_sort, by Herve Bronnimann. Before I continue development on my current sorting library, I would like to make sure that my library is not interfering with linear_sort.

2 1

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

05 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

[units] dimensionless specialization
by Matthias Schabel 05 Apr '07

05 Apr '07

Steven raised some good points about the dimensionless specializations of quantities. The crux of the problem is that sometimes we would like to be able to specify a formally dimensionless quantity as a heterogeneous quantity : e.g. 1.0*CGS::dyne/SI::newton. If we automatically convert, we lose the ability to represent quantities like this and all dimensionless quantities become equivalent. However, in some cases you would like to preserve the information on the unit system; for trig functions, as an example, you would like to have closure so that acos(cos(quantity<some_angular_unit,Y>)) returns the argument passed to cos. If system information is stripped, this becomes impossible without explicitly specifying the return type of acos. Furthermore, now we can't represent dimensionless quantities for which conversion factors haven't been defined. Now, if we preserve this capability, the system resulting from a dimensionless unit such as 1.5*CGS::dyne/SI::newton becomes ambiguous - should it be an SI dimensionless quantity or a CGS dimensionless quantity. So, even though it is a bit ugly, I think Steven is right that users will just need to explicitly cast heterogeneous dimensionless quantities to homogeneous ones which are well-defined and convertible to the underlying value_type... 1.0*CGS::dyne/SI::newton -> quantity< unit<dimensionless_type,[mixed CGS/SI system]> >, not convertible to double quantity<SI::dimensionless>(1.0*CGS::dyne/SI::newton) -> convertible to double At least this is consistent with the treatment of heterogeneous units (which will be better documented any time now...) throughout the remainder of the library... Matthias

2 4

units review
by Kevin Lynch 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. > I apologize to the authors and other reviewers in advance for not actively participating in the discussion over the review period, nor in providing as detailed a review report as I feel this submission deserves; project deadlines being what they are, however .... you know the drill. I'd also like to thank the authors for "diving into the breach" on this one; there has been no end of discussion on dimensional analysis and units over the last few years on the list. Many proposals have come and gone, with much heated discussion on their various merits. I commend them on their courage and fortitude in rising to the challenge. WHERE I'M COMING FROM ===================== My background is in theoretical and experimental particle physics. I have done extensive scientific simulation work, electronic data acquisition system design and implementation, software control systems and data analysis. I'm a "tight loop bit twiddler" ... one of the wackos that really needs zero-overhead, compile-time dimensional and unit analysis, because I can't afford a performance hit ... "reinterpret_cast is your friend, not your enemy". I would find the ability to define non-standard unit systems invaluable (I'm one of those "natural units for the problem" types ... CGS for E&M, solar mass/AU system for astrophysics, "hbar=c=1" for particle physics, etc). While I understand the usefulness to others of runtime conversions, they are not useful to my work. Likewise, I don't need anything beyond simple debugging output support, but again, I understand the potential usefulness to others of configurable unit IO support. To me, layout compatibility with the underlying fundamental type is quite useful. This is all just to say that I think the library _as described in the documentation_ is a good fit for my needs. That said, I think the library deserves to be reviewed in light of what it claims to be, not what we might want it to be. I do think it is reasonable to consider whether the library is "flexible" enough to support extensions that support those other needs. MY REVIEW ========= > What is your evaluation of the design? I really like the design. I think it comes as close to the standard domain notation as it is possible to get in compile time C++. The interface seems clean, and conversions between units and unit systems seem very nicely specified. The issues with pow<R> and root<R> are unfortunate, but that is a language shortcoming, not a library shortcoming. I'm not thrilled with the "quantity_cast" business, but my understanding from earlier mailing list discussion is that this corner of the library will see significant interface changes, so I won't belabor this issue. > What is your evaluation of the implementation? I fear that I have not given the implementation sufficient study to make useful comments. Although I note that my favorite CODATA constant (Fermi's constant) is missing ... that itself is nearly inexcusable :-) I did play with Example 14 (performance measurements) a bit. Fedora 6, g++ 4.1.1, Intel T7400. Unoptimized, the quantity versions run an order of magnitude more slowly than the double versions. With any optimization at all, there is no runtime difference, 2.6s, satisfying the zero overhead guarantee. > What is your evaluation of the documentation? Overall, it's very well done. I very much like the discussion of dimensional analysis ... it's clear, concise, and with the right level of mathematical sophistication. It beats the pants off the discussion in the BIPM's SI brochure, in substantially less space. I would like to see a warning on example 4 ... the presented "measurement error" type is insufficient for actual use in dealing with measurement errors, since it doesn't deal properly in correlations (quite a hard problem at compile time, I think): assuming x is a measurement<double>, with x.e the error, a correct error propagation would have (2x).e == (x+x).e == 2(x.e) whereas this class would get the addition wrong. Additionally, it is not well protected against internal overflow in the various arithmetic operation. But this isn't a review of "measurement<>", and it is overall still a nice toy example of the relevant library functionality and interface. I'm not sure that example 7 or 8 bring much more to the docs (not that there's really anything "wrong" with them, per se). They aren't "realistic", as they can't be used in production code, and no solutions to their drawbacks are presented. As toy examples, they are fine, but by this point in the documentation, there are already a number of excellent, clarifying toy examples. Even further, example 9 DOES show how to solve the drawbacks of example 8. Examples 14, 15 and 18 could use more discussion :-) Particularly example 14, since the results seem to be highly dependent on the quality of compiler optimizations. > What is your evaluation of the potential usefulness of the libray? I think it will be extremely useful to a broad group of users, particularly in scientific simulations. > Did you try to use the library? With what compiler? Did you have > any problems? Regrettably, not beyond building and compiling some of the examples. I have not had the opportunity to write any code of my own. But all of the examples compiled and ran as expected. > How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? A few hours study of the documentation and examples, and following of the discussion on the mailing list. I have done more in depth study of some of the alternative libraries (Walter Brown's SIunits and Andy Little's pqs); while those are both good libraries, I would be more likely to actually use the current library because the interface and flexibility suit my tastes better. > Are you knowledgeable about the problem domain? Yes. I'm involved in experiments that do precision measurement, and a good understanding of dimensional analysis, units, and the underlying standards based approaches to their measurement and definition are important to my work. > 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. I vote FOR acceptance. And I got my vote in this time before the review period ended in my time zone :-) -- ------------------------------------------------------------------------------- Kevin Lynch voice: (617) 353-6025 Physics Department Fax: (617) 353-9393 Boston University office: PRB-361 590 Commonwealth Ave. e-mail: krlynch(a)bu.edu Boston, MA 02215 USA http://budoe.bu.edu/~krlynch -------------------------------------------------------------------------------

6 9

Re: [boost] [system] Why is this not header-only?
by Alexander Nasonov 05 Apr '07

05 Apr '07

> I'd like to drop this custom class and instead use the ones provided > by the recently introduced Boost.System. However, Boost.System is a > binary library, while Boost.Process is currently a header-only > library. IIRC, someone asked recently why asio requires -lboost_system at link time. In my personal opinion, C++ wrappers for OS services should not be header-only. I would prefer asio, process, shmem and the like to be all consistent with boost.filesystem. Opinions? > Personally, I'd prefer to keep it that way if possible > because it is much easier to use it in third-party code. I don't think that we should follow masses and put everything in header files. There is an autolink on some systems, we could use this feature. The only problem is that people still "have to" follow an instruction for building those libraries. It would be interesting to take a big C++ project that depends on many boost libraries and consists of many shared libraries and analyze an overhead introduced by function defined in boost headers. I suspect many duplicates. -- Alexander Nasonov

19 42

[Boost-bugs] [ boost-Bugs-1695181 ] Duplicate target name bug on Cygwin
by SourceForge.net 05 Apr '07

05 Apr '07

Bugs item #1695181, was opened at 2007-04-05 11:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1695181&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: bjam Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Rene Rivera (grafik) Summary: Duplicate target name bug on Cygwin Initial Comment: CVS version checked out on Apr 5, 11:00AM EST. cygwin: 1.5.24(0.156/4/2) g++: 4.1.0 ran: $./configure --with-libraries=program_options $ ... <nothing interesting> $ make install ./tools/jam/src/bin.cygwinx86/bjam --user-config=user-config.jam --prefix=/usr/local --exec-prefix=/usr/local --libdir=/usr/local/lib --includedir=/usr/local/include --with-program_options install /boost/tools/build/v2/build/virtual-target.jam:996: in virtual-target.register-actual-name from module virtual-target error: Duplicate name of actual target: <p/usr/local/lib>exact.dll.a error: previous virtual target { common%common.hard-link-exact.dll.a.IMPORT_LIB { common%common.copy-boost_program_options-gcc41-mt-d-1_35.dll.a.IMPORT_LIB { gcc%gcc.link.dll-boost_program_options-gcc41-mt-d-1_35.dll.a.IMPORT_LIB { gcc%gcc.compile.c++-cmdline.o.OBJ { cmdline.cpp.CPP } } { gcc%gcc.compile.c++-config_file.o.OBJ { config_file.cpp.CPP } } { gcc%gcc.compile.c++-options_description.o.OBJ { options_description.cpp.CPP } } { gcc%gcc.compile.c++-parsers.o.OBJ { parsers.cpp.CPP } } { gcc%gcc.compile.c++-variables_map.o.OBJ { variables_map.cpp.CPP } } { gcc%gcc.compile.c++-value_semantic.o.OBJ { value_semantic.cpp.CPP } } { gcc%gcc.compile.c++-positional_options.o.OBJ { positional_options.cpp.CPP } } { gcc%gcc.compile.c++-utf8_codecvt_facet.o.OBJ { utf8_codecvt_facet.cpp.CPP } } { gcc%gcc.compile.c++-convert.o.OBJ { convert.cpp.CPP } } { gcc%gcc.compile.c++-winmain.o.OBJ { winmain.cpp.CPP } } } } } error: created from ./install-unversioned error: another virtual target { common%common.hard-link-exact.dll.a.IMPORT_LIB { common%common.copy-boost_program_options-gcc41-mt-1_35.dll.a.IMPORT_LIB { gcc%gcc.link.dll-boost_program_options-gcc41-mt-1_35.dll.a.IMPORT_LIB { gcc%gcc.compile.c++-cmdline.o.OBJ { cmdline.cpp.CPP } } { gcc%gcc.compile.c++-config_file.o.OBJ { config_file.cpp.CPP } } { gcc%gcc.compile.c++-options_description.o.OBJ { options_description.cpp.CPP } } { gcc%gcc.compile.c++-parsers.o.OBJ { parsers.cpp.CPP } } { gcc%gcc.compile.c++-variables_map.o.OBJ { variables_map.cpp.CPP } } { gcc%gcc.compile.c++-value_semantic.o.OBJ { value_semantic.cpp.CPP } } { gcc%gcc.compile.c++-positional_options.o.OBJ { positional_options.cpp.CPP } } { gcc%gcc.compile.c++-utf8_codecvt_facet.o.OBJ { utf8_codecvt_facet.cpp.CPP } } { gcc%gcc.compile.c++-convert.o.OBJ { convert.cpp.CPP } } { gcc%gcc.compile.c++-winmain.o.OBJ { winmain.cpp.CPP } } } } } error: created from ./install-unversioned error: added properties: <debug-symbols>off <define>NDEBUG <inlining>full <optimization>speed <runtime-debugging>off <variant>release error: removed properties: <debug-symbols>on <inlining>off <optimization>off <runtime-debugging>on <variant>debug /boost/tools/build/v2/build/virtual-target.jam:459: in actualize-no-scanner from module object(file-target)@27147 /boost/tools/build/v2/build/virtual-target.jam:111: in object(file-target)(a)27147.actualize from module object(file-target)@27147 /boost/tools/build/v2/build-system.jam:476: in load from module build-system /boost/tools/build/v2/kernel/modules.jam:261: in import from module modules /boost/tools/build/v2/kernel/bootstrap.jam:132: in boost-build from module /boost/boost-build.jam:9: in module scope from module ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1695181&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] [Units] Unique ordinal values (was Re: Review)
by Michael Fawcett 05 Apr '07

05 Apr '07

On 4/3/07, Steven Watanabe <steven(a)providere-consulting.com> wrote: > David Walthall <walthall <at> stanfordalumni.org> writes: > > > > The only complaint I have is that unique values of ordinal<N> have to be > > used. > > Nod. The only way to prevent collisions is to use > more bits and either guids or compile time strings > storing the fully qualified name. Matthias posted about this before and I can't remember the outcome. I was browsing some archived posts about Boost.Typeof and came across this: http://thread.gmane.org/gmane.comp.lib.boost.devel/101946/focus=102070 Would that be enough? Usage would look like: #include BOOST_UNITS_ORDINAL_GENERATOR() struct my_unit : ordinal<BOOST_UNITS_NEXT_ORDINAL> { }; Sorry if you guys have been over this ground before. --Michael Fawcett

4 5

Re: [boost] [units] runtime performance again
by Matthias Schabel 05 Apr '07

05 Apr '07

> I added numeric solution of a simple differential equation to the > benchmark. > > output from 3 runs: > > multiplying ublas::matrix<double>(1000, 1000) : 16.016 seconds > multiplying ublas::matrix<quantity>(1000, 1000) : 16.453 seconds > tiled_matrix_multiply<double>(1000, 1000) : 1.859 seconds > tiled_matrix_multiply<quantity>(1000, 1000) : 1.843 seconds > solving y' = 1 - x + 4 * y with double: 3.219 seconds > solving y' = 1 - x + 4 * y with quantity: 2.656 seconds > > multiplying ublas::matrix<double>(1000, 1000) : 16.281 seconds > multiplying ublas::matrix<quantity>(1000, 1000) : 16.406 seconds > tiled_matrix_multiply<double>(1000, 1000) : 1.906 seconds > tiled_matrix_multiply<quantity>(1000, 1000) : 1.859 seconds > solving y' = 1 - x + 4 * y with double: 3.281 seconds > solving y' = 1 - x + 4 * y with quantity: 2.61 seconds > > multiplying ublas::matrix<double>(1000, 1000) : 16.094 seconds > multiplying ublas::matrix<quantity>(1000, 1000) : 16.516 seconds > tiled_matrix_multiply<double>(1000, 1000) : 1.875 seconds > tiled_matrix_multiply<quantity>(1000, 1000) : 1.859 seconds > solving y' = 1 - x + 4 * y with double: 3.203 seconds > solving y' = 1 - x + 4 * y with quantity: 2.672 seconds Interesting - this definitely shows some of the pitfalls of simple performance testing. Here are my results : multiplying ublas::matrix<double>(1000, 1000) : 42.78 seconds multiplying ublas::matrix<quantity>(1000, 1000) : 42.31 seconds tiled_matrix_multiply<double>(1000, 1000) : 1.73 seconds tiled_matrix_multiply<quantity>(1000, 1000) : 2.05 seconds solving y' = 1 - x + 4 * y with double: 2.59 seconds solving y' = 1 - x + 4 * y with quantity: 2.57 seconds multiplying ublas::matrix<double>(1000, 1000) : 42.74 seconds multiplying ublas::matrix<quantity>(1000, 1000) : 42.43 seconds tiled_matrix_multiply<double>(1000, 1000) : 1.77 seconds tiled_matrix_multiply<quantity>(1000, 1000) : 2.08 seconds solving y' = 1 - x + 4 * y with double: 2.59 seconds solving y' = 1 - x + 4 * y with quantity: 2.59 seconds multiplying ublas::matrix<double>(1000, 1000) : 42.78 seconds multiplying ublas::matrix<quantity>(1000, 1000) : 42.31 seconds tiled_matrix_multiply<double>(1000, 1000) : 1.74 seconds tiled_matrix_multiply<quantity>(1000, 1000) : 2.06 seconds solving y' = 1 - x + 4 * y with double: 2.6 seconds solving y' = 1 - x + 4 * y with quantity: 2.57 seconds I'm not sure why my simple matrix multiplication results are so much slower...the others are comparable. In any case, the relative performance is obviously close enough to identical for non-HPC applications... I think the performance arguments look like red herrings... I'll put this in the sandbox example code. Matthias

4 4