- Boost - lists.boost.org

[functional/hash] integer hash function
by Tim Blechmann 05 Oct '11

05 Oct '11

i was quite amazed that the default hash function for integers seems to be the identity function: from boost/functional/hash/hash.hpp: inline std::size_t hash_value(int v) { return static_cast<std::size_t>(v); } while this is probably the most efficient hash function, it is also the worst possible. is this done intentionally? tim

5 6

[operators] The future
by Daniel Frey 04 Oct '11

04 Oct '11

Hello, I would like to gather some feedback on my plan for the future of the Boost.Operators library. As the maintainer, I have to admit it was a pretty easy job for the last years, as not much has happened. The codebase is full of work-arounds, but it seems to be pretty stable. Another member of the list recently suggested an enhancement, see <https://svn.boost.org/trac/boost/ticket/5929>, which I think shows the first of two points that I would like to straighten out in the future: 1) The library currently mixes two domains, arithmetic operators and iterator helpers 2) No rvalue-support The first point, as already mentioned in the above ticket, could be solved by separating the two parts. I imagine the future Boost.Operators library to concentrate on arithmetic operators, while another, new library could concentrate on iterator and container helpers. Maybe there is an overlap with other libraries (Boost.Iterators), but I'll leave that to others. The (new) Boost.Operators library could provide a base for implementing the iterator helpers just like the current Boost.Operators library does - while there is no dependency in the reversed direction, i.e., the Boost.Operators library does not depend on iterators. The second point is actually a strong argument for a rewrite and a different interface. I have an implementation ready and as it turns out, rvalue-support could be used to optimize some cases *only* if the type itself is commutative. This property of a type is not taken into account in the current Boost.Operators library, which is why the new implementation has different bases, including a new set of grouped operators. See the end of this post for a list of the proposed bases. Note that the new grouped operators are also a consequence of taking commutativity into account, i.e., a field as a commutative_ring+dividable. Dropping some of the old grouped operators should not be a big deal, since grouped operators are more-or-less convenience only, the real functionality is in the "Simple Arithmetic Operators" (see current documentation). If there is a strong need, we could also preserve the old implementation as <boost/legacy/operators.hpp>, but I think it's also practical to drop it completely - old Boost versions are still available for those who need them. To sum up the plan: - Concentrate on arithmetic operators - Add rvalue-support - New set of convenience/grouped operators due to rvalue-support - Drop the old implementation, iterator support Someone else (Olaf?) then takes care of the iterator helpers. So, what do you think? Regards, Daniel ----------------------------- Proposed new base classes: equality_comparable less_than_comparable totally_ordered equivalent partially_ordered addable commutative_addable subtractable subtractable_left multipliable commutative_multipliable dividable dividable_left modable modable_left ring commutative_ring field andable andable_left commutative_andable orable orable_left commutative_orable xorable xorable_left commutative_xorable bitwise bitwise_left commutative_bitwise left_shifttable right_shiftable shiftable incrementable decrementable unit_steppable

10 18

[interprocess] Mixed 32bit/64bit processes shared memory current status
by Pete Bartlett 04 Oct '11

04 Oct '11

