- Boost - lists.preview.boost.org

[Review] Named parameter questions
by Thomas Witt 23 Nov '04

23 Nov '04

Hi, I was going to provide a (late) review for the named parameter lib, but I have some questions before I can do that. 1) I find the use of the name "keyword" for the type of the named parameter somehow odd. It does not seem to fit with what I associate with keywords. What's the rationale behind that choice. 2) The docs give the following example for mixing named and positional parameters: foo("bar", 3.14f); foo(value = 6.28f, "baz") Should print: bar = 3.14 baz = 6.28 I believe the parameter deduction in this case is too smart. Is there a way for the user of the library to enforce a rule like "No positional param after named params" on a case by case basis? 3) Section 5 has the following example // implementation of bar() template <class Params> void bar_impl(Params const& params) { // Extract arguments float x_ = params[x]; float theta_ = params[theta | pi]; float span = params[span || boost::bind(default_span, x_, theta_)]; //!! ^^^^ ^^^^ ... } IIUC this does not work. I assume the second span should refer to a named paramter object. I think it refers to the local span object. Did I miss something? Regards Thomas PS: Doug I know I am late, feel free to ignore me. -- Thomas Witt witt(a)acm.org

5 5

[Named Parameters] BGL named parameters -> review Named Parameters
by Doug Gregor 23 Nov '04

23 Nov '04

The attached "named_function_params.hpp" allows the BGL named parameters to coexist with the named parameters library up for review. The attached "page_rank.hpp" file implements a simple algorithm that now supports both named parameters interfaces. The test file exercises both interfaces. Worked for me on Apple's GCC 3.3. A review is still in the works. Doug

2 1

[Review] Named parameters questions, comments, and food for thought
by Doug Gregor 23 Nov '04

23 Nov '04

I've just implemented a new BGL algorithm using the named parameters library for the interface. The algorithm itself is very simple, but illustrates some of the benefits and pitfalls of the named parameters library. After writing this, I of course have some questions and comments about the named parameters library. This is not actually a review: that will come later. And don't confuse this with my role as review manager. --------------------------Fixed positional parameters----------------------------- The first issue I ran into was that I really wanted a fixed number of positional parameters before any of the named parameters. These parameters will not have defaults and there is no reason to allow them to have names. I say this is an "issue" and not a "problem" because there are several workarounds: 1) Don't use BOOST_NAMED_PARAMS_FUN; write out the forwarding functions manually. (This is the option I chose) 2) Make the required, positional parameters into named parameters (so that we can use BOOST_NAMED_PARAMS_FUN) but do not provide the objects of type "keyword" for these parameters. So, for instance, I'll have "struct graph_t {};" but no corresponding keyword "boost::keyword<graph_t> graph;". The algorithm would also have to use boost::named_param to say that there is no default value for these parameters. I chose option (1) for various reasons. The primary reason actually had to do with something another reviewer brought up: it's rather hard to deal with creating defaults for named parameters that rely on other named parameters. This was never easy (the BGL has the same problem), but picking (2) above makes things much harder: for instance, the first positional parameter is _always_ the graph, and nearly every default value depends on knowing the graph type. However, I wouldn't be able to get at the type of p[graph_t()] without passing it to another helper function and doing the work there. ------------------------Default parameters---------------------- Both normal and lazy defaults work very cleanly. The dispatch to my implementation function is quite readable: detail::page_rank_impl (g, rank_map, p[done | n_iterations(20)], p[num_active_vertices | num_vertices(g)], p[rank_map2 || vector_property_map_builder<Graph, rank_type>(g)]); vector_property_map_builder is a new function object a had to create to perform the lazy construction of a vector_property_map, but that doesn't hurt so badly. A better version of it would just end up somewhere in the BGL and be reused. -----------------------The type of params[foo | def]------------------- Going into this, I had the notion that I'd be able to use BOOST_NAMED_PARAMS_FUN to eliminate all of the extra levels of dispatching calls. It still took 3 levels of function calls: 1 for bundle the parameters, one to stick defaults in, and one to do the actual work. If we could get the return type of p[foo | def] or p[foo || def] directly, we could solve those problems. To make that usable, perhaps some"auto"-like macro: BOOST_NAMED_PARAMS_AUTO(g, graph_t); BOOST_NAMED_PARAMS_AUTO_DEF(done, done_t, n_iterations(20)); BOOST_NAMED_PARAMS_AUTO_LAZY_DEF(rank_map2, rank_map2_t, (vector_property_map_builder<Graph, rank_type>(g))); Unfortunately, I think we need typeof to do that :) ----------------------- Question on boost::keyword ------------------- If the BGL is going to switch to this library, we are going to need backward compatibility. I can do that easily if I'm allowed to derive my keywords from boost::keyword instead of using exactly a "boost::keyword". Can I do that? More comments and probably a real review later... I want to go home now. Doug

