- Boost - lists.boost.org

[admin] Overlapping reviews -- should this be allowed?
by Jeff Garland 10 Sep '04

10 Sep '04

Hi all - Our review wizard, Tom B. has suggested to me that we allow subsequent reviews to begin even if a previous review has been extended. This means 2 or more reviews will possibly be running in parallel. I don't believe we have a written policy, but I'm quite certain we have never run reviews in parallel. I also think it is a very bad idea. I believe reviews will suffer because people that want to review all the libraries in progress and participate in the discussion will not have enough time to do so. For most of us boost is a part-time thing -- we only have so much time per week to participate... This leads me to the conclusion that the current review schedule needs to be redone. 1st because IOStreams has been extended and 2nd because we agree that the current schedule is too aggressive. See http://lists.boost.org/MailArchives/boost/msg11034.php I realize it is a major pain to rearrange the agreed dates, but I don't think overlapping reviews is the answer. Thoughts? Jeff

11 26

Filesytem compile problem
by Martin 10 Sep '04

10 Sep '04

I get a compile error in boost/filesystem/operations.hpp when building an application that also uses the date_time library (using current CVS files). The problem is that date_time includes boost/operator.hpp which defines the template boost::equivalent. The name collides with boost::filesystem::equivalent. Reordering the include files (filesystem before date_time) fixes the problem for me but since boost/operators.hpp is used in a lot of libraries it might not always be that easy.

2 1

intel problems
by Pavol Droba 10 Sep '04

10 Sep '04

Hi, Most of tests in intel-win32-7.1-vc6-stlport-4.5.3 toolset are failing for the string_algo lib. Here is the output: http://tinyurl.com/5l2k4 All are linkinig errors. So there is probably an error in my jamfiles. Can somebody give me a hint what's wrong? Thanks, Pavol

1 0

RE: [boost] [filesystem] large file support test added
by Ben Hutchings 10 Sep '04

10 Sep '04

Beman Dawes <bdawes(a)acm.org> wrote: <snip> > Normally we would have a regression test that identifies the systems > which fail. But we don't test large file support directly because to > do so would be a burden on those who run the regression tests; such > tests would chew up gigabytes of disk space and might also be very > slow. <snip> why so? Unix file-systems support sparse files, as does NTFS.

2 1

[serialization] - xml bug?
by Jeff Flinn 10 Sep '04

10 Sep '04

Robert, The following demonstrates a problem with serialization of strings conataining '<' and/or '>'. This is on VC7.1 using serialization20 with boost_1_13_0. I'm not in a position to check this on the CVS version at this time. Is this still an issue? Thanks, Jeff ///////////////////////////////////////// #include <boost/archive/xml_oarchive.hpp> #include <boost/archive/xml_iarchive.hpp> #include <string> #include <fstream> int main(int argc, char* argv[]) { std::string lStringOut("<empty>"); { std::ofstream lOut( "C:/xmltest.xml" , std::ios_base::out | std::ios_base::trunc ); if( lOut.good() ) { boost::archive::xml_oarchive oa( lOut ); oa << boost::serialization::make_nvp( "MyString", lStringOut ); } } std::string lStringIn; { std::ifstream lIn( "C:/xmltest.xml" ); if( lIn.good() ) { boost::archive::xml_iarchive ia( lIn ); ia >> boost::serialization::make_nvp( "MyString", lStringIn ); } } assert( lStringOut == lStringIn ); return 0; }

1 0

[filesystem] large file support test added
by Beman Dawes 10 Sep '04

10 Sep '04

Something special (defining some preprocessor macro) has to be done for 32-bit POSIX-like operating systems to enable support for file sizes greater than can be represented by 31 bits. The exact preprocessor macro name that has to be defined varies from system to system. Boost Filesystem currently supplies the correct macro for Linux, but not some of the UNIX systems. Normally we would have a regression test that identifies the systems which fail. But we don't test large file support directly because to do so would be a burden on those who run the regression tests; such tests would chew up gigabytes of disk space and might also be very slow. It recently occurred to me that sizeof(stat.st_size) > 4 is a pretty good surrogate for an actual test on a large file. While in theory it could yield a false positive, in practice it should identify whether or not large file support has been correctly enabled. It should never yield a false negative. Accordingly, I've added a new regression test, large_file_support_test.cpp. Initially it should pass on Windows and Linux systems, but fail on any UNIX systems that need additional macros defined. We can then experiment with adding additional macro definitions to get the test to pass on any systems it is currently failing. --Beman

1 0

dynamically created program options
by Rodolfo Schulz de Lima 10 Sep '04

10 Sep '04

Hi, I wonder if it's possible to handle dynamically created program options with boost::program_options. For instance: I have a config file that specifies configure options for dynamic loaded modules in my project. So the cfg file would be: [module.foo1] module_file = foo.so listen_port = 564 enabled = true [module.foo2] module_file = foo.so listen_port = 565 enabled = false [module.bar1] module_file = bar.so listen_port = 145 enabled = true As can be seen, foo1, foo2 and bar1 names are defined by the user in the configure file, and the program doesn't know about them before parsing the configuration. But if we parse that (somehow), an exception saying that the option "module.foo1.module_file" is invalid will be thrown. Can I manage the options_description "on the fly"? Another less complicated situation would be something like this: modules = foo1 foo2 bar1 [module.foo1] . . . [module.foo2] . . . [module.bar1] . . . So when parsing the "modules" option, we would know the new options name and it would be a matter of appending more option descriptions to the object. Regards, rod