Dear Ion and Boost.Interprocessors, I'm very interested in the status of support for using shared memory across processes of mixed bitnesses particularly on Windows. I see from the thread here: http://lists.boost.org/Archives/boost/2011/02/177696.php and the trac here https://svn.boost.org/trac/boost/ticket/5230 that this has been looked at before. The ticket is marked as fixed in 1.47, but I believe the changes are actually only on trunk at the moment? I appreciate Ion saying in that Trac ticket that support is experimental and requires feedback from real-world users. I'd be happy to be such a guinea pig user. But to help me along the way, I have a couple of queries: - with trunk, what features from Boost.Interprocess are intended to work across bitness? (I'd plan to build both the 32-bit and 64-bit with the same version of MSVC). For instance, might interprocess::managed_shared_memory, interprocess::vector and interprocess::basic_string be expected to work? - Is it possible to back port the changes from trunk to 1.47 or 1.46.1? If so what would I need to copy? AlignedStorage, Move and Interprocess? Many thanks for any help on this, Pete Bartlett

1 0

Build trunk 1.46 libraries problems
by Paul A. Bristow 04 Oct '11

04 Oct '11

I've just updated trunk, and note that version.hpp has been updated to 1.46. When I try to link previous tests, I get messages like LINK : fatal error LNK1104: cannot open file 'libboost_test_exec_monitor-vc100-mt-sgd-1_46.lib' But when I try to rebuild the libraries, they are all still *1.45.* :-( my log file is attached. I also note some config failures that suggest something else may be wrong? ...updating 1 target... compile-c-c++ i:\boost-trunk\boost\bin.v2\libs\math\config\msvc-10.0\debug\threading-multi \has_gcc_visibility.obj has_gcc_visibility.cpp libs\math\config\has_gcc_visibility.cpp(7) : fatal error C1189: #error : "This is a GCC specific test case". call "C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"i:\boost-trunk\boost\bin.v2\libs\math\config\msvc-10.0\debug\threading-mul ti\has_gcc_visibility.obj.rsp" ...failed compile-c-c++ i:\boost-trunk\boost\bin.v2\libs\math\config\msvc-10.0\debug\threading-multi \has_gcc_visibility.obj... ...failed updating 1 target... Performing configuration checks - ../config//has_gcc_visibility builds : no ...found 47 targets... ...updating 1 target... compile-c-c++ i:\boost-trunk\boost\bin.v2\libs\math\config\msvc-10.0\debug\threading-multi \has_long_double_support.obj has_long_double_support.cpp ...updated 1 target... - ../config//has_long_double_support builds : yes ...found 15 targets... ...updating 4 targets... compile-c-c++ i:\boost-trunk\boost\bin.v2\libs\regex\build\msvc-10.0\debug\threading-multi \has_icu_test.obj has_icu_test.cpp libs\regex\build\has_icu_test.cpp(12) : fatal error C1083: Cannot open include file: 'unicode/uversion.h': No such file or directory call "C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"i:\boost-trunk\boost\bin.v2\libs\regex\build\msvc-10.0\debug\threading-mul ti\has_icu_test.obj.rsp" ...failed compile-c-c++ i:\boost-trunk\boost\bin.v2\libs\regex\build\msvc-10.0\debug\threading-multi \has_icu_test.obj... ...skipped <pi:\boost-trunk\boost\bin.v2\libs\regex\build\msvc-10.0\debug\threading-mul ti>has_icu.exe for lack of <pi:\boost-trunk\boost\bin.v2\libs\regex\build\msvc-10.0\debug\threading-mul ti>has_icu_test.obj... ...failed updating 1 target... I've tried changing boost_root and boost-build environment variables to 1.46 but makes no difference. Suggestions. Thanks. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

4 7

Interest in simple unformatted binary stream I/O?
by Beman Dawes 04 Oct '11

04 Oct '11

There have been many requests on Boost and various C++ newsgroups for unformatted binary I/O. For example, in 2003 Neal Becker wrote: I wonder if anyone has code for implementing unformatted I/O? What I have in mind is for the simple case where the application that reads data knows the data types, so this is not as complicated as the general marshalling situation. This proposal provides a very simple solution that works with standard library input and output streams. The one caveat is that the stream must be opened with filemode std::ios_base::binary to avoid certain data values being treated as line endings. int main() { fstream f("binary_stream_example.dat", std::ios_base::trunc | std::ios_base::in | std::ios_base::out | std::ios_base::binary); int32_t x = 0x01020304; int32_t y = 0; f << bin(x); // write 4 bytes f.seekg(0); f >> bin(y); // read 4 bytes BOOST_ASSERT(x == y); return 0; } For docs, header, and example code, see http://mysite.verizon.net/beman/binary_stream/binary_stream.html http://mysite.verizon.net/beman/binary_stream/binary_stream.hpp http://mysite.verizon.net/beman/binary_stream/binary_stream_example.cpp Is there interest in this for Boost? It seems way too small and simple to be a whole library itself. Are there any ideas where it should live and what namespace it should be in? --Beman

15 26

[accumulator] no type named 'result_type' in 'boost::fusion::void_'
by Vicente J. Botet Escriba 04 Oct '11

04 Oct '11

Hi, I'm getting this error on trunk ../../../boost/accumulators/framework/extractor.hpp:36:74: error: no type named 'result_type' in 'boost::fusion::void_' typedef typename mpl::apply<AccumulatorSet, feature_type>::type::result_type type; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~ I'm including #include <boost/accumulators/framework/accumulator_set.hpp> #include <boost/accumulators/statistics/count.hpp> If I add the following include everything is OK. #include <boost/accumulators/accumulators.hpp> Is this a know issue? Best, Vicente

2 4

[optional] Thoughts on disallowing assignment for wrapped references.
by Mostafa 04 Oct '11

04 Oct '11

Boost.Optional seems to really have a lot of potential for what I want to do, but one thing about it has been nagging me, specifically it's assignment semantics for wrapped references being different from the semantics of bare C++ references (see http://tinyurl.com/4yna643) Has/have the author(s) of the library or anyone considered disallowing assignment for Boost.Optional types that wrap references, and if so, what would the consequences of this entail? I rather disallow assignment in this case, then have what's basically a wrapper class behave partially differently than the type it's supposed to emulate. Thanks in advance, Mostafa

6 34

help with boost::property_tree erasing nested entries please
by Bernd Prager 04 Oct '11

04 Oct '11

All, I would appreciate some help with erasing a nested node entry in property_tree. Below is my example. (2) works, but only erases an entire tree. (1) doesn't but it's really what I want. Thank you for any help. (I'm sorry, the documentation is not very verbose on this topic.) -- Bernd #include <iostream> #include <string> #include <boost/property_tree/ptree.hpp> using namespace std; namespace pt = boost::property_tree; int main(void) { pt::ptree props; props.put("db.name", "Sesame"); props.put("user.name", "Ali Baba"); cout << props.erase("db.name") << " children erased. " << endl; // (1) cout << props.erase("db")<< " children erased. " << endl; // (2) }

2 2

Re: [boost] [Review:Algorithms] My review
by Brent Spillner 04 Oct '11

04 Oct '11

Also late! My apologies. On Mon, 03 Oct 2011 00:46 Phil Endecott wrote: >implementation. Furthermore, the amount of discussion of a proposal >seems to be in inverse proportion to its complexity! To avoid getting ...which probably tells us more about the number of people who take the time to fully understand more complex submissions than it does about anything else... >bogged down in endless discussions of trivia we should set a lower >bound on the complexity of submissions, and these functions are below >that threshold. I disagree... these algorithms are certainly trivial, but also frequently used by most programmers. A high-quality implementation has the potential to eliminate (well, reduce) the need for every C++ programmer to maintain medium-quality versions in a personal toolkit, saving a tremendous number of aggregate man-hours (initial development, maintenance, and reading others' versions as a possible source of defects in unfamiliar code) worldwide. Note that the original submission has already been substantially improved based on reviewer feedback--- how many of the tens of thousands of one-off versions out there have the same issues, or worse? Anyway, my own review: > * What is your evaluation of the design? Overall design is fine--- these algorithms are simple and should be kept so. Like several other reviewers, I believe some of the function and header names are suboptimal (increasing() should be nondecreasing(), any.hpp should be any_of.hpp, etc.), and as much as I abhor a boat shed argument I do honestly believe that they be reevaluated before release. There does seem to be a lot of redundant code that could be refactored out of the individual search algorithms, but that's an internal issue. > * What is your evaluation of the implementation? Adequate. I filed several issues on GitHub, and others contributed more. Marshall has been extremely responsive, and I think it's clear that the library will be top-notch before release. > * What is your evaluation of the documentation? Incomplete, but what library is in version 1? Certainly adequate for release. > * What is your evaluation of the potential usefulness of the library? Quite. Actually, I think the search algorithms are hindered a bit in this respect by their documentation (strengths and weaknesses in given situations, which to use, caveats, etc.), but that's been beaten to death here and on GitHub and is already being remedied by Marshall. > * Did you try to use the library? With what compiler? Did > you have any problems? No. > * How much effort did you put into your evaluation? A glance? > A quick reading? In-depth study? I carefully read the code and skimmed the docs, and logged my detailed comments as GitHub issues (almost all of which have already been addressed.) > * Are you knowledgeable about the problem domain? Fairly, although I'm not sure I'd ever seen the BMH search before. In summary, I think Algorithms should certainly be accepted, and like Phil and many other reviewers I think it's a good framework for other small submissions that would be useful to the community at large but don't justify a separate library.

1 0

where to go to with libraries for a narrow problem domain?
by Thijs (M.A.) van den Berg 03 Oct '11

03 Oct '11

I'm part of a community that work in financial mathematics, and every now and then there are ideas to start library development on narrow sub-fields. A thing missing is a centralized place -exactly like boost- where people can submit and acquire high quality *narrow* C++ source code libraries. There are a lot of fragmented initiatives in mathematical finance: there is overlap between projects, quality may vary a lot, etc. The landscape resembles a bit the pre uBlas era for matrices. It there a place just like boost (good quality C++ source code libs with a large community) for narrow libraries? If not, wouldn't it be possible to create a subsection at boost for narrow libraries? Something like the Matlab toolboxes for C++ source libraries?

3 2