- Boost - lists.preview.boost.org

[function] [1.47.0] #4717: Non-const local static variable stored_vtable
by Kazutoshi Satoda 01 Jun '11

01 Jun '11

I want the fix for the following ticket (regression, I think) included in 1.47. "#4717: Non-const local static variable stored_vtable" https://svn.boost.org/trac/boost/ticket/4717 Here is a quote of a essential part of the fix. - static vtable_type stored_vtable = + static const vtable_type stored_vtable = { { &manager_type::manage }, &invoker_type::invoke }; https://svn.boost.org/trac/boost/attachment/ticket/4717/djw_function_const_… I did same request for 1.46 and 1.46.1, and got no response. http://lists.boost.org/Archives/boost/2011/03/177769.php http://lists.boost.org/Archives/boost/2011/01/175248.php Please let me know if there is more effective way to push the fix, or if I'm doing something wrong. -- k_satoda

2 2

[shared_ptr] Some design advice
by Johnny Willemsen 31 May '11

31 May '11

Hi, I want to create some refcounted objects using shared_ptr. For example if I have class A_impl, I want my users only to use A. So, I created the following code: class A_impl { public: virtual ~A_impl () {}; void dosomething () {}; }; typedef shared_ptr <A_impl> A; The challenge is now that I want to provide some typedefs on A (which is a shared_ptr()). So that my users can use: A::my_value_type; I am aware of the reference_type, but I need to have some additonal typedefs and constants as part of A. I have started with a partial template specialization of shared_ptr, but I have my doubts whether this is the correct way. Another option would be to create our own shared_ptr that just embeds the boost_shared_ptr and exposes just some of its methods. Any specific ideas on this? Regards, Johnny

2 1

Re: [boost] [tokenizer] tokenizing by strings rather than chars
by Andrzej Krzemienski 31 May '11

31 May '11

> Andrzej Krzemienski wrote: > > I want to parse numbers separated by "new-lines", however, on > > my windows system, a "new-line" is represented by two > > consecutive characters: 13, 10 (or in other words by string > > "\n\r"). So, only if I encounter a sequence of these two chars > > do I want to cut the token. > > Spirit.Qi would do that handily. Something like this should work: > namespace qi = boost::spirit::qi; > std::vector<int> data; > qi::phrase_parse(input.begin(), input.end(), qi::int_, qi::eol, data); Thanks for the reply. And could I ask a similar question? I wanted to simplify my real task to make it shorter and clearer to understand, and it look like I changed it to a different one. My apologies. My real task is to check if the data in Windows clip-board is a column of data (copied from a grid or table). Such a column is just text separated with "\n\r" sequences. So, for example these are valid data: "12" - a column of height 1 with data "12", " a\n\r b" - a column of height 2 with two with data " a" and " b" "-1\n\r\n\r3" - a column of height 3 with datum "-1", empty cell, and datum "3". The spirit solution above will skip the empty cell in my third example. On the other hand, I do need the information about empty cells too. It really looks more like a tokenizing task. Or is there a way to do it easily in Spirit? Regards, &rzej

2 1

Re: [boost] [pimpl] Mini Review
by Ivan Le Lann 31 May '11

31 May '11

