February 2010 - Boost - lists.boost.org

is review system in place is extremely slow? (was Re: [rfc] rcpp)
by vicente.botet 08 Mar '10

08 Mar '10

Hi, ----- Original Message ----- From: "Mathias Gaunard" <mathias.gaunard(a)ens-lyon.org> To: <boost(a)lists.boost.org> Sent: Tuesday, February 23, 2010 12:47 PM Subject: Re: [boost] [rfc] rcpp > > Ivan Sorokin wrote: >> 3 When will Boost.Move become a part of boost? > > When it gets reviewed. > It could be said, however, that the review system in place is extremely > slow and that it's going to take years (literally). Why do you think the review system in place is extremely slow? Currently there are a lot of libraries to review, but no review managers. That means that the user community don't want to spend a little bit of their time to manage a review. In addition, the last review didn't had too much of reviewers (I'm also concerned by this point) I'm the review manager of Boost.Task but the library is not ready for review, because now Boost.Task depends on Boost.Move, Boost.Fiber and Boost.Atomic (which is not yet on the review queue). Maybe the review withards could add this on the schedule page. What do you propose to improve it? Best, _____________________ Vicente Juan Botet Escribá

32 87

[Tokenmap] A (perfect) hash container library chcked-in to sandbox (RFC)
by Slawomir Lisznianski 08 Mar '10

08 Mar '10

http://svn.boost.org/svn/boost/sandbox/tokenmap/libs/tokenmap/doc/html/inde… A tokenmap is a data structure that uniquely maps pseudo-random generated keys with elements of the collection. Boost.Tokenmap is a (perfect) hash container library for C++. An important distinction between tokenmap and other dictionary-like containers, such as std::map or Boost.Unordered, is that tokenmap generates keys internally (referred to as "tokens") rather than relying on user to provide them. Specifically, when a new element is inserted into the tokenmap, an apparently random key is returned back to the caller which uniquely maps to the stored element. The returned key can later be used in a very efficient lookup. Although the code and documentation are far from complete, the implementation in the repo is functional and hopefully serves as a basis for further work. Slawomir

9 27

[Itl] Review
by Phil Endecott 08 Mar '10

08 Mar '10

