- Boost - lists.boost.org

parameters library and rvalue pitfall
by David Abrahams 11 May '05

11 May '05

I just added an index_result metafunction that was requested during the review, for getting the result of a named parameter lookup, possibly with a default or a lazy default. Whereas previously, you would write the following to implement your function with named parameters, template<class Params> void f_impl(const Params& p) { g( p[name] , p[value || boost::bind(&value_default) ] , p[index | 999 ] ); } now you have the option to write something like this: template<class Params> void f_impl(const Params& p) { typename boost::parameter::index_result< Params, struct name_>::type& n = p[name]; typename boost::parameter::index_result< Params, struct value_, double >::type const& v = p[value || boost::bind(&value_default) ]; typename boost::parameter::index_result< Params, struct index_, int >::type const& i = p[index | 999]; g(n,v,i); } The problem, which you may have noticed, is that in the latter case you may be creating dangling references to destroyed rvalues. In the case of the index parameter above, the rvalue 999 gets bound to a const reference that then *passes through* the operator[] and initializes i. Since p[index | 999] returns a const reference and not a value, i is bound directly to the original rvalue 999 which is destroyed at the end of the full expression. The question is, what should we do about this? It turns out to be surprisingly hard to write the declarations of these temporary variables so they work in all cases. For example, v had to be a const& because in one case index_result<...>::type turned out to be char const[4] and when the default is used, it's double with p[value || ...] returning a double rvalue (by value). Thoughts? -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 10

[test] and bcc32 errors
by Russell Hind 11 May '05

11 May '05

Running the regression tests on boost.test with bcc32 leads to many errors like this (and also in other libs regression tests) basic_cstring_test.cpp: Error E2093 c:\Users\russell\Projects\boost-cvs\boost\boost/test/predicate_result.hpp 51: 'operator!' not implemented in type 'tt_detail::equal_impl_frwd' for arguments of the same type in function predicate_result::predicate_result(const tt_detail::equal_impl_frwd &) Any ideas what is going on? Thanks Russell

2 8

Re: [boost] Re: FOREACH / C++ "for" proposal
by brangdon＠cix.compulink.co.uk 11 May '05

11 May '05

In-Reply-To: <428133DD.20505(a)dcook.org> darren(a)dcook.org (Darren Cook) wrote (abridged): > Wouldn't someone wanting to do something "clever" like that fall back to > using a normal for() or while() loop? I thought for(i:vect){} is a > convenience function to save typing and make code clearer; can it do > something a while() loop cannot? I don't think it makes the code clearer, because it looks like a use of i rather than a declaration. I think it is very important for readability that names be declared explicitly. That is a general point. What you are proposing: for (i: vec) is especially misleading because it is inconsistent with: for (i = vec.begin(); i != vec.end(); ++i) I really don't think one should declare i and the other, not. What's wrong with: for (auto i: vec) ? -- Dave Harris, Nottingham, UK.

2 1

Re: [boost] Re: FOREACH / C++ "for" proposal
by brangdon＠cix.compulink.co.uk 11 May '05

11 May '05

In-Reply-To: <d5qtbh$cpi$1(a)sea.gmane.org> nesotto(a)cs.auc.dk (Thorsten Ottosen) wrote (abridged): > which example are you referring to? The one using my_range_adapter, in section 4 of: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1796.html > chances are that <vector> will include <iterator> anyway. I'd rather not have to take chances with my code. -- Dave Harris, Nottingham, UK.

1 0

Re: [boost] Re: Re: Formal Review: FOREACH macro
by brangdon＠cix.compulink.co.uk 11 May '05

11 May '05

In-Reply-To: <00fb01c55599$e9fc23e0$6401a8c0@pdimov2> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > I think that defining size( T[N] ) as N or N-1, depending on whether T > is a character type, will cause problems in generic code and preclude > the widespread use of the library. I agree. If we do support null-terminated character strings, can we support other kinds of terminators too? (Without undue loss of efficiency.) For example: int array[] = { 1, 2, 3, -1 }; int *pArray = array; for (int i, terminator_adaptor(pArray,-1)) cout << i; // Does not write -1. This can be useful if the size of the array is not visible to for(:). I use terminators fairly often, usually NULL for pointers, 0 or -1 for integral types, and "end" for enums. It's not something specific to characters. In fact, for me the need to enumerate character strings is rarer than for these other types. Usually strings are either wrapped in std::string or similar, or else passed to some other routine. By "Without undue loss of efficiency" I really mean without scanning the sequence an extra time to find the end. My impression is that BOOST_FOR_EACH had a fairly general termination mechanism which could cope with that. -- Dave Harris, Nottingham, UK.