----- "Artyom Beilis" <artyomtnk(a)yahoo.com> a écrit : > Hello All, > > Because a pre-review runs this days in collaborator tool I still want > to provide some feedback on this library I was looking on long > time ago. > > - What is your evaluation of the design? > > --------------------------------------------- > This is the major problem of the library: > It tries to do simple things overcomplicated. > --------------------------------------------- > > > Take as an example: > > struct Book : public pimpl<Book>::value_semantics { ... }; > > Is an attempt to do things in "fancy" way where it is not needed. > > struct Book { > public: > private: > struct implementation; > smart_ptr<implementation> pimpl_; > }; > > Is much clearer. Your code would rather simulate pimpl<>::pointer_semantics. And you do not mention the boilerplate code generated. > > The proposed solution is overcomplicated hard to read and in general > makes > more troubles then helps, makes the code less readable by average > programmers. > > ------------------------------------ > shared_ptr as pointer model is Wrong > ------------------------------------ > (snip lots of smart_ptr related lines) Unless you want pointer_semancics ... As for value_semantics, shared_ptr is not used. > 2. clone_ptr - pointer that clones underlying object on its copy. > i.e. something like > > copy_ptr(copy_ptr const &other) : p_(other->clone()) {} Precisely what seems to be used in the library for value_semantics. > > The only advantage I can see in boost.pimpl over scoped_ptr or > auto_ptr > is that it does not require explicit destructor. An important advantage as many developpers get trapped here. And it is "only" a warning to do so ... > Spare Pointer use case > ------------------------ > > Another important use case in the case when pimpl is used to handle > ABI > stability and > in general the object has spare "pimpl" or d-pointer for future uses. > > Consider: > > struct book { > public: > book(); > book(book const &); > ~book(book const &); > book const &operator=(book const &); > std::string title() const; > std::string author() const; > void title(std::string const &); > void author(std::string const &); > private: > std::string author_; > std::string title_; > struct data; > copy_ptr<data> d; > }; > > > Now in book.cpp we define data as > struct book::data {}; And with Pimpl, you would put author_ and title_ in book::data. I failed to see the point here. You seem to say that Pimpl cannot be used for ABI stability, which seems wrong to me. Regards, Ivan.

5 13

Re: [boost] [random] recent changes causing failures in accumulators tests
by Steven Watanabe 31 May '11

31 May '11

