- Boost - lists.preview.boost.org

Re: [boost] [Review] Formal Review of Proposed Boost.Chrono LibraryStarts TOMORROW
by Aaron Graham 10 Nov '10

10 Nov '10

See this gcc bugzilla entry for a discussion I've had about chrono support in the gcc implementation. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41861 Unfortunately, monotonic_clock support, even if it exists, is a transparent lie. It's not so much a problem with the chrono library as it is a problem with the thread library's use of chrono. A monotonic clock is used to provide somewhat accurate/reliable wait times even in the face of changing clocks, especially in the case of mutexes and condition variables. When condition::wait_until is called with a monotonic_clock time_point, that time_point is translated to a system_clock time_point. If the system_clock is changed (via NTP, adjtime, settimeofday, etc) between when convert_to<system_clock> is called and when the underlying posix call is made, the very reason for using monotonic_clock defenestrates and splatters all over the pavement. Depending on the magnitude of the clock change, wait_until could hang forever. In my opinion, all convert_to calls in the thread library should go to the monotonic_clock, if available. Not system_clock. I couldn't get the gcc people to understand this, so I won't be able to use <chrono> in the standard library sans modification. Maybe boost will get it right? Let me know if I'm missing a subtle point that moots my concerns. Other than that, I think the this library is great. I need it badly. I haven't looked over all the code yet, but what I've seen looks good.

3 2

mkl+boost problems
by Andrey Asadchev 10 Nov '10

10 Nov '10

Hello. mkl (intel blas) has "mkl_cblas.h" file which in turn includes " mkl_types.h" file which defines P4 macro variable: 70 /** CPU codes for int MKL_CPU_DETECT(void) **/ 71 #ifdef _IPF 72 #define ITP 0 73 #else 74 #ifdef _EM64T 75 #define NI 0 76 #define CT 1 77 #define MNI 2 78 #define PNR 3 79 #else 80 #define DEF 0 81 #define PIII 1 82 #define P4 2 83 #define P4P 3 84 #define P4M 4 85 #endif 86 #endif This P4 variable creates havoc of MPL templates which have P4 template parameters names. What to do?

9 10

Re: [boost] [msm] Event deferring causes stack overflow
by Christophe Henry 09 Nov '10

09 Nov '10

> Hi All > > We have found a serious problem in msm back end for event deferring. > I case there is a composite state and the outer state machine defers 2 > events when it is in the composite state, the 1st event deferred fine > in the deferred queue of the outer state machine. > Than the 2nd event is processed and this is deferred as well as a part > of this deferral msm back end dispatches the 1st event but it is still > deferred and saved again in the deferred queue but than msm processes > the deferred queue again as an action of the deferral of the 1st event > and dispatches the 2nd event again which is deferred and the cycle > repeats itself until the system runs out of call stack. Hi, No, it's not that serious, but still not nice. The problem is that the principle of the Defer functor is not working and I am wondering if I should keep it. To make short, Defer is an action, and for all front-ends, actions return void. This has the unintended effect of marking the transition results as "handled" instead of "deferred", which breaks my defensive measures. If you replace the transitions by the standard UML method of marking the state as deferring (through the deferred_events typedef), you have no more stack overflow. Now I understand that the Defer functor is cool and offering to remove it is guaranteed to cause disappointment, so I see 2 possibilities: - explaining its limitations in the doc - making a change to all front-ends for this special case to work around the fact that actions return void For the meantime, use the "normal" way and I will see if I find a workaround. Cheers, Christophe

2 1

[mpl] mpl::c_str fails for mpl::push_back
by vicente.botet 09 Nov '10

09 Nov '10

