- Boost - lists.boost.org

[thread] Conformance with N2497 move semantics
by vicente.botet 14 Nov '08

14 Nov '08

Hi Anthony, N2497 includes the following thread constructor overloadings template <class F> explicit thread(F f); template <class F, class ...Args> thread(F&& f, Args&&... args); void swap(thread&&); Boost.Threads try to conforms to N2497 as muh as possible. Boost.Threads defines already #ifdef BOOST_HAS_RVALUE_REFS template <class F> thread(F&& f); #else #ifdef BOOST_NO_SFINAE template <class F> explicit thread(F f); #else template <class F>explicit thread(F f, typename disable_if< boost::is_convertible<F&, detail::thread_move_t<F> >, dummy* >::type=0); #endif template <class F>explicit thread(detail::thread_move_t<F> f); template <class F,class ...Args> thread(F f, Args... args) I have some questions. Is there any deep raison for which template <class F> explicit thread(F f); should not always be defined? Is there any deep raison to emulate template <class F,class ...Args> thread(F f, Args... args) instead of template <class F,class ...Args> thread(F&& f, Args... args) Could template <class F, class ...Args> thread(F&& f, Args&&... args); rally be emulated? You provide 'void swap(thread&)'. Could 'void swap(thread&&)' be emulated? Do you know if the following overloadings are taken in account by the boost::swap utility? void swap(thread& x, thread& y); void swap(thread&& x, thread& y); void swap(thread& x, thread&& y); Thanks in advance, Vicente

2 2

Re: [boost] Compiling 64bit regex 1.37.0 with VS2005
by Gary Mann 14 Nov '08

14 Nov '08

I also see the same problem compiling with 32 bit MSVC 7.1 SP1 (13.10.6030). I don't experience the issue when using STLport - only when using the native Dinkumware STL implementation (not surprising given the preprocessor directives in the file). src\usinstances.cpp(47) : error C2910: 'std::char_traits<wchar_t>::length' : cannot be explicitly specialized I tried grabbing the latest copy of the source file from SVN, but it appears identical to that included in the 1.37.0 distribution. I haven't tried updating all the source and headers for the entire regex component yet... Gary -- View this message in context: http://www.nabble.com/Compiling-64bit-regex-1.37.0-with-VS2005-tp20493076p2… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 4

Re: [boost] [utility/swap] Internal compiler error Siliconman borland-6.10.0 (CodeGear?)
by Niels Dekker - mail address until 2010-10-10 14 Nov '08

14 Nov '08

>> But unfortunately, the rather simple specialized_in_std.cpp test >> gets an internal compiler error (Fatal F1004) from borland-6.10.0. I >> guess this is a CodeGear issue, right? David (siliconman) wrote: > Yes, this looks like a compiler bug. I'll submit it to the bug > tracking system. Thanks! So did you report the bug to http://qc.codegear.com ? If so, can you please give me the report number? Kind regards, Niels

1 0

[unordered] patch to remove warning on Visual C++
by Christopher Lux 14 Nov '08

14 Nov '08

Hi, appended is a small patch to fix some annoying warnings using Visual C++ 8.0 and 9.0. It would be nice if this could be looked at and applied to the trunk. The warnings were: 1>brick_pool.cpp 1>E:\devel\working_copies\schism_x64_vc90_sp1\externals\inc\boost\boost/unordered/unordered_map.hpp(388) : warning C4396: 'boost::operator ==' : the inline specifier cannot be used when a friend declaration refers to a specialization of a function template 1>E:\devel\working_copies\schism_x64_vc90_sp1\externals\inc\boost\boost/unordered/unordered_map.hpp(389) : warning C4396: 'boost::operator !=' : the inline specifier cannot be used when a friend declaration refers to a specialization of a function template Regards -chris -- Christopher Lux | | Bauhaus-Universität Weimar | faculty of media - virtual reality systems group Index: boost/unordered/unordered_map.hpp =================================================================== --- boost/unordered/unordered_map.hpp (revision 49734) +++ boost/unordered/unordered_map.hpp (working copy) @@ -385,8 +385,8 @@ friend bool operator==(unordered_map const&, unordered_map const&); friend bool operator!=(unordered_map const&, unordered_map const&); #else - friend bool operator==<>(unordered_map const&, unordered_map const&); - friend bool operator!=<>(unordered_map const&, unordered_map const&); + friend bool operator==<unordered_map>(unordered_map const&, unordered_map const&); + friend bool operator!=<unordered_map>(unordered_map const&, unordered_map const&); #endif }; // class template unordered_map

