- Boost-users - lists.preview.boost.org

Memory leak while compiling boost
by Martin Gebert 31 Dec '04

31 Dec '04

Hi! I tried to compile the boost lib from source with $ bjam "-sTOOLS=gcc" but while compiling the process "cc1plus" tends to consume memory quite fast, finally bringing the machine to a halt. Environment: SuSE 8.2, Kernel 2.4.20, all updates gcc (GCC) 3.3 20030226 (prerelease) (SuSE Linux) boost-jam 3.1.10 (also made from source) boost 1.32.0 My fault or a boost/bjam problem? Thanks in advance! Martin

2 5

boost graph gives compile error on VC++ 7.1
by gast 128 31 Dec '04

31 Dec '04

Dear all It's already posted, but there was not a really good answer. If you take from boost graph 'examples/file_dependencies.cpp' and strip down some code, but change the graph type to: typedef adjacency_list<listS, listS, directedS, property<vertex_color_t, default_color_type>, property<edge_weight_t, int> > Graph; Graph g; default_dfs_visitor vis; depth_first_search(g, visitor(vis)); It gives C2678 on VC++ 7.1. Does anyone know what's wrong/possible work around? Wkr me _________________________________________________________________ MSN Search, for accurate results! http://search.msn.nl

3 2

boost::regex partial matches
by L.P. Mergen 31 Dec '04

31 Dec '04

Hello, I apologise in advance if this question is not direct to the right mailinglist, but this was the best I could find. The IRC channel also seems very quite... :) I am currently experimenting with the boost::regex library, and so far it seems to do just the thing I need. However, when I have a regex "[0-9]+[a-zA-Z]+" And want to match this against the string "42foo 42bar" It returns false. This is (as far as I can see) due to the library not taking partial matches too, even when I set the boost::match_partial and boost::match_any flags (which, according to my interpretation, should be doing the trick). Here is my statement: bool success = boost::regex_match(subject->c_str(), returns, expression, boost::match_partial | boost::match_any); I hope anyone has an idea what might be the problem here. Thanks in advance! :) Grt, Leon Mergen

5 5

[iostreams] flush in sink method (newbie)
by Daniel Schlyder 30 Dec '04

30 Dec '04

Hi, I have a class derived from boost::io::sink that I use as follows: boost::io::stream_facade<printsink> os; os << "foo" << std::flush; os->set_colour(255, 255, 0); os << "bar"; How can I flush the buffer in set_colour() method instead of requiring the user to do it? TIA, -- Daniel Schlyder http://bitblaze.com/

2 1

spirit problem
by Cory Nelson 30 Dec '04

30 Dec '04

Hello again, I am trying to use Spirit to parse lines like: name:value but, name might contain colons also. I've not been able to come up with anything that parses this correctly without swallowing up the rest of the document. Anyone able to help? -- Cory Nelson http://www.int64.org

3 2

Functors and function_traits<>
by Hossein Haeri 29 Dec '04

29 Dec '04

