- Boost - lists.boost.org

Re: [boost] New Library Proposal: dual_state
by Jost, Andrew 19 Jul '05

19 Jul '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Fernando Cacciola > Sent: Saturday, July 16, 2005 12:48 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] New Library Proposal: dual_state <clip -- discussion on why ?: is clearer than "adaptor"> > You said that > > "the door has been flung open to many templated constructs > that are more difficlt with the ?: operator. For example, a > boost::transform_iterator could be created with the adaptor > to automatically access the underlying objects in a sequence." > > I disagree.. can you post a concrete example with a construct > that is indeed more difficult with operator ?: (... and be > fair; i.e. code the operator version the right way...) > > > IMO you still need to show that the adpator is indeed a good > thing; if you do that we can start discussing a proper design > and implementation for it. > Okay, I'll try. How about finding the max_element (or min_element) of a series of optional integers? Using the ?: operator, we might do this in two steps, the first to filter out non-existent values, the second to apply the max_element algorithm. Another way would be to write a custom predicate function that knows how to compare "full" and "empty" Boost::Optional objects or that duplicates the functionality of adaptor. However, by using an adaptor in conjunction with boost::transform_iterator, the job can be accomplished in one loop without the difficulty of writing a custom predicate. Here is some example code (BTW, others seem to prefer the spelling "adaptor," which is more consistent with other standardized names like "iterator," so I'll conform to that): // -- begin typedef boost::optional<int> opt_int; typedef std::vector<opt_int> Vec; typedef Vec::const_iterator cIter; Vec v; int max; v.push_back(0); v.push_back(1); v.push_back(2); v.push_back(boost::none); v.push_back(3); v.push_back(4); v.push_back(boost::none); v.push_back(5); // METHOD #1a: copy to a new vector std::vector<int> tmp; for( cIter p = v.begin(); p != v.end(); ++p ) { if( *p ) tmp.push_back( p->get() ); } max = *std::max_element( tmp.begin(), tmp.end() ); // METHOD #1b: copy using ?: to provide a signal value for undefined elements (similar to adaptor) tmp.clear(); for( cIter p = v.begin(); p != v.end(); ++p ) { tmp.push_back( *p ? p->get() : -1 ); } max = *std::max_element( tmp.begin(), tmp.end() ); // METHOD #2a: define a custom predicate template< class T, class Pred, T Def = T() > class optPred : public std::binary_function<boost::optional<T>, boost::optional<T>, bool> { Pred f; T _eval( const boost::optional<T>& x ) const { return ( x ? x.get() : Def ); } public: optPred() : f( Pred() ) {} bool operator()( const first_argument_type& a, const second_argument_type& b ) const { return f( _eval(a), _eval(b) ); } }; opt_int opt_max; opt_max= *std::max_element( v.begin(), v.end(), optPred< int, std::less<int>, -1 >() ); // METHOD #2b: use an adaptor-like predicate template< class T > class adaptor_substitute : public std::unary_function< boost::optional<T>, T > { T Def; public: _adaptor_() : Def( T() ) {} _adaptor_(T def) : Def( def ) {} T operator()(const argument_type& x ) { return ( x ? x.get() : Def ); } }; max = *std::max_element( boost::make_transform_iterator( v.begin, adaptor_substitute<int>(-1) ), boost::make_transform_iterator( v.end, adaptor_substitute<int>(-1) ) ); // METHOD #3: use an adaptor max = *std::max_element( boost::make_transform_iterator( v.begin, boost::optional<int>::adaptor(-1) ), // NOTE: boost::optional<int>::adaptor does not currently exist boost::make_transform_iterator( v.end, boost::optional<int>::adaptor(-1) ) ); // -- end It seems to me the adaptor, at the very least, saves us the trouble of defining a custom predicate. The similar exercise for min_element can be done by choosing a different signal value, such as 0x7FFFFFFF (the point at "infinity"). I hope this clears up my comment about using adaptor with boost::transform_iterator, but let me know if I haven't convinced you. -Andy

2 1

[iostreams][tru64] can't pass static mem fn to API expecting extern "C"
by Jonathan Turkanis 19 Jul '05

19 Jul '05

Hi, Compaq C++ for Tru64 seems to have found a problem with the iostreams library that none of the other compilers caught. zlib and libbz2 allow the programmer to customize memory management by specifying a pair of function pointers for allocation and deallocation. I wanted to provide an adaption layer so that users could specify standard library compatible allocators instead. To do this, I defined a class template parameterized by an allocator and having two static member functions with the same signature as the allocation and deallocation functions, and then passed pointers to these static member functions to the zlib and libbz2 API. Unfortunately, when compiled as C++, the zlib and libbz2 headers declare the allocation and deallocation function pointer types as extern "C", and Compaq (correctly, I think) refuses to let me assign pointers to static member functions to variables whose type are declared extern "C". Is there some way to get around this? If not, what should I do? 1. expose the C-language customization interface (yuck) 2. remove the customization interface 3. remove the customization interface only for platforms where it doesn't work 4. Use some more elaborate trick, such as supplying extern "C" allocation functions which operate by delegating to pointers stored in a table. I like 2. Jonathan

4 4

[mpl] integral_c bool partial specialization
by Matt Calabrese 19 Jul '05

19 Jul '05

The bool partial specialization of ::boost::mpl::integral_c currently does not appear to contain a value_type type member meaning it does not fully conform to the Integral Constant pure abstraction specified in documentation.

2 1

[tokenizer] Type requirements
by Nikolay Mladenov 18 Jul '05

18 Jul '05

Hi All, What are the requirements on the Type template parameter of boost::tokenizer. I could not find this in the documentation. I want to pass type similar to std::pair < std::string::const_iterator, std::string::const_iterator > . But it seems that the type should have operator += and/(or?) assign member. Is that correct? Is there any other customization mechanism here? Thanks Nikolay

1 0

multi_array 64-bit patch
by Thomas Klimpel 18 Jul '05

18 Jul '05

Hello, The Boost Multi_Array library produces some 64-bit related warnings when used with Visual C++.NET. It seems to me that these warnings are valid and correspond to real 64-bit problems. To get rid of these annoying warnings, I have fixed two minor inconsistencies in multi_array/iterator.hpp and multi_array/multi_array_ref.hpp, but that was not enough. I also had to change the definition of boost::detail::multi_array::index in multi_array/types.hpp from "typedef int index;" to "typedef std::ptrdiff_t index;". There might be better solutions, but it was the best I could think of, because std::ptrdiff_t is a signed type and will adapt to a 64-bit environment. Index: multi_array/iterator.hpp =================================================================== --- multi_array/iterator.hpp (Revision 1040) +++ multi_array/iterator.hpp (Arbeitskopie) @@ -98,7 +98,7 @@ array_iterator() {} - array_iterator(int idx, TPtr base, const size_type* extents, + array_iterator(index idx, TPtr base, const size_type* extents, const index* strides, const index* index_base) : idx_(idx), base_(base), extents_(extents), Index: multi_array/types.hpp =================================================================== --- multi_array/types.hpp (Revision 1040) +++ multi_array/types.hpp (Arbeitskopie) @@ -26,7 +26,7 @@ // needed typedefs typedef std::size_t size_type; -typedef int index; +typedef std::ptrdiff_t index; } // namespace multi_array } // namespace detail Index: multi_array/multi_array_ref.hpp =================================================================== --- multi_array/multi_array_ref.hpp (Revision 1040) +++ multi_array/multi_array_ref.hpp (Arbeitskopie) @@ -389,7 +389,7 @@ // Calculate the array size num_elements_ = std::accumulate(extent_list_.begin(),extent_list_.end(), - 1,std::multiplies<index>()); + size_type(1),std::multiplies<size_type>()); #if 0 assert(num_elements_ != 0); #endif

2 1

[Preprocessor] Workaround for CW8.3
by David Abrahams 18 Jul '05

18 Jul '05

BOOST_PP_SEQ_ENUM is failing for me when invoked from another macro; When the argument is (A0) I get BOOST_PP_SEQ_ENUM_2 and when the argument is (A0)(A1) I get BOOST_PP_SEQ_ENUM_4 I think what happens is that CW "sees through" the outer set of parens in # define BOOST_PP_SEQ_ENUM(seq) BOOST_PP_CAT(BOOST_PP_SEQ_ENUM_, BOOST_PP_SEQ_SIZE(seq)) seq and pastes seq to itself, yielding a length of 4 instead of 2. Here's a workaround: # define BOOST_PP_SEQ_ENUM_I(size,seq) BOOST_PP_CAT(BOOST_PP_SEQ_ENUM_, size) seq # define BOOST_PP_SEQ_ENUM(seq) BOOST_PARAMETER_SEQ_ENUM_I(BOOST_PP_SEQ_SIZE(seq), seq) I hope this is useful. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

[1.33.0] Inspection report
by Douglas Gregor 18 Jul '05

18 Jul '05

The inspection report shows that we have a bunch of little fixes to make before we release. Please check it out and fix whatever you can: http://www.boost.org/regression-logs/inspection_report.html Doug

8 14

some ptr_container issues
by Ross Boylan 18 Jul '05

18 Jul '05

I'm using the cvs version (as of a couple of days ago) of the ptr_container library with a regular 1.32 boost. Should transfer operations between dissimilar containers (e.g., ptr_vector and ptr_list, assuming both have the same underlying type) work? They don't seem to. I can't quite tell from the docs (which define these abstractly, e.g., for ptr_sequence) whether this should work or not. Previous versions of the docs made it explicit that the operations were templated on the type of the second container. Second, the definition of transfer does not say where the elements are to be inserted (i.e., whether they go before the "before" iterator, or whether the "before" iterator will end up before the inserted elements). While it's not hard to guess right with some knowledge of how the standard works (and even how other ptr_container functions work), it would be nice to be explicit. Third, I didn't see any explicit discussion of circumstances that invalidate iterators. Again, it's pretty easy to guess this is the same as the corresponding standard classes, but it's probably worth saying so. Finally, the discussion of exception classes does not describe the circumstances under which the exceptions are thrown. Some functions do discuss their exceptions, but I'm not sure if they all do. I was surprised that at throws bad_ptr_container_operation; I would have expected bad_index (this behavior *is* documented--I'm just saying it seems odd). Thanks for your work on these utilities. -- Ross Boylan wk: (415) 502-4031 530 Parnassus Avenue (Library) rm 115-4 ross(a)biostat.ucsf.edu Dept of Epidemiology and Biostatistics fax: (415) 476-9856 University of California, San Francisco San Francisco, CA 94143-0840 hm: (415) 550-1062

2 3

Re: [boost] Macros at namespace scope: trailing semicolon?
by Dave Gomboc 18 Jul '05

18 Jul '05

You were asking another, but... > 1) Do you think that the LOG() macro should contain a trailing > semicolon? The macro itself should, yes, so the user need not type one. > 2) I'm pretty sure you'll say #1, but which of the following examples > do you prefer? > > int foo() > { > LOG("NO SEMICOLON HERE?") // 1 > stuff(); > > LOG("OR does this seem better?"); // 2 > more_stuff(); > } #1. If someone did #2, yielding an extra, empty statement, it's not a tragedy, however (unless my compiler warned about such empty statements -- in which case I would delete the extraneous semicolon.) There's undoubtedly some compiler that boost supports that will do this, so best not to have the extra one there in the first place, I think. > 3) Do you see harm if the macro does not contain the trailing > semicolon? If so, what harm is it? Specifically, how does usage > #2 above re-enforce bad understanding of macros? (Or am I > misconstruing the nature of your objection?) It's logically inconsistent for the macro to not to perform its entire job. If that job is to "expand into an expression", certainly, it shouldn't generate a semicolon. If that job is to "expand into a statement", then just as certainly, it should. But its job ought not to be to "expand into a statement except for the trailing semicolon": that would be absurd. > 4) What is the important degree of indirection that I would be missing > by talking about the usage of the LOG macro as a call to the log > function? I understand that I could call it "a macro that expands > to a call to the log function" but I don't think that anyone would > be more enlightened by that. Other than being more detailed about > what's really happening, it's not clear to me what important > mistake is being made that bothers you. If our coding convention > states that macros are uppercase, then we already know it's a > macro, so simply repeating that is unnecessary, IMHO. Referring to it as the log function is clearly wrong. The listener might doubt your understanding, even if you knew perfectly well that it was indeed a macro that expanded to a function call. I see no disadvantage in referring to it as the LOG macro. Dave

1 0

Boost regression notification (2005-07-18)
by Douglas Gregor 18 Jul '05

18 Jul '05

Boost regression test failures ------------------------------ Report time: 2005-07-18T15:30:25Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. io Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 229 failures in 12 libraries: filesystem (2) io (1) multi_index (1) parameter (7) program_options (5) python (53) random (2) serialization (139) spirit (1) test (6) thread (2) wave (10) |filesystem| operations_test_dll: borland-5_6_4 path_test_dll: borland-5_6_4 |io| ios_state_unit_test: intel-win32-8_1 |multi_index| test_special_set_ops: vc-8_0 |parameter| basics: gcc-3_4_3-sunos vc-8_0 macros: gcc-3_4_3-sunos vc-8_0 sfinae: cw-8_3 gcc-3_4_3-sunos vc-8_0 |program_options| cmdline_test_dll: mingw-3_4_2 positional_options_test_dll: mingw-3_4_2 unicode_test_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_3-darwin |python| andreas_beyer: intel-win32-8_1 args: intel-win32-8_1 auto_ptr: intel-win32-8_1 back_reference: intel-win32-8_1 ben_scott1: intel-win32-8_1 bienstman1: intel-win32-8_1 bienstman2: intel-win32-8_1 bienstman3: intel-win32-8_1 builtin_converters: intel-win32-8_1 callbacks: intel-win32-8_1 const_argument: intel-win32-8_1 crossmod_exception: intel-win32-8_1 data_members: intel-win32-8_1 defaults: intel-win32-8_1 dict: intel-win32-8_1 docstring: intel-win32-8_1 enum: intel-win32-8_1 exception_translator: intel-win32-8_1 extract: intel-win32-8_1 implicit: intel-win32-8_1 injected: intel-win32-8_1 iterator: intel-win32-8_1 keywords: intel-win32-8_1 list: intel-win32-8_1 long: intel-win32-8_1 map_indexing_suite: intel-win32-8_1 minimal: intel-win32-8_1 multi_arg_constructor: intel-win32-8_1 nested: intel-win32-8_1 numpy: intel-win32-8_1 object: intel-win32-8_1 opaque: intel-win32-8_1 operators: intel-win32-8_1 pearu1: intel-win32-8_1 pickle1: intel-win32-8_1 pickle2: intel-win32-8_1 pickle3: intel-win32-8_1 pickle4: intel-win32-8_1 pointer_vector: intel-win32-8_1 polymorphism: intel-win32-8_1 polymorphism2: intel-win32-8_1 properties: intel-win32-8_1 raw_ctor: intel-win32-8_1 return_arg: intel-win32-8_1 shared_ptr: intel-win32-8_1 slice: intel-win32-8_1 staticmethod: intel-win32-8_1 str: intel-win32-8_1 test_pointer_adoption: intel-win32-8_1 try: intel-win32-8_1 tuple: intel-win32-8_1 vector_indexing_suite: intel-win32-8_1 virtual_functions: intel-win32-8_1 |random| random_test: intel-win32-8_1 intel-win32-8_1 |serialization| test_class_info_load_binary_archive: gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 test_class_info_load_binary_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 test_class_info_load_text_archive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 test_class_info_load_text_archive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 test_class_info_load_text_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 test_class_info_load_text_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-6_5 vc-7_1 vc-7_1 vc-8_0 test_class_info_load_xml_archive: gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 test_class_info_load_xml_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 test_class_info_load_xml_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 test_class_info_load_xml_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 test_const_load_fail1: borland-5_6_4 test_const_load_fail1_nvp: borland-5_6_4 test_const_load_fail2: borland-5_6_4 test_const_load_fail2_nvp: borland-5_6_4 test_const_save_fail1: vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail2: vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail3: vc-6_5 vc-6_5-stlport vc-7_0 test_demo: intel-win32-8_1 test_demo_dll: cw-9_4 cw-9_4 test_demo_exception: intel-win32-8_1 test_demo_exception_dll: cw-9_4 cw-9_4 test_demo_fast_archive_dll: vc-6_5 test_demo_pimpl_dll: vc-6_5 vc-7_0 test_demo_portable_archive: intel-win32-8_1 intel-win32-8_1 vc-7_0 vc-7_1 vc-7_1 vc-7_1 vc-7_1 vc-8_0 vc-8_0 vc-8_0 test_demo_portable_archive_dll: borland-5_6_4 intel-win32-8_1 intel-win32-8_1 test_demo_shared_ptr: cw-9_4 cw-9_4 cw-9_5-darwin intel-win32-8_1 test_demo_shared_ptr_dll: cw-9_4 cw-9_4 cw-9_5-darwin vc-6_5 vc-7_0 test_demo_xml_load: intel-win32-8_1 test_demo_xml_save: intel-win32-8_1 test_diamond_binary_archive: cw-8_3 cw-9_5-darwin test_diamond_binary_archive_dll: cw-9_5-darwin test_diamond_text_archive: cw-8_3 cw-9_5-darwin test_diamond_text_archive_dll: cw-9_5-darwin test_diamond_text_warchive: cw-8_3 cw-9_5-darwin test_diamond_text_warchive_dll: cw-9_5-darwin test_diamond_xml_archive: cw-8_3 cw-9_5-darwin test_diamond_xml_archive_dll: cw-9_5-darwin test_diamond_xml_warchive: cw-8_3 cw-9_5-darwin test_diamond_xml_warchive_dll: cw-9_5-darwin test_map_binary_archive_dll: vc-6_5 vc-7_0 test_map_text_archive_dll: vc-6_5 vc-7_0 test_map_text_warchive_dll: vc-6_5 vc-7_0 test_mi_xml_archive_dll: vc-8_0 test_mult_archive_types: cw-9_4 cw-9_4 cw-9_5-darwin test_mult_archive_types_dll: cw-9_4 cw-9_4 cw-9_5-darwin vc-6_5 test_non_default_ctor_text_archive_dll: cw-9_5-darwin test_non_default_ctor_text_warchive_dll: cw-9_5-darwin test_non_default_ctor_xml_archive_dll: cw-9_5-darwin test_non_default_ctor_xml_warchive_dll: cw-9_5-darwin test_non_intrusive_text_archive_dll: cw-9_5-darwin test_non_intrusive_text_warchive_dll: cw-9_5-darwin test_non_intrusive_xml_archive_dll: cw-9_5-darwin test_non_intrusive_xml_warchive_dll: cw-9_5-darwin test_registered_xml_archive: vc-8_0 |spirit| owi_mt_tests: gcc-3_3-darwin |test| errors_handling_test: cw-9_5-darwin vc-8_0 test_fp_comparisons: borland-5_6_4 test_tools_test: cw-9_4 cw-9_4 cw-9_5-darwin |thread| test_mutex: vc-7_1 test_thread: vc-6_5 |wave| test_re2c_lexer: vc-8_0 vc-8_0 test_slex_lexer: vc-8_0 vc-8_0 testwave: cw-8_3 cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux vc-8_0 vc-8_0

1 0