My review of the proposed Interval Template Library follows. This is based only on studying the documentation, and previous discussion of the library on the Boost mailing list (e.g. http://lists.boost.org/Archives/boost/2009/03/149396.php ). Joachim has clearly put a lot of work into what is a substantial and well-documented library. Unfortunately, it seems to me that it is built on a weak foundation. One of the most well-known problems involving intervals is to determine which of a given set of intervals contains a particular point. How to store a set of intervals in such a way as to make this problem efficient has been extensively studied. If an "interval tree" (See e.g. Wikipedia: http://en.wikipedia.org/wiki/Interval_tree) is used, then the problem can be answered in logarithmic time and linear space. (More precisely: if there are N intervals in the container and M overlap the point of interest, finding them should take O(M + log N) time and the data structure should take O(N) space.) I was hoping to find that this library was an implementation of an interval tree. But it is not: it is built on top of normal standard-library containers. The implementation used can find the intervals that overlap a point in O(M + log N) time, but to do so it needs worst-case O(N^2) space and I think it needs O(N^2 log N) time to build that structure. Presumably this complexity is not an issue in Joachim's application. Unfortunately, library code will be used in many different applications including those where optimal complexity is required. For example, consider trying to store the lifespans of people in a genealogy program: recording a few thousand people living over a few hundred years would approach the worse-case space complexity and need megabytes of storage. Perhaps other reviewers will feel that there are sufficient applications where this library is suitable to justify its inclusion in Boost. My feeling is that since the interval tree data structure is so well known and its performance is so much better, we should not accept this library. Ideally it would be possible for Joachim to replace ITL's current standard containers with an interval tree implementation. Could an interval tree be implemented with an interval sufficiently similar to a std::set/map to make that possible, without losing the complexity benefits? Once again, I believe that apart from this weak foundation this looks like an excellent submission that is comprehensive and well-documented. Regards, Phil.

3 9

[Review] ITL review starts today, February 18th
by Hartmut Kaiser 07 Mar '10

07 Mar '10

Hi all, The formal review of the Interval Template Library (ITL) starts today, February 18th, 2010 and will end February 27th, 2010. ITL is being developed by Joachim Faulhaber. ------------------------------------------------ About the library: The Interval Template Library (ITL) is a library of interval containers that facilitates computations on collections of intervals and associated values. Use cases of such computations typically occur in the date and time problem domain, when collections of time intervals with associated data are analyzed, combined and aggregated. But the scope of applications for interval containers is more general and not limited to date and time problems. Interval containers allow to access and manipulate collections of intervals on an abstract level as sets and maps (of elements), but also to exploit segmental information that is given by the interval borders. Interval containers are fairly generic. They can be instantiated with discrete domain (or key) types like integral numeric types or boost::date or time types. But they also work with continuous domain types like double, rational or string. Using the latter allows to represent infinite sets and maps. The interface of the interval containers strives to be very intuitive and in line with the stl and other boost libraries. * The set theoretic operations union, difference, intersection and symmetric difference are available as operators for all interval containers and for many useful overloads between them. * There is iterator support on the level of segments and interval containers can be combined with stl containers of intervals via stl algorithms. * For discrete domain types, element iterators are available which makes interval sets and maps models of SortedAssociative Containers so they can be used with many stl algorithms. All interval containers are addable and subtractable. The addability and subtractability concept of the ITL leads to a general mechanism of aggregation on interval_maps which is called 'aggregate on overlap'. Exploiting 'aggregate on overlap' allows to compute many useful aggregation results in a simple and abstract manner. The ITL's Set and Map concepts are defined by a signature and collections of laws or axioms. Those semantical constraints have been validated using automatic law based tests. This gives the library both a well founded formal specification and an unusual thorough test base. The ITL emerged out of real world use cases and is successfully used at Cortex Software GmbH since a couple of years in the production code of various applications. On the boost developer's list it has been proposed in four previews and a review request since May 2008 and has been refactored and refined according to boost standards and suggestions from the list. The ITL is available from the boost vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=itl_3_2 _0.zip&directory=Containers Documentation is online available at: http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/index.html The current sources are in the sandbox: https://svn.boost.org/svn/boost/sandbox/itl/ ------------------------------------------------ Everybody on this list is invited to participate in this formal review. I hope to see your review of this library, including your vote, and I welcome your participation in the discussions on the Boost mailing list. Please always state in your review, whether you think the library should be accepted as a Boost library. Additionally, please consider giving feedback on the following general topics: - 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? Regards Hartmut Review Manager --------------- Meet me at BoostCon www.boostcon.com

9 29

[transact] Handling with user exceptions
by vicente.botet 07 Mar '10

07 Mar '10

Hi, I would like to initiate a discussion on how to manage with user exceptions. Here follows some thougth I'm implementing in Boost.STM. There are two main ways to manage with user exceptions: * exceptions commit transactions - corresponds to the current C++ behavior * exceptions abort on exit - corresponds to rollback The behavior associated to the curent language-like macros is to throw the catched exception. In this case, the exception shouldn't contain references to transaction specific objects. I was wondering if we cannot add a second family of macros that before a user exception leaves the transaction block the transaction is commited. BOOST_TRANSACT_A_ family will abort the transaction on user exception BOOST_TRANSACT_C_ family will commit the transaction on user exception This will allows to explore which both approaches, and see which approach is more usable, or if there is an approach that is better adapted to some particuler contexts. * Exceptions Commit Transactions - How to get this? While trying to commit on destruction we have catched any exception to release the commit_on_destruction variable. commit_on_destruction __comm( __txn ) ; t ry { i f ( false ) ; else / / to for ce a sentence / / t r a n s a c t i o n sentence } catch ( . . . ) { __comm. release ( ) ; throw ; } To make exception commit transactions by default, we should not release the committer. However, we need to avoid exception throw by commit when the transaction has been set as forced to abort or during unwinding exception. commit_on_destruction __comm( __txn ) ; t ry { <sentence > } catch ( . . . ) { i f ( __txn_.forced_to_abort ( ) ) __comm.release ( ) ; else __comm.commit ( ) ; throw ; } We need how to override the default behavior. If we have Exceptions Commit Transactions - we can abort the transaction in two ways: * Explicit try-block to Abort Transactions * Explicitly abort before throw - Explicit try-block to Abort Transactions The user may want the exception abort the transaction while leaving the transaction block. The user must explicitly state that this is the desired behavior by adding a try-catch block as shown below: BOOST_STM_C_TRANSACTION t ry { / / t r a n s a c t i o n block } catch (Ex&) { BOOST_STM_ABORT( ) ; throw ; } BOOST_STM_C_END_TRANSACTION; - Explicitly abort before throw The user may want the transaction to be aborted before throwing an exception. The user may explicitly state that this is the desired either by setting the current transaction as forced to abort, BOOST_STM_ABORT( ) ; throw except ( ) ; or by throwing the exception using the macro : / / . . . BOOST_STM_ABORT_AND_THROW( except ( ) ) ; / / . . . If we have Exceptions Abort on Exit we can commit the transaction as follows: - Explicit try-block to Commit Transactions The user must explicitly state that this is the desired behavior by adding a try-catch block as shown below: BOOST_STM_TRANSACTION t ry { / / t r a n s a c t i o n block } catch (Ex &ex ) { BOOST_STM_COMMIT( ) ; throw ; } BOOST_STM_END_TRANSACTION; boost::exception_ptr error; BOOST_STM_TRANSACTION t ry { / / t r a n s a c t i o n block } catch (Ex &) { error=boost::current_exception(); } BOOST_STM_END_TRANSACTION; if( error) boost::rethrow_exception(error); } Please let me know what do you think? Do you find this useful? Should we provide two families of macros? Best regards, _____________________ Vicente Juan Botet Escribá

