- Boost - lists.preview.boost.org

[test] backward compatibility issue
by Jürgen Hunold 10 Oct '11

10 Oct '11

Hi Gennadiy, I'm getting some compiler errors when using the new trunk version of Boost.Test with our sources. I'm getting error: ‘global_fixture_impl’ in namespace ‘boost::unit_test::ut_detail’ does not name a type when using BOOST_GLOBAL_FIXTURE and only #including "boost/test/unit_test_suite.hpp" This file #defines at line 179: static boost::unit_test::ut_detail::global_fixture_impl<F> BOOST_JOIN( gf_, F ) ; a simple #include <boost/test/tree/global_fixture.hpp> fixes this. Patch attached. Okay to commit? yours, Jürgen -- Dipl.-Math. Jürgen Hunold | IVE mbH Software-Entwickler | Lützerodestraße 10 Tel: +49 511 897668 33 | 30161 Hannover, Germany Fax: +49 511 897668 29 | http://www.ivembh.de juergen.hunold(a)ivembh.de | | Geschäftsführer: Sitz des Unternehmens: Hannover | Univ.-Prof. Dr.-Ing. Thomas Siefer Amtsgericht Hannover, HRB 56965 | PD Dr.-Ing. Alfons Radtke

2 2

Boost.Algorithms request
by Zoltán Tóth 10 Oct '11

10 Oct '11

I ask to change the name of function is_ordered(). The "is_" prefix suggests that it is a boolean function which it is not. Also, there are other functions there with prefix "is_" and which are boolean functions, and this non-uniformity hurts the eye. I suggest the name "first_misordered".

4 3

Re: [boost] vsix - template_profiler extension, Templight
by József Mihalicza 09 Oct '11

09 Oct '11

