- Boost - lists.boost.org

[ublas] matrix.hpp doesn't compile with Borland bcc32 5.6.4
by Nicola Musatti 08 Dec '04

08 Dec '04

Hallo, A translation unit that only includes #include <boost/numeric/ublas/matrix.hpp> from Boost 1.32.0 doesn't compile with Borland's bcc32 5.6.4 (BCB6 with Update 4), but it used to with Boost 1.31.0 . I get the following error messages: Build [C++ Error] traits.hpp(349): E2285 Could not find a match for 'std::abs(const _STL::complex<float>)' [C++ Error] traits.hpp(354): E2285 Could not find a match for 'std::sqrt(const _STL::complex<float>)' [C++ Error] traits.hpp(419): E2285 Could not find a match for 'std::abs(const _STL::complex<double>)' [C++ Error] traits.hpp(424): E2285 Could not find a match for 'std::sqrt(const _STL::complex<double>)' [C++ Error] traits.hpp(486): E2285 Could not find a match for 'std::abs(const _STL::complex<long double>)' [C++ Error] traits.hpp(491): E2285 Could not find a match for 'std::sqrt(const _STL::complex<long double>)' [C++ Error] vector.hpp(813): E2356 Type mismatch in redeclaration of 'T' [C++ Error] vector.hpp(804): E2344 Earlier declaration of 'T' [C++ Error] vector.hpp(819): E2356 Type mismatch in redeclaration of 'T' [C++ Error] vector.hpp(805): E2344 Earlier declaration of 'T' [C++ Error] vector.hpp(1030): E2356 Type mismatch in redeclaration of 'T' [C++ Error] vector.hpp(1022): E2344 Earlier declaration of 'T' Cheers, Nicola Musatti

1 0

Solaris+gcc regression errors should be marked expected
by Caleb Epstein 08 Dec '04

08 Dec '04