2 6

[BGL] Testing a graph for bipartiteness
by Matthias Walter 06 Mar '10

06 Mar '10

Hi, I'm working on a project where I need to determine whether a given graph is bipartite (possible yielding certificates for the two cases). As such a test can be perfectly implemented via BFS and visitor patterns, I wondered why there is no implementation in the BGL. Is there any reason or am I just to blind to find it? If I'm forced to write my own one, how about submitting it to BGL? best regards Matthias Walter

4 29

[log] init methods and named parameters
by Michael Caisse 05 Mar '10

05 Mar '10

I've gotten a head start looking at the boost.log library that will be reviewed in a couple weeks. The utility methods utilize boost.parameter's named parameters. For example, boost::log::init_log_to_file. I would like to decide at runtime (via a config file) which set of parameters will listed. For example, rotation_size or rotation_interval or both. It is my first real use of boost.parameter so I may be missing something that is common knowledge. I don't see an easy way to do this. I thought maybe building a fusion sequence of parameters or something like that was the way to go... Looking for guidance. Thanks. michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

3 8

[rfc] rcpp
by Ivan Sorokin 04 Mar '10

04 Mar '10

Hello! I have a small library that is intended for convenient and declarative resource wrappers creation. Read Documentation: http://rain.ifmo.ru/~sorokin/rcpp/doc/index.html Main Page: http://rain.ifmo.ru/~sorokin/rcpp/ Although this library is small I think it is useful. I think it is possible to use it in implementations of asio, filesystem and thread. **-- Ivan Sorokin

6 16

[Filesystem V3] Filesystem Version 3 beta 1 available for download and comment
by Beman Dawes 03 Mar '10