1 0

Compiling 64bit regex 1.37.0 with VS2005
by Foster Brereton 14 Nov '08

14 Nov '08

Hi, I've been looking around for potential issues I may have missed but have found none, so I thought I'd ask the list. I am trying to compile the regex library from 1.37.0 using MSVC2005. This used to work for boost 1.36.0, but does not anymore. The extended error set I have pasted here for email brevity: http://pastebin.com/md368403 The start of the errors I'm seeing are: usinstances.cpp C:\boost_libraries\libs\regex\src\usinstances.cpp(47) : error C2910: 'std::char_traits<wchar_t>::length' : cannot be explicitly specialized ... wc_regex_traits.cpp C:\boost_libraries\libs\regex\src\wc_regex_traits.cpp(48) : error C2910: 'std::char_traits<wchar_t>::length' : cannot be explicitly specialized ... ... the really strange thing is, those lines read as follows: template<> BOOST_REGEX_STDLIB_DECL std::size_t __cdecl char_traits<unsigned short>::length(unsigned short const*); ...and... template<> BOOST_REGEX_STDLIB_DECL std::size_t __cdecl char_traits<unsigned short>::length(unsigned short const*); ... respectively, and make no mention of wchar_t. My project settings are as follows: /Od /I "." /I "." /D "DVA_COCOA_UI=0" /D "BOOST_ALL_DYN_LINK" /D "BOOST_ALL_NO_LIB" /D "_WINDOWS" /D "MSWindows" /D "_CRT_SECURE_NO_DEPRECATE" /D "_SCL_SECURE_NO_DEPRECATE" /D "BOOST_THREAD_BUILD_DLL" /D "BOOST_REGEX_USE_CPP_LOCALE" /D "BOOST_NO_WREGEX" /D "BOOST_REGEX_RECURSIVE" /D "BOOST_REGEX_NO_LIB" /D "DEBUG=1" /D "_DEBUG" /D "_WINDLL" /D "_UNICODE" /D "UNICODE" /GF /FD /EHsc /RTC1 /MDd /Zp8 /Gy /Zc:wchar_t- /Fo"..\..\obj\win\debug\64/" /Fd"..\..\lib\win\debug\64/boost_regex.pdb" /W3 /nologo /c /Zi /TP /wd4355 /errorReport:prompt I'm compiling with wchar_t support turned off, and am defining BOOST_NO_WREGEX in an attempt to state as much explicitly for the library. (I couldn't find much documentation about disabling wchar_t support for the regex library explicitly). Does anyone have any pointers to guide me in the direction I should go to get this building again under a 64-bit environment? Thanks in advance for the help, Blessings, Foster -- Foster T. Brereton Adobe Systems Incorporated fbrereto(a)adobe.com

2 1

Boost, preprocessing, computed #includes, and distcc
by David Abrahams 14 Nov '08

14 Nov '08