Sorry, I think I sent an empty message just before this one. Please ignore it. There are several test failures for date_time and other Boost libs on sunos5+gcc (see for example http://tinyurl.com/4y6tx) that are due to incomplete wide character support on that platorm. This situation appears to be similar to a number other configurations (e.g. win32+mingw) which have a similar or identical tests marked as expected failures in the test matrix. I think sunos5+gcc should be treated similarly. Here is the relevant section of boost/config/stdlib/libstdcpp3.hpp: #if !defined(_GLIBCPP_USE_WCHAR_T) && !defined(_GLIBCXX_USE_WCHAR_T) # define BOOST_NO_CWCHAR # define BOOST_NO_CWCTYPE # define BOOST_NO_STD_WSTRING # define BOOST_NO_STD_WSTREAMBUF #endif -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

Name checking in filesystem
by Walter Landry 08 Dec '04

08 Dec '04

Greetings, I have come across an annoying problem with the filesystem library. I have wrapped filesystem with Swig so that I can call it from python. I had to rewrite the filesystem::path implementation a little because Swig can't handle nested classes. In any case, once I got that sorted out, I wanted to do something like p=path(".bar") which doesn't work because filenames starting with a period are not allowed by the default name checking routine. Argh. Unfortunately, I can't figure out how to change the default name checker from python. If I worked at it long enough, I could probably work it out. But I am sure that I don't want to have to run something like path.default_name_check(no_check) at the beginning of every 10 line script. It is a particular piece of functionality (name checking) that just gets in the way. I would wager that most people using boost::filesystem from scripts would not want to have to deal with it, since it is completely different from every other portable, cross platform filesystem API. So to make a long story short, I think the default for boost::filesystem should be not to check for "portable" paths. This is different from a position I took earlier, where I thought that it is ok if I only have to set it once at the beginning. That is acceptable for large programs, but not for small ones. Regards, Walter Landry wlandry(a)ucsd.edu

6 14

[review-results] Smart Container Library
by Pavol Droba 08 Dec '04

08 Dec '04

Hi, I hereby announce that the Smart Container library is ACCEPTED into Boost. Congratulations and thanks to Thorsten Ottosen for providing us with this library. Most of the reviewers were in favor of acceptance, but there were several requests for improvements. I have consulted them with Thorsten and he proposed to do following changes. I consider them sufficient for acceptance. 1. add support for boost.range in insert functions, constructors etc 2. use void* implementation 3. improve docs as discussed during the review 4. add support for null values: - remove preconditions - add functions is_null( size_t idx ); is_null( iterator ); 5. add more debug checks after access to ptr_begin(), ptr_end() 6. reconfigure policies: ptr_vector<T,clone_manager> becomes ptr_vector<T,clone_allocator = something, std::allocator<T*> = std::allocator<T*> > or perhaps ptr_vector<T,clone_allocator = something< std::allocator<T* > > 7. improve tests I also suggest, that before the inclusion of the library into the boost distribution, the library should be brought in the discussion to verify, that all issues above have been addressed. Best Regards, Pavol Droba Review Manager

2 1

[date_time] SunPRO patch for date_names_put facet
by Caleb Epstein 07 Dec '04

07 Dec '04

The following patch is required to build date_time using the Sun Workshop C++ compiler. I mentioned this previously in another thread, but I fear it has been lost. --- boost/date_time/date_names_put.hpp~ 2004-12-01 08:58:32.846228000 -0500 +++ boost/date_time/date_names_put.hpp 2004-12-01 08:59:38.334228000 -0500 @@ -52,6 +52,11 @@ typedef std::basic_string<charT> string_type; static std::locale::id id; + +#if defined (__SUNPRO_CC) && defined (_RWSTD_VER) + std::locale::id& __get_id (void) const { return id; } +#endif + void put_special_value(iter_type& oitr, special_value_enum sv) const { do_put_special_value(oitr, sv); -- Caleb Epstein caleb dot epstein at gmail dot com

2 1

Two more logos...
by JOAQUIN LOPEZ MU?Z 07 Dec '04

07 Dec '04

...to add to the bunch. Variations on a previous theme. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 3

duplicate source files in boost- utf8_codecvt_facet
by Robert Ramey 07 Dec '04

07 Dec '04

We now have a at least one set of files more or less duplicated in boost. Ron Garcia's utf8_codecvt_facet is included in: boost/utf8_codecvt_facet.hpp boost/detail/utf8_codecvt_facet.hpp boost/libs/serialization/src/utf8_codecvt_facet.cpp boost/libs/program_options/detail/utf8_codecvt_facet.cpp boost/libs/doc/serialization/utf8_codecvt_facet.html boost/libs/serialization/test/test_utf8_codecvt_facet.cpp Leaving aside how this came to be, I would like to do the following: boost/detail/utf8_codecvt_facet.hpp boost/libs/detail // new directory boost/libs/detai/src/utf8_codecvt_facet.cpp boost/libs/detail/test/test_utf8_codecvt_facet.cpp boost/libs/detail/doc/utf8_codecvt_facet.html This would make both the serialization and program options libraries that much smaller and server our needs until a reviewed version of codecvt facets in added to boost. Robert Ramey

7 11

Program Options Custom Notifier Function Order of Execution
by Tony Han Bao 07 Dec '04

07 Dec '04

Hi all, Can anyone tell me the precise definition or behaviour of the order of execution of the user supplied functions to handle command line options defined in boost program options library. For example, my option menu was defined as follows boost::program_options::options_description menu("Valid Options"); menu.add_options() ("help,h", "Display this menu.") ("time,t", boost::program_options::value<double>(&time_arg_value) -> notifier(&my_function1) "Description of option") ("memory,m", boost::program_options::value<double>(&memory_arg_value) -> notifier(&my_function2), "Description of option") ("file,f", boost::program_options::value<std::vector<std::string> >(&file_arg_value) -> composing() -> notifier(&file_arg_handler<std::vector<std::string> >), "Something"); boost::program_options::variables_map menu_map; boost::program_options::store(boost::program_options:: parse_command_line(argc, argv, menu), menu_map); boost::program_options::notify(menu_map); Question is: Will the following two calls to the program result in different behaviour? >./Test --time 76 --memory 97 --help >./Test --memory 97 --time 76 --help I want my two functions for time and memory be independent of each other but I would like the function be called in the same order as the options specified on the command line. Sure I can test but can someone guarantee that what I discovered will remain valid in the future release of the library. Another question: What will happen if this program was called on the command line with the following options. >./Test --file myfile1 --time 87 --file myfile2 Will the file_arg_handler be called first with composed arguments and then time function (my_function1) or will the time function (my_function1) be called first and then the file_arg_handler function. Can I count on it that what happens will always happen in the future? Is there definitions for the order of execution guarantee by the library? Thanks in advance for your help! Best Regards, Tony Han Bao tonybao(a)mac.com

3 8

[named_params] member function overload autogen macro
by Cromwell Enage 07 Dec '04

07 Dec '04

It turns out that class member function definitions that take in named parameters will not compile with BOOST_NAMED_PARAMS_FUN. The first two lines of this macro, meant to generate the function prototype so that free function overloads can call it, cause a "duplicate definition" error when the macro is used in a class body. Fortunately, removing those two lines to create the BOOST_NAMED_PARAMS_MEMBER_FUN macro was all that was needed to eliminate the error. Sooo...here's yet another patch, along with a two-file program illustrating both macros in action. Cromwell D. Enage P.S. I better start adding my middle initial, to match with the name I use in my licensing info. __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

1 0

no auto-link for serialization
by Martin Slater 07 Dec '04

07 Dec '04

Posted before but being a lemon I put filesystem in the subject instead of serialisation, please see No auto-link for filesystem message from yesterday. sorry Martin

2 1