03 Mar '10

The first beta release of Boost.Filesystem Version 3 is now available. The documentation can be viewed at http://mysite.verizon.net/beman/v3/index.htm Important differences from the prior version: http://mysite.verizon.net/beman/v3/v3.html The beta can be downloaded from the Boost vault. See http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Files… Installing the beta is described at http://mysite.verizon.net/beman/v3/install_distro.html I'm concerned about breaking existing code. While some workarounds have been provided already, I'd open to further suggestions as to how to mitigate code breakage. The tentative plan for integrating V3 into the boost release cycle involves several steps: * For the first boost release cycle, ship V2 as the default, but V3 is present and can be activated by users. * For an additional boost release cycle, ship V3 as the default, but V2 is present (but deprecated) and can be activated by users. * For the following boost release cycle, V2 is removed and no longer supported. The plan is to go through as many beta cycles as needed to reach stability. Although quite a bit of testing has already been done, this is definitely beta software that isn't ready yet for production use. Any comments appreciated. --Beman

10 23

[iostreams] array and gzip_decompressor
by Nikolay Mladenov 01 Mar '10

01 Mar '10

Recently I came back to a source written some time ago, that was running then but it is not compiling now. the failing snippet is: typedef boost::iostreams::composite<boost::iostreams::gzip_decompressor, boost::iostreams::array_source> array_gzip_decompressor; boost::iostreams::gzip_decompressor filter; boost::iostreams::array_source source(&_storage[0], _storage.size()); array_gzip_decompressor dev(filter,source); boost::iostreams::stream_buffer<array_gzip_decompressor> ibuf(dev); the error is: > boost\iostreams\read.hpp(191) : error C2039: 'putback' : is not a member of 'boost::iostreams::detail::direct_adapter<Direct>' > with [ Direct=boost::iostreams::array_source ] It seems to me that gzip_decompressor requires peekable source, but array_source is not peekable. Is there another way I should be creating gzipped stream into memory? Or maybe the arrays could be made peekable? Thanks in advance, Nikolay Mladenov

3 5

[ITL][Review] A late mini review
by Thomas Klimpel 01 Mar '10

01 Mar '10

