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

boost.logging v2 compiler errors
by ope 20 Jan '08

20 Jan '08

Hi, I did try the boost.logging lib from svn http://svn.boost.org/svn/boost/sandbox/logging/ and got with the starter example the compiler errors: $ LANG=en g++ -Iboost/logging -Iboost/logging/lib/logging/samples/starter/ boost/logging/lib/logging/samples/starter/log.cpp -o log In file included from boost/logging/lib/logging/samples/starter/log.cpp:2: boost/logging/lib/logging/samples/starter/log.h:47: error: 'g_l' declared as function returning a function boost/logging/lib/logging/samples/starter/log.cpp: In function 'boost::logging::log_holder<boost::logging::logger_format_write<boost::logging::default_, boost::logging::default_, boost::logging::writer::threading::ts_write, boost::logging::default_, boost::logging::scenario::usage::detail_find_logger::find_logger<boost::logging::scenario::usage::logger_::favor::correctness, boost::logging::scenario::usage::logger_::change::often<10>, boost::logging::default_>::lock_resource<10> >, boost::logging::default_, boost::logging::override>& g_l()': boost/logging/lib/logging/samples/starter/log.cpp:14: error: new declaration 'boost::logging::log_holder<boost::logging::logger_format_write<boost::logging::default_, boost::logging::default_, boost::logging::writer::threading::ts_write, boost::logging::default_, boost::logging::scenario::usage::detail_find_logger::find_logger<boost::logging::scenario::usage::logger_::favor::correctness, boost::logging::scenario::usage::logger_::change::often<10>, boost::logging::default_>::lock_resource<10> >, boost::logging::default_, boost::logging::override>& g_l()' boost/logging/lib/logging/samples/starter/log.h:47: error: ambiguates old declaration 'int g_l()' boost/logging/lib/logging/samples/starter/log.cpp: At global scope: boost/logging/lib/logging/samples/starter/log.cpp:14: error: no matching function for call to 'boost::logging::ensure_early_log_creation::ensure_early_log_creation(int)' boost/logging/boost/logging/detail/log_keeper.hpp:86: note: candidates are: boost::logging::ensure_early_log_creation::ensure_early_log_creation(type&) [with type = int] boost/logging/boost/logging/detail/log_keeper.hpp:85: note: boost::logging::ensure_early_log_creation::ensure_early_log_creation(const boost::logging::ensure_early_log_creation&) boost/logging/lib/logging/samples/starter/log.cpp: In function 'void init_logs()': boost/logging/lib/logging/samples/starter/log.cpp:20: error: base operand of '->' is not a pointer boost/logging/lib/logging/samples/starter/log.cpp:21: error: base operand of '->' is not a pointer boost/logging/lib/logging/samples/starter/log.cpp:22: error: base operand of '->' is not a pointer boost/logging/lib/logging/samples/starter/log.cpp:23: error: base operand of '->' is not a pointer boost/logging/lib/logging/samples/starter/log.cpp:26: error: base operand of '->' is not a pointer boost/logging/lib/logging/samples/starter/log.cpp:27: error: base operand of '->' is not a pointer boost/logging/lib/logging/samples/starter/log.cpp:28: error: base operand of '->' is not a pointer On other examples I've got linker errors. Does exist some decencies? Thanks, Olaf

2 5

Re: [Boost-users] Memory Leak Detection output format
by Jamie Cook 20 Jan '08

20 Jan '08

Dieter, I've actually already found VLD, however I had some small problems with it... firstly it's a compile time library meaning that I'd have to include it into the stlport source and compile it in from the ground up rather than just linking. While this is doable (with a bit of work) my second problem was that it caused random crashes in my application ... this was much harder to work around :) Thanks to all for the suggestions however - has anyone ever had any luck with mpatrol? I've got the source downloaded however development stopped in 2001 as far as I can tell. Jamie -- Jamie Cook Research Engineer ………………………………………..………………… Veitch Lister Consulting Pty Ltd. Ground Floor, 80 Jephson St, PO Box 1054, Toowong, QLD 4066 AUSTRALIA Ph: +61 7 3870 4888 Fax: +61 7 3870 4446 Email: jamie.cook(a)veitchlister.com.au Web: www.veitchlister.com.au ………………………………………..…………………

1 0