Hi, the following results in a compile error for msvc-10.0. It works for gcc-3.4, gcc-4.3, gcc-4.5. typedef mpl::vector_c<char, 'h','e','l','l','o',' ','w','o','r','l','d'> hello; typedef mpl::push_back<hello, mpl::char_<'!'> >::type hello2; BOOST_TEST((std::string(mpl::c_str<hello2>::value)== "hello world!")); // line 59 C:\cygwin\boost\v44\boost/mpl/string.hpp(592) : error C2039: 'value_type' : is not a member of 'boost::mpl::vector12<T0,T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,T11>' with [ T0=boost::mpl::integral_c<char,104>, T1=boost::mpl::integral_c<char,101>, T2=boost::mpl::integral_c<char,108>, T3=boost::mpl::integral_c<char,108>, T4=boost::mpl::integral_c<char,111>, T5=boost::mpl::integral_c<char,32>, T6=boost::mpl::integral_c<char,119>, T7=boost::mpl::integral_c<char,111>, T8=boost::mpl::integral_c<char,114>, T9=boost::mpl::integral_c<char,108>, T10=boost::mpl::integral_c<char,100>, T11=boost::mpl::char_<33> ] io\match_pass.cpp(59) : see reference to class template instantiation 'boost::mpl::c_str<Sequence>' being compiled with [ Sequence=hello2 ] Is this a known bug? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

3 13

[msm] Event deferring causes stack overflow
by Richard Szabo 09 Nov '10

09 Nov '10

Hi All We have found a serious problem in msm back end for event deferring. I case there is a composite state and the outer state machine defers 2 events when it is in the composite state, the 1st event deferred fine in the deferred queue of the outer state machine. Than the 2nd event is processed and this is deferred as well as a part of this deferral msm back end dispatches the 1st event but it is still deferred and saved again in the deferred queue but than msm processes the deferred queue again as an action of the deferral of the 1st event and dispatches the 2nd event again which is deferred and the cycle repeats itself until the system runs out of call stack. please find the code to reproduce the problem in attachment. thanks for the help in advance. Br. Richie

1 0

Boost and (Microsoft's) _SECURE_SCL
by Martin B. 09 Nov '10

09 Nov '10

Boost and Microsoft's _SECURE_SCL Long story short of this post: Are there any plans (left) to add additional name mangling to the boost libs on Windows to address the problem of mismatched _SECURE_SCL setting? The Microsoft (Dinkumware) _SECURE_SCL=1 macro [1],[2] adds additional checks to standard library iterators/containers, rendering them ABI incompatible with _SECURE_SCL setting 0 vs. 1. This in turn leads to crashes when using a wrong combination of this flag. For example: [3] This has been discussed numerous times before: [4], [5], [6] -- see [5] for a list of further links to more threads. A trac issue [7] to add a specific build option has been closed as invalid. What I have been unable to determine is what the status is on supporting an additional *name mangling scheme* for the _SECURE_SCL option. From what I can discern from the current Getting Started page [8], not only do we not support any such name mangling, but the _SECURE_SCL macro (or the new _ITERATOR_DEBUG_LEVEL macro in VS2010) is not even mentioned on the Getting Started page. Since Visual Studio 2005 defaulted to _SECURE_SCL=1 and boost just uses the default, many people hit this when they used _SECURE_SCL=0 to improve performance in their release builds. (Which, as an aside, doesn't yield too much, as the real showstopper is the - independent! - _HAS_ITERATOR_DEBUGGING macro and that is only active in debug builds anyway.) In Visual Studio 2010, the situation is reversed, as Microsoft decided to now default to _SECURE_SCL=0. That means the people who change it to 1 in their release build for additional security will be bitten by the problem. (Or not, as it seems that they added some link-time checks in VS2010 to detect mismatches regarding the _ITERATOR_DEBUG_LEVEL. [9]) OK, so now again: Are there any plans (left) to add additional name mangling to the boost libs on Windows to address the problem of mismatched _SECURE_SCL setting? -- Or are we just going to ignore the issue since VS2010 defaults to the "boost preferred" - off - option now anyway? By "boost preferred" I mean that from some of the discussions it seemed to me that there was doubts w/rgd to complexity issues etc. when _SECURE_SCL is on. cheers, Martin p.s.: FWIW, here's how /I/ compile my release version of boost 1.44 on VS2005: bjam.exe --build-type=complete variant=release toolset=msvc-8.0 threading=multi define=_SECURE_SCL=0 --with-regex --with-program_options --with-test --with-serialization stage [1] Visual Studio 2005 - _SECURE_SCL : http://msdn.microsoft.com/en-us/library/aa985896%28VS.80%29.aspx [2] Visual Studio 2010 - _SECURE SCL : http://msdn.microsoft.com/en-us/library/aa985896%28v=VS.100%29.aspx [3] access violation with _SECURE_SCL turned off : http://lists.boost.org/boost-users/2009/02/45137.php [4] _SECURE_SCL for msvc (2009) : http://thread.gmane.org/gmane.comp.lib.boost.devel/185898/focus=185987 [5] MSVC _SECURE_SCL causes ABI change, ODR violation - mangle library names? : http://lists.boost.org/boost-users/2008/10/41253.php [6] Re: Bug/Incompatibility: Visual C++ 2005 checkediteratorslead to major crashes : http://thread.gmane.org/gmane.comp.lib.boost.devel/144082/focus=144089 [7] Add build option to define _secure_scl=0 + add runtime check to ensure no ODR violation : https://svn.boost.org/trac/boost/ticket/2086 [8] Boost 1.44 Getting Started on Windows : http://www.boost.org/doc/libs/1_44_0/more/getting_started/windows.html [9] Visual STuduio 2010 - detect_mismatch : http://msdn.microsoft.com/en-us/library/ee956429.aspx