AMDG On 05/30/2011 09:23 PM, Eric Niebler wrote: > On 5/27/2011 12:24 PM, Steven Watanabe wrote: >> On 05/26/2011 09:49 PM, Eric Niebler wrote: >>> Many accumulators tests are now failing on both trunk and release. I >>> have tracked it down to recent changes in Boost.Random. I don't know for >>> how long this has been happening. > <snip> >>> >>> Steven, this seems like a regression. Can you look into this? >>> > >> I think the only thing I changed was the seeding algorithm. >> The number of random bits was reduced from 53 to 48, but >> that's all lagged_fibonacci607 ever claimed to provide. > >> Your limits may be too low. I switched extended_p_square.cpp >> to use mt19937_64 and random_device with >> generate_canonical<double, 53> and it still failed >> with both. It's getting a bit late tonight. I'll >> work through the math tomorrow. > > Hi Steven, have you had a chance to look into this? I'm not so much > concerned about accumulators as I am about the potential regression in > random, especially since the release branch is effected and we're > closing in on a release. > For extended_p_square, the check for 0.25 with epsilon = 2, works out ot a 75% confidence interval. I bumped epsilon up to 3. I think this is somewhere between a 90 and 95% confidence interval. I adjusted the tests at 0.01 and 0.001 also. Once I got the test to pass with random_device consistently, it also passed with lagged_fibonacci607. (I'm not absolutely sure about the confidence intervals. I was estimating them using the binomial distribution, which is a poor approximation towards the edges). I'm pretty sure from this that the problem was that the probability that the test would pass with random values was too low, so the change in the seeding algorithm was enough to make it fail. I'll try to make time to check the other failing tests soon. In Christ, Steven Watanabe

1 0

[pimpl] Mini Review
by Artyom Beilis 31 May '11

31 May '11

Hello All, Because a pre-review runs this days in collaborator tool I still want to provide some feedback on this library I was looking on long time ago. - What is your evaluation of the design? --------------------------------------------- This is the major problem of the library: It tries to do simple things overcomplicated. --------------------------------------------- Take as an example: struct Book : public pimpl<Book>::value_semantics { ... }; Is an attempt to do things in "fancy" way where it is not needed. struct Book { public: private: struct implementation; smart_ptr<implementation> pimpl_; }; Is much clearer. The proposed solution is overcomplicated hard to read and in general makes more troubles then helps, makes the code less readable by average programmers. ------------------------------------ shared_ptr as pointer model is Wrong ------------------------------------ You almost never want to have shared object semantics for pimplized object. I use pimpl ideom widely in my projects CppCMS, CppDB and even in Boost.Locale and I used shared semantics only once where it was explicitly shared. In rest of the cases I had found myself using following smart pointers: 1. copy_ptr - pointer the copies underlying object on its copy. i.e. something like copy_ptr(copy_ptr const &other) : p_(new Object(*other)) {} Copy the object on copy. 2. clone_ptr - pointer that clones underlying object on its copy. i.e. something like copy_ptr(copy_ptr const &other) : p_(other->clone()) {} 3. hold_ptr - pointer with same const-semantics as an object it points to T const &operator*() const; T &operator*() ; T const *operator->() const; T *operator->() ; They cover almost all use cases, so with addon of shared_ptr it covers ALL use cases. In any case current boost::scoped_ptr or std::auto_ptr is much more suitable smart pointer for implementing pimpl then Boost.pimpl. The only advantage I can see in boost.pimpl over scoped_ptr or auto_ptr is that it does not require explicit destructor. i.e. class Foo : boost::noncopyable { public: Foo(); int x() const; void x(int v); private: struct data; std::auto_ptr<data> d; }; No good. You need to add ~Foo(); So it would know to destroy Foo::Data correctly. But this can be easily solved on hold_ptr, copy_ptr and clone_ptr level same as it solved for shared_ptr and in reality even this not needed as it is better to add empty destructor in cpp. Spare Pointer use case ------------------------ Another important use case in the case when pimpl is used to handle ABI stability and in general the object has spare "pimpl" or d-pointer for future uses. Consider: struct book { public: book(); book(book const &); ~book(book const &); book const &operator=(book const &); std::string title() const; std::string author() const; void title(std::string const &); void author(std::string const &); private: std::string author_; std::string title_; struct data; copy_ptr<data> d; }; Now in book.cpp we define data as struct book::data {}; And we do not initialize d at all. It is fast and efficient object that does not use data at all. Now when we decide to add new member "isbn" without breaking ABI. in book.cpp we define in book.cpp struct book::data { std::string isbn_; } And now we initialized the d pointer in constructor. And add new members in book.h std::string isbn() const void isbn(std::String const &); And implement them std::string book::isbn() const { return d->isbn_; } void isbn(std::string const &s) { d->isbn_ = s; } This is very important use case the the author does not even relate to. - What is your evaluation of the implementation? Generally not looked into too deeply but it is does not follow boost standards: - Naming conventions - Documentation - Build So it is not even ready for the review (even thou it can be easily changed as it is a small library) - What is your evaluation of the documentation? 1. The documentation should be in HTML file not on some Internet web site. 2. Rationale part missing The documentation in not Boost-Ready - What is your evaluation of the potential usefulness of the library? Useless for 90% of pimpl use cases. - Did you try to use the library? With what compiler? Did you have any problems? No I hadn't - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? About 4-5 hours of studying - Are you knowledgeable about the problem domain? Yes, I work with pimpl-ized object on daily bases in many different approaches including implementing my own smart pointers for pimpl (clone_ptr, hold_ptr, copy_ptr) - ABI Stability - Compilation time reduction, - Decoupling of the interface from implementation details. Should The library be accepted in Boost: ======================================== No it should not. It is "a fancy" library that was written without a knowledge of the problem domain. It tries to solve problem in smart way making it overcomplicated. IMHO old std::auto_ptr is much more suitable for writing pimpl-objects then Boost.Pimple. For easy pimpl-ideom you do not need a fancy class but rather a set of pimpl-suitable smart pointers. Best Regards, Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

10 31

[Config] Big changes in C++0x detection...
by John Maddock 31 May '11

31 May '11

Just a heads up, that the latest Boost.Config changes: * Remove the concept related macros. * Tighten up most of the C++0x related tests, with the result that some C++0x features that were previously enabled are no longer - this may also cause the Boost.Config tests to fail on some platforms. * Some C++0x features that were not previously enabled are now - because they were passing the Boost.Config tests - there's at least one case where this is causing regressions in other libraries - if any more pop up please let me know ASAP! Thanks for your patience! John.

9 34

boost-test, why is there no DOUBLES_EQUAL?
by Sebastian Nowozin 31 May '11

31 May '11

Hello, I am a regular user of the boost test library, having used CPPunit before. I miss the following macro: BOOST_CHECK_DOUBLES_EQUAL(first, second, absolute_tolerance); which would check whether "std::fabs(first-second) <= absolute_tolerance" is true. It seems the boost test library does not support it, and instead forces/encourages users to use BOOST_CHECK_CLOSE(first, second, percent_relative_tolerance); The above macro does not really make sense in my application, I really need to check for absolute tolerances, irrespectively of the magnitude of the numbers. CPPunit has this feature as DOUBLES_EQUAL. Would you consider adding this? Thanks, Sebastian

9 16

[shared_ptr] calling functions by reference
by Sid Sacek 31 May '11

31 May '11

This might be a unimportant question and may have already been answered many times before, but I was wondering about functions that take shared pointers as arguments. Is there ever a reason I would not want to use a shared_ptr reference as an argument? I can't think of any, but is there any? class XYZ; void foo( shared_ptr< XYZ > &xyz ) { }

5 12

boost.atomic and boost.lockfree backports
by Bryce Lelbach 30 May '11

30 May '11

Hartmut and I have been using modified versions of Boost.Lockfree and Boost.Atomic in our codebase at work. I've put git repositories of our versions of both libraries up on github, so that the lockfree/atomic authors can integrate our bug fixes and/or feature extensions if they wish. The code is under the BSL. In addition to a number of bug fixes/tweaks, our variants contain the following enhancements: * boost.atomic: 128bit lockfree atomics for MSVC 2008+ (using _InterlockedCompareExchange128 and SSE2 intrinsics) and GCC-compatible POSIX compilers (using 16 byte __sync intrinsics). This code is x86-64 specific, and disabled by default. Define BOOST_ATOMIC_HAVE_SSE2 to enable in x86-64 MSVC 2008+ environments. Define BOOST_ATOMIC_HAVE_SSE2, BOOST_ATOMIC_HAVE_GNU_SYNC_16 and BOOST_ATOMIC_HAVE_GNU_ALIGNED_16 to enable for GCC-compatible compilers. The following command line flags are also needed for GCC-compatible compilers: -mcx16 (enables 16byte sync intrinsics) and -msse2. * boost.lockfree: A growable lockfree deque, based on algorithms by M. M. Michael. Backed by 128bit atomics. This is the first lockfree data structure I've written, so take it with a grain of salt. There's one bug that I'm aware of, unfortunately, it occurs infrequently so I haven't had much luck tracking it down. Links: https://github.com/brycelelbach/boost.atomic https://github.com/brycelelbach/boost.lockfree P.S. I don't have a list of the specific bug fixes on hand, I'll have to go through the SVN logs for that. The only non-trivial one that I know of is the problem with intel-linux that I found and fixed (intel doesn't define *amd64* macros, and they were used for x86-64 bit detection). -- Bryce Lelbach aka wash boost-spirit.com px.cct.lsu.edu github.com/lll-project

