January 2010 - Boost - lists.preview.boost.org

Re: [boost] Boost library submission (poll for interest)
by Bob Walters 20 Jan '10

20 Jan '10

Sorry for the delay here. Original reply bounced due to 'reply to digest' subject line. On Tue, 5 Jan 2010 21:21:29 +0100, "vicente.botet" <vicente.botet(a)wanadoo.fr> wrote: > I'm interested on a library that has transactional shared memory, but something more general that your containers database in shared memory. Can your library be extendeed to manage with types that are not containers? Currently there is an interface between the trans infrastructure (TI) and the containers allowing the containers to offer transactional operations, and indicate to the TI how they should be logged, committed, etc. This was intended to help make adding containers easier. There isn't really an assumption that transactional objects are containers - they could be anything which adheres to the interface. For example: I'm planning a quick wrapper for types T which makes T transactional for updates done to it via operator=. I need this for integerss that I want to use as sequences in one use of STLdb. (e.g. for key generation.) > If I have understood, the data is stored using Boost.Interprocess. Could you clarify why do you force the stored types to be Serializable? I'm not relying on the durability of the boost interprocess region. Nor am I trying to serialize the shared memory from directly to disk. Stefan has challenged me to do that, and I'm considering a variation which would do that, but it isn't without it's own issues. For now, I went with the approach of using serialization for sending K,V types to logs or checkpoints as a way to avoid those issues. My current concern with direct storage is that (assuming K and V may not be concrete types) it seems like it will require a lot of memory use tracking which could add an unwanted expense to shared memory pointer traversal. > With your library, there are alreasy 3 libraries under construction providing a transactional service (Boost.STLdb, Boost.Persistent and TBoost.STM). The ideal would be to have a single transactional framework with several transactional resources, e.g shared memory resource (Boost.STLdb), persistent resource (Boost.Persistent ), in memory resource (Boost.STM). If I'm not wrong Boost.Persistent contains already a Ressource concept. I would like to see how this transactional framework can be made generic so the three libraries can share the same transaction. Stefan, Bob, are you interesteed in participating on such a framework? Yes. Stefan had suggested this in private e-mails earlier, and I'll have to adapt to fit his interfaces. As I've alluded previously, I would like to see it possible to use Boost.Persistence with my library, as several shortcomings of STLdb would be addressed in that way. Part of doing that involved bringing all transaction control under one manager. Stefans library is the most robust in this sense, so I plan to work with and adapt to his interfaces. > Could you give a link from where to download the code. If you want I can add your library to the Boost Libraries Under Construction page https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction. Currently it's in subversion only on sourceforge. I'm finishing some changes to the checkpointing mechanism, and I'm going to finish that first. Will let you know when its ready, thereby supporting the under construction entry. If it helps at all, I could move the SVN repository to the sandbox, or post the tarball into the Vault (?)

5 12

[boost-lists][string algo] C++0x string algo.
by Germán Diago 19 Jan '10

19 Jan '10

Hello. I'm using c++0x-enabled c++0x compiler. I was going to use this piece of code: typedef vector< string > split_vector_type; split_vector_type svec; split(svec, str, is_any_of(":")); for c++0x, I shouldn't need to define a typedef to take advantage of that. I think it would be more idiomatic (and way easier to do) to use something like this: auto splitrange = split(str, is_any_of(":")); So I would like to know if it's possible to map split to a range result by default (not a vector, maybe). And it could also be used with a vector if you put it explicitly: auto splitvec = split<vector<string>>(str, ....); I think the whole library should be readapted to return by value. I've spent some time figuring how to use the library because of the out parameters in the arguments. Can anyone tell me if there is any plan to change this? Or if it should be possible? Thanks in advance.

5 11

[random] normal_distribution
by Neal Becker 19 Jan '10

19 Jan '10

According to: http://www.taygeta.com/random/gaussian.html The method we're using is less stable and less computationally efficient than the method presented there. Is this true?

1 0

The boost component dependencies blues
by Stefan Seefeld 19 Jan '10

19 Jan '10

