- Boost - lists.boost.org

Re: [boost] Persistency library
by Lifshitz, Yair 26 Sep '11

26 Sep '11

Date: Sat, 24 Sep 2011 14:29:44 -0400 From: Dave Abrahams <dave(a)boostpro.com> To: boost(a)lists.boost.org Subject: Re: [boost] Persistency library Message-ID: <m2litdrdyf.fsf(a)pluto.luannocracy.com> Content-Type: text/plain on Sat Sep 24 2011, "Lifshitz, Yair" <yair.lifshitz-AT-intel.com> wrote: > > Hi, > > > > Object-based persistency/serialization libraries often require > > significant modifications to the code. Would Boost consider adding a > > process-level checkpointing library to boost? > > > > This is obviously not easily portable, so I understand this is a long shot. > > If it is relevant, we might contribute a package used by my team that > > support multiple Linux platforms. > Can it, in principle, be ported to other known platforms? Yes, it can be ported. However, the porting requires low-level understanding of the target OS/architecture. While our Linux solution is rather portable, porting can (in theory) be non-trivial and require more than just recompilation on another platform. --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

2 1

configuring the clang toolset
by Eric Niebler 25 Sep '11

25 Sep '11

I'm trying to get bjam and clang to play nice. I have Ubuntu linux running in an VM with boost trunk and the llvm+clang sources also from svn. I've built clang as described here: <http://clang.llvm.org/get_started.html>. I added the following line to my user-config.jam: using clang : : /home/eric/build/Debug+Asserts/bin/clang++ ; Now when I try to build, say, the Foreach tests, I get: In file included from cstr_byref.cpp:11: In file included from ../../../boost/test/minimal.hpp:37: In file included from ../../../boost/test/impl/execution_monitor.ipp:170: In file included from /usr/include/errno.h:36: In file included from /usr/include/bits/errno.h:25: /usr/include/linux/errno.h:4:10: fatal error: 'asm/errno.h' file not found #include <asm/errno.h> ^ 1 error generated. "/home/eric/build/Debug+Asserts/bin/clang++" -c -x c++ -O0 -g -fno-inline -Wall -g -fPIC -DBOOST_ALL_NO_LIB=1 -I"../../.." -o "../../../bin.v2/libs/foreach/test/cstr_byref.test/clang-linux-3.0/debug/cstr_byref.o" "cstr_byref.cpp" What have I done wrong? -- Eric Niebler BoostPro Computing http://www.boostpro.com

6 6

Re: [boost] Persistency library
by Lifshitz, Yair 25 Sep '11

25 Sep '11

From: Edward Diener <eldiener(a)tropicsoft.com> > On 9/24/2011 10:31 AM, Lifshitz, Yair wrote: > > Hi, > > > > Object-based persistency/serialization libraries often require significant modifications to the code. > > Would Boost consider adding a process-level checkpointing library to boost? > Why not explain what you mean by a "process-level checkpointing library" > and then others can comment if they might find it useful ? Process-level checkpointing is an approach where an entire process' memory image is dumped in binary format. The checkpointing library does not require any understanding of the saved application - it works by traversing the entire memory image and directly dumping that to disk. On Linux for example, this can be done by traversing all memory segments described in /proc/self/maps. This approach is highly robust, and generally considered good for very large applications where serialization is a challenge. Some examples can be seen here - http://checkpointing.org/ - though we had little luck with most of them when starting to work on persistency (~6 years ago). --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

2 1

Re: [boost] [Review:Algorithms] About a static clamp function
by Ahmed Charles 25 Sep '11

25 Sep '11

C++11 constexpr would handle the function case while also working for user defined types. This suggests that the template version is less generic. My phone doesn't allow bottom posting. :( From: Vicente J. Botet Escriba Sent: Sunday, September 25, 2011 7:13 AM To: boost(a)lists.boost.org Subject: [boost] [Review:Algorithms] About a static clamp function Hi, Sometimes the bound values are know at compile time. Could we ensure that the compiler could optimize the following code auto res = clamp(val, 1, 100); If this is not the case, I was wondering if it is worth adding a static clamp function that has its bounds defined as template parameters. auto res = static_clamp<1,100>(val); Best, Vicente _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[Review:Algorithms] About a static clamp function
by Vicente J. Botet Escriba 25 Sep '11

25 Sep '11

Hi, Sometimes the bound values are know at compile time. Could we ensure that the compiler could optimize the following code auto res = clamp(val, 1, 100); If this is not the case, I was wondering if it is worth adding a static clamp function that has its bounds defined as template parameters. auto res = static_clamp<1,100>(val); Best, Vicente