4 7

[profile_templates] template profiling on darwin
by Gordon Woodhull 29 May '11

29 May '11

Hey Steven, Thanks for your help getting the template profiler working on darwin. I just had to make a couple more obvious config copy/pastes to get this working - my diffs are below. Also, it appears that the tool is broken for gcc < 4.3 - it looks like some changes were made halfway for template_profiler_test{_enter|_exit} but still some undefined references to template_profiler_test. I mucked about with this for a few minutes, then gave up and upgraded to gcc 4.5, updated my simlinks, and darwin configuration works ok now. Now I've got LOTS of data to wade through (65K template instantiations for a very small MSM test!) Thanks again, Gordon Index: template-profile.jam =================================================================== --- template-profile.jam (revision 72066) +++ template-profile.jam (working copy) @@ -53,6 +53,22 @@ } +module darwin { + import template-profile : init-toolset ; + template-profile.init-toolset darwin ; + + actions compile.c++.preprocess { + $(CONFIG_COMMAND) $(OPTIONS) $(USER_OPTIONS) -D$(DEFINES) -I"$(INCLUDES)" -E "$(>)" | $(INSTRUMENT-ACTION) >"$(<)" + } + + actions compile.c++.template-profile { + "$(CONFIG_COMMAND)" $(LANG) -ftemplate-depth-$(TEMPLATE_DEPTH) $(OPTIONS) $(USER_OPTIONS) -D$(DEFINES) -D PROFILE_TEMPLATES -I"$(INCLUDES)" -c "$(>:W)" 2>&1 | "$(FILTER)" $(FILTER-OPTIONS) >"$(<)" + } +} + +IMPORT gcc : compile.c++.preprocess : darwin : compile.c++.preprocess ; +IMPORT gcc : compile.c++.template-profile : darwin : compile.c++.template-profile ; + module msvc { import template-profile : init-toolset ; @@ -88,6 +104,8 @@ toolset = msvc ; case gcc* : toolset = gcc ; + case darwin* : + toolset = darwin ; case * : errors.error unrecognized toolset $(toolset) ; } @@ -124,6 +142,7 @@ generators.register [ class.new warn-generator msvc.compile.c++.template-profile : INSTRUMENTED_TEMPLATE_PREPROCESSED_CPP : RAW_TEMPLATE_PROFILE : <toolset>msvc ] ; generators.register [ class.new warn-generator gcc.compile.c++.template-profile : INSTRUMENTED_TEMPLATE_PREPROCESSED_CPP : RAW_TEMPLATE_PROFILE : <toolset>gcc ] ; +generators.register [ class.new warn-generator darwin.compile.c++.template-profile : INSTRUMENTED_TEMPLATE_PREPROCESSED_CPP : RAW_TEMPLATE_PROFILE : <toolset>darwin ] ; class final-profile-generator : generator {