5 11

encryption?
by Brian Wood 09 Nov '10

09 Nov '10

I recall a few threads on the subject of a fledgling Boost Encryption library, but haven't seen anything about it recently. Could someone update me on this? I've used OpenSSL enough to desire a C++ alternative. (Imagine some existing Boost libs written in C.) -- Brian Wood Ebenezer Enterprises http://webEbenezer.net (651) 251-9384 "The kingdom of heaven is like a treasure hidden in the field, which a man found and hid again; and from joy over it he goes and sells all that he has and buys that field."

1 0

[function] new implementation
by Domagoj Saric 09 Nov '10

09 Nov '10

Hi, <...those that followed the latest function related discussions can skip the first paragraph...> For about a year and half now (or even more but that's about how long I've been involved in the matter) there have been repeated discussions/requests/complaints about various aspects of Boost.Function. Most of those fall into one or more of these categories: - overall code speed overhead - overall code bloat overhead - lack of configurability - dependencies on RTTI and exception handling with the most frequently brought up specific issue being the various implications (in all of the above mentioned areas) of the hardcoded throw-on-empty behaviour... Unfortunately Boost.Function code remained virtually unchanged (except for the added RTTI emulation for platforms w/o RTTI support) with all of the issues still remaining... The new implementation proposal @: https://svn.boost.org/svn/boost/sandbox/function/boost/function http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Funct… Objects solves or at least provides drastic improvements for all of the mentioned issues. It is intended as a drop in replacement for the current implementation and as such I have so far tested it in the following ways: - compiling some real world code: VC10, GCC 4.2.1, LLVM-GCC 4.2.1, GCC 4.5.1, GCC 4.6, Clang 2.0, Clang 2.8 - compiling and running a real world project: VC10, Clang 2.8 - building Boost trunk: VC10, GCC 4.2.1, GCC 4.5.1, Clang 2.0 - running Boost regression tests for Function, Signals, Signals2, Thread, Program Options and Graph libraries: VC10, GCC 4.2.1, Clang 2.0. (All of the tests passed except for two bogus assertion failure boxes that pop up with VC10 and the Program Options tests during the automated regression test procedure that OTOH do not popup when I run the same tests manually through the VC10 IDE, i.e. the tests finish successfully...I tried to make sure all the relevant compiler switches were the same in both cases so I am out of ideas what else can make the difference.....) Next, let me give you a comparison of for-size-optimized code generated by VC10 with both the current and the proposed implementation for a short code snippet demonstrating invocation, construction and assignment: struct X { int foo( int const x ) const { return x + y; }; int y; }; int main( int /*argc*/, char * * /*argv*/ ) { using namespace boost; X x; function<int(int)> foof( boost::bind( &X::foo, &x, _1 ) ); foof( 0 ); function<int(int)> barf; barf = foof; barf( 1 ); return 0; } Notice in new_function_code_listing.txt how all of the wrapper code in the new Function was completely transparent to the compiler and was completely inlined to relatively simple machine code with direct calls to/through the vtable pointers...while OTOH in current_function_code_listing.txt the code generated for the "barf = foof;" assignement alone is several times larger than the entire code generated for the new Function implementation. The small asm snippet of the generated invoker/'thunk'/'trampoline' code also demonstrates the effects of various tweaks done to minimize or all together remove the need for any stack adjustment on the invoker side... The new implementation of course has the same semantics and exception safety guarantee levels as the original/current one. Listing all of the improvements and detailed implementation changes here in the first post would be quite cluttering as they are quite numerous. Those that desire more tests and details right now, can follow this trail: http://lists.boost.org/Archives/boost/2010/01/160908.php As for the dependencies issue this is solved in several ways: - use of exception handling: new code uses guard objects instead of explicit exception handling and provides a way to change on-empty-behaviour so that the EH code/dependency can easily be removed/disabled - use of RTTI (for getting the type of the stored function object): this can be globally disabled with the BOOST_FUNCTION_NO_RTTI macro. BOOST_NO_RTTI is not used for this purpose for backward compatibility reasons: in the current implementation it actually turns on RTTI emulation...The idea is to also add per instantiation RTTI on-off configurability... 'Configurability' will probably be the most controversial issue/change because it required the addition of an extra template parameter through which an MPL list of policies can be specified at compile-time. This parameter is properly defaulted to allow existing code to compile without changes while providing current Boost.Function behaviour (e.g. on-empty- behaviour). As all the performed tests showed this to also be true in practice the proposed code should IMO go in as a straight drop-in replacement but, of course, I might have missed some important higher level detail/concern so this is open to discussion... Currently two policies are supported: - on throw behaviour (with throw-on-empty, nop-on-empty and assert-on-empty handlers provided) - whether the function instantiation should mark itself (i.e. its operator()) as nothrow. Additional policies my be added later, for example: - sizeof and/or alignment of the SBO buffer - default allocator - per instantiation RTTI on/off ... Finally, there is one more addition, somewhat 'unholy' as it brings in the concept of binding into Boost.Function but considering its efficiency and/or verbosity benefits (and the fact that the first issue can be 'explained away' by saying that this is not actually 'binding' but a workaround for the lack-of-delegates-support C++ language deficiency). The addition is in the form of two more assign() member function overloads (one for a free function that has the exact signature as the Boost.Function instantiation, and one for a member function that has a matching signature with the addition of a this pointer) that allow assignment of (suitably typed) plain (free or member) functions specified as non-type-template parameters. This allows for the removal of the extra indirect-call-through-function-pointer otherwise incurred by traditional assignment of function pointers (not functors), which is actually a rather common use case. For example, in the above example given, one can now write: foof.assign<X, &X::foo>( x ); and get a trivial invoker with the X::foo() target function inlined straight in... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman

7 27

Will test/doc be merged?
by Jim Bell 08 Nov '10

08 Nov '10

Looks like a lot of changes to test/doc and subdirectories were committed to the trunk on 6/10/2010. They fix at least one problem I saw. (doc/html/index.html, BOOST_TEST_PASSPOINT points to "Logging floating point type numbers", which is in the mis-named file BOOST_TEST_PASSPOINT.html.) Anyone know the status? Can it be merged into the release?

1 0

[multi_index] scalar insert interface
by Maxim Yegorushkin 08 Nov '10

08 Nov '10

Hey guys, In ordered_index there are two scalar insert overloads: std::pair<iterator,bool> insert(const value_type& x); iterator insert(iterator position,const value_type& x); The second version is lacking the bool result, which is sometimes required. In my source code of boost-1_42 I patched the second version like this: ==== .../ordered_index.hpp#2 (text) ==== @@ -97,6 +99,16 @@ struct ordered_unique_tag{}; struct ordered_non_unique_tag{}; +template<class T, class U> +struct auto_cast_pair : std::pair<T, U> +{ + typedef std::pair<T, U> base_pair; + auto_cast_pair(base_pair const& b) : base_pair(b) {} + using base_pair::operator=; + operator T&() { return this->first; } + operator T const&() const { return this->first; } +}; + template< typename KeyFromValue,typename Compare, typename SuperMeta,typename TagList,typename Category @@ -274,14 +286,14 @@ return std::pair<iterator,bool>(make_iterator(p.first),p.second); } - iterator insert(iterator position,value_param_type x) + auto_cast_pair<iterator,bool> insert(iterator position,value_param_type x) { BOOST_MULTI_INDEX_CHECK_VALID_ITERATOR(position); BOOST_MULTI_INDEX_CHECK_IS_OWNER(position,*this); BOOST_MULTI_INDEX_ORD_INDEX_CHECK_INVARIANT; std::pair<final_node_type*,bool> p=this->final_insert_( x,static_cast<final_node_type*>(position.get_node())); - return make_iterator(p.first); + return std::pair<iterator,bool>(make_iterator(p.first),p.second); } template<typename InputIterator> Now it automatically figures which return value one wants. Just an idea. -- Max

