- Boost - lists.boost.org

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

[c++-sig] A question regarding arguments bindings
by Sandeep Gupta 13 Nov '08

13 Nov '08

Hi, My question is regarding the default behavior of the compiler when there is mismatch in the argument type between binding declaration and function declaration. By default no warning is generated. Consider following example: class A{ public: A(const B&); }; In wrapper, if by mistake (which I made in my code), i write class_<A>("A", init<B>) ; The compiler does not complain about no constructor found. Instead for reasons, beyond my understanding of boost.python, B get passed by value. My question why doesn't compiler issue at least a warning. Needless to say i am new to boost.python. My apologies if this is something trivial or well known. Thanks sandeep

2 2

[flyweight] key value with objects not constructible from a key
by Michael Marcin 13 Nov '08

13 Nov '08

The flyweight factory concept seems to be missing a key part of the GoF Flyweight pattern's FlyweightFactory participant. The GoF factory supplies the flyweight if one exists. This is what the current boost flyweight Factory concept does. If no flyweight exists the GoF flyweight factory creates one. In the boost flyweight library this functionality is somewhere else that doesn't seem to be described in the documentation. The name factory for what is currently in place is misleading. Isn't it really just an associative container? I'm trying to use flyweight to represent texture objects right now. These are surely a good candidate for use with flyweight as they are one of the examples given. My textures are fairly simple objects, with low coupling. Creating a texture is however expensive and has a lot of dependencies (libjpeg,libpng,etc). I typically have a TextureFactory which decouples the construction of a texture from the actual texture object and allows the work required to setup the various libraries to read images to be reused by all textures constructed from the same TextureFactory instance. It doesn't seem possible to have this decoupling with flyweight. Am I missing something? -- Michael Marcin

5 20

[Chrono] Boost.Chrono added to sandbox
by Beman Dawes 13 Nov '08

13 Nov '08

Work-in-progress for the Boost.Chrono library has been added to the sandbox. See http://svn.boost.org/svn/boost/sandbox/chrono This work is in a very preliminary state. The only testing has been with VC++ 9.0 on XP-64 and a tiny bit on Ubuntu 8.04 Linux. There has been no work done yet on C++0x headers. The Jamfiles are there, but haven't been tested; I've been developing using the provided VC++ solution. The implementation of the clocks is going to be very system specific. If anyone would like to try .../libs/chrono/example/await_keystroke.cpp and report whether or not it compiles and works on their system, it would be appreciated. Patches to make .../libs/chrono/src/chrono.cpp work for various operating systems would be even more appreciated! I'm still unsure about even some of the basics, such as how to partition the three parts for boost. Are the time utilities, the compile-time rational arithmetic, and the type trait common_type three boost libraries, one boost library, or three parts of a larger boost library? There was some discussion of this in a prior thread, but I thought having the actual code available might move the discussion forward. There is a tiny bit of documentation; see .../libs/chrono/doc/index.html. Comments welcome! --Beman

4 6

[TR1] Sun problems (again)
by Ling Li 13 Nov '08

13 Nov '08

(The related thread is http://lists.boost.org/Archives/boost/2006/08/109450.php) Sun CC seems to have #include guards automatically for standard headers like <memory>. This somehow causes problems to Boost::TR1. Here is a simple example (call it sun-test.cpp) that doesn't compile with Sun's compiler: #include <string> #include <memory> void f() { std::tr1::shared_ptr<int> p(new int()); } The command line is: CC -c -library=stlport4 -I<BOOST_TOP>/boost/tr1/tr1/sun -I<BOOST_TOP>/boost/tr1/tr1 -I<BOOST_TOP> sun-test.cpp And the error msgs: "sun-test.cpp", line 5: Error: tr1 is not a member of std. "sun-test.cpp", line 5: Error: shared_ptr is not defined. "sun-test.cpp", line 5: Error: Badly formed expression. The reason is that the 2nd include, "#include <memory>," is not honored since Sun's <string> (included from Boost::TR1's string) somehow loads <memory> inside it. Although the <memory> header it loads is the Boost::TR1 version, Boost is smart enough not to include the TR1 extension part. That is actually the correct thing to do, and other compilers (VS and GCC) will get the TR1 extension via the 2nd include. But for Sun's CC, since the 2nd include is not honored, std::tr1 is missing. Sun CC doesn't do that auto #include guards for user headers. I am wondering if there is a way to turn off that auto guards for Sun CC (I haven't found a way yet). Or is there some way to change Boost::TR1 to accommodate this special behavior?

3 6