July 2005 - Boost - lists.boost.org

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

20 Jul '05

Boost regression test failures ------------------------------ Report time: 2005-07-19T15:08:59Z 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… 143 failures in 11 libraries: filesystem (4) io (1) lambda (1) multi_index (5) parameter (1) program_options (5) random (2) serialization (110) spirit (1) test (6) wave (7) |filesystem| operations_test_dll: borland-5_6_4 mingw-3_4_2 path_test_dll: borland-5_6_4 mingw-3_4_2 |io| ios_state_unit_test: intel-win32-8_1 |lambda| exception_test: vc-8_0 |multi_index| test_basic: intel-win32-8_1 test_mpl_ops: intel-win32-8_1 test_range: intel-win32-8_1 test_set_ops: intel-win32-8_1 test_update: intel-win32-8_1 |parameter| sfinae: cw-8_3 |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 |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 test_class_info_load_binary_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_archive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_archive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-6_5 test_class_info_load_xml_archive: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux 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: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail2: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail3: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_demo_dll: cw-9_4 cw-9_4 test_demo_exception_dll: cw-9_4 cw-9_4 test_demo_fast_archive_dll: msvc vc-6_5 test_demo_pimpl_dll: msvc 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-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 test_demo_shared_ptr_dll: cw-9_4 cw-9_4 cw-9_5-darwin msvc vc-6_5 vc-7_0 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_list_text_archive: vc-8_0 test_map_binary_archive_dll: msvc vc-6_5 vc-7_0 test_map_text_archive_dll: msvc vc-6_5 vc-7_0 test_map_text_warchive_dll: msvc vc-6_5 vc-7_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 msvc 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 |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 |wave| test_re2c_lexer: vc-8_0 test_slex_lexer: vc-8_0 testwave: cw-8_3 cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux vc-8_0

2 1

Re: [boost] Boost.Filesystem i18n mini-review
by Jan Hermelink 20 Jul '05

20 Jul '05

Russell Hind wrote: > Peter Dimov wrote: >> >> No. 8.3 aliases are optional on NTFS and turning them off improves >> the performance of the file system, sometimes significantly. >> > > Do you have any links to documentation on this (MSDN or whatever?) I > didn't realise you could disable that feature and would be interested > to > read about the advantages/disadvantages of doing so. Sorry, no link. Bit I have described the registry value for this in my other post. You also can use the "fsutil" command: fsutil.exe behavior query disable8dot3 queries your setting, and fsutil.exe behavior set disable8dot3 1 disables 8.3 alias generation. Jan

1 0

Re: [boost] Boost.Filesystem i18n mini-review
by Jan Hermelink 20 Jul '05

20 Jul '05

This is not (yet) a review, but I use your filesystem library in several unicode projects and am very interested in the wide char implementation. I have tried wpath and wpath_directory_iterator with two projects and run in several minor problems: - Building I can't build the DLLs on my system (Windows XP SP2, VC 7.1): path.cpp(51) : error C2491: 'boost::filesystem::wpath_traits::imbue' : definition of dllimport function not allowed Static builds run fine. - fstream.hpp: Declaration of function narrow_path(const std::wstring & file_ph, ...) If several filesystem fstream objects are declared in different translation units, the linker complains this symbol as multiple defined. Adding an inline specifier helps as workaround. - fstream.hpp: Implementation of function narrow_path(const std::wstring & file_ph, ...) This function doesn't work at all on my system, it returns always the empty string. Why is this 8.3 conversion needed, can this work on NTFS reliable? Replacing the current implementation thru a simple narrow conversion helps as workaround. - is_symlink() Why isn't this function implemented on Windows? A NTFS junction is symlink, isn't it? After fixing the above problems the library seems to run fine. Thank you for your work! Jan

3 3

Re: [boost] Boost.Filesystem i18n mini-review
by Jan Hermelink 20 Jul '05

20 Jul '05

Peter Dimov wrote: > Jan Hermelink wrote: > >> - fstream.hpp: >> Implementation of function narrow_path(const std::wstring & >> file_ph, ...) This function doesn't work at all on my system, it >> returns always the empty string. Why is this 8.3 conversion needed, >> can this work on NTFS reliable? > > No. 8.3 aliases are optional on NTFS and turning them off improves the > performance of the file system, sometimes significantly. Now I remember it: In fact I have turned off the 8.3 aliases for my machine months ago. I have set the registry value NtfsDisable8Dot3NameCreation (HKLM\System\CurrentControlSet\Control\FileSystem) to 1. Jan

1 0

[config] Why is BOOST_HAS_LONG_LONG defined in suffix.hpp?
by Markus Schöpflin 20 Jul '05

20 Jul '05

