- Boost - lists.boost.org

Bug in boost::filesystem (1.33.1)
by Jorge Lodos 15 Mar '07

15 Mar '07

Hi The function BOOST_FILESYSTEM_DECL path system_complete( const path & ph ) in operations_posix_windows.cpp contains the following code: char buf[MAX_PATH]; char * pfn; std::size_t len = ::GetFullPathNameA( ph.string().c_str(), sizeof(buf) , buf, &pfn ); if ( !len ) { boost::throw_exception( filesystem_error( "boost::filesystem::system_complete", ph, "size is 0" ) ); } buf[len] = '\0'; If the full path name is larger than MAX_PATH, the last line will cause a buffer overflow. This bug is not present in 1.34. Best regards Jorge Lodos

1 0

[HEAD] [patch] BoostBook update WARNING for WIN32 in Python Script
by Dean Michael Berris 15 Mar '07

15 Mar '07

I just noticed that the WARNING for WIN32 users of BoostBook points to an old URL of the xslt-proc for win32. Attached is a trivial patch to change the warning. -- Dean Michael C. Berris http://cplusplus-soup.blogspot.com/ mikhailberis AT gmail DOT com +63 928 7291459

1 0

[Sorting] How would developers like me to implement the library?
by Sam Schetterer 15 Mar '07

15 Mar '07

Would users prefer that it is their own responsiblity to write the proper functions for a type or should a class be provided with virtual functions that are redefined as needed? Just wondering.

1 0

[graph] [iterator] use of iterator_facade in leda_graph.hpp
by Jens Müller 15 Mar '07

15 Mar '07

From leda_graph.hpp: class out_edge_iterator : public iterator_facade<out_edge_iterator, leda::edge, bidirectional_traversal_tag, const leda::edge&, const leda::edge*> Can someone explain to me the parameter "const leda::edge*"? http://www.boost.org/libs/iterator/doc/iterator_facade.html#difference says the last template parameter is the type for the difference between two iterators, how can this be a pointer? Shouldn't it just be the default std::ptr_diff_t? Cheers, Jens

3 3

[boost cvs] Boost.Python and Boost.Mpi collide?
by elviin 15 Mar '07

15 Mar '07

