September 2011 - Boost - lists.boost.org

[property_tree] Primitive types for data not supported?
by Boris Schaeling 26 Sep '11

26 Sep '11

I just noticed that Boost.PropertyTree doesn't support primitive types for data (Boost 1.47.0). For example, this doesn't compile: boost::property_tree::basic_ptree<std::string, int> pt, pt2; pt.swap(pt2); The reason is this code in <http://svn.boost.org/svn/boost/trunk/boost/property_tree/detail/ptree_imple…>: template<class K, class D, class C> inline void basic_ptree<K, D, C>::swap(basic_ptree<K, D, C> &rhs) { m_data.swap(rhs.m_data); // Void pointers, no ADL necessary std::swap(m_children, rhs.m_children); } Primitive types like int obviously don't have a member function swap(). Is this an oversight or are primitive types intentionally not supported? Boris

2 2

[Review:Algorithms] Comments about search algorithms
by Phil Endecott 26 Sep '11

26 Sep '11

Dear All, Here are some observations about the proposed search algorithms: - I was confused as to whether the caller must keep the pattern pointed to by the iterators passed to the constructor after the constructor returns. My guess was that once the internal tables were built the pattern would not be needed any more - but that turns out to be wrong. At the least, the docs need to explain this. - The three algorithms have very similar interfaces. The docs could perhaps define a "searcher" concept and explicitly declare these algorithms' classes to be models of that concept. - std::search is similar to the three algorithms' free function versions (congratulations on getting the arguments in the same order!). For completeness, how about adding a searcher class that uses std::search? - A user faced with these three (or four) algorithms will need to choose one. The docs should offer some guidance, e.g. benchmarks or rules-of-thumb, about which to use. - It would sometimes be useful to have a variant of the constructor that takes a const char* pattern. - The tables store ints. For patterns shorter than 256 characters I think that uint8_t would be sufficient, and would reduce the size of a table from 1024 or 2048 bytes to only 256 bytes. Similarly uint16_t or uint32_t could be used for larger patterns. It is not obvious how to implement this, though; perhaps an optional max_pattern_length template parameter, making it the user's responsibility to ensure the supplied pattern is not too long. - The docs describe some methods that are private to the implementation; why? Regards, Phil.

3 5

Introduction : Being a Newbie to the Boost community
by avishek banerjee 26 Sep '11

26 Sep '11

Hi everyone, I am Avishek Banerjee.. I work as a software engineer at Google.. I graduated last year from college. I am quite passionate about coding in c++, but never got the chance earlier to be a community developer. I guess, thats why I am here. I want to be a part of this community and make contributions to the libraries.. I would be keeping track of the posts to see if I can associate myself on some existing project. Besides, it would really help if someone can give me certain pointers on some project(not so immediately important) that I can take up as starter to begin with and familiarize. thank you so much, Avishek -- Avishek Banerjee, Software Engineer, Google-BLR

2 1

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

26 Sep '11

Message: 10 Date: Sun, 25 Sep 2011 22:53:12 +0200 From: Oliver Kowalke <oliver.kowalke(a)gmx.de> To: boost(a)lists.boost.org Subject: Re: [boost] Persistency library Message-ID: <4E7F94B8.7030706(a)gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed > I assume resuming from a checkpoint would also require to restore the > registers, flags, stack (pointer), instruction pointer etc. - I'd like > to know if your lib supports only intel or some other architectures too. > > Oliver Your assumption is correct. However, the actual implementation is done via getcontext()/setcontext(), so it is not hard-wired to a specific hardware architecture. We use assembly only in one case, and that is to avoid a glibc issue. PID is being cached in user-space and therefore isn't correct after restore, and glibc does not provide a simple way to invalidate this. Right now, the library has only been validated on x86-64, but I can of course validate it on other architectures (given the right hardware :)). 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.

2 5

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 26 Sep '11

26 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 26 Sep '11

26 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