2 1

Using program_options with other options methods
by Allen Bierbaum 23 Nov '04

23 Nov '04

I have recently started using the program_options library, and I find it very useful. Unfortunately I can't seem to figure out how to allow it to work with other option parsers/handlers at the same time. For example, right now I am writing an application that uses a library that has its own set of common options that are process internally. So I end up needing to write code similar to the following: po::options_description desc("Allowed options"); desc.add_options() ("help", "produce help message") ("my_opt", po::value<int>(), "set my option") ; po::variables_map vm; po::store(po::parse_command_line(ac, av, desc), vm); po::notify(vm); custom_lib::options opts; opts.process(ac, av); Then when I run this application: ./app --my_opt=10 --liboption=custom The problem is that I get an exception from program_options: error: unknown option --liboption Is there any way to tell the program options parser to ignore options that it does not recognize? If there is no option like this, how can program_options be used with other option parsers? -Allen -- -- Allen Bierbaum allenb(a)vrac.iastate.edu

1 0

posix_time::time_from_string() assertion failed due to bad input format
by Alexander Konovalenko 23 Nov '04

23 Nov '04

boost::posix_time::time_from_string() terminates the program due to a failed assertion on certain inputs. Boost version used: 1.31.0. Compiler used: GCC 3.3.4. (All the tools come from pre-built Debian GNU/Linux packages.) I didn't find a fix for this problem in the latest change log. Running the attached test program (see the source) gives the following output: date_format_bug_demo: /usr/include/boost/token_iterator.hpp:59: const Type& boost::token_iterator<TokenizerFunc, Iterator, Type>::dereference() const [with TokenizerFunc = boost::char_delimiters_separator<char, std::char_traits<char> >, Iterator = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, Type = std::basic_string<char, std::char_traits<char>, std::allocator<char> >]: Assertion `valid_' failed. Aborted I expected it to throw some descendant of a standard exception instead. Is it indeed the accepted policy in the Date_time library to always handle invalid input data by throwing an appropriate exception? Or are there cases where the input is intentionally assumed to be correct and is thus left unchecked? Thanks in advance! -- Alexander

2 3

Boost license
by Falk Hueffner 23 Nov '04

23 Nov '04

