- Boost - lists.preview.boost.org

boost regex build problem
by Qihong Wang 13 Apr '09

13 Apr '09

Hi, I feel awkward to post almost the same question again. But I really have a problem when I build 32 bits boost.regex with icu support on a 64 bits Linux machine. If I build 64 bits regex with icu support, they are fine. If I build 32 bits regex without icu support, they are fine. When I tried to build 32 bits regex with icu support, I used command for ICU building ./runConfigureICU Linux --disable-64bit-libs ./configure --prefix=/home/qhwang/mylibs_32/icu --disable-64bit-libs I checked icu libraries they are not dependent on 64bits libraries. So I'm confident they are 32bits. But when I use the command to build 32 bits regex ./bjam --prefix=/home/qhwang/mylibs/boost/ --with-regex --build-dir=/tmp/boost_build/ --build-type=complete --address-mode=32 --architecture=x86 -sHAVE_ICU=1 -sICU_PATH=/home/qhwang/mylibs/icu/ install Bjam showed ...failed updating 4 targets... ...skipped 12 targets... ...updated 7477 targets... there were only static libraries built. When I linked them to my program which were also compiled in 32 bits, the linker complained the libraries were incompatable. Could someone give me some help again? Thanks in advance. Qihong

3 6

[fusion] repetitive_view
by Stjepan Rajko 12 Apr '09

12 Apr '09

Hello, I just noticed `repetitive_view` in boost/fusion/view. It doesn't appear to be documented, but judging from the test, it appears that repetitive_view<Sequence> is an infinite repetition of the elements of the sequence. Is that correct? I would find this extremely useful, but I'm slightly put off by the lack of documentation and the fact that it results in a (not currently officially supported?) infinite sequence. What is the status of repetitive_view? Is it safe to use? Stjepan P.S. we have discussed infinite sequences before: http://archives.free.net.ph/message/20080716.025311.1b54b65e.da.html

2 3

boost/pool/pool.hpp why reinterpret_cast instead of static_cast?
by Philippe Vaucher 12 Apr '09

12 Apr '09

Hi, In the file https://svn.boost.org/trac/boost/browser/trunk/boost/pool/pool.hpp there's the following code: struct default_user_allocator_malloc_free { ... static char * malloc(const size_type bytes) { return reinterpret_cast<char *>(std::malloc(bytes)); } ... }; It is my understanding that void* to T* convertions should be done using static_cast and not reinterpret_cast. Is there a reason for using reinterpret_cast there? Thanks, Philippe

7 11

[filesystem] Version 3 request for comments
by Beman Dawes 12 Apr '09

12 Apr '09

A prototype implementation of version 3 of Boost.Filesystem is available for comment. The critical feature of this prototype is the replacement of the class basic_path template with a single class path that supports both narrow and wide character paths. It also supports user supplied types, and will support the new C++0x char16_t and char32_t character types as compiler and standard library support becomes available. There is still a lot of additional work before V3 could be added to the trunk and eventually released. For example, work so far has concentrated on the new functionality, and ignored breaking changes to existing code. But enough stuff is working to make requesting comments useful. See http://svn.boost.org/svn/boost/sandbox/filesystem-v3/libs/filesystem/doc/v3… for a fuller description of the prototype and links to the prototype implementation. I've got some specific issues I'd like opinions on, but would first like to hear comments from anyone interested. --Beman

11 21

Re: [boost] BoostCon 2009 Early Registration Extended to April 26th
by David Abrahams 12 Apr '09

12 Apr '09