The first few lines of suffix.hpp currently look like this: #include <limits.h> # if !defined(BOOST_HAS_LONG_LONG) \ && !defined(BOOST_MSVC) && !defined(__BORLANDC__) \ && (defined(ULLONG_MAX) || defined(ULONG_LONG_MAX) || defined(ULONGLONG_MAX)) # define BOOST_HAS_LONG_LONG #endif What is the reason for this code being there? Isn't it enough to test for this in the platform/compiler/stdlib config? I'm asking this question because currently stdlib/libstdcpp3.hpp explicitely turns off BOOST_HAS_LONG_LONG when the library indicates that there is no support for long long, and this is foiled by the code in suffix.hpp, which turns on BOOST_HAS_LONG_LONG again. (And this causes errors with gcc-3.3.x on Tru64.) Maybe we need two config macros for this? One for BOOST_COMPILER_HAS_LONG_LONG, and one for BOOST_STDLIB_HAS_LONG_LONG? Comments or thoughts, anyone? Markus

4 7

Re: [boost] multi_array 64-bit patch
by Thomas Klimpel 20 Jul '05

20 Jul '05

Ronald Garcia wrote: > I made the changes you show below thanks > with the exception of the switch to ptrdiff_t for the index type. > It's not obvious to me that that is the correct change to make I have to admit that the name "std::ptrdiff_t" sounds strange in the context of "index", but there are some container classes in boost that use std::ptrdiff_t as the argument type for operator[], "boost::scoped_array" and "boost::shared_array" for example. And I think "std::ptrdiff_t" makes perfect sense as the index type for an operator[] that accepts both negative and positive integers. There might be types with more comforting names like typedef boost::intmax_t index; // from "boost/cstdint.hpp" typedef boost::detail::integer_traits<std::size_t>::difference_type index; // from "boost/detail/numeric_traits.hpp" typedef intmax_t index; typedef intptr_t index; but "intmax_t" and "intptr_t" seem to be more part of the "c standard" than of the "c++ standard", and the boost types don't help me with the annoying warnings on 32-bit windows with Visual C++.NET. On 32-bit windows, size_t is defined as "typedef _W64 unsigned int size_t;" where the _W64 just means that I will get warning messages, if I convert this type to a type without _W64. Now ptrdiff_t works for me, because it is defined as "typedef _W64 int ptrdiff_t;". Besides the warnings issue, "boost::detail::multi_array::index" should be a signed integer type, that satisfies the assertion "assert(sizeof(boost::detail::multi_array::index) == sizeof(std::size_t));". While this assertion will probably be satisfied on all current platforms, it is not garantied by the standard, which just reads: "The types are 'ptrdiff_t' which is the signed integer type of the result of substracting two pointers; 'size_t' which is the unsigned integer type of the result of the sizeof operator;". Thanks, Thomas

1 0

extra semicolons
by Arkadiy Vertleyb 19 Jul '05

19 Jul '05

Hi all, Not having extra semicolons is one of the strongest arguments against incuding a trailing semicolon into a statement-generating macro. Can anybody explain why having an extra semicolon is considered a potential problem by some compilers? Isn't null as good as any other number? Shouldn't an empty statement be considered as good as any other statement? Regards, Arkadiy

6 15

Generic Factory Library
by Dean Michael Berris 19 Jul '05

19 Jul '05

Good Day, For the past few years, I have been exposed to both C++ software development as well as Java software development. I have been lucky enough to get to use many different frameworks from both languages (ACE in C++ and countless othes in Java). Introductions aside, I would like to ask whether a generic object factory implementation would be best put in a framework or a library. What I am looking for is something to the effect of the Spring [1] framework but in C++. With the issues like late/dynamic binding having many different implementations in many different platforms, the best I could conceptualize is a static template for different object types. What I'm looking for is something that will be able to allow me to forget about reimplementing the static factory every time I need it, and use a generic template instead. Something that will allow me the following functionalities: <code> // return a reference to a _huge_ statically allocated object, // too impractical to always instantiate whenever an instance of it // is needed: static_factory<Object> ObjectFactory; ... Object & object1 = ObjectFactory.getObject(); ... // later perhaps Object & object2 = ObjectFactory.getObject(); ... // later still Object & object3 = ObjectFactory.getObject(); </code> For other cases when I want a different instance returned every time I need a reference to something new, there's a dynamic_factory -- returning a pointer or reference to an object: <code> dynamic_factory<Object> ObjectFactory; Object instance1 = ObjectFactory.getObject(); std::auto_ptr<Object> instance2 (ObjectFactory.getObject()); </code> -- Of course, it is assumed that `Object' has a default constructor in both dynamic_factory and static_factory. Do you know of anything similar to these already? Otherwise, I would be most glad to put up a sample implementation soon. TIA PS. Perhaps XML definition files may be used to provide object registration when the factory is used dynamically to load object definitions from dynamic libraries. -- Dean Michael C. Berris <mikhailberis(a)free.net.ph> GPG Key: 0x08AE6EAC http://mikhailberis.blogspot.com Mobile: +63 921 7841815

3 4

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