1 0

[type_erasure] default implementation of concept signatures
by Vicente Botet 28 May '11

28 May '11

Hi Steve, Concepts are able to define default implementations if the type doesn't provides the specific signature. For example in 20.1.2 Comparisons the concept LessThanComparable defines a default for implementation for bool operator>(U const& a, T const& b) { return b < a; } bool operator<=(U const& a, T const& b) { return !(b < a); } bool operator>=(T const& a, U const& b) { return !(a < b); } In the definition of the concept less_than_comparable in Boost.Any, you define the implementation of these operators in function of operator<(), but if the types provide the specific signature the specific function is not called. I guess that the default implementation of for example operator<= should use operator< only if the the underlying types don't provide operator<=. What do you think? Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/type-erasure-default-implementation-of-c… Sent from the Boost - Dev mailing list archive at Nabble.com.

5 9

[1.47.0] Release schedule
by Beman Dawes 28 May '11

28 May '11

* Monday, June 6: branches/release closed for all changes, except by permission of a release manager. * Monday, June 13: branches/release frozen. Only release managers may commit. Once tests have cycled and the release managers are satisfied with stability, release candidates for the beta will be generated. * Monday, Jun 20: Beta release target date. See June in http://www.boost.org/development/index.html or https://www.google.com/calendar/embed?src=5rorfm42nvmpt77ac0vult9iig@group.… The final release date won't be set until later in the process. Thanks, --Beman

1 0

'unnamed_Path' was not declared in this scope
by Ilya Chernykh 28 May '11

28 May '11

Hi! While building a package against boost I receive the following message: /usr/include/boost/filesystem/v2/operations.hpp: In function 'Path boost::filesystem2::current_path()': /usr/include/boost/filesystem/v2/operations.hpp:534:14: error: 'unnamed_Path' was not declared in this scope Is this an error in boost and how can I overcome it?

2 1

[gsoc] heap review
by Tim Blechmann 28 May '11

28 May '11

