- Boost - lists.boost.org

[Report] 0 regressions on RC_1_34_0 (2007-04-05)
by Douglas Gregor 05 Apr '07

05 Apr '07

Boost Regression test failures Report time: 2007-04-05T01:00: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… No failures! Yay!

1 0

Question about submission process
by Eric Niebler 05 Apr '07

05 Apr '07

Is it kosher to submit a library for review, and continue to work on documentation and tests? Or should the library be "final" before it can be put in the queue? I'd like to get my expression template library (Proto) in the queue, and considering how deep the queue is at the moment, I think I'll have plenty of time to finish the docs before the review happens. -- Eric Niebler Boost Consulting www.boost-consulting.com

7 11

Re: [boost] Intrusive library review results: library accepted
by brass goowy 05 Apr '07

05 Apr '07

Steven Watanabe writes: >AMDG >brass goowy <brass <at> goowy.com> writes: >> >- Drop the 'i' prefix from the names of containers. >> >> I disagree with this one. I think std and intrusive containers >> will often be used together. This decision will lead to longer >> names in those cases. >Is there something wrong with longer names? I prefer being able to write ilist to Intrusive::list >> I would support dropping the prefix >> if the resulting name wasn't the same as in the std. Why >> not get rid of all the vowels and call them lst? >For one thing, it looks too much like 1st. Isn't there a possibility intrusive containers will make it into the standard? If they get that nod there will be a little problem if they have the exact same names as the standard containers. This reminds me of that tv program... "This is my brother Daryl and this is my other brother Daryl." Brian Wood Ebenezer Enterprises www.webEbenezer.net

4 3

[boostbook] Duplicates and free functions
by Julio M. Merino Vidal 05 Apr '07

05 Apr '07

Hello, I'm currently having trouble with the conversion between the XML generated by Doxygen and the Boostbook code generated by doxygen2boostbook.xsl. Some of my files define free functions and types inside a namespace (or at the top level; the problem appears equally). However, when these files are converted to Boostbook and later turned into HTML, I cannot see any of these functions. I can only see those classes that appear in the same file, but nothing else. The problem is because the code is skipping such cases. Additionally, Doxygen seems to be generating duplicate entries for some members, and I don't know why it's happening (a bug?). For example, if you document some #defines in a file, the resulting Boostbook will contain two entries for each #define, which is incorrect because 1) there are duplicate IDs, 2) the rendered document contains two entries. (This also happens with the free functions mentioned above, once they are fixed.) At last, Doxygen is also generating sectiondef's elements with an empty kind, which are also unhandled by the current code. I'm using Doxygen 1.5.1 under Mac OS X and Boost from CVS HEAD. The problems can easily be seen when building the Boost.Process' documentation that is currently in the SVN repository and later inspecting the synopsis of each header file in the Reference chapter. For example, note how "operations.hpp" is completely empty, or how "config.hpp" contains duplicates for all macros. The attached patch resolves these issues for me, but I'm not sure it is correct. Specially, the new sectiondef template in toplevel mode is needed to avoid the duplicates in the #defines' synopsis... but maybe it'd be avoided in some other way. Feel free to modify it to correct any obvious mistake, but please resolve the conversion issue :-) Thanks, PS: Is this Doxygen->Boostbook conversion experimental? Support for several things seem to be missing... -- Julio M. Merino Vidal <jmmv84(a)gmail.com>

5 9

[Review] [units]
by Steven Watanabe 05 Apr '07

05 Apr '07

AMDG Janek Kozicki wrote: > My only complaint is about lengthy typenames. Like for example my > Newton's Law function (attached calculatorform.cpp:65): > > quantity<SI::force> newtons_law(const quantity<SI::mass>& m, const quantity<SI::acceleration>& a) > { > return m*a; > } > I don't know of any good general solution. We have the identical problem: force is already taken. It makes more sense to use it for the unit than the quantity because you can also have quantity<SI::force, long double>. > <snip> > > > The "base_unit_converter<>" in Example 16 should be hyperlinked to the > explanations what it is and how to use it. > I'll make sure that Doxygen finds the definition. > Documentation should have a FULL list of all predefined units, so it will be a > quick reference for the users. > > Ok. > > EXAMPLES > > Speed "Example 14": > > With debug information and no optimizations: > > <snip> > > > With units it is faster by two seconds. I ran the test several times, and read > the code few times. Maybe executable with "slower" units is accidentally better > synchronized with memory access frequency MHz. Congratulations, you beat me. > > Those results were obtained with: > gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) > It's easily within the noise level. > Yes it should be accepted. Before adding to CVS-HEAD please do following: > > 1. support calculations of conversion factors as explained above. Attached file > calculatorform.cpp:47 (or convince me that I'm wrong, but hey - how to do it > more conveniently than in this way?) > It should be a compile error. Try quantity<SI::dimensionless>(1.0*CGS::dyne/SI::newton) With the sandbox version > 2. check for compiler used and emit an #error when unsupported compiler is > detected. So that users won't waste time on futile fights with their compilers. > Ok. Thank you for your comments. In Christ, Steven Watanabe

2 1

[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

[Boost-bugs] [ boost-Bugs-1694634 ] listS for VertexListS on adjacency_list, breadth_first...
by SourceForge.net 04 Apr '07

04 Apr '07

Bugs item #1694634, was opened at 2007-04-04 15:53 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=1694634&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: graph Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Jeremy Siek (jsiek) Summary: listS for VertexListS on adjacency_list, breadth_first... Initial Comment: It seems that if one uses a listS for VertexListS on adjacency_list, breadth_first_search does not work. It has an issue because the list iterators only take ++ and not + number (at least in MSVC 2003). It'd probably be better to use std::advance... Oh yeah, and the next thing probably isn't you folks' fault, but boost::get seems to lock up MSVC IntelliSense. Lovely. :/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1694634&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

[boostbook] Formatting for typedefs
by Julio M. Merino Vidal 04 Apr '07

04 Apr '07

Hello, The attached patch adds the ability to format those typedefs that include a more complete description than just the <purpose> comment. It seems to work fine so far, except for those typedefs defined inside classes. I don't know why, yet, but this is too complex already... -- Julio M. Merino Vidal <jmmv84(a)gmail.com>

2 2

[units] reference frames and conversions
by Matthias Schabel 04 Apr '07

04 Apr '07

So this appears to work correctly (append this code to the end of unit_example_15 and #include <boost/units/systems/si/length.hpp>) : // two-tier quantity for providing reference frame and underlying unit safety typedef boost::array<quantity<SI::length>,3> vector_type; typedef quantity<world_space_unit,vector_type> world_space_vector_type; typedef quantity<object_space_unit,vector_type> object_space_vector_type; vector_type vec1 = { 0*SI::meter, 0*SI::meter, 0*SI::meter }, vec2 = { 1*SI::meter, 1*SI::meter, 1*SI::meter }; world_space_vector_type wsv1 = vec1*world_space, wsv2 = vec2*world_space; object_space_vector_type osv1 = vec1*object_space, osv2 = vec2*object_space; world_space_vector_type wsv3(wsv1); object_space_vector_type osv3(osv1); world_space_vector_type wsv4(osv2); object_space_vector_type osv4(wsv2); I believe this is the cleanest solution to your requirement for reference frame conversions. The last two lines fail to compile now because the conversion itself is not defined...just specialize conversion_helper and you're off... Matthias

1 0