The following message is a courtesy copy of an article that has been posted to comp.lang.c++.moderated,comp.std.c++,comp.lang.c++ as well. on Thu Apr 09 2009, woodbrian77-AT-gmail.com wrote: > Would you agree that recoding that takes advantage of C++ 1998 > should be higher priority than C++0x? In general, maybe. For BoostCon, no. > For example, Boost Serialization doesn't use hinted inserts with > (mulit)set or (multi)map. Have you submitted a ticket for that at http://svn.boost.org? > I believe Boost Multi Index does. In the > performance section here -- > http://webEbenezer.net/comparison.html -- there's a subsection > on Load/Receive tests that mentions this. I also mentioned > this subject twice in this thread: > http://lists.boost.org/boost-users/2009/03/45712.php > > If anyone cared or even noticed wasn't clear as there was > no response to that particular point. Different library maintainers take different approaches to responding to reports on the Boost list. Specific Trac tickets (especially with patches attached, as you seem to be able to provide) are a little harder to leave dangling because to make them go away you have to explicitly close them, so I suggest you try that approach with one ticket per issue. > For some reason I doubt the author or anyone else bothered to improve > the library in this way and the 1.39 version of the Serialization > library will have the same weak performance in this area. > > Additionally and more importantly, now the C++ Middleware > Writer has support for several boost::intrusive containers. > Neither Boost Intrusive nor Boost Serialization have > serialization support for any of the intrusive containers. > The Boost Instrusive containers are superior to the > standard containers in a number of ways, so this gap is > big. > > While working to update parts of Boost to be able to > take advantage of C++ 2010 (or 20110), makes sense to > me, I think the items I mentioned should be higher > priority than the C++0x work. A Boost bugfixing sprint sounds like a great idea, but that can happen in cyberspace (the way Ubuntu does it). I invite you to come to the Boost developers' list and kick one off. I would certainly be grateful for an excuse to focus on closing Boost Trac tickets. In fact, it sounds like a good thing to mull over at BoostCon At BoostCon I want to take advantage of the face-to-face time to do things that are a bit more educational, less critical-path, and that can really benefit from having a bunch of people in the same room. I think exploring how C++0x features interact in real C++ libraries is one of those. > It's not as cool or sexy though. That's an issue, too. To make it worthwhile for people to travel across the country to BoostCon, you need to put "cool" things on the program ;-). > The first item should be relatively easy to address, which makes it > all the more surprising that as the releases go by it doesn't get > addressed. Remember that addressing any given issue in a Boost library is basically up to one person: whoever is maintaining that library. Maintainers are volunteers, and each one arranges his priorities differently. But in the case of something posted on the -users mailing list whose thread sorta trailed off, I wouldn't be surprised if the issue has fallen off the maintainer's radar. I suggest getting it into the tracking system. > The second item, though is a different story. Anyway, > even if you are only able to address the first item by the time > BoostCon is over, I'll be impressed. Well, it's not really up to me, and I don't /think/ Robert Ramey is planning to come to BoostCon this year. > And since I'm able to point out two weaknesses like this with one > library, there may be other problem areas in other libraries. Definitely: https://svn.boost.org/trac/boost/report/1 Looks like we have 766 open issues right now :-( > This could be incorporated into the pricing of the conference: $499 > gets you into the C++98 "fixer" and $599 gets you into the C++0x > "fixer." :) Yeah, not very practical. Those sessions are just two 3-hour segments out of a whole week of material. We're not making the conference itself into one big sprint. Take a look at the program: http://www.boostcon.com/program Cheers, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

1 0

boost::interprocess mixing heap and shared memory ?
by Oncaphillis 11 Apr '09

11 Apr '09

Working with boost::interprocess I came across the following question. using namespace boost::interprocess; // ... Assume that I've declared all the necessary allocators // ... for chars and std::pair<my_string,my_string> here typedef basic_string<char,my_char_allocator_t> my_string; typedef map<my_string,my_string,std::less<my_string>,my_string_string_allocator> my_map; managed_shared_memory shm(open_or_create,"BogusMemory",0x1000) my_map *the_map = some_how_construct_map_in_shared_memory(shm); // So now I have a map residing in shared memory // The only way to search within this map I could // find was the following. my_map::iterator i = the_map->find(my_string("BOGUS",my_char_allocator_t(shm))); This might throw since the search string is constructed within shared memory although it is only needed temporary and destructed right after the statement. Is there a way to use heap or stack memory for thinks like that ? Thank you very much O.

2 1

Default variants on windows
by Vladimir Prus 11 Apr '09

11 Apr '09

Per: https://svn.boost.org/trac/boost/ticket/2899 we have a problem that the default set of libraries build on Windows does not match autolink defaults, which causes confusion. In that issue, John say that the only sensible solution for Windows is to build all possible variants by default (IIRC, a total of 6). I would like other Windows developers to comment if that is sensible solution. In particular, is it best to build all possible variants that user might need, or build just the variants that autolink needs by default, so that user can build other later. Note that I can add arbitrary explanation messages into the build process -- both to warn the user that a scary pile of things will be built, and to warn the user that only couple of variants will be built. - Volodya

10 18

How to open parallel port
by master master 11 Apr '09

11 Apr '09

Is there any library exist for opening parallel ports? I know for serial it is "serial_port". I worked with it and it is working fine. For parallel communication; which class(library) is needed. -Rahul Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/

