- Boost - lists.preview.boost.org

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

Re: [boost] [Review] ITL
by Wuttke Peter 27 Feb '10

27 Feb '10

To Begin with the most important point: YES, boost::ITL should be accepted as a boost library. (Please be don't be to disappointed of my english, for i'm a developer from Germany, and this would be my first review on Boost). The ITL (interval template library) is a very valueable part of our (the Cortex Software GmbH, incidently the company i work for) daily development routine. In our industry (which is health care) sampling of Status-Informations for collections of evaluations (in time) are an essential part of our work, so we are using the ITL-Library for some years with great success. (We have to aggregate Events based on equivalent properties, eg. same admission - which diagnosis, same discharge - which diagnosis, and so on. ) . As far as I know, there is really no alternative for using the ITL do work with Intervals - I've tried is with plain SQL, and, belive me: It's possible - but really no fun - no,no,no. (I've also seen Experiments trying to implement the ITL-Solution for specific problem-domains - they aren't usefull or elegant, either. Forget them.) Until now, we only used the library for intervals of datetimes (coded as integers), but i Im sure, that its usefullness goes far beyond. Concerning the overall architecture, I think, the actual version is more than complete, I'm especially impressed withn the idea of big, sparse bitsets implmenented by the ITL - it's cool. The documentation (using samples) is clear and completly comprehensive - couldn't hope for more. So, being not a specialist in template/generics programming (or in algebraic specification), I LIKE this Library - and use it.

2 1

[random] new documentation
by Steven Watanabe 26 Feb '10

26 Feb '10

AMDG This is hopefully the final version of the work I did back in November to convert the Random docs to Quickbook/Doxygen/Boostbook. I've uploaded the generated documentation to http://www.cs.hmc.edu/~swatanabe/random_doc/libs/random/doc/html/ The patch itself is rather large, even compressed, so I uploaded it to http://www.cs.hmc.edu/~swatanabe/random.patch.zip Okay to commit? In Christ, Steven Watanabe

9 19

[exception] virtual inheritance troubles
by Eric Niebler 26 Feb '10

26 Feb '10

In xpressive, I'm trying to follow the recommended use of Boost.Exception and use virtual inheritance in my exception class, regex_error. I'm also trying to hew as closely as possible to the standard, which says that regex_error should inherit from std::runtime_error. However, this simple use of Boost.Exception does not compile: #include <string> #include <exception> #include <boost/throw_exception.hpp> #include <boost/exception/exception.hpp> struct regex_error : virtual std::runtime_error , virtual boost::exception { explicit regex_error(std::string const& what) : std::runtime_error(what) {} }; int main() { boost::throw_exception(regex_error("what")); } On VC9, I get the following: > C:\boost\org\trunk\boost/exception/exception.hpp(400) : error C2512: 'std::runtime_error::runtime_error' : no appropriate default constructor available The trouble is that std::runtime_error does not have a default constructor, and that boost::throw_exception doesn't simply throw the exception passed to it; it throws an object of type of clone_impl<regex_error>. Because of the virtual inheritance, clone_impl needs to call std::runtime_error's directly, but it doesn't. It can't know to do that in general. What is the recommended practice here? <aside> It actually doesn't seem to be particularly useful in this case to use virtual inheritance because std::runtime_error inherits from std::exception non-virtually. In order to avoid the pitfall described here <http://tinyurl.com/yb2jpns>, it seems *ever* exception type in the hierarchy needs to use virtual inheritance, and that unfortunately is not the case for the standard exception hierarchy. </aside> -- Eric Niebler BoostPro Computing http://www.boostpro.com

4 6

[forward] looking for help to keep MSVC7.1 from ICEing
by Tobias Schwinger 26 Feb '10

26 Feb '10