4 5

[mpl] map insert
by vicente.botet 08 Nov '10

08 Nov '10

Hi, in /libs/mpl/doc/refmanual/map.html insert<m,x>::type point to the description of insert<m,pos,x>::type. In addition I don't find the descrition of insert<m,x>::type in libs/mpl/doc/refmanual/intrinsic-metafunctions.html Can this be added? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

2 2

Re: [boost] [Boost-commit] svn:boost r66442 - in trunk/boost: math/tools test test/impl
by Jürgen Hunold 08 Nov '10

08 Nov '10

Hi ! On Sunday, 7. November 2010 21:05:06 admin(a)thefireflyproject.us wrote: > Author: wash > Date: 2010-11-07 15:05:04 EST (Sun, 07 Nov 2010) > New Revision: 66442 > URL: http://svn.boost.org/trac/boost/changeset/66442 > > Log: > Clang hand-holding, mostly for issues caused by Clang defining GCC macros. I do not think that removing the inclusion of "fenv.h" for clang is the right solution. According to http://llvm.org/bugs/show_bug.cgi?id=6907 it is a known compiler bug that clang fails to correctly load "fenv.h" in certain environments (several gcc versions installed...) I've been working around this by simply adding (see below) > Text files modified: > trunk/boost/math/tools/config.hpp | 2 +- > trunk/boost/test/execution_monitor.hpp | 15 ++++++++------- > trunk/boost/test/impl/execution_monitor.ipp | 18 +++++++++--------- > 3 files changed, 18 insertions(+), 17 deletions(-) > > Modified: trunk/boost/math/tools/config.hpp > =========================================================================== > === --- trunk/boost/math/tools/config.hpp (original) > +++ trunk/boost/math/tools/config.hpp 2010-11-07 15:05:04 EST (Sun, 07 > Nov 2010) @@ -255,7 +255,7 @@ > } // namespace tools > }} // namespace boost namespace math > > -#if (defined(__linux__) && !defined(__UCLIBC__)) || defined(__QNX__) || > defined(__IBMCPP__) +#if (defined(__linux__) && !defined(__UCLIBC__) && > !defined(__clang__)) || defined(__QNX__) || defined(__IBMCPP__) > > #include <fenv.h> #if defined(__clang__) #include </usr/include/fenvh.> #else for my local working copies. > return ~old_cw & BOOST_FPE_ALL; > -#elif defined(__GLIBC__) && defined(__USE_GNU) > +#elif defined(__GLIBC__) && defined(__USE_GNU) && !defined(BOOST_CLANG) > > ::feclearexcept(BOOST_FPE_ALL); And this actually removes fp-Support from Boost.Test. Not good. Please find a better solution. And/Or mark the relevant places with Todo containing a reference to the clang bug report. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