Hi, the boost license (http://www.boost.org/LICENSE_1_0.txt) does not allow redistributing modified versions. Is that intentional or an oversight? -- Falk

7 27

Boost 1.32.0 released
by Aleksey Gurtovoy 23 Nov '04

23 Nov '04

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + NOTE: This is a stripped-down copy of the Boost 1.32.0 release + + notes. See http://www.boost.org for the full version. + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Important - New Toolset Names ----------------------------- The names of some the Boost.Build toolsets have been changed to remove the "." (dot) character and to fix some other naming inconsistencies. For example, vc7.1 toolset was renamed to become vc-7_1. Please refer to the Supported Toolsets section of the installation guide for the complete list of the current toolset names. This change was made as a part of the effort to make the Boost distribution compatible with ISO 9660 level 2 requirements. New Libraries ------------- * Assignment Library: Filling containers with constant or generated data has never been easier, from Thorsten Ottosen. * Minmax Library: Standard library extensions for simultaneous min/max and min/max element computations, from Herv Brnnimann. * Multi-index Containers Library: Containers with multiple STL-compatible access interfaces, from Joaqun M Lpez Muoz. * Numeric Conversion Library: Optimized policy-based numeric conversions, from Fernando Cacciola. * Program Options Library: Access to configuration data given on command line, in config files and other sources, from Vladimir Prus. * Range Library: A new infrastructure for generic algorithms that builds on top of the new iterator concepts, from Thorsten Ottosen. * Serialization Library: Serialization/de-serialization of arbitrary C++ data structures to various formats including text, binary, and xml, from Robert Ramey. * String Algorithms Library: Collection of string related algorithms for case conversion, trimming, find/replace operations and more, from Pavol Droba. * Tribool: 3-state boolean type library, from Doug Gregor. Updated Libraries ----------------- * Compose: This deprecated library has been removed. * Graph: - Added bundled properties to the adjacency_list and adjacency_matrix class templates, greatly simplifying the introduction of internal vertex and edge properties. - The LEDA graph adaptors have been ported to LEDA 4.5. - Added algorithms for betweenness centrality and betweenness centrality clustering. - Added circle layout and undirected spring layout algorithms. * MPL Library: - Updated to use the Boost Software License. - New documentation, including a complete reference manual. - Major interface changes and improvements, many of which are not backward compatible. Please refer to the 1.32 changelog for the detailed information about upgrading to the new version. * Python Library: - Updated to use the Boost Software License. - A new, better method of wrapping classes with virtual functions has been implemented. - Support for the new Python Bool type, thanks to Daniel Holth. - Support for upcoming GCC symbol export control features have been folded in, thanks to Niall Douglas. - Improved support for std::auto_ptr-like types. - Components used by other libraries have been moved out of python/detail and into boost/detail to improve dependency relationships. - Miscellaneous bug fixes and compiler workarounds. * Signals Library: Introduced deterministic slot ordering, permitting slots to be connected at the beginning or end of slot groups or the slot list itself. Combiners may safely have state and are accessible from the signal. * Utility: class template result_of added. * Test Library: - namespace names gets shorten; old one still supported till next release. - added proper encoding of XML PCDATA. - support for wide string comparison implemented. For complete list of changes see Test Library release notes. Regression tests ----------------- This release has been extensively tested on a variety of different compilers and platforms. It is known to contain no regressions against the previous reference release on the compilers and configurations tested. Please refer to the corresponding regression reports at http://www.meta-comm.com/engineering/boost-regression/1_32_0 to see how well your compiler performs on the new Boost codebase. Acknowledgements ---------------- This release wouldn't have been possible without the dedicated effort of many, many members of the Boost community who generously contributed their outstanding expertise, time and energy to making it happen. For patches, bug fixes, troubleshooting, expert advice, and prompt responses to the release manager's requests we thank: David Abrahams, Misha Bergal, Jonathan Brandmeyer, Fernando Cacciola, Marshall Clow, Christopher Currie, Pavol Droba, Caleb Epstein, Eric Friedman, Jeff Garland, Michael Glassford, Doug Gregor, Joel de Guzman, Hubert Holin, Jaakko Jrvi, Hartmut Kaiser, Bronek Kozicki, Tarjei Knapstad, Toon Knapen, Aaron W. LaFramboise, Joaqun M Lpez Muoz, Christoph Ludwig, John Maddock, Paul Mensonides, Guillaume Melquiond, Thorsten Ottosen, Vladimir Prus, Robert Ramey, Rene Rivera, Gennadiy Rozental, Stefan Slapeta, Jonathan Turkanis, Pavel Vozenilek, Jonathan Wakely, Daryle Walker, Victor A. Wagner Jr. and Martin Wille. Also, our special thanks go to: John Maddock for the managing the effort of converting the majority of the Boost libraries to the Boost Software License, Eric Niebler and Joel de Guzman for taking on the important job of improving the Boost documentation's look and feel, and last, but not least, to our regression test runners, without whom we simply would never have released: Toon Knapen, Bronek Kozicki, Rene Rivera, Markus Schpflin, Stefan Slapeta, Victor A. Wagner Jr. and Martin Wille. Thank you everybody! -- Aleksey Gurtovoy MetaCommunications Engineering

6 8

[date-time] small interface nitpick
by Pavol Droba 23 Nov '04

23 Nov '04

Hi, I have spoted another small inconsistence in the date-time interface. Generic date_time::time_duration 4-parameter contructor have a default values for seconds and fractional seconds. Posix variant have default value only for frac_seconds. Regards, Pavol

2 1

date_time request for addition
by Pavol Droba 23 Nov '04

23 Nov '04

Hi, In the Date-Time library, date_duration class provides a set of basic arithmetic operations. Among others there is multiplication and division. Current interface supports only integer factors. Sometimes this precision is not sufficient. I have actualy came accross such a occasion. I need to adjust the duration using a multiplier from range <0,1>. Currenly it is not feasible, and I have to workaroud it by converting to microseconds and back. Would it be possible to alter the interface, so it will be able to use real factors? Thanks. Regards, Pavol

2 5

MPL documentation
by Edward Diener 23 Nov '04

23 Nov '04

The MPL documentation is better than before and the reference is excellent. However I do not believe the tutorial is adequate for bringing new programmers interested in understanding metaprogramming using MPL into a general understanding of how MPL works and how to use it. This is because the tutorial does not start at the beginning of defining MPL concepts but jumps into high order metafunctions without explaining the basis of metafunctions or metaprogramming classes to begin with. I understand the problem, that metaprogramming is a large concept and that understanding the basics would entail starting at a point where explaining anything further takes up much more space than a mere tutorial would normally encompass. The answer no doubt is to buy Mr. Abrahams and Mr. Gurtovoy's book. However despite the good intent of the tutorial, I think that it only performs the function of bringing further knowledge of the MPL library to those who already understand how the basics of the library already work. For those C++ programmers who want to learn to understand how to use the MPL library from scratch, I do not think the tutorial is adequate. Perhaps MPL was never meant to appeal to those without a knowledge of its precepts to begin with, but by assuming that I think that the tutorial will either leave C++ programmers who would like to learn to use MPL feeling pretty cold about it, or force them to buy the book in order to understand how it works.

2 5