[newbie question] how to get rid of vector of vectors using boost structures
by Michał Nowotka 19 Jan '08

19 Jan '08

Hello, In my app I'm using vector of vectors as a matrix but it has cumbersome interface especially accesing data. Does boost offer some more accurate data structure (it shuld be flexible as vector but with friendly interface)? -- Cheers Michał Nowotka

2 1

quick_tour example of BGL
by Rajesh Tengli 19 Jan '08

19 Jan '08

Hi, In the quick_tour example of Boost Graph Library and the documentation at this link http://www.boost.org/libs/graph/doc/quick_tour.html i think the edge_array for the example graph should be: Edge edge_array[] = { Edge(A,B), Edge(A,E), Edge(A,D),Edge(A,C), Edge(C,A), Edge(C,D), Edge(D,B),Edge(D,A), Edge(E,D), Edge(E,B), Edge(E,A)}; // 11 edges instead of the mentioned Edge edge_array[] = { Edge(A,B), Edge(A,D), Edge(C,A), Edge(D,C), Edge(C,E), Edge(B,D), Edge(D,E), }; // 7 edges -Rajesh Tengli

1 0

[iostreams] issue to compile code with intel-linux 9.1 and 10.0
by frederic.bron＠alcan.com 19 Jan '08

19 Jan '08

Compiling on Linux 2.6.9-42.ELsmp #1 SMP x86_64 x86_64 x86_64 GNU/Linux I had no issue building the boost libraries using icpc 10.0 (toolset intel-linux). But when I try to compile the code I have written (which compiles well with g++), I get the following error (intel 9.1 and 10.0 give the same error): /soft/bal/usr/boost_icc/include/boost/iostreams/detail/streambuf/indirect_streambuf.hpp(237): error: identifier "streamsize" is undefined streamsize keep = (std::min)( static_cast<streamsize>(gptr() - eback()), ^ detected during: instantiation of "boost::iostreams::detail::indirect_streambuf<T, Tr, Alloc, Mode>::indirect_streambuf() [with T=boost::iostreams::basic_null_device<char, boost::iostreams::input>, Tr=std::char_traits<char>, Alloc=std::allocator<char>, Mode=boost::iostreams::input]" at line 80 of "/soft/bal/usr/boost_icc/include/boost/iostreams/stream_buffer.hpp" Any idea? F. Bron Avis : Ce message et toute pièce jointe sont la propriété d'Alcan et sont destinés seulement aux personnes ou à l'entité à qui le message est adressé. Si vous avez reçu ce message par erreur, veuillez le détruire et en aviser l'expéditeur par courriel. Si vous n'êtes pas le destinataire du message, vous n'êtes pas autorisé à utiliser, à copier ou à divulguer le contenu du message ou ses pièces jointes en tout ou en partie. Notice: This message and any attachments are the property of Alcan and are intended solely for the named recipients or entity to whom this message is addressed. If you have received this message in error please inform the sender via e-mail and destroy the message. If you are not the intended recipient you are not allowed to use, copy or disclose the contents or attachments in whole or in part.

2 1

Re: [Boost-users] Memory Leak Detection output format
by Jamie Cook 19 Jan '08

19 Jan '08

> Try building with internal STL. After all you only interested in your own leaks, right? > Gennadiy yeah I am, and having every test run spit back four blocks of unfreed memory makes it harder to see which memory leaks are from my code and which are from stlport - especially if there is no contextual information such as file/line# to distinguish them, I basically have to memorize the sizes of each leak and compare back against those on each run. Hence why I really want to either a) Find out where this last 1280 bytes of memory is being allocated b) Have filename/line# output so that it's easier to see which leaks are from my own code Which is why I'm wondering if there is a way to change the output of the memory leak detector ... guess I might have to start looking at external leak detectors that are linked at runtime instead... does anyone know any good ones? Kindly, Jamie Cook Research Engineer ………………………………………..………………… Veitch Lister Consulting Pty Ltd. Ground Floor, 80 Jephson St, PO Box 1054, Toowong, QLD 4066 AUSTRALIA Ph: +61 7 3870 4888 Fax: +61 7 3870 4446 Email: jamie.cook(a)veitchlister.com.au Web: www.veitchlister.com.au ………………………………………..…………………

6 6