1 0

Thread-safety issue with Boost Function?
by Sohail Somani 11 Apr '09

11 Apr '09

Hi, I was just looking through the Boost Function source and noticed the following in assign_to: // Note: it is extremely important that this initialization use // static initialization. Otherwise, we will have a race // condition here in multi-threaded code. See // http://thread.gmane.org/gmane.comp.lib.boost.devel/164902/. static vtable_type stored_vtable = { { &manager_type::manage }, &invoker_type::invoke }; However, my copy of the C++ standard seems to say this regarding local statics in section 6.7: The zero-initialization (8.5) of all local objects with static storage duration (3.7.1) is performed before any other initialization takes place. A local object of POD type (3.9) with static storage duration initialized with constant-expressions is initialized before its block is first entered. An implementation is permitted to perform early initialization of other local objects with static storage duration under the same conditions that an implementation is permitted to statically initialize an object with static storage duration in namespace scope. I read this to mean that an implementation may decide to initialize stored_vtable statically or the first time the block is entered. So I think that this means we cannot rely on static initialization behaviour. If you agree, then a simple fix for this might just be: template<typename VTable, typename Invoker, typename Manager> struct vtable_static_constructor { static VTable vtable; }; template<...> VTable vtable_static_constructor<V,I,M>::vtable = { {&Manager::manage, &Manager::invoke } }; assign_to() { ... vtable_type & stored_vtable = vtable_static_constructor<vtable_type,invoker_type,manager_type>::vtable; ... } If not, could you please point me to where in the standard this is guaranteed to be statically initialized? It would help me decide whether or not to fix some other code that has a similar pattern, if nothing else. Thanks in advance! -- Sohail Somani http://uint32t.blogspot.com

1 0