1 0

[system] Boost.Timer replacement
by Beman Dawes 25 Sep '11

25 Sep '11

"The best is the enemy of the good." Voltaire's famous bon mot applies to a replacement for Boost.Timer. I've had a "good", although not "best", replacement ready since circa 2006. It has always been set aside waiting for something better. The data-time, std::chrono, boost::chrono, boost::stopwatch, and probably others, were all candidates. I'm tired of waiting. http://beman.github.com/timer/ documents a useful replacement for Boost.Timer. The full library has been in the sandbox for years, but current development is on GitHub. See https://github.com/Beman/timer I'd like to move the header into boost/system/pending or boost/system/detail, and the rest into the appropriate libs/system subdirectories. The library will be proposed for a full review, or a mini-review if enough other Boost libraries start using it. If Endian gets accepted, for example, it certainly needs timing benchmarks. Comments? --Beman

7 13

[preprocessor] PP_CAT with symbols
by lcaminiti 25 Sep '11

25 Sep '11

Hello all, I just want to confirm that the following: BOOST_PP_CAT(old_size =, =) correctly (and always) expands to: old_size == I tested it on MSVC and GCC and it works. Plus from GCC documentation says about ##: Usually both will be identifiers, or one will be an identifier and the other a preprocessing number. When pasted, they make a longer identifier. This isn't the only valid case. It is also possible to concatenate two numbers (or a number and a name, such as 1.5 and e3) into a number. Also, multi-character operators such as += can be formed by token pasting. http://gcc.gnu.org/onlinedocs/gcc-3.2.3/cpp/Concatenation.html I am asking because ## has some limitation (x ## = is not valid, etc) so I want to confirm my understanding is correct. Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-preprocessor-PP-CAT-with-symbols-t… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 2

Overload resolution speed
by Mathias Gaunard 25 Sep '11

25 Sep '11

As part of the Boost.SIMD effort, another library was developed, Boost.Dispatch, which relies heavily on overload resolution. Before submitting this library for review, however, I did some compile-time benchmarking, and it's not looking very good. I'm therefore asking the Boost community if 1) this is expected, 2) if there is a workaround to this problem and 3) if compilers should be made to deal with this better. Boost.Dispatch essentially overloads a single free function, with, as arguments, a tag identifying the function followed by tags identifying properties/categories of the arguments (in an attempt to make a transparent tag dispatching system). The scripts from the link below [1] (the shell script is POSIX/GCC-only but should be easily adaptable) performs two tests: - Resolving a call with 1,000 function tags, overloaded 10 times each, everything implemented by overloading the same function as described above, - Resolving a call with 1,000 function tags, overloaded 10 times each, but with each function tag using a different functon. It takes 30s in the first case, 160ms in the second one. Unfortunately, the second solution is very restrictive and doesn't play very nice with generic programming. C++ apparently lacks a mechanism to define overloadable free functions with template parameters in their name. Back to the benchmark, making the number of functions vary show an apparent exponential increase in compile time. It's reasonably fast for 100 functions, but not at all for 1,000. On the other hand, changing the depth of the inheritance tree used for the category tags doesn't seem to affect it much. Any suggestions? [1] http://dl.dropbox.com/u/26902324/dispatching_bench.tar.gz

6 14

Persistency library
by Lifshitz, Yair 24 Sep '11

24 Sep '11

Hi, Object-based persistency/serialization libraries often require significant modifications to the code. Would Boost consider adding a process-level checkpointing library to boost? This is obviously not easily portable, so I understand this is a long shot. If it is relevant, we might contribute a package used by my team that support multiple Linux platforms. Thanks, Yair --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

3 2

Re: [boost] [Review:Algorithms] is_ordered name
by Brent Spillner 24 Sep '11

24 Sep '11

On Sat, 24 Sep 2011 09:34:59 joaquin wrote: >>Isn't this the same as the C++11 is_sorted_until? > >Yes! C+11 had is_sorted_until and is_sorted (equivalent to is_sorted_until(first,last)==last). I think the names here should be the same for >consistency reasons, and probably the functions should be just aliases to the c++11 ones where applicable. With the RV convention change that I proposed on github (always point before the first element that is out-of-order with respect to its predecessor, rather than the first that is out-of-order with respect to its successor), it would be exactly the same, so I think we may be stuck with this name, even though I agree that it sounds like it should return a bool. If we were starting from scratch my first impulse would be end_of_ordered_prefix(), but that too seems wordier than the ideal.

5 8