I'm not sure what the best place is for this question, but since it is symptomatic for a general theme (which I have complained about a lot in the past), I'll write it here: I'm trying to generate a boost subset that allows me to build boost.python and its dependencies into my own package. To do that, I ran "bcp python ...". I'm surprised to find all these components in the generated source tree: date_time, graph, mpi, regex, serialization, test, thread. And that's only compiled components (content of lib/). There are many more header-only components (i.e. subdirectories under boost/), such as spirit, variant, property_map, property_tree, dynamic_bitset. Is this really a minimal subset to use boost.python ? I can't quite believe it. In particular, what is boost.mpi doing there, and what boost.serialization (and boost.spirit) ? I'm going to great length to be able to use boost in a production environment, but I have to admit that this is quite unacceptable. :-( Stefan -- ...ich hab' noch einen Koffer in Berlin...

9 24

[math] Comeau can't match math::tools::fmod_workaround
by Mateusz Loskot 19 Jan '10

19 Jan '10

Hi, I'm not sure if I should submit this issue directly to Trac, so I decided to post it here first. Compiling Boost.Math using Comeau + GCC on Linux throws error that suggests mismatch of dobule and long double where single type T is expected: como-linux.compile.c++ ../../../bin.v2/libs/math/build/como-linux/debug/link-static/ellint_3l.o Comeau C/C++ 4.3.10.1 (May 7 2008 12:23:21) for LINUX_INTEL_ELF_Beta Copyright 1988-2008 Comeau Computing. All rights reserved. MODE:non-strict warnings C++ noC++0x_extensions "../../../boost/math/special_functions/ellint_3.hpp", line 185: error: no instance of function template "boost::math::tools::fmod_workaround" matches the argument list argument types are: (double, long double) T rphi = boost::math::tools::fmod_workaround(fabs(phi), T(constants::pi<T>() / 2)); ^ detected during instantiation of "T boost::math::detail::ellint_pi_imp(T, T, T, T, const Policy &) [with T=long double, Policy=c_policies::c_policy]" at line 309 1 error detected in the compilation of "../../../libs/math/build/../src/tr1/ellint_3l.cpp". como -tused -c --long_long -DBOOST_ALL_NO_LIB=1 -D_GNU_SOURCE=1 --no_inlining -O0 -g --exceptions -I"../../.." -I"../../../libs/math/src/tr1" -o "../../../bin.v2/libs/math/build/como-linux/debug/link-static/ellint_3l.o" "../../../libs/math/build/../src/tr1/ellint_3l.cpp" Could any one confirm if it is an error indeed? Should I submit ticket? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

2 10

[Signals2] Using dummy_mutex in a multithreaded program
by Peter Petrov 18 Jan '10

18 Jan '10

Greetings Frank, boosters, Currently using a signal with a boost::signals2:dummy_mutex works well only in single-threaded programs. I'm wondering if it can be made a little more useful. I have an use case with a single global signal, where all slots and connections are setup on program start. Afterwards a bunch of threads are fired, and each of them can call the signal's operator(). There are no more connections added/removed, only signal invocations. According to the workflow described here: http://www.boost.org/doc/libs/1_41_0/doc/html/signals2/thread-safety.html#i… ...it seems that a dummy_mutex should be enough, since the slot list is never modified. It turns out it's not - I'm getting assertion failures in nolock_cleanup_connections() because the _shared_state.unique() requirement is sometimes violated. Because using a real mutex will significantly degrade both performance and concurrency, I'm wondering if this assertion is really necessary. In this case it should be safe to continue even if the uniqueness is violated, because the connection list is never modified. And I think my use case is quite common :) - Peter

2 2

[chrono] v0.3 New Stopwatch Feature
by vicente.botet 18 Jan '10

18 Jan '10