hi all, during this `summer of code', i will do the review of two proposed libraries, boost.lockfree and boost.heap. the boost.heap review will be the first one, taking place from may 30th to june 8th. boost.heap is an implementation of different priority queue data structures. they can be found at: tarball: http://tim.klingt.org/git?p=boost_heap.git;a=snapshot;h=HEAD;sf=tgz git repository: git://tim.klingt.org/boost_heap.git documentation: http://tim.klingt.org/boost_heap/ there will be a `formal' review announcement, i want to invite people to check out code, examples and documentation ... cheers, tim -- tim(a)klingt.org http://tim.klingt.org Question: Then what is the purpose of this "experimental" music? Answer: No purposes. Sounds. John Cage

6 9

[Block Pointer] benchmark
by Phil Bouchard 27 May '11

27 May '11

Hi, Just for the records I have benchmarked block_ptr using: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/example/be… And I get the following: auto_ptr: 9208870 ns shared_ptr: 22958516 ns block_ptr: 75860365 ns Which is pretty good given the complexity it goes thru. I was wondering if there is any hope in having a pool::ordered_malloc() call of O(1) instead of O(n) and a faster pool::is_from()? The latter could be just a check to see if a pointer is within reserved memory pages of the pool. I tried to talk to the author of pool but I got no response. Thanks, -Phil

10 47

[release] 1.4.7
by Thomas Heller 27 May '11

27 May '11

Hi, Now that boostcon is over, what are the dates for 1.47? Thanks, Thomas

9 11

boost.move?
by Bryce Lelbach 27 May '11

27 May '11

Has been Boost.Move been accepted already? If so, can we squeeze it in for the next Boost release? -- Bryce Lelbach aka wash boost-spirit.com px.cct.lsu.edu github.com/lll-project

1 0

Boost Steering Committee
by Beman Dawes 27 May '11

27 May '11

There was a special session Friday morning at BoostCon 2011 to announce the formation of a Boost Steering Committee. The slides from that session have been annotated to make them more comprehensible to those not present. See http://tinyurl.com/3l27o3q (There is also a link on steering.boost.org, but DNS isn't resolving that yet for me. Instead use https://sites.google.com/a/boost.org/steering/) We haven't yet decided anything beyond what is on the slides, so it will take a bit of time before details emerge. As the slides mention, the first job of the steering committee is to design of its own operating procedures and policies. Input from the Boost community will help form those procedures and policies. The steering committee is an important change in the way Boost operates! We hope it will position Boost to continue to grow and prosper. --The Boost Steering Committee Beman Dawes Dave Abrahams Hartmut Kaiser Jeff Garland Jon Kalb Marshall Clow Robert Stewart Steven Wantanabe

3 2

[tokenizer] tokenizing by strings rather than chars
by Andrzej Krzemienski 27 May '11

27 May '11

Hi, I am facing a problem, and I wonder if Boost.Tokenizer, or any other Boost library solves it already. I want to parse numbers separated by "new-lines", however, on my windows system, a "new-line" is represented by two consecutive characters: 13, 10 (or in other words by string "\n\r"). So, only if I encounter a sequence of these two chars do I want to cut the token. boost::char_separator appears to be a bad choice, because it only "cuts" on single chars. Is there a solution to that problem in Boost? Regards, &rzej

3 3

iterator_facade triggers ADL, fails to compile
by Arno Schödl 27 May '11

27 May '11