Custom deleter for ptr_vector?
by Robert Dailey 18 Jan '08

18 Jan '08

Hi, I was wondering it is currently possible to give ptr_vector a custom deleter? This could simply be in the form of a functor. If this feature does not exist, would it be hard to add? For example, you could do this: namespace boost { namespace detail { template< typename t_type > struct default_deleter { void operator() ( t_type* ptr ) { delete ptr; } }; } template< typename t_type, typename t_deleter = detail::default_deleter<t_type> > class ptr_vector { private: std::vector<t_type*> m_pointers; public: ~ptr_vector() { std::for_each( m_pointers.begin(), m_pointers.end(), t_deleter() ); } }; }

1 0

[flyweight] Remainder: Flyweight review will start January 21
by Ion Gaztañaga 18 Jan '08

18 Jan '08

Hi to all, Flyweight library will be reviewed January 21-30. For those interested in the library, this post contains all the information needed for the review: *Author:* Joaquín M. López Muñoz *Description:* Flyweights are small-sized handle classes granting constant access to shared common data, thus allowing for the management of large amounts of entities within reasonable memory limits. Boost.Flyweight makes it easy to use this common programming idiom by providing the class template flyweight<T>, which acts as a drop-in replacement for const T. *Online docs:* http://tinyurl.com/2sstyr http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/index.html *Download:* http://tinyurl.com/hrdm6 http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directo… *Notes:* 1) We've seen some suggestions in the mailing list for Flyweight. Joaquín has nicely explained a couple of issues that we'd like to address/discuss in the review: http://tinyurl.com/33ghtf http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/doc/review_… 2) Flyweight needs Boost 1.35 elements because the library depends on libraries like Interprocess for some features/tests. Since SVN snapshot tarballs seem to be missing these days, those who want to try flyweight can download a working SVN-HEAD snapshot here: http://igaztanaga.drivehq.com/boost_trunk.tar.bz2 3) Serialization tests won't work. This feature is expected to work when some new features (discussed in the mailing list between Joaquín and Robert Ramey) are added in Boost.Serialization. Those are expected for Boost 1.36. Regards, Ion

1 0

Filesystem bug in directory_iterator (operations.cpp, readdir_r_simulator function)
by raulh39＠ya.com 18 Jan '08

18 Jan '08

Hi, I have encountered an error in the filesystem library. I am working with Boost 1.34.1, SunOs 5.7, and a multi-threaded environment. This small program reproduces the problem: ------------------------------------------------------ #include <boost/filesystem/fstream.hpp> #include <boost/filesystem/operations.hpp> #include <boost/filesystem/convenience.hpp> #include <boost/foreach.hpp> #include <iostream> int main() { namespace fs = boost::filesystem; fs::path path(".",fs::native); if(fs::exists(path) && fs::is_directory(path)) { fs::directory_iterator begin(path), end; BOOST_FOREACH(fs::path file, std::make_pair(begin,end)) std::cout << file.leaf() << std::endl; } } ------------------------------------------------------ The problem is that this program never ends. Apparently the "begin" iterator never reaches the "end" iterator. It only happens in a multi-thread compilation. But, I think that I know where the bug is. In the file libs/filesystem/src/operations.cpp is were the function 'readdir_r_simulator' is implemented, and, if I understand it correctly, it should return != 0 if an error has ocurred. But, the 1247 line: { return ::readdir_r( dirp, entry, result ); } is wrong, because when an error is encountered, readdir_r() returns a null pointer. NULL is converted to the int 0 and the function returns it. So, I suggest to change that line with: { if(::readdir_r( dirp, entry, result )==NULL) return errno; else return 0; } I will try to post this bug to the bug tracking facility (¿trac?). Regards, Raul.

1 1

[program_options] Non-conventional options
by ope 18 Jan '08

18 Jan '08

Hi, I've read http://www.boost.org/doc/html/program_options/howto.html#id1592624 about Non-conventional Syntax but it doesn't solve my problem. For a program I have to bypass some options to the underlying library (to be concrete Qt), where some of the Qt specific options I have to parse for my program too. Qt's QApplication recognizes cmd line arguments in a style of '-command' which differs from long option style of boost.program_options. Therefore the '-command' should be valid, the '--command' not! How can I get this? Thanks, Olaf

1 0