3 4

[mpl] What about wstring, u16string and u32string
by vicente.botet 08 Nov '10

08 Nov '10

Hi, I was considering to use mpl::string to implement chrono_io but I see that there are not the couterparts wstring, u16string and u32string. Without these classes I could not use the mpl strings. Is there a possibility to add these classes to Boost.Mpl? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

3 2

Re: [boost] [Boost-commit] svn:boost r66441 - in trunk/tools/build/v2: . engine/src engine/src/modules tools
by Jürgen Hunold 08 Nov '10

08 Nov '10

Hi ! On Sunday, 7. November 2010 20:51:11 admin(a)thefireflyproject.us wrote: > Modified: trunk/tools/build/v2/engine/src/modules/order.c > =========================================================================== > === --- trunk/tools/build/v2/engine/src/modules/order.c (original) +++ > trunk/tools/build/v2/engine/src/modules/order.c 2010-11-07 14:51:05 > EST (Sun, 07 Nov 2010) @@ -50,8 +50,8 @@ > > if (colors[adjacent_vertex] == white) > do_ts(graph, adjacent_vertex, colors, result_ptr); > - else if (colors[adjacent_vertex] == gray) > - ; /* This is loop. Not sure what to do... */ > + //else if (colors[adjacent_vertex] == gray) > + //; /* This is loop. Not sure what to do... */ > } > colors[current_vertex] = black; > **result_ptr = current_vertex; Are you sure that you really wanted to commit this ? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

3 3

Re: [boost] [ptr_container] [1.45] you own a showstopper
by Thorsten Ottosen 07 Nov '10

07 Nov '10

Den 07-11-2010 23:05, Eric Niebler skrev: > Thorsten, > > The following bug in ptr_container is marked as a Showstopper for the > 1.45 release. What are your plans for it? If you're planning on fixing > it, can you do so soon? If you feel it is not a showstopper, can you set > its priority appropriately? > > https://svn.boost.org/trac/boost/ticket/4598 Should hav been fixed for a day or more. -Thorsten

2 2

[ptr_container] [1.45] you own a showstopper
by Eric Niebler 07 Nov '10

07 Nov '10

Thorsten, The following bug in ptr_container is marked as a Showstopper for the 1.45 release. What are your plans for it? If you're planning on fixing it, can you do so soon? If you feel it is not a showstopper, can you set its priority appropriately? https://svn.boost.org/trac/boost/ticket/4598 Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

[property_tree] [1.44] you own a showstopper
by Eric Niebler 07 Nov '10

07 Nov '10

Sebastian, The following bug in property_tree is marked as a Showstopper for the 1.44 release. What are your plans for it? If you're planning on fixing it, can you do so soon? If you feel it is not a showstopper, can you set its priority appropriately? Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 1

[function] does calling boost::function from boost::function involve nested virtual calls?
by Mostafa 07 Nov '10

07 Nov '10

Hi all, Correct me if I'm wrong, using boost::function involves a virtual function call. If so, then does nesting boost::function calls result in nested (multiple) virtual function calls? For example: int foo(float); boost::function<int (float)> f1 = foo; boost::function<double (int)> f2 = f1; Does f2(5) result in two virtual functions being called on the part of boost::function? (I couldn't find the answer in the documentation and reading the source code I got lost in the macros.) Thanks, Mostafa

2 1

[build] print test failing on release
by Eric Niebler 06 Nov '10

06 Nov '10

Volodya, can you investigate the failure of the Boost.build "print" test on the release branch? It's currently failing across all platforms. Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 3

[type traits] is_virtual_base_of causes C4250 (class inherits member via dominance) with VS 2005
by Martin B. 06 Nov '10

06 Nov '10