Hello, the attached file arg_names.cpp fails to compile (VS2008) when using boost::lambda::_1 or boost::phoenix::arg_names::_1. The compilation succeeds when using boost::bind. All three variations are in the attached code for illustration. The compilation fails due to the presence of a templated operator& definition which is introduced by the instantiation of a class that is declared "andable" (from boost/operators.hpp). The compilation fails because iterator_facade triggers ADL in BOOST_ITERATOR_FACADE_INTEROP and finds the aforementioned operator& when comparing iterators that carry boost::lambda::_1 or boost::phoenix::arg_names::_1 as part of their type specification. In the example, this is illustrated by using filter_iterator. It is not clear to me what exactly the mechanism is that causes this ADL problem. But the static_cast in BOOST_ITERATOR_FACADE_INTEROP can be implemented using references instead of pointers, as shown below, which makes the problem disappear. In any case, using operator& on the iterator may be problematic if the iterator overloads operator&. --- C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/boost_1_46_1/boost/iterator/iterator_facade.hpp Wed May 25 11:42:14 2011 +++ C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/boost_1_46_1/boost/iterator/iterator_facade - Copy.hpp Wed May 25 11:41:49 2011 @@ -819,8 +819,8 @@ is_interoperable< Derived1, Derived2 >::value \ )); \ return_prefix iterator_core_access::base_op( \ - *static_cast<Derived1 const*>(&lhs) \ - , *static_cast<Derived2 const*>(&rhs) \ + static_cast<Derived1 const&>(lhs) \ + , static_cast<Derived2 const&>(rhs) \ , BOOST_ITERATOR_CONVERTIBLE(Derived2,Derived1) \ ); \ } Does anyone understand better what is happening? Or can we simply adopt the change? Regards, Arno -- Dr. Arno Schödl | aschoedl(a)think-cell.com Technical Director think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany http://www.think-cell.com | phone +49 30 666473-10 | US phone +1 800 891 8091 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl

3 4

[local] couple questions
by Jeffrey Lee Hellrung, Jr. 27 May '11

27 May '11

1) I notice from http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca… that (proposed) Boost.Local has a dependency on Boost.ScopeExit. It seems that Boost.Local provides all the functionality of Boost.ScopeExit, and then some; at least, that's what seems to be implied by http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca… It would seem reasonable then, maybe, should Boost.Local be accepted, to remove the dependence on Boost.ScopeExit and officially deprecate Boost.ScopeExit in favor of Boost.Local's BOOST_LOCAL_EXIT: http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca… What are your (you = Lorenzo or anyone else) thoughts regarding that development path? 2) I haven't read through the docs in *too* much detail yet, but I would guess from, for example, http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca… that copying a Boost.Local functor amounts to something less than a deep copy, and possibly an entirely shallow copy. In other words, does int x = 0; void BOOST_LOCAL_FUNCTION_PARAMS( bind(int) x ) { // bind x by value, so a copy is taken... std::cout << ++x << std::endl; } BOOST_LOCAL_FUNCTION_NAME(f) boost::function< void ( ) > g(f); f(); g(); print "1" followed by "2" (my guess), or does it print "1" twice? I may have missed it entirely, but I'd like the semantics of copying a Boost.Local functor explicitly spelled out. P.S.: I noticed in http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca… a misspelling in the comments of the last example, s/BOOST_IDENTITY_VALE/BOOST_IDENTITY_VALUE/. - Jeff

2 1

[type_at] Variadic template utility
by tymofey 27 May '11

27 May '11

While experimenting with varidic templates of the upcoming standard i discovered that quite often one would need to extract a type from parameter pack at specified position. While the task is trivial it would be quite handy to have a ready tool for this purpose, rather that specifying one yourself every time. You can find source code consisting of a single header at Vault/Utilities/type_at.hpp The usage is simple: boost::type_at<index, some_type_0, some_type_1, some_type_2, some_type_n>::type corresponds to some_type_index where index is in range [0..n]. For example: boost::type_at<2, int, float, char, long>::type corresponds to char. I hope this will be useful.

5 6

Test results down for a little while
by Daniel James 27 May '11

27 May '11