One of the few options Boost users have for speeding up long compiles is to throw more machines at the problem, as with distcc (http://code.google.com/p/distcc/) I was just wondering why I couldn't get distcc's incredible "pump" mode to work as well as it should, and discovered this text: "In distcc-pump mode, the include server is unable to handle certain very complicated computed includes as found in parts of the Boost library. The include server will time out and distcc will revert to plain mode." (http://distcc.googlecode.com/svn/trunk/doc/web/man/distcc_1.html#TOC_22) It's nice that they consider it a bug, but it doesn't sound they're going to go out of their way to fix it. Just another lovely trade-off to keep in mind when making design decisions... ;-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com

3 3

[MPL.Math] ratio
by Cromwell Enage 14 Nov '08

14 Nov '08

Hi, all! Sorry I've been out for so long. I've been reading N2691 for the past couple of days. I just noticed section 20.3, called "compile-time rational arithmetic", and I'm wondering how stable that specification is. I'm also wondering whether or not anyone else has been working on an implementation. A Google search turned up a "Summer of Code" project labeled 'ontl', but the ratio source code is not part of the download or its SVN distribution. In the meantime, my questions are: * Should I resume work on MPL.Math? Should I make a different branch, still part of MPL? Or should I fork a separate Boost project altogether? * If I resume work, should I make the implementation more standards-conformant? Cheers, Cromwell D. Enage

4 9

[MPL.Math] linear solver
by Cromwell Enage 14 Nov '08

14 Nov '08

Hi, Matthias. We were talking about Steven Watanabe's compile-time linear solver, currently part of Boost.Units. Can you point me in the right direction as to where the implementation is? (My initial guess is <boost/units/detail/linear_algebra.hpp>.) Documentation would be a big plus, but at least I can read source code. Cheers, Cromwell D. Enage

3 2

Re: [boost] Fwd: [signals2][review] little REVIEW
by vicente.botet 14 Nov '08

14 Nov '08

> ----- Original Message ----- > From: "Frank Mori Hess" <fmhess(a)speakeasy.net> > To: <boost(a)lists.boost.org> > Sent: Wednesday, November 12, 2008 4:01 AM > Subject: Re: [boost] Fwd: [signals2][review] little REVIEW > > > On Tuesday 11 November 2008 11:23, Stjepan Rajko wrote: >> ---------- Forwarded message ---------- >> From: <Jean-Christophe.BENOIST(a)fr.thalesgroup.com> >> * On test suite / test cases : >> >> - I cannot see any MT test case (from the documentation, in >> "acceptance tests" section at least). It's rather surprising. I cannot >> imagine there is no test case for MT (calling a signal while >> disconnecting slot etc..). In particular, I'd whish to see if this >> library is robust in a multi-core environment and run test cases in >> this environment (I know cases where a library is perfectly thread >> safe on mono-core, even hyperthreading, but fails on multi-core). At >> least, there should be a rationale explaining why this library should >> be robust in a multi-core environment (especially with a proprietary >> signals2::mutex). > > It's not obvious to me how to write a test for the library's > thread-safeness that is any more focused than "we did some signals stuff > in multiple threads and the program didn't crash". It's sort of like > writing a test for memory leaks. What you need is a debugging tool, like > what valgrind's helgrind tries to be. Then you can have your > multi-threaded test program, and the test is whether or not the debugging > tool detected any funny business (like multiple threads messing with the > same variable without locking). Yes I know that doing test on a multi-threading environement is not eassy, but we can not deliver a thread safe library without the minimal unit testing coverage on all the functionalities concerned by the multi-threading. Please could you take a look on hwo the tests of the Boost.Thread library are done. Regards, Vicente

2 1

[signals2] extended_slot_type bug with preferred syntax
by Frank Mori Hess 13 Nov '08

13 Nov '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In case anyone is trying to use extended_slot_type/connect_extended with the "preferred syntax" signal for the review, there is a bug with the default ExtendedSlotFunction template type parameter. Fix is in svn revision 49593: https://svn.boost.org/trac/boost/changeset?new=49593%40sandbox%2Fthread_saf… The "portable syntax" signals are not affected. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJELwa5vihyNWuA4URAueDAJ9V/2Bdpf2N6VWaUrjgWpyIvyH1mgCgrOP0 mJzCelYUnWTmNsoHzMPfKdY= =8bRd -----END PGP SIGNATURE-----

3 10