1 0

[test] mingw (3.2.3) failure
by Gennadiy Rozental 11 May '05

11 May '05

Does anybody know what the deal here? Test output: mslater - test - basic_cstring_test / mingw Linker output [2005-05-10 22:57:32 UTC]: "g++" "-Wl,--enable-auto-image-base" -g -Wl,--allow-multiple-definition -mno-cygwin -o "C:\testing\boost\results\bin\boost\libs\test\test\basic_cstring_test.test\mingw\debug\basic_cstring_test.exe" -L"C:/testing/boost/results/bin/boost/libs/test/build/libboost_unit_test_framework.lib/mingw/debug" "C:\testing\boost\results\bin\boost\libs\test\test\basic_cstring_test.test\mingw\debug\basic_cstring_test.obj" "C:\testing\boost\results\bin\boost\libs\test\build\libboost_unit_test_framework.lib\mingw\debug\libboost_unit_test_framework.lib" "C:\testing\boost\results\bin\boost\libs\test\build\libboost_unit_test_framework.lib\mingw\debug\libboost_unit_test_framework.lib" C:\testing\boost\results\bin\boost\libs\test\test\basic_cstring_test.test\mingw\debug\basic_cstring_test.obj(.text$_Z19asignment_test_implIwEvPN5boost4typeIT_EE+0xef): In function `ZSt4setwi': c:/mingw/include/c++/3.2.3/iomanip: undefined reference to `std::char_traits<wchar_t>::compare(wchar_t const*, wchar_t const*, unsigned)' And a lot more like this. Why references to std::char_traits<wchar_t> symbols are undefined? Gennadiy

3 4

Re: [boost] Re: Formal Review: FOREACH macro
by Peter Dimov 11 May '05

11 May '05

Peter Dimov wrote: > Eric Niebler wrote: > >> Yes, but I was refering to native (C-style) strings, as in: >> BOOST_FOREACH(char ch, "hello world") > > This is a good opportunity to ask: what does this do? > > char const a[] = { 0, 1, 2 }; Or for extra fun, drop the 0. > BOOST_FOREACH( int x, a ) > { > std::cout << x << std::end; > }

6 20

Review Schedule (11-May-2005)
by Tom Brinkman 11 May '05

11 May '05