> Please always state in your review, whether you think the > library should be accepted as a Boost library. ITL should be accepted as a Boost library. > - What is your evaluation of the design? I haven't spend sufficient time reviewing the library to be able to judge the design. At least, I haven't seen any obvious flaws during my short review. > - What is your evaluation of the implementation? I took a cursory look at all source (header) files, and they look nicely written. I took a cursory look at the directory structure, to verify that it follows boost conventions. It does so in general, but I was surprised to find a "libs/itl/build" folder, since I "know" that ITL is a headers only library. The content of the build folder also didn't make me happy (it's extremely "unportable"), but this is a completely different topic that has nothing to do with this specific library. The template meta programming in boost/itl/type_traits/* could follow MPL conventions more closely. > - What is your evaluation of the documentation? The documentation is nicely written. However, please don't invent new words like "aggrovering" or "unon". Please also try to avoid changing the meaning of existing words like "neutron". > - What is your evaluation of the potential usefulness of the library? The need to work with "interval sets" arises sufficiently frequently in "time based" and "geometry based" problem domains to warrant a library dedicated especially to this problem domain. (In my review of Boost.Polygon, I pointed out that interval set concepts were missing.) I have to admit that I haven't spend sufficient time evaluating ITL to be able to judge whether ITL is able to handle all these needs. > - Did you try to use the library? With what compiler? Did you have any problems? No, I didn't try to use the library. > - How much effort did you put into your evaluation? > A glance? A quick reading? In-depth study? Some month ago, I read through the documentation just for the pleasure it gave me, pondered a bit about the concept and looked at the BoostCon2009 slide show. I was certainly planning to do a proper review during the review period, but I was (and still am) occupied with other things. What I've done now while writing this review was just a glance. > - Are you knowledgeable about the problem domain? This is not important in this case, since I haven't spend enough time for the review anyway. Regards, Thomas P.S.: As I guessed from recent experience, the review period has just been extended. However, I decided to submit this mini review nevertheless. I may have a look at "I have to admit that I haven't spend sufficient time evaluating ITL to be able to judge whether ITL is able to handle all these needs." with respect to the issue raised by Phil Endecott in http://lists.boost.org/Archives/boost/2010/02/162198.php (and write about it in case I can make up my own opinion), because this seems to be an interesting question. Even so I want to thank Phil Endecott for his courage to bring up this issue, and I guess that he is right (in a certain sense), I think it is wiser to base my review only on my personal experiences and not on my judgment of whether Phil is right or wrong with respect to this issue.

2 1

[numeric][intervall] msvc_rounding_control.hpp broken in 64 bit build.
by Juergen Hunold 01 Mar '10

01 Mar '10

Hi ! boost/numeric/interval/detail/msvc_rounding_control.hpp does not compile in x64 (64bit) build with (at least) msvc-9 The offending commit is: ------------------------------------------------------------------------ r59350 | marshall | 2010-01-29 19:01:34 +0100 (Fri, 29 Jan 2010) | 1 line Applied patches to fix #2512 and #2513 ------------------------------------------------------------------------ This does not show up in regression test because we don't have a test runner running a 64bit version of msvc. The compiler bails out on the x86 inline assembler introduced in that commit when running in 64bit mode. The simple patch is to fall back to the old behaviour using "rint" for target "x64": Index: msvc_rounding_control.hpp =================================================================== --- msvc_rounding_control.hpp (revision 59697) +++ msvc_rounding_control.hpp (working copy) @@ -25,7 +25,7 @@ namespace interval_lib { namespace detail { -#if BOOST_MSVC < 1400 +#if BOOST_MSVC < 1400 || defined(WIN64) extern "C" { double rint(double); } #else inline double rint(double x) I can apply this if necessary. Tested with msvc-9.0 I have not looked into the referenced tickets. Any (better) ideas ? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 1

ptr_container move support
by Zachary Turner 01 Mar '10

01 Mar '10

The collections in ptr_container don't seem to support move constructors. All the recent compilers support r-value refs, has there been any discussion of adding support for this? Zach

2 1

[Serialization] extended_type_info.hpp
by fab 01 Mar '10

01 Mar '10

Hi, With boost 1.42.0, when I use BOOST_CLASS_EXPORT, I always need to include extended_type_info.hpp to resolve this error : xxx.hpp:153: error: 'guid_defined' is not a template xxx.hpp:153: error: explicit specialization of non-template 'boost::serialization::guid_defined' xxx.hpp:153: error: expected initializer before '<' token xxx.hpp:153: warning: 'boost::archive::detail::<unnamed>::init_guid<MyClass>::g' defined but not used Maybe extended_type_info.hpp can be included in export.hpp ? Fabien Castan

4 5

Setting up a test suite
by Marshall Clow 28 Feb '10

28 Feb '10

I've got two implementations of the same functionality I want to compare with Boost.Test. One's in C++ (natch), the other in Python. Currently, they're packaged as tools that take a file as a parameter, and write results to stdout. Call them "dumpinfo.cpp" and "dumpinfo.py". How would I use Boost.Test to compare the output of these tools for a selection of sample tests? Conceptually, I would do: g++ -o dumpInfo dumpInfo.cpp ./dumpInfo testFile > /tmp/c.out python dumpInfo.py testFile > /tmp/py.out diff -q /tmp/c.out /tmp/py.out But how to do this using Boost.Test? Notes: * I have several (many) test files. It would be nice to list these files in a Jamfile. * There are a couple bugs in the Python packages I am using. I need to mark some of them as "expected failures" Thanks in advance! -- Marshall

1 0

[iostreams]mapped_file bug on Win32?
by Nelson, Erik - 2 28 Feb '10

28 Feb '10

Or maybe a feature? Or maybe I'm just using it incorrectly. I'm trying to create a new file of a certain size, regardless of whether or not a file of the same name exists. If I run a test program along the lines of boost::iostreams::mapped_file file; boost::iostreams::mapped_file_params p("test.txt"); p.new_file_size = 1201; p.length = 1; p.mode = ios_base::in | ios_base::out; file.open(p); It fails with the error 'failed setting file size: Cannot create a file when that file already exists.' if file 'test.txt' already exists. It seems to me that this error is a bug caused by incorrect error checking in mapped_file.cpp in function mapped_file_impl::open_file. At the call to CreateFileA, dwCreationDisposition=CREATE_ALWAYS and a valid handle value is returned. The Win32 docs say that in this case the call to CreateFileA has succeeded and the last-error code is set to ERROR_ALREADY_EXISTS. http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx Immediately after the call to CreateFileA, the handle is checked for validity but the last-error code is not reset. Shortly thereafter is a call to SetFilePointer. The docs say that the proper way to check for an error from SetFilePointer is to compare its return value to INVALID_SET_VALUE_POINTER. http://msdn.microsoft.com/en-us/library/aa365541%28VS.85%29.aspx This isn't done in the code... Instead, GetLastError() is called, which apparently returns the ERROR_ALREADY_EXISTS code generated by CreateFileA, which wasn't an error at all. It seems to me that a couple of things need to be changed to make this correct- 1) after the check for valid handle creation by CreateFileA, call SetLastError(NO_ERROR) 2) when resizing the file the code if (::GetLastError() != NO_ERROR || !::SetEndOfFile(handle_)) should be something like if (::SetFilePointer(handle_, sizelow, &sizehigh, FILE_BEGIN) == INVALID_SET_VALUE_POINTER || !::SetEndOfFile(handle_)) Does that make sense? Or am I just setting the mapped_file_params incorrectly to force creation of a new file? Erik

2 8

[ITL] Short remarks on the lastest 3 Reviews
by Joachim Faulhaber 28 Feb '10

28 Feb '10

Hi Barend, Vicente and Thomas, thank you for your efforts to synchronize the submission of your reviews as an attack on my Sunday evening =) First and foremost I'd like to thank Barend, who obviously did a really thorough investigation of the ITL, creatively testing own applications and going into the detail of the probably bewildering possibilities to use the generalized addition, subtraction and intersection operations on interval_maps. This was extremely important for me, because I realized how much those concepts and possibilities transcend the expectations of potential users. I have spent a lot of time investigating generalized operations on interval_maps and I am fairly sure that the definitions of their semantics based on axioms (laws) are pretty sound. I think that the usefulness and flexibility of the ITL that Barend discovered comes from that base. I have tried to describe all those semantical issues in the documentation. But obviously, due to limited time resources of readers, I am afraid that this has not been well received. Also I'd like to thank to Vicente and Thomas for their reviews and the included remarks. I am going to address all of your questions, problems and objections, but probably not at once, during the next days. Best Regards, Joachim

1 0

[date_time] monotonic_time() proposal
by Dmitry Goncharov 28 Feb '10

28 Feb '10

This proposal suggests adding monotonic_time() static member function to the boost::date_time::microsec_clock and second_clock classes. usage example: #include <unistd.h> // for sleep() #include <iostream> #include <boost/date_time/posix_time/posix_time.hpp> #include "monotonic_time.hpp" int main() { namespace pt = boost::posix_time; typedef ext::microsec_clock<pt::ptime> usclock_t; // namespace ext instead of boost::date_time pt::ptime now = usclock_t::monotonic_time(); sleep(1); pt::ptime later = usclock_t::monotonic_time(); std::cout << later - now << std::endl; } Prototype implementation can be found in the attachment. If there is interest i am willing to finish the implementation and documentation. BR, Dmitry

2 4

[chrono] v0.4 New thread_clock
by vicente.botet 28 Feb '10

28 Feb '10

Hi, I'm pleased to announce the version 0.4 of the Boost.Chrono library. The implementaton is stable, I don't plan to add more features before review. I'll concentrate in improving the documentation and the tests. I know that review managers are hard to find, so if you are interested in the library, please contact me or the Review Wizards. The library can be downloaded from http://www.boostpro.com/vault/index.php?action=downloadfile&filename=chrono… and the documentation is online on the sandbox http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/doc/html/index.ht…. New Features since v0.3.2: * Suspendible Clock concept + template class suspendible_clock<> * Added scope_suspend which do suspend/resume if the Clock is a model of Suspendible Clock concept, and nothing otherwise. * thread_clock support on platforms providing it natively. * Added support for wide character for stopwatch_reporter, stopclock, and stopclock_accumulator. * digital_time renamed t24_hours Perf * Added performances measures. Bug Fixes * Bug on timeval_demo. time_point t(duration(xtime(0))); // this was taken as a function declaration gettimeofday((timeval*)&t, 0); return t; time_point t(duration(xtime(0))); // this was taken as a function declaration gettimeofday((timeval*)&t, 0); return t; by timeval tv; gettimeofday(&tv, 0); xtime xt( tv.tv_sec, tv.tv_usec); return time_point(duration(xt)); * Bug on run_timer_test (add a global variable to avoid optimization that removes completely the code to be measured Best regards, _____________________ Vicente Juan Botet Escribá

1 0

[vault] Can you login?
by Lorenzo Caminiti 28 Feb '10

28 Feb '10

Hi all, Can you login into the Boost Vault? I get the errors below on my browser when I try to login. I tried logging in from Linux and Windows using Firefox, Chrome, and Explorer. Regards, Lorenzo Warning: fopen(/home/rene/boost.vault/var/users/lcaminiti) [function.fopen]: failed to open stream: Permission denied in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 616 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 617 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 618 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 619 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 620 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 621 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 622 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 623 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 624 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 625 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 626 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 628 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 629 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 630 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 631 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 632 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 633 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 634 Warning: fclose(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 635 Warning: Cannot modify header information - headers already sent by (output started at /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php:616) in /home/rene/boost.vault/phpATM-1.30-patched/login.php on line 395

3 3

[log] link problems with keywords::format
by Michael Caisse 28 Feb '10

28 Feb '10

Using msvc 8 I am having a link issue with the following code snippet. Commenting out the line with blog::keywords::format will cause the link error to go away. --------------------------------------------------- #include <iostream> #include <boost/log/attributes.hpp> #include <boost/log/common.hpp> #include <boost/log/core.hpp> #include <boost/log/exceptions.hpp> #include <boost/log/filters.hpp> #include <boost/log/formatters.hpp> #include <boost/log/sinks.hpp> #include <boost/log/trivial.hpp> #include <boost/log/utility/init/to_file.hpp> #include <boost/log/utility/init/common_attributes.hpp> namespace blog = boost::log ; int main() { blog::init_log_to_file( blog::keywords::file_name = "foo_%N.log", blog::keywords::rotation_size = 10 * 1024 * 1024, blog::keywords::format = "[%TimeStamp%]: %_%", blog::keywords::open_mode = std::ios_base::app ); BOOST_LOG_TRIVIAL(trace) << "A trace severity message"; return 0; } ------------------------------------------------------ main.obj : error LNK2019: unresolved external symbol "class boost::function2<void,class std::basic_ostream<char,struct std::char_traits<char> > &,class boost::log_mt_nt5::basic_record<char> const &> __cdecl boost::log_mt_nt5::parse_formatter<char>(char const *,char const *)" (??$parse_formatter@D@log_mt_nt5@boost@@YA?AV?$function2@XAAV?$basic_ostream@DU?$char_traits@D@std@@@std@@ABV?$basic_record@D@log_mt_nt5@boost@@@1@PBD0@Z) referenced in function "class boost::function2<void,class std::basic_ostream<char,struct std::char_traits<char> > &,class boost::log_mt_nt5::basic_record<char> const &> __cdecl boost::log_mt_nt5::parse_formatter<char>(char const *)" (??$parse_formatter@D@log_mt_nt5@boost@@YA?AV?$function2@XAAV?$basic_ostream@DU?$char_traits@D@std@@@std@@ABV?$basic_record@D@log_mt_nt5@boost@@@1@PBD@Z) bin\msvc-8.0\release\threading-multi\trivial.exe : fatal error LNK1120: 1 unresolved externals ------------------------------------------------------ Any ideas? michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

2 1

[move] one more dumb question
by DE 27 Feb '10

27 Feb '10

how do i make a function return an object by value and other object to, say, move assign from that returned object within current C++ std? i.e. my_type foo() {/*...*/} //... my_type a; a = foo(); //move assignment is intended here -- Pavel