Hi! I didn't find any references to this, so I thought I'd let you know that boost::is_virtual_base_of<Base, Derived> will cause (harmless) C4250 when evaluating to true. (VC++ 2005) I hit this when using the BOOST_CLASS_EXPORT macro from Boost.Serialization, as this uses is_virtual_base_of internally. cheers, Martin ps: For code see: http://stackoverflow.com/q/4091166/321013

3 2

[icl/itl] Interval Container Library ready for inclusion
by Joachim Faulhaber 06 Nov '10

06 Nov '10

Dear list! After the review of the Interval Template Library in February and its acceptance for inclusion, I worked on a number of suggestions and proposals from the reviewers, in order to improve the design and quality of the library. The library is now renamed to Boost.Icl: Interval Container Library. I have completed a release icl-4.0.0, where those suggestions are implemented. Apart from typos and flaws in the docs that might be there after renaming, this will be the version for inclusion into the next boost release (1.46.0). The now renamed library has a new path in the sandbox: https://svn.boost.org/svn/boost/sandbox/icl/ The sources are also in the vault http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Conta… and on sourceforge (extended version) http://sourceforge.net/projects/itl/ The BoostBook docs are online available here: http://www.joachim-faulhaber.de/boost_icl/doc/libs/icl/doc/html/index.html Many of the proposals from the reviewers were agreed upon during the discussion on the library. In particular I took into account suggestions by Jeff Flinn (JF), Luke Simonson (LS), Barend Gehrels (BG), Vicente Botet (VB), Thomas Klimpel (TK), Paul A. Bristow (PB), Robert Stewart (RS), John Reid (JR) and Markus Werle (MW). Some suggestions by Phil Endecott, Jerry Jeremiah, Brian Wood, Barend Gehrels, Luke Simonson and John Reid are not or not yet implemented for different reasons but they may be considered for the future evolution of the library. * The library has been renamed from Interval Template Library (ITL) to Interval Container Library (ICL) Its namespace is now icl instead of itl. (Renaming was suggested by MW). * Introduction of dynamically bounded and statically bounded intervals (JF,JR,VB) + The 'universal' interval class itl::interval has been replaced by + dynamically bounded discrete_interval and continuous_interval http://www.herold-faulhaber.de/boost_icl/doc/libs/icl/doc/html/boost_icl/ex… + statically bounded right_open_interval, left_open_interval closed_interval and open_interval and a uniform set of namespace global functions or interval_concept for them. Statically bounded intervals don't carry information about their interval bounds and use less memory. (JF,JR) http://www.herold-faulhaber.de/boost_icl/doc/libs/icl/doc/html/boost_icl/ex… + The interval class templates are now quite small. The functions are namespace global functions that make up an interval concept (JF,LS) + Added functions 'distance' and 'inner_complement' for intervals.(JR) http://www.herold-faulhaber.de/boost_icl/doc/libs/icl/doc/html/boost_icl/fu… * User defined interval types are now customizable (JF) + An interval_traits and dynamic_interval_traits template describes the generic properties of the interval concept ... + and allows to customize the icl library for user defined interval types. http://www.herold-faulhaber.de/boost_icl/doc/libs/icl/doc/html/boost_icl/ex… * Extraction of namespace global functions. (LS,JF,RS) + Member functions have been extracted form class templates as long as they are not needed to maintain type invariants. + The sets of namespace global functions build concepts icl::element_set, icl::element_map, icl::interval_set, icl::interval_map + Some functions have been renamed to conform existing standards (ISO/OGC). (BG) + std::set and other stl conformant set types are models of the icl's element_set concept. Class template icl::set has been removed. + Member functions for element iterations are extracted from the interval container class templates. (LS) * Names, referred to as 'colorful terminology' have been renamed (TK,VB,PB) + neutron -> identity_element + unon -> unit_element + ... and also their occurrence in composite identifiers If you find bugs in the library or typos or other flaws in the docs, please let me know so I can fix them before inclusion of the library into the next boost release. Enjoy, Joachim

5 4

