- Boost - lists.preview.boost.org

Re: [boost] first steps to submitting - boost :: observers
by Bjorn Reese 19 Sep '16

19 Sep '16

On 09/17/2016 08:10 PM, Robert McInnis wrote: > https://github.com/tiny/boost_observers.git What are the advantages of this library over Boost.Signals2 [1]? Same question with regards to the Boost.Synapse [2] proposal. My impression from a brief look at your repository is that you need to focus more on thread-safety. Is there any way to avoid the overhead of thread synchronization in a single-threaded application? Observers are invoked while the mutex is locked, so observers cannot make calls on the subject. How does the lock-free mutex perform, especially when congested? Why is the lock-free mutex recursive? There are several member variables that are used as if they are atomic but they are not declared as such, e.g. Subject::_block, Numeric<T>::_x (think T == long long.) The Scope template can be replaced by lock_guard if you model the LockFreeMutex after the BasicLockable concept [3]. The thread_self() and thread_pid() functions can be replaced by this_thread::get_id(). Replace the hAtomic macro with a type alias. Use <cstdint> instead of <stdint.h> to reduce polution of the global namespace. [1] http://www.boost.org/doc/html/signals2.html [2] http://zajo.github.io/boost-synapse/ [3] http://en.cppreference.com/w/cpp/concept/BasicLockable

4 6

[density] version 7
by Giuseppe Campana 19 Sep '16

19 Sep '16