Dear all, Yep, again it's me, and it's agian function_traits<>... AFAIK, std::iterator_traits<> is one of the counterparts of function_traits<>, not? A sort of symmetry which iterator_traits<> has got is that it can work for Iterators as well as plain pointers. This seems to be not the case for function_traits<>. That is, you can pass a function type to it, but you can't do that for a functor. Is that right? If it is, a big drawback turns out to happen for variations of the following which are not that few common: template < typename ..., ..., typename Function > struct Foo { typedef typename function_traits<Function> ::result_type result_type; Foo (Function f) : f_(f) {} //... result_type operator () () {/*..*/} Function f_; }; This well works for sth like this: double f(double) {/*...*/} Foo<blah, ..., double (&) (double)> foo(f); But it does not work with the following: struct F { double operator () () {/*...*/} }; Foo f; Foo<blah, ..., F> foo(f); Is this what it should be? Or am I missing anything? In fact, the following code: struct F { double operator () (double x) const {return f(x);} }; typedef boost::function_traits<F>::result_type result_type; makes GCC 3.3.1 to give me an error like the previous one. This is what it says: Compiler: Default compiler Building Makefile: "C:\Documents and Settings\Hossein\My Documents\My Programmes\Probability I\Distributions\7.2.1\Makefile.win" Executing make... make.exe -f "C:\Documents and Settings\Hossein\My Documents\My Programmes\Probability I\Distributions\7.2.1\Makefile.win" all g++.exe -D__DEBUG__ -c 7_2_1Main.cpp -o 7_2_1Main.o -I"C:/Dev-Cpp/include/c++/3.3.1" -I"C:/Dev-Cpp/include/c++/3.3.1/mingw32" -I"C:/Dev-Cpp/include/c++/3.3.1/backward" -I"C:/Dev-Cpp/lib/gcc-lib/mingw32/3.3.1/include" -I"C:/Dev-Cpp/include" -pg -g3 7_2_1Main.cpp: In instantiation of `boost::function_traits<F>': 7_2_1Main.cpp:70: instantiated from `inverse_variate_generator<main()::Engine, main()::Distribution, F>' 7_2_1Main.cpp:106: instantiated from here 7_2_1Main.cpp:70: error: base class `boost::detail::function_traits_helper<F*>' has incomplete type 7_2_1Main.cpp: In instantiation of `inverse_variate_generator<main()::Engine, main()::Distribution, F>': 7_2_1Main.cpp:106: instantiated from here 7_2_1Main.cpp:70: error: no type named `result_type' in `struct boost::function_traits<F>' 7_2_1Main.cpp:76: error: no type named `result_type' in `struct boost::function_traits<F>' 7_2_1Main.cpp: In function `int main()': 7_2_1Main.cpp:113: error: no match for call to `( inverse_variate_generator<main()::Engine, main()::Distribution, F>) ()' 7_2_1Main.cpp:117: error: no match for call to `( inverse_variate_generator<main()::Engine, main()::Distribution, F>) ()' make.exe: *** [7_2_1Main.o] Error 1 Execution terminated What's wrong with it? Am I missing anything? If I'm not missing anything, then what is the work-around? I find myself right in expecting myself to be able to write a functor (like Foo) which can work equaly well with both function pointers and functors, as like as how the Standard algorithms do. Am I right? Or am I right? ;) TIA, --Hossein __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo

3 5

PROBLEM: How to determining the correct type to use at run time?
by Stephen torri 29 Dec '04

29 Dec '04

I want to expand the File_Base virtual interface here to allow me to pass the 'file_data' from the File class without have two sets of code: if (size == 32) 32 bite code else 64 bite code How do I expand the File_base interface? Is there a way to grab the type of a variable passed into a function and reuse it at run time? So that one time doSomething would have the following if the 'file_data' variable was passed in the File_Base interface: void doSomething (boost::shared_ptr<File_Base> const& f) { File<32> a = f->get_File(); // do 32 bit code } While another time the function code be: void doSomething (boost::shared_ptr<File_Base> const& f) { File<64> a = f->get_File(); // do 64 bit code } I would like to be generic so I don't have to repeat the same code. Stephen --------- SAMPLE PROGRAM -------- #include <iostream> #include <boost/shared_ptr.hpp> /*! \brief Type Mapper type */ template <int size> struct Type_Mapper; /*! \brief 32-bit Type Mapper */ template <> struct Type_Mapper<32> { /*! \brief 32-bit type */ typedef uint32_t arch_t; }; /*! \brief 64-bit Type Mapper */ template <> struct Type_Mapper<64> { /*! \brief 64-bit type */ typedef uint64_t arch_t; }; class File_Base { public: virtual uint32_t const get_Size() = 0; }; template <uint32_t size> class File : public File_Base { public: virtual uint32_t const get_Size() { return size; } typename Type_Mapper<size>::arch_t file_data; }; void doSomething (boost::shared_ptr<File_Base> const& f) { // Needs to access the variable 'file_data' in File<size> // Problem: How to expand File_Base interface so that // the variable 'file_data' can be returned without have // code like: if (f->get_Size() == 32) { // do 32 bit code } else { // do 64 bit code } } void create (void) { boost::shared_ptr<File_Base> f (new File<32>()); doSomething (f); } int main (int, char*) { create (); return 0; }

1 0

[iostreams] New version available
by Jonathan Turkanis 29 Dec '04

29 Dec '04

Dear All, The latest version of the Iostreams library is now available: http://home.comcast.net/~jturkanis/iostreams/ I'd like to thank everyone who sent me bug reports after I posted the previous version. I will include you in the acknowledgments when I rewrite the documentation. Contents: - I. Changes - II. Supported platforms - III. Remaining bugs. ----- I. Changes. There are two important changes. First, the code conversion component has been renamed "code_converter", and it now has an optional Codecvt template parameter. Example. #include <boost/iostreams/code_converter.hpp> #include <boost/iostreams/device/mapped_file.hpp> // Perform code conversion using the global locale: typedef code_converter<mapped_file_source> wide_mapped_file_source; // Perform code conversion using utf8_codecvt_facet: typedef code_converter< mapped_file_source, utf8_codecvt_facet<wchar_t> > utf8_mapped_file_source; code_converter has now been tested with all the codecvt facets from the Dinkumware CoreX library. Second, there is now an option to build the libraries zlib and bzip2 from the source, rather than linking to a pre-built version. To build zlib from the source, define the following variables: ZLIB_SOURCE - path to the .co files ZLIB_INCLUDE - path to the .he files, if different from ZLIB_SOURCE To link to a pre-built version, define the following variables: ZLIB_INCLUDE - path to the .h files ZLIB_LIBPATH - path to the library or archive file ZLIB_BINARY - name of the library or archive file If ZLIB_LIBPATH is not defined, it is assumed that the library file is in a location where it will be found automatically. If ZLIB_BINARY is not defined, it defaults to "z" on UNIX and Cygwin, and to "zdll" on windows (see http://www.gzip.org/zlib/DLL_FAQ.txt) Similar remarks apply for bzip2. ----- II. Supported platforms The tests have been run on the following platforms: VC7.1 with Dinkumware GCC 3.2 (MinGW) GCC 3.4.2 (MinGW) GCC 3.4.1 (Cygwin) CodeWarrior 8.3 (static runtime only) Intel 7.1 with Dinkumware (static runtime only) Intel 8.0 with Dinkumware Borland 5.6.4 with STLPort Failures: - GCC (MinGW, Cygwin): wide streams not supported - Borland 5.6.4: undiagnosed runtime errors in seekable_file_test.cpp, direct_adapter_test.cpp and code_converter_test.cpp III. Remaining bugs. Although the bzip2 tests pass on all the platforms in II, there is an outstanding problem reported by Michel Decima which I haven't been able to fix yet. Best Regards, Jonathan

1 1

Help requested: is_directory fails unexpected
by Tiziano Müller 28 Dec '04

28 Dec '04

Hi all I'm developing a little application (at the moment with VS.NET) using the boost::filesystem part to keep it portable. In the code I use the is_directory() function which fails unexpected when testing files with special characters ("little squares") in it. I tracked it down to the GetFileAttributesA-function which gives the error 123 ("The filename, directory name, or volume label syntax is incorrect."). After reading some pages in the internet, I assume that the only two solutions would be a) rename all those files first or b) make an own solution with the (unicode-enabled) function GetFileAttributesW which makes my app less portable (and will give me some headaches again). Is there a better solution? Thanks in advance, Tiziano

2 1

function, bind & shared_ptr
by Roland Schwarz 28 Dec '04

28 Dec '04

I have found that it is bossible to create an in place functor like object by combining function, bind and shared_ptr. However altough it seems to work I am not sure whether this is safe usage. I would be glad if someone more knowledgeable had a look on it: class bar { void foo() { } }; boost::function<void ()> pfoo; int main(int argc, char* argv[]) { pfoo = boost::bind(&bar::foo, boost::shared_ptr<bar>(new bar)); pfoo(); // ... pfoo = 0; // this operation causes the ~bar dtor to be called return 0; } Thank you, Roland

3 5