Hello, I'm trying to make Forward release-ready and I'd really like to support MSVC 7.1 which is currently ICEing (in msc1.cpp, line 2701). According to online research that ICE typically occurs when the ODR is violated and the compiler fails to diagnose it. Although the code should be valid, it's likely to be about name management. The code uses an inheritance chain to add call operators of different arities. IOW the class template for arity N inherits from the class template for arity N-1. A 'using base::operator();' is used to pull in the base class' overloads. A stripped-down version of this pattern compiles. When I take out the 'using' declaration the ICE disappears (and so do the base class' overloads). Ideas anyone? Anyone keen enough to look into it? In case of the latter, I recommend the simpler of the two headers: trunk/boost/functional/lightweight_forward_adapter.hpp [ link to svn: http://tinyurl.com/ydoyoa4 ] Thanks, Tobias

1 0

Boost.Polygon : How to deal with per point attributes
by philippe.lamontagne.2＠ens.etsmtl.ca 26 Feb '10

26 Feb '10

Hi Boost community, I am currently experimenting with the BOOST polygon library and I have a few questions. Question 1: For my specific application the points inside the polygons need to contain attributes in addition to their x and y coordinates. This extra information is required in a per-point basis. I need to compute intersections and differences of polygons. The operations can be performed regardless on the attributes, but it's important that the attributes be present in the polygons resulting from the operations. Does BOOST provide a mechanism for keeping such per point attributes? I followed the example to make my own point and polygon classes work with BOOST, but for what I can see, the polygons operations are performed using GTL's own data types and transferred back to my types, loosing any attributes in the process. I am missing something here? Question 2: I noticed that if I have multiple points located on the same straight line only the initial and final points will be kept in the resulting polygon and that the intermediate points will be discarded. Whereas this behavior is probably preferable in the general case, it causes me a problem if I want to maintain point attributes because the attributes are not guaranteed to be the same all over the straight line. Is there a way to change this behavior? I'm aware that polygon operations may create new points. I can deal with a few empty attributes as long as original points keep their initial attributes. We hope there are some solutions or workarounds because I strongly appreciate the library. Thanks for the excellent work.

2 2

[Boost][Container] Non mandatory template parameter not defaulted
by Mathieu - 26 Feb '10

26 Feb '10

Hi, I was reading the boost.container vector sources, and I can't figure how this vector instantiations can work : boost::container::vector<int> foo; considering that the vector definition looks like : template <typename T, typename A> vector; As the second template parameter A has no default type, I believe it's actually mandatory but it's not the case as this : boost::container::vector<Type> compiles fine. I've been reading through the whole source file but I can't find where the trick is. if anyone can enlighten me? ps : sorry for my bad english..

2 2

[filesystem] 1.40 documentation refers to wrong API version?
by Johan Nilsson 26 Feb '10

26 Feb '10

Hi, the Boost.Filesystem documentation at e.g.: http://www.boost.org/doc/libs/1_40_0/libs/filesystem/doc/reference.html#Ope… seems to refer to more recent version. As a specific example, there are no overloads of remove in 1.40 that accepts an instance of boost::system::error_code (as opposed to what the documentation indicates) - easily verifiable in e.g.: http://svn.boost.org/svn/boost/tags/release/Boost_1_40_0/boost/filesystem/o… Is the actual 1.40 documentation available online somewhere? / Johan

1 0

Re: [boost] review system in place is extremely slow? (was Re: [rfc] rcpp)
by Brian Wood 26 Feb '10

26 Feb '10

Mathias Gaunard writes: >> 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) > > So you can see, indeed, that this is fairly concerning. I think this may be due to economic changes. When Boost was getting started the economy was better than today. I think Boost should work on turning traffic on it's pages into advertising revenue. That money could be used to help those who want to be involved in the project. Giving a review manager $200 for 40+ hours of work only makes sense. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net (651) 251-9384

5 4

Re: [boost] review system in place is extremely slow? (was Re: [rfc] rcpp)
by Brian Wood 25 Feb '10

25 Feb '10