bjam in lib/<x>/test is equivalent to run.py
by Jim Bell 06 Nov '10

06 Nov '10

Compelled as I am to audit everything, I had to compare running bjam in the lib/<x>/test directory with run.py. I'm confident that they do produce (essentially) the same compile, link, and execute commands. Notes, from a regression-runner's POV: * They use different directories: run.py uses {boost-root}/../results/bin.v2/..., and bjam uses {boost-root}/bin.v2/... * run.py sets up bjam with a lot of flags, like --debug-configuration [shouldn't matter for most people] -d2 [important for many, described below] -lxxx [that's lower-case L, with a time-out in seconds: potentially important] preserve-test-targets=off [not sure if this matters or not] * run.py runs from the boost/status directory, I think. Might matter for some tests. Not sure about straight bjam. To make your own script to rebuild/rerun a particular test, run bjam with -d+2 (i.e., -d2) and direct the output to a file. Then copy the compile & link commands out of that file. The -lxxx command (e.g., -l120) matters if a test could hang (e.g., <https://svn.boost.org/trac/boost/ticket/4766>).

3 5

Re: [boost] [Boost-users] [icl/itl] Interval Container Library ready for inclusion
by Joachim Faulhaber 05 Nov '10

05 Nov '10

2010/11/5 Jeff Flinn <TriumphSprint2000(a)hotmail.com>: > Hartmut Kaiser wrote: >>> >>> After the review of the Interval Template Library in February and its >>> acceptance for inclusion, I worked on a number of suggestions and >>> proposals from the reviewers, in order to improve the design and quality >>> of the library. The library is now renamed to Boost.Icl: Interval >>> Container Library. >>> >>> I have completed a release icl-4.0.0, where those suggestions are >>> implemented. Apart from typos and flaws in the docs that might be there >>> after renaming, this will be the version for inclusion into the next >>> boost >>> release (1.46.0). >>> >>> The now renamed library has a new path in the sandbox: >>> https://svn.boost.org/svn/boost/sandbox/icl/ >>> >>> The sources are also in the vault >>> >>> http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Cont >>> ainers >>> >>> and on sourceforge (extended version) >>> http://sourceforge.net/projects/itl/ >>> >>> The BoostBook docs are online available here: >>> >>> http://www.joachim-faulhaber.de/boost_icl/doc/libs/icl/doc/html/index.html >> >> Joachim, that's great news. Many people are waiting for this! > > Awesome! I'm looking forward to working with the final result. > >> Why don't you just go ahead and move everything into Boost trunk. That >> does >> not disrupt any release procedures, but gives you the benefit of running >> the >> tests on a daily basis on a broad range of platforms. Additionally it >> simplifies things for people working from Boost SVN trunk wanting to use >> your library. > > Yep, that would be great. Thank you all for your welcoming remarks on the new version of the Interval Container Library. Yes, I am prepared to move this version of the ICL into the Boost trunk, but I don't have write permission yet. How do I get it? Are there any special policies to follow when working with the Boost trunk? Best regards, Joachim

2 1

[Boost.config] User.hpp for new PGI 10.9 compiler
by K. Noel Belcourt 05 Nov '10

05 Nov '10

Hi, Can a Boost.config developer take a look at the attached user.hpp generated by the configure script for the pgi-10.9 toolset? Are there any obvious changes necessary to boost/config/compiler/pgi.hpp? Thanks. -- Noel

2 5

Best method of checking for ==, <, streamability
by Christopher Jefferson 05 Nov '10

05 Nov '10

A user recently posted on boost-users asking for operator== support in boost::any. I have added this support to my private version, which extends spirit's implementation of any. I am interested in cleaning this up and submitting it to replace boost::any, if everyone is happy with this. The major issue is that my implementation requires type support operator==, operator< , hash and operator<< / operator>>. Are there any techniques in boost for detecting the presence of these operators which are sufficiently reliable they could be used in boost::any? Apologises for this question, but I have lost track of how well such checks can be implemented. Thanks, Christopher Jefferson

5 4