- Boost-users - lists.boost.org

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

Re: [Boost-users] Memory Leak Detection output format
by Dieter Rosch 18 Jan '08

18 Jan '08

You might want to do a google for VLD (Visual Leak Detector). It is an excellent free memory leak detector for MSVC 8. From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Jamie Cook Sent: 16 January 2008 01:07 AM To: boost-users(a)lists.boost.org Subject: [Boost-users] Memory Leak Detection output format Hi all, I'm using the boost.test unit tests with memory leak detection turned on and I'm slightly puzzled about the format of the output. I've been working on getting boost to play nicely with STLport and one of the 'problems' I'm having is with memory leaks being reported by boost.test which are actually coming from stlport (there is a discussion on their FAQ about how these aren't really memory leaks at all but that is beside the point). I've managed to get rid of most of these leaks but I've still got one hanging around and I don't know where it comes from. My output from my testing looks like this Embedding manifest... Performing Post-Build Event... *** No errors detected Running 1 test case... Detected memory leaks! Dumping objects -> {171} normal block at 0x00378B88, 1280 bytes long. Data: < 7 lationStatis> A8 8D 37 00 6C 61 74 69 6F 6E 53 74 61 74 69 73 Object dump complete. My question is this... how can I enable more informative memory leak output? In this article () it says that by #define _CRTDBG_MAP_ALLOC, the filename and line number will also be displayed. I'm looking into execution_monitor.ipp and I can see where < crtdbg.h> is included but even if I put the #define directly before this include the output comes out exactly the same as above. (and yes I recompiled the library) I'm using MSVC8.0, boost 1.34.1 and stlport 5.1.4 and the test library is compiled as C:\Program Files\boost\boost_1_34_1\libs\test\build>bjam --toolset=msvc link=static stdlib=stlport threading=multi I would really appreciate if anyone could give me some insight on why this is being reported in such a way that I can't actually use it. Cheers, -- 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

[review] Fast track review of Boost.Utility/Singleton begins today
by John Torjo 18 Jan '08

18 Jan '08

Hi all, Today starts the formal Fast-Track review of the Boost.Utility/Singleton library. This is a very useful utility, so I'm expecting lots of reviews ;) *Description* A Singleton describes a globally accessible and unique facility, typically implemented as a class with inaccessible constructors and a globally accessible function for clients to access a single instance which is created when accessed for the first time. This library provides three Singleton templates that share an identical interface : |- boost::singleton| : can be used to create Singletons with synchronized initialization. If further synchronization is required it has to be implemented by the user. |- boost::mutexed_singleton| : additionally ensures that concurrent access to the instance is mutually exclusive. In other words, only one thread can access the instance at a given time. |- boost::thread_specific_singleton| : instances exist once per thread. *Author* Tobias Schwinger *Download* Get it from here: http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam… Read documentation online here: http://torjo.com/tobias/ What to include in Review Comments ================================== Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. Here are some questions you might want to answer in your review: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Best, John Torjo - Review Manager - -- http://John.Torjo.com -- C++ expert ... call me only if you want things done right

4 8

Writing binary data in a specific byte ordering (i.e. network order)
by legalize+jeeves＠mail.xmission.com 18 Jan '08

18 Jan '08

[Please do not mail me a copy of your followup] Does boost have a facility for this? I have a bunch of code that did binary I/O on x86. I want to make the code endian-neutral. This is similar to writing binary data in "network order" as is done with TCP and other internet protocols. I was thinking that you could now determine completely at compile-time whether or not bytes need to be swapped using a template class. My thought was that you would have a class for writing "LittleEndian" bytes that took a boolean template parameter. The parameter is determined at compile-time based on the endian-ness of your architecture. Then a specializations for the template determines whether or not you just use stream.write() to write the binary bytes directly from the POD datum or whether or not you manually extract the individual bytes for writing in the proper order. I hope that's clear... it hasn't gelled in my mind enough to have a sample implementation. I'm hoping that there's a facility in boost for this already? -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>

3 2