On 02/25/2010 11:56 AM, Nevin Liber wrote: > Then comes the "which jobs do we pay for?". If a reviewer > spends 80 hours doing a detailed review, should we pay > them too? What about all the people who tirelessly work > on getting a release out the door every quarter? Why > should they work "for free" if other people are getting paid? I thought about some of these things as well.... I think release managers should be paid as well and more than review managers. For reviewers, I would set up a system that rewarded them also. The review manager might be expected to judge who has given the best and second best reviews. It would add a little excitement to the whole process... seeing who wins the gold and silver medals. > If we don't make enough money from web advertising, you > can't just not pay the review managers. Who will make up > the deficit? Etc., etc. > The way I'd do it is to make offers based on money already collected and not based on anticipated earnings. That way you commit some income to an individual and should be able to follow through and pay them. It might take a few months before you had enough saved to begin doing this. Advertisers love to reach niche audiences, especially audiences with above average incomes. This approach would be mixed with the current approach. If there was money to pay for a review manager it would be offered. If not you would just keep going hoping some generous soul volunteers. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net (651) 251-9384

1 0

Fwd: [Boost-users] [Review] ITL review starts today, February 18th
by Joachim Faulhaber 25 Feb '10

25 Feb '10

Hi, this question of Mathias was posted in both [Boost-users] and [boost] but the answer was accidentally send to [Boost-users] only. ---------- Forwarded message ---------- From: Joachim Faulhaber <afojgo(a)googlemail.com> Date: 2010/2/23 Subject: Re: [Boost-users] [Review] ITL review starts today, February 18th To: boost-users(a)lists.boost.org 2010/2/23 Mathias Gaunard <mathias.gaunard(a)ens-lyon.org>: > Hartmut Kaiser wrote: > >> 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. > > I have no knowledge of the problem domain (nor did I actually look at the > library yet, sorry about that), but I simply have a question: how does this > compare to geometry libraries or spatial indexes that provide that kind of > facilities for arbitrary dimensions? > > I certainly wouldn't want to force over-generalization to the authors, but I > am wondering how much is gained by limiting things to one dimension. So can this library survive in a field of power called boost of an ever abstracting ever generalizing and ever optimizing bunch of thinkers? A few points: * Geometry usually is based on a numeric coordinate type that comes with a distance measure. Many algorithms in geometry libraries rely on that. Intervals and interval containers of the ITL, similar to SortedAssociativeContainers, only require a strict weak ordering on their key type. So interval containers are less restricted and allow for a larger class of instantiations. You may for example want to work with interval sets of strings. * Interval containers implement interval combining styles that can be useful in providing and manipulating certain time grids. E.g. http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/ex… I'm not aware of something like that in geometry. * There are not only interval sets but also interval maps. itl::interval_map is the real workhorse in those real world applications that already exist. interval_maps provide a general idiom of aggregation of associated values. This idiom is very useful for computing statistical data through aggregation that occur in time. * Sometimes a more simple and basic class of data structures is advantageous. It may be simpler to implement optimizations. Like Lukes Manhattan integral polygons compared to more general GGL polygons. * Transfer of geometry knowledge to the more simple models of interval sets and maps may be a step users may not come up with. * The basic set and map concepts of the ITL allow for a variety of applications that may go beyond the scope of geometry. One such example is the self compressing large bitset, which not really has the look and feel of geometry ... http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/pr… ... or the example of a system of authorisations. See the example user_groups http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/ex… * Well known data structures from geometry like interval_tree or spatial indices do have different focuses and different applications. An interval_tree is more space efficient than an interval_map that can computes all overlaps at once. This may be desired if you need all of them. If you don't and you have reoccurring arbitrary stabbing queries interval_trees are the better choice. * itl::Maps are defining a generalized addition, which I think is a quite powerful feature that accounts for most of the goodies in the applications that we have done. This addition function is a generalisation of the common insert function on SortedAssociativeContainers and it introduces the aggregating properties of itl::Maps. The aggregate on overlap idiom is independent of the question, if the domain_type of the map or interval_map is a scalar or a tuple (has dimensions) or something else. There are already interesting applications of aggregations using itl::maps of tuples, but this exceeds the scope of the core library. Cheers, Joachim

1 0

[date_time] int64 overflow bug with subsecond duration
by Zachary Turner 25 Feb '10