2 1

ublas::vector from std::vector
by Neal D. Becker 10 Sep '04

10 Sep '04

I noticed there is no constructor for ublas::vector that takes a pair of iterators. Is there no direct way to construct a ublas::vector from a std::vector? Could there either be a constructor: (STL-style) template<typename input_iterator> vector (input_iterator begin, input_iterator end); or: (range-style) template<typename cont_t> vector (cont_t const&)

1 0

mingw build failed at regex
by Jim Pritts 10 Sep '04

10 Sep '04

Hi all, I am compiling boost 1.31.0 with mingw. Specifically the packages I am using are: boost 1.31.0 with regex patch binutils-2.13.90-20030111-1.tar gcc-core-3.4.1-20040711-1.tar gcc-g++-3.4.1-20040711-1.tar mingw-runtime-3.3.tar Boost builds find until bjam reaches the regex library. There seems to be a problem with wide character streams in the regex library. I don't think the latest mingw supports wide character streams. Is this correct? If so, how do I compile the regex library? If there is no workaround, is it possible to use mingw with STLPort and boost? The following is an excerpt form the actual error message I get: g++ -c -Wall -ftemplate-depth-100 -DBOOST_REGEX_CONFIG_INFO=1 -DBOOST_REG EX_DYN_LINK=1 -g -O0 -fno-inline -mno-cygwin -I"c:\build\bin\boost\libs\regex \build" -I "C:\boost_1_31_0" -o "c:\build\bin\boost\libs\regex\build\boost_reg ex.dll\mingw\debug\c_regex_traits.obj" "C:/boost_1_31_0/libs/regex/build/../src /c_regex_traits.cpp" ...failed gcc-C++-action c:\build\bin\boost\libs\regex\build\boost_regex.dll\min gw\debug\c_regex_traits.obj... gcc-C++-action c:\build\bin\boost\libs\regex\build\boost_regex.dll\mingw\debug\c _regex_traits_common.obj gcc-C++-action c:\build\bin\boost\libs\regex\build\boost_regex.dll\mingw\debug\c pp_regex_traits.obj C:/mingw/bin/../lib/gcc/mingw32/3.4.1/../../../../include/c++/3.4.1/streambuf: I n instantiation of `std::basic_streambuf<wchar_t, std::char_traits<wchar_t> >': C:/boost_1_31_0/libs/regex/build/../src/cpp_regex_traits.cpp:92: instantiated from `<unnamed>::parser_buf<wchar_t, std::char_traits<wchar_t> >' C:/boost_1_31_0/libs/regex/build/../src/cpp_regex_traits.cpp:590: instantiated from here C:/mingw/bin/../lib/gcc/mingw32/3.4.1/../../../../include/c++/3.4.1/streambuf:13 5: error: no type named `pos_type' in `struct std::char_traits<wchar_t>' C:/mingw/bin/../lib/gcc/mingw32/3.4.1/../../../../include/c++/3.4.1/streambuf:23 4: error: no type named `pos_type' in `struct std::char_traits<wchar_t>' C:/mingw/bin/../lib/gcc/mingw32/3.4.1/../../../../include/c++/3.4.1/streambuf:23 9: error: no type named `pos_type' in `struct std::char_traits<wchar_t>' C:/mingw/bin/../lib/gcc/mingw32/3.4.1/../../../../include/c++/3.4.1/streambuf:57 4: error: no type named `pos_type' in `struct std::char_traits<wchar_t>' C:/mingw/bin/../lib/gcc/mingw32/3.4.1/../../../../include/c++/3.4.1/streambuf:58 6: error: no type named `pos_type' in `struct std::char_traits<wchar_t>' C:/boost_1_31_0/libs/regex/build/../src/cpp_regex_traits.cpp: In instantiation o f `<unnamed>::parser_buf<wchar_t, std::char_traits<wchar_t> >': C:/boost_1_31_0/libs/regex/build/../src/cpp_regex_traits.cpp:590: instantiated from here ... Thanks, Jim.

2 1

Empty member optimization
by Joao Abecasis 10 Sep '04

10 Sep '04

Hi! I have written a small utility class to provide "empty member optimization" for arbitrary types. The implementation makes use of the empty base class optimization (EBCO) but avoids injection of the class. A uniform and contained interface is exposed wether the optimization applies or not: template <typename T, size_t Index> compressed_pair { // several constructors may be provided but, for now, // default and copy constructor typedef T value_type; value_type & get(); value_type const & get() const; }; I believe this could be used as the basis for a compressed_tuple. Here's a sample use: template <typename T0, typename T1> struct A : private compressed_member<T0> , private compressed_member<T1, 1> { typedef compressed_member<T0> member0; typedef compressed_member<T1, 1> member1; T0 const & first() { return base0::get(); } T1 const & second() { return base1::get(); } }; There is a catch with the current implementation: some regular empty member (or regular empty member of some compressed_member) could end up sharing address with an empty compressed_member. This happens because compressed_member<T> does not inherit from T but hides this "relationship" from the compiler. Is there any interest in such an utility? To test compressed member I wrote another (toy) utility: empty_store. empty_store is an empty class with a static map that associates an instance's address to data. Checks are made everywhere to ensure that no two instances share the same address. The code can be found (zipped) here: *http://tinyurl.com/4e85l* Best regards, João Abecasis

4 8