Hi, I just noticed that the server load was pretty high because someone was spidering the test results. So I removed them for a little while (I don't have time to work how to block an IP address). They'll be back soon-ish. Hopefully, whoever was doing so will understand. If you want an offline copy of the test results, you should probably ask on the testing list, I'm sure we can work something out. Daniel

1 0

[ICL] Compile error when using "is_numeric"
by sguazt 27 May '11

27 May '11

Hi, I've just checked-out the last SVN version of ICL and after compiling with gcc (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4) (flags: -Wall -Wextra -pedantic -ansi) I get these errors: --- [error] --- boost-trunk/boost/icl/concept/interval_bounds.hpp:89:58: error: type/value mismatch at argument 2 in template parameter list for ‘template<class Type, class Compare, bool Enable> struct boost::icl::numeric_minimum’ boost-trunk/boost/icl/concept/interval_bounds.hpp:89:58: error: expected a type, got ‘boost::icl::is_numeric<Type>::value’ ... boost-trunk/boost/icl/concept/interval_bounds.hpp:104:58: error: type/value mismatch at argument 2 in template parameter list for ‘template<class Type, class Compare, bool Enable> struct boost::icl::numeric_minimum’ boost-trunk/boost/icl/concept/interval_bounds.hpp:104:58: error: expected a type, got ‘boost::icl::is_numeric<Type>::value’ ... boost-trunk/boost/icl/left_open_interval.hpp:52:64: error: type/value mismatch at argument 2 in template parameter list for ‘template<class Type, class Compare, bool Enable> struct boost::icl::numeric_minimum’ boost-trunk/boost/icl/left_open_interval.hpp:52:64: error: expected a type, got ‘boost::icl::is_numeric<Type>::value’ ... boost-trunk/boost/icl/open_interval.hpp:51:64: error: type/value mismatch at argument 2 in template parameter list for ‘template<class Type, class Compare, bool Enable> struct boost::icl::numeric_minimum’ boost-trunk/boost/icl/open_interval.hpp:51:64: error: expected a type, got ‘boost::icl::is_numeric<Type>::value’ --- [/error] --- To solve this problem, it seems it is sufficient to prefix the use of "is_numeric" with "typename". Here below is the diff file: --- [diff] --- Index: boost/icl/left_open_interval.hpp =================================================================== --- boost/icl/left_open_interval.hpp (revision 72177) +++ boost/icl/left_open_interval.hpp (working copy) @@ -49,7 +49,7 @@ // Only for discrete types this ctor creates an interval containing // a single element only. BOOST_STATIC_ASSERT((icl::is_discrete<DomainT>::value)); - BOOST_ASSERT((numeric_minimum<DomainT, is_numeric<DomainT>::value >::is_less_than(val) )); + BOOST_ASSERT((numeric_minimum<DomainT, typename is_numeric<DomainT>::value >::is_less_than(val) )); } /** Interval from <tt>low</tt> to <tt>up</tt> with bounds <tt>bounds</tt> */ Index: boost/icl/concept/interval_bounds.hpp =================================================================== --- boost/icl/concept/interval_bounds.hpp (revision 72177) +++ boost/icl/concept/interval_bounds.hpp (working copy) @@ -86,7 +86,7 @@ { if(is_left_closed(decl) && !is_left_closed(repr)) { - BOOST_ASSERT((numeric_minimum<Type, is_numeric<Type>::value >::is_less_than(low) )); + BOOST_ASSERT((numeric_minimum<Type, typename is_numeric<Type>::value >::is_less_than(low) )); return icl::pred(low); } else if(!is_left_closed(decl) && is_left_closed(repr)) @@ -101,7 +101,7 @@ { if(!is_right_closed(decl) && is_right_closed(repr)) { - BOOST_ASSERT((numeric_minimum<Type, is_numeric<Type>::value >::is_less_than(up) )); + BOOST_ASSERT((numeric_minimum<Type, typename is_numeric<Type>::value >::is_less_than(up) )); return icl::pred(up); } else if(is_right_closed(decl) && !is_right_closed(repr)) Index: boost/icl/open_interval.hpp =================================================================== --- boost/icl/open_interval.hpp (revision 72177) +++ boost/icl/open_interval.hpp (working copy) @@ -48,7 +48,7 @@ // Only for discrete types this ctor creates an interval containing // a single element only. BOOST_STATIC_ASSERT((icl::is_discrete<DomainT>::value)); - BOOST_ASSERT((numeric_minimum<DomainT, is_numeric<DomainT>::value >::is_less_than(val) )); + BOOST_ASSERT((numeric_minimum<DomainT, typename is_numeric<DomainT>::value >::is_less_than(val) )); } /** Interval from <tt>low</tt> to <tt>up</tt> with bounds <tt>bounds</tt> */ --- [/diff] --- Can you fix it? Thank you very much!! Best, -- Marco

2 4