25 Feb '10

Consider the following code, very simple in nature: static const boost::gregorian::date windows_epoch_base(1601, 1, 1); date_time d(windows_epoch_base, microseconds(12908391903991608)); This should resolve to sometime in early 2010 Now, the problem is that this number is already really big, not that many factors of 10 away from the int64 overflow boundary. microseconds() is really just the subsecond_duration<> template, and on my machine it's being parameterized as subsecond_duration<boost::posix_time::time_duration, 1000000>. The code for the constructor is as follows: explicit subsecond_duration(boost::int64_t ss) : base_duration(0,0,0, ss*traits_type::res_adjust() / frac_of_second) {} res_adjust is also resolving to 1000000. So compiler is doing 12908391903991608*res_adjust first, which causes an overflow. I think it should be doing ss * (traits_type::res_adjust() / frac_of_second) instead. I don't know a whole lot about date_time internals, so I thought I would ask here before just submitting a bug. Is the proposed fix correct? I made the change locally and it does indeed appear to resolve the problem. Zach

2 3

[move] will boost::rv work with types with virtual destructor?
by DE 25 Feb '10

25 Feb '10

sorry for a dumb question i noticed boost move lib mentioned in a recent message and decided to look at it i noticed that destructor for boost::rv class is declared but not defined so it can no longer be generated automatically then if an arbitrary type has a virtual destructor and we want to parameterize the boost::rv template with it a vtable for the boost::rv<type> must be generated among other things it must hold a pointer to rv<type>::~rv which is not defined is that really a problem? -- Pavel

2 2

Spirit V1.8 to V2.1 Porting Errors
by Alireza Bemanian 25 Feb '10

25 Feb '10

Hi, Trying to port the code to V2.1, a number of redefinition errors get generated by the compiler. The first instance is the extern InterLockedIncrement variable at line 73 of the interlocked.hpp file. The code is segmented for different platforms using #if #elif and so on directives. The project is at the same time ported from Visual Studio 2008 to 2010 RC1, and the redefinition error is caused by compiler not excluding parts of that file. The define by the Visual Studio is the _WIN32_WINNT base on the use of the 32 bit development PC. This definition is not listed by the #elif chain within the interlocked.hpp code and it seems that BOOST_USE_WINDOWS_H is used instead. Knowing the segments are coded to be mutually exclusive, still the code generates errors? Regards, Reza Bemanian

2 4

Re: [boost] is review system in place is extremely slow? (wasRe:[rfc] rcpp)
by Pete Bartlett 25 Feb '10

25 Feb '10

>From Robert Ramey > > to move those 3 libraries to the 'detail' namespace > > of Boost.Task and have review as it is, as opposed to waiting. What > > do you think? >I think I caught hell for doing something similar in the serialization >library. I had to make a number of components such as >BOOST_STRONGTYPEDEF, state_saver, smart_cast, etc. >which I put into boost - (not detail) and year afterwards this >was raised as a huge problem. And this was even though the >components had been their through two reviews. So I would >be careful about doing this. This seems a little more negative than I remember. If we are thinking of the same thread (see e.g. http://lists.boost.org/Archives/boost/2007/11/130567.php ) then a lot of the discussion was about headers directly in the boost root directory rather than a subdirectory, rather the issue at hand. My opinion is that there is no overarching programming design deity that is going to come down and smite us if we be a bit pragmatic. So what if Move [*], Fiber and Atomic get "smuggled" in if Task gets reviewed and accepted first? They don't have to be documented as accepted - on the contrary the documentation could have appropriate warnings as *not* formally accepted apart for indirect use via Task. >Another issue is: if Boost.Task depends upon Boost.Fiber >and Boost.Atomic, what happens if the Boost.Fiber or >Boost .Atomic are not approved? Sometimes the laudable goal of perfection turns open source projects into games of Nomic! Again, pragmatism should play a role here else Boost will never be the rich and full set of libraries that it fantastically could be. Pete [*] Move seems so core these days - another bit of pragmatism would see that fast-tracked through.

5 5