The singleton library review started on 5-May-2005. If you haven't done so already, download the library at http://tinyurl.com/6qvrd. You should submit a review by 15-May-2005. The Typeof Library review begins 20-May-2005. You can download this library at http://boost-sandbox.sourceforge.net/vault/ (typeof.zip) Contact Tom Brinkman at reportbase(a)gmail.com for updates to this schedule. Review Queue as of May 11, 2005 1) Singleton (Current) 5-May-2005; Ends: 15-May-2005 2) Typeof Starts: 20-May-2005; Ends: 30-May-2005 3) Function Types Starts: 5-June-2005; Ends: 15-June-2005 4) Logging To be confirmed: 20-June-2005; Ends: 30-June-2005 5) Policy Pointer To be confirmed: 5-July-2005; Ends: 15-June-2005 Other Libraries (no particular order): 6) Fixed Strings 7) Intrusive 8) TR1 9) Fusion 10) Factory 11) Interfaces 1) Singleton Author: Jason Hise chaos(a)ezequal.com Review Manager: Pavel Vozenilek pavel_vozenilek(a)hotmail.com Availabe At: http://tinyurl.com/6qvrd The singleton library provides multiple powerful methods of controlling the lifetimes of global resources. Client code can choose among the many provided methods of creation, or can easily write new creators for specialized initialization needs. Client code can additionally control precisely when a singleton instance is automatically created and destroyed, can create and destroy singleton instances explicitly any number of times, and can set up dependencies between singletons in an easy and natural way. 2) Typeof Author: Arkadiy Vertleyb Arkadiy Vertleyb, Peder Holt vertleyb(a)hotmail.com peder.holt(a)gmail.com Review Manager: Andy Little andy(a)servocomm.freeserve.co.uk Available: http://boost-sandbox.sourceforge.net/vault/ (typeof.zip) The proposed Typeof library implements the functionality of the non-standard typeof() operator. Depending on the compiler, it utilizes one of the following three methods: 1) Forwards to the non-standard typeof extension, usually called __typeof__, on the compilers where such extension is available; 2) Utilises a loophole, available on the Microsoft vc6.5, vc7.0, and vc7.1; 3) Emulates typeof by the means of template and preprocessor metaprogramming for the compilers that do not fall into above two categories, such as vc8.0 beta, etc. This method is rather portable, and can also be used on the compilers that implement the __typeof__ as a language extension, when compiling with language extensions switched off. The emulation mode is currently working with vc7.1, vc8.0 beta, and gcc 3.3/3.4; The MS-specific trick is working with vc6.5, 7.0, and 7.1. The __typeof__ extension forwarding is working with gcc 3.3/3.4 and Metrowerks. 3) Function Types Author: Tobias Schwinger tschwinger(a)neoscientists.org Review Manager: John Maddock john(a)johnmaddock.co.uk Available at: http://tinyurl.com/4oe7q This library provides a metaprogramming facility to classify, decompose and synthesize function-, function pointer-, function reference- and member function pointer types. For the purpose of this documentation, these types are collectively referred to as function types (this differs from the standard definition and redefines the term from a programmer's perspective to refer to the most common types that involve functions). The classes introduced by this library shall conform to the concepts of the Boost Metaprogramming library (MPL). The Function Types library enables the user to: * test an arbitrary type for being a function type of specified kind, * inspect properties of function types, * view and modify sub types of an encapsulated function type with MPL Sequence operations, and * synthesize function types. This library supports variadic functions and can be configured to support non-default calling conventions. 4) Logging Library Author: John Torjo john.lists(a)torjo.com Review Manaer: Hartmut Kaiser hartmut.kaiser(a)gmail.com Available at: http://torjo.com/code/logging-v132.zip The Boost Log Library is a small library, who: * makes it very easy to declare/define new logs * allows you very simple access to logs * allows for log hierarchies, and for modifying log hierarchies * allows for easy and efficient enabling/disabling of logs/log hierarchies * allows for easy manipulation of log behaviors (the log's destination(s) and/or adjusting the original message) * is thread-safe Using the library in code is easy and straightforward: int i = 1, j = 2, k = 3; BOOST_LOG(app) << "testing " << i << '-' << j << '-' << k << std::endl; BOOST_LOG(dbg) << "this is a debug message, i=" << i << std::endl; BOOST_LOG(info) << "I just wanted to tell you something...."; Additions to v1.3.2 - can be compiled as a static/dynamic runtime (works as a DLL as well) - removed dependency on boost_thread Note: I did not test this on Unix, but it should work. If anybody can take a look at detail/ts_posix.hpp, I'd appreciate it. - solved other small issues, based on feedback - slightly improved documentation 5) Policy Pointer Author: David B. Held dheld(a)codelogicconsulting.com Review Manager: Gennadiy gennadiy.rozental(a)thomson.com Available At: Boost Sandbox under policy_ptr Smart pointers are used to automate memory management by handling the deletion of dynamically allcoated objects (and other resources). They assist in ensuring program correctness, exception safety, and memory integrity. Policy Pointer is a policy-based smart pointer framework designed to accomodate the large number of smart pointer designs. Through the use of policy classes, virtually any smart pointer type can be constructed within this framework. This library is a Boostification of the original Loki::SmartPtr type with significant modifications. 6) Fixed Strings Author: Reece Dunn msclrhd(a)hotmail.com Review Manager: Beman Dawes bdawes(a)acm.org Available At: boosts-sandbox/boost/fixed_string The fixed string library provides buffer overrun protection for static sized strings (char s[ n ]). It provides a C-style string interface for compatibility with C code (for example, porting a C program to C++). There is also a std::string-style interface using a class based on flex_string by Andre Alexandrescu with a few limitations due to the non-resizable nature of the class. 7)Intrusive Author: Olaf Krzikalla krzikalla(a)gmx.de Review Manager: Needed Available At: http://people.freenet.de/turtle++/intrusive.zip Library presenting some intrusive containers to the world of C++. While intrusive containers were and are widely used in C, they became more and more forgotten in the C++-world due to the presence of the standard containers, which don't support intrusive techniques. Boost.Intrusive not only reintroduces this technique to C++, but also encapsulates the implementation in STL-like interfaces. Hence anyone familiar with standard containers can use intrusive containers with ease. 8) TR1 9) Fusion 10) Factory Author: Federico Stella f.stella(a)flashnet.it 11) Interfaces Author: Jonathan Turkanis <technews(a)kangaroologic.com> Review Manager: Needed Available: http://www.kangaroologic.com/interfaces "Boost.Interfaces provides a macro-based Interface Definition Language (IDL) which can be used to define C++ class types called interfaces. An interface is a lightweight value type associated with a set of named function signatures. An interface instance can be bound at runtime to any object which implements the interface, i.e., to any object of a type with accessible non-static member functions having the same name and signature as the set of functions associated with the interface. The functions of the bound object can then be invoked through the interface instance using the 'dot' operator. Binding is completely non-intrusive: the object's type need not declare any virtual functions or derive from any particluar base class. "Current applications of Boost.Interfaces include: * Non-intrusive dynamic polymorphism — interfaces can often be used in place of abstract base classes, and are sometimes much faster (see Performance). * Dynamic inheritance — allows function calls to be forwarded automatically to an object specified at runtime (see Delegation). * Smart Interface Pointers — smart pointers which can manage the lifetime of any object whose type implements a given interface. * Smart References — like smart interface pointers, but the managed object is accessed using the "dot" operator."