Hi, I'm pleased to announce the new version of the Boost.Chrono library. The implementaton is quite stable; the new interface could suffer of some modifications, renaming, ... as far as you submit some proposals. I would request a formal review soon and I will need a review manager. I know that review managers are hard to find, so if you are interested in the library, please 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…. I've tested it with gcc and MSVC. Previoous version of the library have been testted on Mac, but I'm not able to test this platform. Could someone check if there are some regressions on Mac? New Features: * Process cpu clocks * Independent process cpu clocks for real, user, system process CPU time * Global process cpu clock for real, user, system process CPU time * Stopwatch concept measuring elapsed time between different points in time associated to the operations start, stop, suspend and resume. * stopwatch is a model Stopwatch measuring the elapsed time between the start and the stop operations. * stopwatch_accumulator is a model Stopwatch allowing to accumulate several time samples and give the average, ... * Scoped helper classes allowing to pairwise start/stop operations, suspend/resume and resume/suspend a Stopwatch. * Stopwatch Formatter concept * stopwatch formatter "%ds\n" * stopwatch accumulator formatter "%c times, sum%ss, min%ms, max%Ms, mean%as\n" * time formatter "real %rs, cpu %cs (%p%), user %us, system %ss\n" * digital_time decomposition class separating days, hours,minutes,seconds, nanoseconds from any duration class (looking for a better name) * digital_time formatter "%d days(s) %h:%m:%s.%n\n" * stopwatch_reporter is a convenient generic class reporting elapsed time for the Stopwatch concept. * stopclock<Clock> shortcut stopwatch_reporter<stopwatch<Clcok>> * typeof registration for classes duration and time_point Depreceated Features: * The classes process_times, process_clock, process_timer, timer and run_timer are now deprecated as the preceding additions are more generic. However for backward compatibility they are preserved until inclusion of the library in Boost. Next follows the equivalences: timer<> ~ stopwatch<> process_timer ~ stopwatch<process_cpu_clock> run_timer ~ stopclock<> Bug Fixes * Try to correct warning C4251: 'boost::chrono::run_timer::m_format' : class 'std::basic_string<_Elem,_Traits,_Ax>' needs to have dll-interface to be used by clients of class 'boost::chrono::run_timer', by don't including inlines functions using the std::string m_format. For people that doesn't know it yet, Boost.Chrono library provides: * The C++0x Standard Library's common_type. * The C++0x Standard Library's compile-time rational arithmetic. * The C++0x Standard Library's time utilities, including: * Class template duration * Class template time_point * Clocks: * system_clock * monotonic_clock * high_resolution_clock * typeof registration for classes duration and time_point * Process clocks: * process_real_CPU_clocks, capturing real-CPU times. * process_user_CPU_clocks, capturing user-CPU times. * process_system_CPU_clocks, capturing system-CPU times. * process_cpu_clock, tuple-like class capturing at once real, user-CPU, and system-CPU times. * Stopwatches: * stopwatch, capturing elapsed Clock times. * stopwatch_accumulator, capturing cummulated elapsed Clock times. * scoped helper classes allowing to pairwise start/stop operations, suspend/resume and resume/suspend a Stopwatch. * Stopclocks or Stopwatch reporters: * stopwatch_reporter, convenient reporting of models of Stopwatch results. * stopclock<Clock> shortcut of stopwatch_reporter<stopwatch<Clock>> Best regards, _____________________ Vicente Juan Botet Escribá

4 8

[inspect] Changes to Inspection Report
by Beman Dawes 18 Jan '10

18 Jan '10

The latest run of the trunk inspection report is up at http://boost.cowic.de/rc/inspect-trunk.html Several new features have been added: * References to unknown bookmarks are now detected. * Duplicate bookmarks are now detected. * Each problem detected is reported on a separate line, to make it easier to work with files that have multiple problems. For example, see the errors below in the filesystem library. Comments? --Beman filesystem libs/filesystem/doc/faq.htm: *LINK* unknown bookmark: #global libs/filesystem/doc/i18n.html: *LINK* unknown bookmark: #Footnote *LINK* unknown bookmark: #status libs/filesystem/doc/index.htm: *LINK* unknown bookmark: #path libs/filesystem/doc/reference.html: *LINK* duplicate bookmark: exists *LINK* duplicate bookmark: initial_path *LINK* unknown bookmark: #basic_directory_entry-comparisons *LINK* unknown bookmark: #operator-eq libs/filesystem/test/deprecated_test.cpp: *APPLE-MACROS* violation of Boost apple-macro guidelines on line 21 *APPLE-MACROS* violation of Boost apple-macro guidelines on line 27 libs/filesystem/test/path_test.cpp: *APPLE-MACROS* violation of Boost apple-macro guidelines on line 34 *APPLE-MACROS* violation of Boost apple-macro guidelines on line 43

8 11

[1.42] Release Notes
by Daniel James 18 Jan '10

18 Jan '10

Hi, Just a quick reminder about the release notes. This is the ideal time to add them to 'boost_1_42_0.qbk' in: https://svn.boost.org/svn/boost/website/public_html/beta/feed/history/ Or if you send them to the list and I'll add them for you. It's helpful if they're added before the beta, so that beta testers know what needs testing. thanks, Daniel

2 3

[1.42.0] Ready for beta?
by Beman Dawes 18 Jan '10

18 Jan '10

How do we look for going ahead with the beta? Unless there are concerns, I'll start putting the beta together later today. --Beman

1 0