3 7

[Review] ITL review planned to end tomorrow, February 28th
by Hartmut Kaiser 27 Feb '10

27 Feb '10

Hey all, We're almost at the planned end of Joachim Faulhabers ITL review (see the original review announcement here: http://comments.gmane.org/gmane.comp.lib.boost.announce/253) Now would be a good time to submit your reviews. If you need more time, please let me know. Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com

1 0

[Filesystem V3] file_status over-design?
by Beman Dawes 27 Feb '10

27 Feb '10

Both Filesystem V2 and V3 status() functions return an object of class file_status. file_status is just a thin wrapper around a file_type enum: enum file_type { status_error, file_not_found, regular_file, directory_file, symlink_file, block_file, character_file, fifo_file, socket_file, type_unknown }; It was designed that way on the assumption that file_status would eventually include additional state information. But that never happened, so it looks like over-design my part. The fix would be to rename the enum as file_status, and remove the current class file_status entirely. That would break a certain amount of existing code, but I suspect the C++ committee would force such a change anyhow for TR2, so better to get it over with now. Comments? Opinions? --Beman

5 6

[function] improvements/proposals
by Domagoj Saric 27 Feb '10

27 Feb '10

A while back, in various threads more or less related to the topic, I posted various ideas and/or code contributions to the effect of improving boost::function in terms of efficiency (concentrated on invocation speed, assignement performance/overhead and reducing template and RTTI bloat) and configurability, however there was no "official response" as to whether it was any good, or whether any of it would be accepted or what's wrong with it if not. IMHO the results { - 'Speed': the test presented here http://marc.info/?l=boost&m=118835709647084&w=2 modified to work with boost::signals2 (because it is a header only library/does not require a recompilation of boost if something in boost::function changes) with the dummy mutex/no threading support and a simple recompilation with the new boost::function<> code yielded a ~10% boost, changing the default policy to be nothrow the boost doubled to ~20% - 'Size': my real life project, that uses heavy metaprograming for generating function objects (that as a consequence have _very_ long type names, and thus RTTI records) to assign to boost::functions shrunk by ~10% simply by using the modified boost::function (with RTTI features disabled)...This post http://lists.boost.org/Archives/boost/2009/12/160202.php has more detailed and updated results when my project grew further (with an even bigger difference) } show/hint that there is room for improvement in boost::function and therefor warrant atleast some kind of response (even if along the lines of 'it's no good' or 'there is no time for this now')...which is the reason for (re)posting this (in a separate thread). The relevant threads with more detail are these: http://thread.gmane.org/gmane.comp.lib.boost.devel/196906 http://thread.gmane.org/gmane.comp.lib.boost.devel/194514/focus=195351 since then I've moved the modified code from the vault into the sandbox SVN (under the obvious name "function" :) -- "That men do not learn very much from the lessons of history is the most important of all the lessons of history." Aldous Huxley

6 9