1 0

Boost.Test: major update
by Gennadiy Rozental 11 May '05

11 May '05

Hi, I would like to take this moment to share with you finally the modifications Boost.Test went through during last couple month. Most of Boost.Test components undergo a major or significant change in both design and implementation. I've strived to keep an interface unchanged as much as possible. The primary goals for this update were: * Make a unit test framework better suited for different 'runners' * Make unit test framework simpler internally by eliminating test cases hierarchy * Make test tools more uniform * Make auto unit test framework as usable as possible Following are details of what updated/changed specifically in each area of Boost.Test: I. Execution Monitor The execution monitor design changes from inheritance to delegation. If previously one needed to inherit from the boost::execution monitor to do a monitored run of a function, now one need to employ an instance of the boost::execution_monitor: boost::execution_monitor em; // register translators for custom user exception em.register_exception_translator<ExceptionType>( my_translator ); em.execute( function_to_execute ); function_to_execute should be any zero arity function or function object. To implement the polymorphic function handling I employ my own class callback (see utilities section). I did not want to introduce a dependency on Boost.Function. But in a future I plan to switch to tr1::function. In addition following features implemented: * Debugger presence detected, in which case catching system errors (SEH) is disabled unless explicitly enabled. For now only works for msvc family * Automatic detection of memory leaks introduced. For now only works for msvc family Unit test framework turns this feature on by default. User could manage it by specifying runtime parameter (in a form of command line argument or environment variable). For example test --detect_memory_leak=<leak_allocation_number> set leak_allocation_number to integer number: 0 - to disable detection of memory leaks; 1 - to enable detection of memory leaks; N>1 - to enable detection of memory leaks and set a system breakpoint at the moment of Nth memory allocation. For more on how to find N and some issues with usage of this feature see documentation II Unit test framework (UTF) This component of Boost.Test undergo a most dramatic changes in both design and implementation. Here are main modifications: 1. UTF doesn't employ test cases hierarchy anymore. There is single class test_case that model one testing unit and class test_suite that model a collection of test units. Previously UTF employed compound test cases (for example parameterized test case) which went through it's components (simple subtests) during testing run time. Now compound test present itself as test case generator which produce a collection if test_case instances during test tree construction time. One consequence of this is that user doesn't need to keep track of compound test case parameters is it used be. test_case now employs a polymorphic callback to a actual test function. As a result of this one could supply any zero arity function as an argument of BOOST_TEST_CASE. SO no extra support needed to be able to create boost::function or boost::bind based tests cases. 2 .Introduced generic mechanism to traverse the test tree. Anyone willing to do so just need to implement test_tree_visitor interface and employ traverse_test_tree. This allows to implement any pre/post processing over test tree. 3. Introduced a notion of framework. The framework is responcible for: a) initializing and providing access to master test suite b) providing access to current test case c) running testing from given test tree node (simple or compound). By default it runs from root - master test suite. Supports both sequential and random order. d) One may register any test observer agent (implements test_observer interface) and framework notifies it of all test events e) providing access to any test case based to unique test unit id Using the framework one could implement different test runners. UTF library supplies one console runner (unit_test_main.cpp). But it's possible to do one winmain based or anything else. For example GUI program that build test tree and then run tests by request from any point in test tree. 4. Unit test log interface changed to single line (used to be begin/end macros). Unit test log formatter interface changed. How it much simpler and straightforward. Two supplied implementation are separated. 5. Notion of unit test result that was responcible for result collection and reporting eliminated. Instead introduced independent notions: results_collector and results_reporter. Results reporting formatter interface made public. Also results_reporter now allows to change an output stream. 6. Progress monitor functionality (which used to be activated in log level log_progress) now is an independent test observer and implemented by class progress_monitor. 7. Test case template interface changed. Now user doesn't need to explicitly register meta class. In addition couple more features implemented: * Added support for test case timing * UTF made __cdecl - safe * Result report include skipped tests * io saver facilities employed to guard against undesirable modification in output streams formatting * template test case automatically generate name that includes type name * --detect_memory_leak and --random cla added III Test Tools The two major changes in Test Tools are: * Test Tools interfaces to provide 3 version for each tool: CHECK- reports an error if assertion failed WARN - reports a warning if assertion failed REQUIRE - reports an error if assertion failed and aborts test case execution * Test Tools implementation completely reworked. All tools implemented now through single vararg function In addition following modifications made: * CHECK_COLLECTION interface changed: it now expect 4 arguments * BITWISE_EQUAL renamed to CHECK_BITWISE_EQUAL; old name still provided, but is deprecated * CHECK_COLLECTION interface changed to use PP_SEQ and as a result support arbitrary(actually maximum is fixed but configurable) number of predicate arguments * most of templates eliminated speeding up test modules compilation * floating-point precision set to include all significant digits (actually the formula may require some rework since it obviously doesn't do a good job sometimes) * BOOST_CHECK/WARN/REQUIRE_SMALL test tool added * old test tools names are *deprecated* IV Auto unit test framework Interesting discussion with Noel Llopis and several user requests lead to several additions to the auto_unit_test.hpp. Here is a short descriptions: * BOOST_AUTO_UNIT_TEST renamed to BOOST_AUTO_TEST_CASE. Old name still provided but deprecated * BOOST_AUTO_TEST_CASE_TEMPLATE provides an ability to write a self-registering test case template * BOOST_FIXTURE_TEST_CASE provides an ability to write a self-registering test case with fixture * BOOST_AUTO_TEST_CASE_EXPECTED_FAILURES provides an ability to specify a number of expected failures in any self-registering test case * BOOST_AUTO_TEST_SUITE and BOOST_AUTO_TEST_SUITE_END provide an ability to structure test cases into self-registering test suites V Included components Implementation moved from source files (.cpp) under lib/test/src into implementation files (.ipp) under boost/test/impl to eliminate dependency of included/minimal components on lib/test/src directory. VI Utilities Basic utilities that may have value outside of Boost.Test now separated into utils subdirectory. If there is an interest to promote any of them onto public boost level I am ready to discuss it. Here is a short descriptions (some of them existed before, but most are new): 1) algorithm.hpp Implements several variations of STL algorithms including 4-arg mismatch 2) assign_op.hpp Hook for overloadable assignment 3) callback.hpp Implements a polymorphic function callback facility (similar to boost::function). 4) class_properties.hpp Simple facility that mimic notion of read-only read-write properties in C++ classes 5) custom_manip.hpp Simple helpers for creating custom output manipulators 6) fixed_mapping.hpp Fixed sized mapping (initialized in constructor ) with specified invalid value. 7) foreach.hpp This is an abridged version of BOOST_FOREACH. The only difference is portability. 8) named_params.hpp Facility for named function parameters support. Even though Dave A. did not see a value in my suggestion during Boost.Parameter review period. I couldn't justify for myself using that inconvenient interface (IMO) and absence of optional parameters. This facility implements an alternative solution with different set of tradeoffs and features. It used in several places in Boost.Test. 9) nullstream.hpp I should probably deprecate this one , but more-io was not accepted. 10) rtti.hpp Simple alternative to compiler RTTI. Provides an access to unique type id at runtime. I plan to extend this to implement type_descr similar to what is described in "C++ template metaprogramming". 11) trivial_singleton.hpp As the name suggest this simple singleton helper. 12) wrap_stringstream.hpp Wraps strstream and stringstream (depends with one is present) to provide the unified interface 13) basic_cstring/ class template basic_cstring wraps raw memory pointers and provide std_string like interface 14) iterator/input_iterator_facade.hpp Helps to build input iterators 15) iterator/token_iterator.hpp Yet another token iterator 16) iterator/istream_line_iterator.hpp Iterate over istream and produce lines 17) runtime/ This is long promised framework for parsing CLA handing environment variable and parsing config files. This is an alternative solution to what boost::program_options present. Unfortunately I did not have enough time to incorporate it completely into Boost.Test main components, so the detailed description will follow once this will happened. Sorry, for babbling for so long. Any comments are greatly appreciated. Regard, Gennadiy

3 5

[patch] Memory leak in the thread_specific_ptr implementation in Boost.Threads
by Jeremie Detrey 11 May '05

11 May '05

Hello, It seems to me that there is a possibly huge memory leak in the file boost/libs/thread/src/tss.cpp, as the thread specific data slot vector is allocated (line 120) but never freed. It causes a few bytes' memory leak for each thread, as it appears when using valgrind (see attached files: input program = example.cpp, valgrind output = example.valgrind). I propose here a simple patch to fix this. It works perfectly with my programs, and frankly I cannot see why it should not work. Thanks, Jeremie Detrey.

1 0