Hello, From: Domagoj Saric: ...you might want to try the Templight route. A couple of years back the Hungarian team behind it tried to do the same thing as you (a "meta program debugger and profiler" Visual Studio add-in, only it was written in C++ rather than in C#). The source for an alpha-ish version was also available somewhere... The biggest problem with our tools is that they are rather prototypes than tools for everyday use. As none of the authors have had enough time to maintain them, they more or less remained in an alpha state. Fortunately this seems to change soon, a team with dedicated resources is being formed to make these tools usable and presumably public domain. What we have so far: * Templight framework: a set of command line utilities, based on Xerces and boost.{wave,spirit}. Supports g++ and VC (patches and warning message interpretation). * Visual Studio add-in, where the user can place breakpoints in templates, view template stack, instantiation history, debug step by step. * Standalone debugger application with the same features as of the VS add-in. C++, Qt, mainly tested on Windows. * Templar: standalone visualizer application: can load previously generated (with the cpp2trace tool) trace files and draws the instantiation forest allowing step by step debugging. C++, Qt, graphviz. The latest binary for Windows is available here: http://people.inf.elte.hu/pocok/ * Ad-hoc solutions for profiling: modified g++, also had some patches for VC to print timestamp at each warning. * A not-yet-implemented approach to cope with inheritance. If B inherits A, currently the reported order is Abegin,Aend,Bbegin,Bend instead of the expected Bbegin,Abegin,Aend,Bend. As we used handcrafted makefiles (on linux) and projects files (VC) with absolute paths to installed libraries, it is not trivial to make the source compilable. This is why we decided not to publish it in its current form. Still, if anyone is interested in any of them, feel free to contact me, I can send the current version. Regards, Jocó

1 0

Re: [boost] [1.46.0] Compilation Issues
by Lars Viklund 08 Oct '11

08 Oct '11

On Sat, Oct 08, 2011 at 11:34:02AM +0530, ranganaths wrote: > Hello, > trying to compile on MSVC 6.0, but the same works well in Cygwin. Most of > Pls let me know how to overcome the same. All the > redefinitions are the clashes with that of the MSVC compiler includes. VC6 is a pre-standard compiler. As such, it has lots of quirks and templates are pretty much unusable on it. I strongly recommend either upgrading the compiler (there's free Express editions and reasonably cheap business and academic versions through BizSpark and DreamSpark), or using older Boost versions who accidentally care more about legacy toolchains. Strong words, but it's not feasible maintaining workarounds for legacy toolchains, not to mention actively fixing things for them. There's a huge thread on what to do with dysfunctional toolchains a few months ago. It's an amusing read. -- Lars Viklund | zao(a)acc.umu.se

1 0

[1.46.0] Compilation Issues
by ranganaths 08 Oct '11

08 Oct '11

Hello, I am new to this forum. I am using the Boost Library in my open source application and I am facing lot of compilation issues when trying to compile on MSVC 6.0, but the same works well in Cygwin. Most of the compilation errors are based on the redefinition. The errors is as below error C2371: 'XXX' : redefinition; different basic types Pls let me know how to overcome the same. All the redefinitions are the clashes with that of the MSVC compiler includes. Eg: Boost has definition for 'round_toward_zero' in e:\Application \boost\detail\limits.hpp(58) : see declaration of 'round_indeterminate' c:\program files\microsoft visual studio\vc98\include\limits(28) : error C2371: 'round_toward_zero' : redefinition; different basic types Regards, Ranganath

1 0

fusion - reverse_view on maps
by Brandon Kohn 07 Oct '11

07 Oct '11

Hello, Awhile back I was using fusion.reverse_view on a fusion.map sequence (I think it was ~<=1.37 or thereabouts.) In later upgrades this became broken as a bidirectional concept was enforced on the reverse_view (quite sensible.) To work around this I made a minor change to my version which allowed reverse_view to work on both bidirectional sequences and those meeting the is_associative trait. Anyway, it got me wondering if there is a good reason that the map type doesn't model a bidirectional sequence? Cheers, Brandon

2 2

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

07 Oct '11

I wrote about: >http://lists.boost.org/Archives/boost/2011/02/177696.php >https://svn.boost.org/trac/boost/ticket/5230 What was obvious to the contributors to the above discussion, but dawned on me only slowly, was that mixed bitness shared memory only stands a chance of working if ones uses offset_ptr< void , boost::int64_t , boost::uint64_t > rather than the default offset_ptr< void > (which is possible on current trunk). I've now begun testing this in my own app and it is looking promising so far. Hope this helps someone googling for the same thing. Pete

2 1

[Containers] How about a list with O(1) splice?
by Phil Endecott 07 Oct '11

07 Oct '11

In another thread, Stephan T. Lavavej wrote: > Two-list partial-splice is now linear time. FDIS 23.3.5.5 > [list.ops]/14: "Complexity: Constant time if &x == this; > otherwise, linear time." Is there an opportunity here for Boost.Containers to provide a std::list replacement that keeps the old O(1) splice and O(N) size? I can imagine a lot of demand for this once people discover that their old splicing code is trashed by a std library upgrade... [OT: does anyone know of a list of "C++1x nasties" like this? It's easy to find lists of new features, but harder to find lists of misfeatures...] Regards, Phil.

8 19

[Review] Review results for Lockfree
by Hartmut Kaiser 07 Oct '11

07 Oct '11

All, The review for the Lockfree library written by Tim Blechman started July 18th 2011 and ended on July 28th. I counted 8 votes, none of which were NO. All authors votes YES, some made additional requests. Overall, the verdict of the community was clear: Tim Blechmann's Lockfree library is ACCEPTED The discussion was lively and it touched on several points. Design ------ The design of the library is sound, the API is usable. Except for naming issues (discussed below) almost no comments have been made on how to change it. People reviewing the library would like to see a more modular approach to lockfree data structures in general, possibly by exposing building blocks or by utilizing policies. The general interest was to have a more diverse set of data structures available, such as a lock-free linked list or bounded and fixed-sized data structures. Atomics Library --------------- As the initial review announcement stated, Lockfree depends on an external Atomics library, which has to be separately reviewed in order to get into Boost as a first class library. There has been some discussions whether Lockfree could be accepted without Atomics being reviewed. Others suggested Lockfree may be reviewed and added to Boost SVN only after Atomics got reviewed (this was mentioned in the review announcement as well). After all those discussions and based on the wide interest Lockfree data structures have, I'd suggest to add the current Atomics library as an implementation detail to Lockfree. Special handling of compilers which already have implemented std::atomics would be good if added to Lockfree, though. Naming ------ The consensus was that the naming of the reviewed data structures has to be changed. The names should be either fifo and lifo or queue and stack. AFAIK, Tim already addresses this point. Documentation ------------- The consensus of almost everybody referring to the documentation was that it needs more work. Here is a short (but non-exhaustive) list of things being mentioned: - It lacks rationale and information about the implementation - The class synopsis of the data structures should be accessible from the "Reference" page. - Make non-thread-safe parts more explicit (fifo::empty is described as non-thread-safe) - Document exception guarantees - More information needed on internals, the design, and rationale I would like to thank all who participated in the discussions. Regards Hartmut --------------- http://boost-spirit.com

5 8

[boost.program_options] another constructor for option_description
by Guilherme Maciel Ferreira 07 Oct '11

07 Oct '11

Hi list, Through options_description_easy_init::operator()(const char* name, const char* description), I can create an option_description with just the option name and description, without the value_semantic. However, all option_description class constructors require this value_semantic. Checking the code, I saw that options_description_easy_init uses untyped_value to create an option_description without type. Why not providing a set of constructors consistent with the options_description_easy_init::operator() operators? Kind regards, Guilherme -- Guilherme Maciel Ferreira Gtalk: guigasurf MSN: guigasurf(a)hotmail.com Mobile Brazil: +55 48 9904 3728 e +55 48 9134 4651 Skype: guilherme.maciel.ferreira

1 0

[property_tree] include directive for non-info files
by Ivan Le Lann 07 Oct '11

07 Oct '11

Hi, In Boost.PropertyTree, INFO format has the nice #include directive. But it seems you cannot include other formats. Typically such INFO file, key { #include_xml "my.xml" } with "my.xml" : <root><child>kid</child></root> could give : get<std::string> ("key.root.child") == "kid" A very quick look at info parser makes me think that it would be easy to implement. Any comment ? Regards, Ivan

2 1

[filesystem] New operational function added: canonical()
by Beman Dawes 06 Oct '11

06 Oct '11

A canonical() function has been added at the suggest of David Svoboda from CERT. Boost.Filesystem's class path had such a function at one time, but it was deprecated because it didn't handle symlinks correctly. The new canonical() free function walks the path resolving symlinks, so now works correctly even when symlinks are present. For the curious, David's rationale for the function follows. --Beman Canonicalized pathnames are an important security measure when you want to do validity checking on your path (eg does this path live in /home/goodguy or /home/badguy?). There are several implementations of canonicalization functions, ranging from POSIX's realpath() function, to the GNU library's canonicalize_file_name(). For platform-independent implementations, Java provides the File.getCanonicalFile() method. CERT advocates the use of canonicalized filenames in its Secure Coding rules for both C FIO02-C. Canonicalize path names originating from untrusted sources https://www.securecoding.cert.org/confluence/x/EAY and Java IDS02-J. Canonicalize path names before validating them https://www.securecoding.cert.org/confluence/x/S4EVAQ

1 0

Interest in Boost.Array companion: StaticVector - A statically allocated fixed capacity vector
by Andrew Hundt 06 Oct '11

06 Oct '11

I've implemented a small companion class to boost.array that functions like a stack allocated vector with fixed capacity. The motivation for this class came when I was using boost.array in an interprocess library, when I realized that I actually desired an adjustable size boost.array, without the complexity of the vector class in the interprocess library. The result is StaticVector, which is boost.array directly modified with a size in front of the array, and added facilities to match std::vector. The Implementation is available at: https://github.com/ahundt/Boost.StaticVector Sample Code: StaticVector<std::size_t,3> three; three.push_back(5); three.push_back(2); // size: 2 capacity: 3 three.push_back(3); three.push_back(1); // throws std::out_of_range exception indicating the capacity has been exceeded So here is the big question: Is there any interest in the class? Cheers! Andrew Hundt

7 12

[Review:Algorithms] all.hpp vs std::count
by Andrew Hundt 05 Oct '11

05 Oct '11

What is the advantage of the functions in all.hpp over std::count? I feel like one could simply call (in pseudocode) std::count == 0, std::count == 1, std::count == class.size() to achieve the same effect. Cheers! Andrew Hundt Robotics Engineer National Robotics Engineering Center Carnegie Mellon University 908-720-5501

5 11

[website] URL for most recent version of BoostBook docs?
by Beman Dawes 05 Oct '11

05 Oct '11

http://www.boost.org/doc/libs/1_47_0/doc/html/boostbook.html is the URL for 1.47.0. What URL always points to the most recent version? --Beman

4 4

[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