Hello, If I want to build Boost from cvs with using gcc; (4.1.1) using python ; using mpi ; then there is a collision in target names or at least I undestand that as a collision: ~/elviin/src/boost/tools/build/v2/build/virtual-target.jam:985: in virtual-target.register-actual-name from module virtual-target error: Duplicate name of actual target: <p/usr/local/lib>mpi.so error: previous virtual target { common%common.copy-mpi.so.PYTHON_EXTENSION { gcc%gcc.link.dll-mpi.so.PYTHON_EXTENSION { gcc%gcc.compi le.c++-collectives.o.OBJ { python/collectives.cpp.CPP } } { gcc%gcc.compile.c++-py_communicator.o.OBJ ... ... ... The only way how to install the mpi binding is to comment the line with "using python;" directive. Regards, elviin

2 2

[1.34.0] some failure markup
by Vladimir Prus 15 Mar '07

15 Mar '07

I've checked in the attached to markup some easy failures. The patch is both on HEAD and RC_1_34_0. I did not move merged_to_RC_1_34_0 tag because apparently about 30 commits were done to the HEAD version, and right now I don't feel like figuring out whether each one should be merged to RC, or not. I'll look at remaining RC failures later, when test result with fresh python changes are available. - Volodya

1 0

[format] - exponential format, NaN and infinity
by frederic.bron＠alcan.com 15 Mar '07

15 Mar '07

This is about output of real values (float, double, ...) in exponential format and output of not a number and infinity. My concern is that in C++, the output differs from one compiler/machine to another. It would be very nice if boost::format could garantee the same output on every computer. For example, the following code gives the following output on various machines (using boost 1.33.1): std::cout << format("%1% ") % 1e12 ; std::cout << format("%1% ") % std::numeric_limits<double>::quiet_NaN() ; std::cout << format("%1% ") % std::numeric_limits<double>::infinity() ; std::cout << format("%1%") % (-std::numeric_limits<double>::infinity()) ; The output on cygwin (compiled with g++ 3.4.4) is: 1e+12 nan inf -inf The output on windows (compiled with g++ 3.4.4 on cygwin with flag -mno-cygwin) is: 1e+012 1.#QNAN 1.#INF -1.#INF The output on Tru64 (compiled with g++ 3.4.4) is: 1e+12 NaNQ INF -INF This makes difficult to check if the programs do the same on various machines as soon as tests include output of numbers. Here, I cite section 7.19.6.1 The fprintf function of standard "Programming languages — C" ISO/IEC 9899:1999(E): The effect of the printf function in C is descibed as: A double argument representing an infinity is converted in one of the styles [-]inf or [-]infinity — which style is implementation-defined. A double argument representing a NaN is converted in one of the styles [-]nan or [-]nan(n-char-sequence) — which style, and the meaning of any n-char-sequence, is implementation-defined. A double argument representing a floating-point number is converted in the style [-]d.ddd e±dd, ... The exponent always contains at least two digits, and only as many more digits as necessary to represent the exponent. Could we have the same in C++: 1. 2 digit in the exponent and more only if needed 2. a standard format for not a number and infinity: nan and inf. (They are roughtly implementation defined in C!) In the C++ standard "Programming languages — C++" ISO/IEC 14882:2003(E), the only reference to printf is in 27.8.2 C Library files where we can find the list of functions in cstdio. Also using cout, there is no description of how to handle NaN, infinity and the number of digits in the exponents. The function should be described in the previous C standard "Programming languages – C" ISO/IEC 9899:1990 which I do not have. Thanks, 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.

5 11

Is the Md5 license compatible with Boost?
by Henrik Sundberg 15 Mar '07

15 Mar '07

Found this Boost::Md5: http://www.garret.ru/~baranov/boost_md5/lib/md5/md5.html Is this going to be a part of Boost? Is the Md5 license ok for Boost at all? /$

4 5

C++0x configuration macros redux
by Douglas Gregor 15 Mar '07

15 Mar '07

Hi all, A while back, I put some preliminary C++0x configuration macros into the Config library, but they were half-baked. I've finally finished them. The macros are: BOOST_HAS_CONCEPTS BOOST_HAS_LONG_LONG (it's part of C++0x) BOOST_HAS_RVALUE_REFS BOOST_HAS_STATIC_ASSERT BOOST_HAS_VARIADIC_TMPL Documentation, configure tests, and the appropriate detection code is on mainline CVS. The only client of these macros so far is static_assert.hpp, which uses the C++0x static_assert facility when it is available. In the near future, I hope to get some nightly regression tests running with the prerelease GCC 4.3's experimental C++0x mode, so we can start trying out some of these features in Boost. Cheers, Doug

2 2

[SoC] Boost.Extensios enhancements and Reflection
by Mariano Consoni 15 Mar '07

15 Mar '07

Hi Boost Community! Maybe you remember that I've sent a couple of emails last days because I want to participate in SoC with Boost. My original idea was a plugin library, and then someone pointed me out the existence of Boost.Extensionsand then contacted its author (Jeremy Pack) to try to enhanced/complete that library. Last days, we've been working together. I reviewed Boost.Extensions, Jeremy reviewed my approach to see if there are any feature that could be added to Boost.Extensions. and then we agreed in a possible list of tasks as a SoC project. Now, we want to share this list with the community, to know if there is something missing or something that anyone in the community would like to see implemented. Our current task list is: - Preprocessor tricks to remove template redundancy - Provide (optionally) automatic closing of unneeded linked libraries. - Implement Reflection. and the required tasks for the completion of Extensions: - Finish up documentation - Write lots more unit tests, as well as larger tests - Submit it to Boost for review We think that the most important parts of the project are submitting the library and doing something with Reflection. Another issue that I must resolve is the mentoring. I know that at least two people offered their help, and It would be great if we can decide that to be able to start to write my proposal, checking it with the mentor and with Jeremy. Thanks! Mariano.

4 6