Hi to all, I’ve just merged to the master branch a major review of density, an header-only library of heterogeneous dense containers. Unfortunately this update includes some renamings. Anyway the new names are simpler and more explicative: heterogeneous_array, heterogeneous_queue, function_queue, lifo_array. The update consists of fixes and optimizations. The results of the benchmarks are included in the documentation. The container function_queue gives the best results, being many times faster than an std::queue of std::function’s (http://peggysansonetti.it/tech/density/html/func_queue_bench.html) The library is not yet ready for asking a formal review, but hopefully it will be in a few months. Html overview (now a little more schematic) and reference doc at http://peggysansonetti.it/tech/density/html/index.html Repository at https://github.com/giucamp/density/tree/master Giuseppe Campana.

1 0

Fuzzy string search to the Boost String Algortihm
by Зайцев Александр 19 Sep '16

19 Sep '16

Hello. I want to discuss about some proposals. I am working on Levenshtein distance and Damerau-Levenshtein distance algortihms. I hope, that these implementations will be pulled to the Boost String library. But i think that we can add to the Boost String Library some more algorithms for fuzzy searhing. I mean these algortihms: Levenshtein distance Damerau-Levenshtein distance Bitap algorithm with modifications by Wu and Manber Spell-checker method N-gram method Signature hashing method BK-trees What do you think about this idea? If you think that it can be implemented to the Boost String Algo, i will start work on this list immediately. Best regards, Zaitsev Alexander.

2 2

first steps to submitting - boost :: observers
by Robert McInnis 19 Sep '16

19 Sep '16

G'afternoon, This is my first time submitting to a public repo, please be gentle I'd like to submit a series of classes I have been using since '90. The initial set implements a thread safe subject/observer pattern. I have included a handful of example programs, two fairly trivial and the third more in-depth. All examples are single file examples to make compilation trivial. This is the first re-work of my original tools, making them more boost-friendly. I expect to add more default observer templates and observable objects, but that will come with time. WHY? -- The reason for these classes is to help insure the mathematical integrity of your data model in relation to your business rules. If at any time you were to change one of your data elements without updating all those dependent on it, then your data integrity would be compromised. These classes look to solve that. As an example: -- using namespace boost::observers ; Numeric<long> x, y, z ; // rules: y = x + 2; z = y * 3 ; x = 5 ; printf( "%d \n", z ) ; x = 1 ; printf( "%d \n", z ) ; -- Setting the rules properly, the classes allow for 'z' to be correct each time it's printed using code almost exactly like this. This will remove the possibility of accidently forgetting to trigger the rule update. WHERE? -- The repo can be found here: git clone https://github.com/tiny/boost_observers.git Any input on how to continue from this point would also be much appreciated. I have skype and ventrilo servers available if that helps. Thanks in advance, Rob -- Robert McInnis

5 7

[release] Boost 1.62.0 - One week to close.
by Rene Rivera 16 Sep '16

16 Sep '16

Reminder.. Next week, on the 21st, the release will close for all changes. Except for extra ordinary and approved changes. Please exercise caution when merging changes to master branches. Remember that changes need to be well tested on the develop branches before going into master. And that changes at this point should be for critical problems. Thanks, the Release Team. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 2

[uuid] PR to remove auto-linking to advapi32 when BOOST_ALL_NO_LIB is defined
by Edward Diener 15 Sep '16

15 Sep '16

I don't know how to resolve a PR for uuid ( https://github.com/boostorg/uuid/pull/11 ). If a library exists only as a DLL and not as a static library should BOOST_ALL_NO_LIB still be considered in effect ? My viewpoint is 'no' but the person who created the PR believes that the BOOST_ALL_NO_LIB config macro should turn off any #pragma auto-linking in code even when their is no other way to use a library other than as a shared library. What I am afraid of is breaking user code even if BOOST_ALL_NO_LIB is defined by producing link errors. But perhaps I am wrong and this should be considered justified when BOOST_ALL_NO_LIB is being used.

5 7

[algorithm] Musser-Nishanov sequence search algorithm
by Jeremy Murphy 15 Sep '16

15 Sep '16

Dear Boost community, most of you are probably familiar with Dave Musser, well known for his work on generic programming, introsort and more. What you maybe didn't know, and I didn't until not that long ago, is that he and Gor Nishanov also designed (based off KMP) and wrote a generic sequence search algorithm to compete with Boyer-Moore, etc, which apart from being competitively fast is ostensibly more generic than the others. You can read for yourself on Dave Musser's website: http://www.cs.rpi.edu/~musser/gp/algorithms.html By "more generic" I mean it has a fallback algorithm if the corpus does not have random-access iterators, and its behaviour can easily be tuned for the alphabet size to dramatic effect. (I haven't looked into the 'tunability' of BM, BMH, KMP, etc, so I'm not sure if this is a unique feature.) But at face value, it appears to have powerful features that the others lack without compromising performance, which is pretty neat. So I've been in contact with the original authors and with their permission am just playing the messenger to bring the algorithm to wider attention with the expectation that it is something we could really benefit from. What I hope for now is to have discussion on whether indeed it is an algorithm that we want, presumably alongside the others in Boost.Algorithm. My slightly more controversial thought is that, if no shortcomings or weaknesses are revealed, this could up being the superior search algorithm. I've opened a pull request on Boost.Algorithm with the code so everyone can play around with it if they want. https://github.com/boostorg/algorithm/pull/25 Looking forward to hearing what everyone thinks. Cheers. Jeremy

1 0

[uuid][rational] Pushed bug fixes to 'master'
by Edward Diener 15 Sep '16

15 Sep '16

I pushed some bug fixes from 'develop' to 'master' for the uuid and rational libraries. The fixes had been tested on the 'develop' branch for a long time and the results showed that the fixes were fine. While none of the fixes were major I felt that the fixes were important enough to go in the upcoming Boost release if they are going to be picked up. I, and probably other members of CMT, should have been more proactive in pushing these fixes to 'master' sooner, once they showed green on the develop test matrix.

2 3

Final Call for Extended Abstracts and Posters: International Conference on Information Society (i-Society 2016), Technical Co-Sponsored by IEEE UK/RI Chapter!
by David Brown, i-Society 2016 14 Sep '16

14 Sep '16

1 0

[log] Boost 1.62 cannot compile log with Oracle Developer Studio 12.5
by Aparna Kumta 14 Sep '16

14 Sep '16

Compiling Boost.log with Oracle Developer Studio 12.5, we see the following failure: % "CC" -std=c++11 -library=stdcpp,CrunG3 -xO4 -mt -erroff=%none -m32 -KPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_DATE_TIME_DYN_LINK=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_LOG_BUILDING_THE_LIB=1 -DBOOST_LOG_DLL -DBOOST_LOG_HAS_PTHREAD_MUTEX_ROBUST -DBOOST_LOG_WITHOUT_DEBUG_OUTPUT -DBOOST_LOG_WITHOUT_EVENT_LOG -DBOOST_SPIRIT_USE_PHOENIX_V3=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_DONT_USE_CHRONO=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_DLL=1 -DDATE_TIME_INLINE -DNDEBUG -D_XOPEN_SOURCE=500 -D__EXTENSIONS__ -D__STDC_CONSTANT_MACROS -D__typeof__=__typeof__ -I"../../.." -I"../../../libs/log/src" -c -o "../../../bin.v2/libs/log/build/sun/release/stdlib-gnu/threading-multi/posix/ipc_reliable_message_queue.o" "../../../libs/log/src/posix/ipc_reliable_message_queue.cpp" "../../../libs/log/src/posix/ipc_reliable_message_queue.cpp", line 61: Error: #error Boost.Log: Native 32-bit atomic operations are required but not supported by Boost.Atomic on the target platform. This seems to be a configuration issue. The following changes seems to work: 1) In boost/atomic/detail/platform/platform.hpp % !diff diff ./platform.hpp ./platform.hpp_orig 46c46 < #elif (defined(__GNUC__) || (__SUNPRO_CC >= 0x5130)) && (defined(__i386__) || defined(__x86_64__)) --- > #elif defined(__GNUC__) && (defined(__i386__) || defined(__x86_64__)) 68c68 < #elif (defined(__GNUC__) || (__SUNPRO_CC >= 0x5130)) && defined(__sparc) --- > #elif defined(__GNUC__) && defined(__sparc_v9__) The above change causes the compilation to proceed further, however, it fails again with another configuration issue causing failure to build atomic library "CC" -std=c++11 -library=stdcpp,CrunG3 -xO4 -mt -erroff=%none -m32 -KPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_ATOMIC_SOURCE -DNDEBUG -I"../../.." -c -o "../../../bin.v2/libs/atomic/build/sun/release/stdlib-gnu/threading-multi/lockpool.o" "../../../libs/atomic/src/lockpool.cpp" "../../../boost/atomic/detail/ops_gcc_sparc.hpp", line 69: Error: The function "fence_before_store" must have a prototype. In boost/atomic/detail/ops_gcc_sparc.hpp, the following change seems to resolve the issue % !diff % diff ./ops_gcc_sparc.hpp ./ops_gcc_sparc.hpp_orig 69c69 < fence_before(order); --- > fence_before_store(order); 71c71 < fence_after(order); --- > fence_after_store(order); 110c110 < fence_before(order); --- > base_type::fence_before(order); 118c118 < fence_after(order); --- > base_type::fence_after(order); I will submit a PR for this change. Thanks, Aparna

1 0