Re: [boost] [#pragma once]
by jbosboom＠uci.edu 10 Apr '09

10 Apr '09

> If unrecognized pragmas are ignored, then I don't see why boost > developers should jump > through a hoop to satisfy the "el-cheapo" compilers. In other words, if > a compiler gives > a warning about the #pragma-once, then let the programmer turn off the > warning locally > for the build, which is usually done in a single location within a > makefile. Well, what about the compilers that recognize #pragma once but don't implement it correctly? Or implement it as well as they can on their platform but somehow differ from other compilers? Also, there was once a version of GCC that would launch nethack or rogue when it encountered #pragma once. That's a perfectly legal thing for it to do (if not all that helpful). My point is that since we can't depend on the semantics of #pragma once, we ought not to use it. --Jeffrey Bosboom

1 0

BoostCon 2009 Early Registration Still Available
by David Abrahams 10 Apr '09

10 Apr '09

In recognition of the economic climate, and in order to make possible the maximum participation this year, we've extended the early registration deadline for BoostCon until April 26th, so BoostCon is still only $599. BoostCon has always been a great place to network, find out what is happening in the C++ community, and learn about the coolest C++ libraries being developed within and outside of Boost --- and this year will be better than ever. The official schedule is now live at http://www.boostcon.com/program. A few highlights of the "mouth-watering content" (in the words of one enrollee) are: * A keynote address from Andrei Alexandrescu called "Iterators Must Go." * Troy Straszheim's presentations on how high-energy physicists are using Boost to process massive datasets as they go "Icefishing for Neutrinos" and on Kamasu, his library for offloading computation to your machine's GPU. * Two hands-on sessions where we'll start recoding parts of Boost for C++0x, applying rvalue references, variadic templates, decltype, and advanced SFINAE capabilities using the latest GCC. * "Practical C++ Test-Driven Development with Boost.Test and Bmock," by Asher Sterkin * A session on compiler construction using Boost.Spirit v2, from Hartmut Kaiser and Joel de Guzman The complete list of sessions covers a wide range of other Boost and C++-related topics. Please have a look: http://www.boostcon.com/program/sessions. The quality of BoostCon has always depended on its diverse and interesting participants, so bring your ideas, questions, and experience, and sign up now! http://www.boostcon.com/registration See you in Aspen, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

2 1

Interest check: constant input matching manipulator
by Eugene Wee 10 Apr '09

10 Apr '09

Hi, Recently, I observed in an online community a question on whether C++ had a direct replacement for a call to scanf("a=%d", a) for some int a, using std::cin. The response given was to read the input as a string and then parse it. Another user noted that "iostreams would be more useful if it had the ability to match constant portions of the input". Looking at what already exists in the standard library and Boost, there does indeed seem to be no direct way to match such expected constant input. Boost.Regex and Boost.Tokenizer are indirect in this case (and possibly overkill), and Boost.Format is about output stream formatting only. Boost.Spirit appears to provide a way with file_iterator, but a manipulator seems more appropriate here considering that the functionality is quite simple. Does anyone think that adding such a manipulator to Boost would be desirable? I expect the syntax to be along these lines (names and namespaces to be decided): std::cin >> match("a=") >> a; where a failure to match would place the input stream in a failed state. It would also be possible to use a std::basic_string instead of a string literal converted to a pointer to its first element as the argument. I have already written such a manipulator, so if anyone is interested, I can provide my sample source. Regards, Eugene Wee

5 10

Re: [boost] [threads] making parts of Boost.Threads header-only
by Brian Wood 09 Apr '09

09 Apr '09

Anthony Williams writes: >Emil Dotchevski <emildotchevski(a)gmail.com> writes: >> >> I am against such a move. Boost Threads requires linking for other >> features which makes it one of the few libraries in Boost that can be >> properly designed to avoid unnecessary physical coupling. Unless >> something is proven to cause performance problems it should not be >> inlined, regardless of how simple it is. > >Wow, that's a hard line you've drawn there. I'm not sure I agree. The >only reason this matters is if you're going to be changing the >implementation and don't want to recompile the code that uses the >header. For boost users, the implementation only changes if they change >boost versions, and in that case I would expect people to recompile >anyway --- I wouldn't trust something compiled against boost 1.37 to >link against a 1.38 lib, for example. I'm sure you know more about Boost than I do, but I disagree that the implementation only changes when users change versions. There are fixes that have to be applied by users to libraries from time to time. I tend to agree with Emil's arguments here. Brian Wood Ebenezer Enterprises www.webEbenezer.net

6 6

[exception] updated in the trunk and in the release branch
by Emil Dotchevski 09 Apr '09

09 Apr '09

Two new functions added: current_exception_cast (http://svn.boost.org/svn/boost/trunk/libs/exception/doc/current_exception_c…) and current_exception_diagnostic_information (http://svn.boost.org/svn/boost/trunk/libs/exception/doc/current_exception_d….) There is a minor breaking change in the interface of the get_error_info function: it used to return shared_ptr, now it returns just a raw pointer: http://svn.boost.org/svn/boost/trunk/libs/exception/doc/get_error_info.html. This limits the lifetime of error_info objects to not exceed the lifetime of the exception object, which could make custom platform-specific error_info optimizations possible (the type of the pointee is guaranteed to be copyable, so if the user needs to hold on to it after the exception object has expired, they can simply copy it instead of relying on shared_ptr to keep it afloat.) -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

1 0

[Polynomial] Review Result
by John Maddock 09 Apr '09

09 Apr '09

Apologies for the delay in putting this together... First off I'd like to thank the author for submitting this for review - I wish all our SOC students were similarly diligent! :-) We received a number of reviews of this library, but none were in favor of acceptance in its current form, and most thought that there was still a fair bit of work to do to get the library into shape. However, most thought that the library could be accepted into Boost given sufficient changes/enhancements. Therefore the library is not accepted into Boost at this time, but I would like to encourage the author to continue to work on the library and resubmit at a future time. In no particular order the main review comments are summarized below: Principal comments: * Documentation, especially the background is inadequate and needs a good proofreading a) From the examples are nothing that a competent programmer couldn't figure out from the declarations. Some more interesting or useful examples would be nice, particularly for things like the special forms. It's not exactly clear what I would do with those functions. b) There is no documentation or references to the various algorithms used. Those, too, would be nice. c) Doc.html appear to have been created 'the Hard Way'. Would be much more useful and look nicer if produced with the Quickbook, Doxygen... toolchain. And make it maintainable by other people. * Use of constructors and assignment operators that modify their arguments isn't acceptable - best to find another interface for this. * Several reviewers noted that the code didn't build for them, in particular log2 isn't available on all platforms/compilers. * evaluate_polynomial() and evaluate_polynomial_faithfully() take their coefficient arguments in the opposite order of all the other functions/constructors in the library, without providing any reason for that choice. That's seems somewhat surprising. I'd suggest fixing that, or at the very least providing an argument in the documentation why this makes some sense. * Rename evaluate() to horner() and provide evaluate() as an inline call to horner(). * Rename evaluate_faithfully() to compensated_horner(). * Things that say "Be careful about this" generally need fixing. * It would be nice to have operator* and operator/ as well as *= and /=. * Considering they share the same core algorithm, it might be nice to have a function that could do division and return the remainder at the same time. Something like poly::divide(P &divisor, P &quotient, P &remainer) * FFTs are good for multiplying polynomials above a certain size, but they are rather heavy for small polynomials and can lead to unexpected crosstalk between terms. There should be an option for * that doesn't use the FFT, and it should be the default for small polynomials. * operator/= has a hardcoded "std::vector<double> new_coefficients" that later gets rounded?? This should be fixed to work with any type that fulfills the necessary conceptual requirements (and tested and documented what those requirements are - it would be nice if they were the same as the rest of Boost.Math). * The name FieldType is mathematically misleading since the instantiating type is very likely not to be a field (e.g. int or a multiple precision integer type). * the Polynomial class provides a fairly minimalist set of supported functions. This may well be deliberate (if so, apologies), but I would like to see a richer interface including such things as - content (gcd of coefficients, where that makes sense) - polynomial discriminant - resultant of 2 polynomials - evaluation of homogeneous polynomial ( f(x) = sum c_i x^i,f(a,b) = sum c_i a^i b^(d-i) ) - evaluation at a polynomial (f(g(x))) - Pseudo-division of polynomials - finding roots over C - finding roots over F_p - factorisation over Z - factorisation over F_p * We had one feature request for extending support to finite fields. * This constructor: template<typename U> polynomial(const U& v); had me a little confused at first - is there any advantage to making this a template rather than simply accepting a const FieldType& as the single argument? * It's not clear from the documentation what this constructor does: polynomial(InputIterator first1, InputIterator last1, InputIterator first2); It needs to clearly state the degree of the resulting polynomial and whether it passes through all/any of the points - in fact maybe the constructor should have a final parameter for the degree of the polynomial and use least-squares fitting when required? Likewise for the member function template<typename InputIterator> void interpolate(InputIterator first1, InputIterator last1, InputIterator first2); * Operators: the / and % operators need good descriptions of what they do, given that no exact division is possible. As someone else has already noted, a function to calculate divide and remainder in one step would be useful too. * GCD: presumably this is restricted to polynomials with integer coefficients? If so it should say so. * Evaluation: The docs should say what method is used for the evaluate_faithfully method and give a reference. Renaming as someone else suggested may be better too, but personally I'm easy either way on that. I'm not sure whether there should be an evaluate_by_preconditioning method, shouldn't the polynomial "know" that it has been preconditioned and react accordingly. I haven't looked/checked but do the usual arithmetic operators still work if the polynomial has been preconditioned? I assume probably not, but if that's the case there should be a stern warning to that effect, *and* checks in code to prevent us from doing something stupid :-) BTW, preconditioning can be applied to polynomials of any degree I believe it's just that it gets hard to implement in the generic case. In addition I'd like to see the evaluation functions templated, so that the type being evaluated can differ from FieldType - it would surely be quite common for example to create and manipulate polynomials with integer coefficients, but then want to evaluate on a floating point type. There is machinery in Boost.Math BTW to handle the mixed argument-promotion and calculation of the result type, let me know if you need help in using this. * Special Forms: the functions provided do *not* generate polynomials in the alternative forms, but rather generate the named polynomial of order N, which is rather less useful, but at the very least the docs need updating to reflect this. * test_arithmetics.cpp fails on cygwin: or at least it did once I added a using std::pow; to start of operator*= to get things compiling. * None of the code builds with msvc: there are a couple of issues here: friend polynomial<FieldType> boost::math::tools::gcd<>(polynomial<FieldType> u, polynomial<FieldType> v); Needs to be changed to: friend polynomial<FieldType> boost::math::tools::gcd<FieldType>(polynomial<FieldType> u, polynomial<FieldType> v); to get msvc to Grok the code. After that there are a bunch of failures due to the use of log2 which msvc doesn't support (and since it's not part of the std other compilers are likely to complain too). * I haven't looked too hard at the implementation, except to echo the comments posted previously that the Conceptual requirements for FieldType need documenting and *testing*. There are concept checking classes and archetypes in Boost.Math which may be of use here. Again, shout if you need help in figuring out how to use these. I did notice that operator*= for example uses std::complex<double> internally which effectively limits the precision that can be achieved - to be useful to me - and to replace the existing "implementation detail" polynomial class in Boost.Math - I would need the polynomial class to be usable with arbitrary precision types such as NTL::RR or mpfr_class. Also as previously noted, multiplication of small polynomials may well be more efficient with the "naive" algorithm, so some performance tests and experimenting is required here. Related to this, use of "round" should be restricted to types that are known to be integers? Regards, John Maddock Review Manager for Polynomial Library.

2 1

why the output is different?
by Dongfei Yin 09 Apr '09

09 Apr '09

I write some code like this: #include <iostream> using namespace std; class Base1 { public: typedef Base1 base; void f() { cout<<"Base1::f()"<<endl; } }; class Base2 { typedef Base2 base; public: void f() { cout<<"Base2::f()"<<endl; } }; class A : public Base1 , public Base2 { public: A() { base::f(); } }; void main() { A a; } the output is : Base1::f() But if the definition of class A modified like this, class A : public Base2 , public Base1 { public: A() { base::f(); } }; the out will be: Base2::f() the output depends on the sequence of base class, that means the "typedef" in base class is unreliable. complier gives no warning. I try these code at both VS2005 and VS2008, the result are same.

2 1

[math] Help needed porting to AMD64/Linux platforms
by John Maddock 09 Apr '09

09 Apr '09

Folks, I'm still having trouble with some failures that appear to be specific to Linux on AMD64, if anyone with access to such a platform can help me out I'd be most grateful. You can test whether your machine exhibits the issue by: cd into libs/math/test and bjam gcc test_hypergeometric_dist1 If that fails, then I'm looking for the output from the following program to try and track down the cause of the error (caution this will be quite voluminous!): #define BOOST_MATH_INSTRUMENT #include "boost/math/distributions.hpp" int main() { double x = 30520, r = 130605, n = 130605, N = 523360, p = 1.315394088731268169855067478460234e-53, q = 1; boost::math::hypergeometric_distribution<> hyp(r, n, N); unsigned x_found = quantile(hyp, p); BOOST_MATH_INSTRUMENT_VARIABLE(x_found); return 0; } Perplexed yours, John.

3 5

[proto] _value doesn't enforce zero arity
by troy d. straszheim 09 Apr '09

09 Apr '09

I see some funny behavior when misusing _value: #include <boost/proto/proto.hpp> namespace bp = boost::proto; int main(int, char**) { bp::terminal<int>::type t = {0}; bp::terminal<int>::type hmm = bp::value(t * 2); bp::terminal<int>::type uhm = bp::_value()(t * 2); bp::terminal<const int&>::type hrm = bp::value(2 * t); bp::terminal<const int&>::type feh = bp::_value()(2 * t); } Which does compile.. but the docs say that _value requires an expression of zero arity. Here as usual is an attempt at a patch, to see if I'm learning anything: BOOST_MPL_ASSERT_RELATION( remove_reference<Expr>::type::proto_arity_c, ==, 0L); in the body of struct _value in transform/args.hpp. How'd I do? -t

6 16

[Testing] Sandia-tiger-x86 intel-darwin compiler crashes
by Emil Dotchevski 08 Apr '09

08 Apr '09

I'm wondering if someone with access to that compiler can help me diagnose the problem and/or submit compiler bug reports. Here are the tests that seem to crash the compiler: http://www.boost.org/development/tests/trunk/developer/output/Sandia-tiger-… http://www.boost.org/development/tests/trunk/developer/output/Sandia-tiger-… This one has no log, but might not be a crash: http://www.boost.org/development/tests/trunk/developer/output/Sandia-tiger-… Thanks, Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

1 0

Patches in trac...
by Marshall Clow 08 Apr '09

08 Apr '09

At BoostCon last year, we had a discussion about the Trac system. One of the things that we discussed was the fact that the "Patches" tag in Trac was really a bad way to label things. Don't get me wrong - patches are a good thing. However, if a submitted patch fixes a problem, it should be categorized as a "bug report" with a fix attached. And if a patch adds new functionality, it should be categorized as a "feature request" with a proposed implementation attached. The conclusion that was reached at the end of the discussion was that we wanted to get rid of the "Patches" label for Trac tickets, and to move all the existing patches to either "Bugs" or "Feature Requests". I am proposing that this happen immediately after the release of version 1.39 - or immediately after BoostCon, say. What do people think? -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

2 2

Moving property map library into a directory
by Jeremiah Willcock 08 Apr '09

08 Apr '09

The Boost Property Map Library (property_map) currently consists of a number of files in the top-level boost/ include directory. It would probably be better to move all of them into a subdirectory, especially as Nick Edmonds and I will be adding new files and directories into that library soon. Should I do that move? I will update Boost.Graph; are there other libraries in Boost that use property_map? -- Jeremiah Willcock

4 4

Re: [boost] Compilation errors upgrading boost from 1.34 to 1.37 (Windows)
by tinkertom 08 Apr '09

08 Apr '09

I figured out what my problem was: When constructing a boost::mutex::scoped_lock in 1.33 the second parameter is a boolean. In 1.38, boost::mutex::scoped_lock (defined as unique_lock) constructor is overloaded using different types as the initial lock state instead of a single constructor with a boolean. In the constructor I now have to use adopt_lock_t, defer_lock_t, or try_to_lock_t as the second parameter. In 1.33: boost::mutex mtx; boost::mutex::scoped_lock lock(mtx, false); In 1.38 now looks like: boost::mutex mtx; boost::mutex::scoped_lock lock(mtx, defer_lock_t()); -Tom -- View this message in context: http://www.nabble.com/Compilation-errors-upgrading-boost-from-1.34-to-1.37-… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

Shorter link to getting started
by Vladimir Prus 08 Apr '09

08 Apr '09

I would like to modify the configure script to mention getting started, so that user knows where to look for information, but unfortunately, the current URL is a bit long: http://www.boost.org/doc/libs/1_38_0/more/getting_started/unix-variants.html It is 77 characters, so it does not leave any space for any other text. Can the website administrators arrange for some shorter redirect to be available? Say http://www.boost.org/getting_started/unix-variants.html ? Thanks, Volodya

4 3

[data_binding] Lets bind data
by Kasra 08 Apr '09

08 Apr '09

Hi, I am looking for interest in data_binding techniques in C++. The idea is to have a class that could bind to a list of data and when ever any of them is changed the value of the binder is changed too: data_bindee<mpz_class> x; data_bindee<mpz_class> y; typedef tuple<mpz_class,mpz_class> my_bind_tuple_type; struct my_bind_pred_type { template<typename BinderT> void operator(BinderT& me, my_bind_tuple_typeT t) { me.x = get<0>(t); me.y = 2 * get<0>(t); } }; data_binder<struct { mpz_class x,y; }, my_bind_tuple_type, my_bind_pred_type> point(x, y); // when ever data of x and y is changed the value of point // is updated too. Any suggestions?? Kasra With Best Regards -- Kasra Nassiri

1 0

Preliminary progress on Boost.Python py3k support
by Haoyu Bai 08 Apr '09

08 Apr '09

Hi, I did some preliminary work on BPL py3k support in these days. With Troy's help we have a py3k SVN tree in sandbox now, which is branched from trunk. I also tried to compile BPL with Python 3, and by following the error report of the compiler, I did some patch - now we have 14 .cpp files out of 28 in total can be compiled. The patch is committed, you can see it here: [2]. Please point me out if the code has something don't conform to Boost coding policy. There's also something interesting, maybe a bug I caught, for example: (Search the changeset to see details) 39 // XXX(bhy) Potentional memory leak here since PyObject_GetAttrString returns a new reference 40 // const char *mod = PyString_AsString(PyObject_GetAttrString( self_, const_cast<char*>("__module__"))); 41 PyObject *mod = PyObject_GetAttrString( self_, "__module__"); Also I found some potential problem with Py_ssize_t, I will take this as a chance to fix them. The biggest problem I see still is the "Text Vs. Data Instead Of Unicode Vs. 8-bit" in py3k. As we discussed and the suggestion by Niall [3], we have a clear solution for this and I will work towarding this. The other changes in py3k such as PyObject_HEAD change, int type removal and unbound method removal also affected Boost.Python's code, but they don't require logical change of BPL code and easy to handle. Hopefully in the end of this summer, we will have a Boost.Python library with Python 3 support! Thanks again for many people's help! References: [1] https://svn.boost.org/trac/boost/browser/sandbox-branches [2] https://svn.boost.org/trac/boost/changeset/52118 [3] “Nabble - Python - c++-sig - Some thoughts on py3k support,” http://www.nabble.com/Some-thoughts-on-py3k-support-td22564813.html. -- Haoyu Bai

2 1