- Boost - lists.boost.org

Boostcon 2008- should I book my flights?
by Terence Wilson 01 Feb '08

01 Feb '08

Hello all, Can anyone give me a status update, is registration open yet? Thanks, Terence

3 4

[trac][wiki] Correct wiki for development
by Jonathan Turkanis 01 Feb '08

01 Feb '08

Hi, I'd like to prepare some notes about future development of Boost.Iostreams and make them available in a shared location. I'm wondering if I should use the trac wiki or the user wiki at crystalclearsoftware.com. I'm inclined to say it should be the trac wiki, but I don't see anything similar there, except for "Boost.Graph Version 2", under "Projects" on the home page. Can I just create a Boost.Iostreams link under "Projects"? Thanks, -- Jonathan Turkanis CodeRage http://www.coderage.com

2 1

[1.35] proposal to add two platforms as release platforms for 1.35
by Boris Gubenko 01 Feb '08

01 Feb '08

I'd like to propose two additional platforms as release platforms for 1.35: 1. gcc-3.4.6_linux_ia64 (runner id: linux_ia64_gcc). It is all green on the trunk with Interprocess library marked as n/a. 2. gcc-4.2.1_hpux_ia64 (runner id: HP-UX_ia64_gcc). Three libraries are currently failing on trunk: Interprocess, Regex and Serialization. . Interprocess library: as for other HP platforms, this library will have to be marked n/a. I don't believe I'll have time to investigate failures and propose fixes in the 1.35 timeframe. . Regex library: fails because of the problem in <http://lists.boost.org/Archives/boost/2008/01/132318.php> The problem does not exist in release branch (and is fixed in trunk by <http://svn.boost.org/trac/boost/changeset/42745>) . Serialization library: test_exported* group of tests fail the same way they fail on all the platforms with gcc 4.1 and higher, including BGD-Ubuntu, which is a release platform for 1.35. I assume, this issue will be resolved before 1.35 is released and resolution will automatically cover gcc-4.2.1_hpux_ia64 as well. If I get a permission, I'll start testing these platform on the release branch, in addition to continuing testing on trunk. Thanks, Boris

3 3

Errors in status/explicit-failures-markup.xml?
by Jens Seidel 01 Feb '08

01 Feb '08

Hi, I noticed that status/explicit-failures-markup.xml seems to contain some errors. I really wonder e.g. about "These compilers are unfortunately able to correctly compile". It looks like there is a "not" missing in this sentence (multiple times!). Jens

4 4

Document python::handle behavior
by Neal Becker 01 Feb '08

01 Feb '08

To allow handle to work with various PyObject compatible types, handle relies on specializations of base_type_traits. I don't think that's mentioned in the reference docs, and leads to mysterious compile errors to the un-initiated.

2 1

Boost serialization DLL issues on x64 platforms
by Terence Wilson 01 Feb '08

01 Feb '08

Folks, I've finally found the cause of a problem that has been tripping us up for some time. We have a Windows application that we build for IA32 and x64. Naturally the IA32 version links against 32-bit import libraries and the x64 64-bit import libraries. But here's the rub: Boost generates output binaries with the same name for both platforms: bjam -sTOOLS=vc-8_0 bjam -sTOOLS=vc-8_0-amd64 both result in boost_serialization-vc80-mt-gd-1_33_1.lib boost_serialization-vc80-mt-gd-1_33_1.dll being created (among other things). Now because the Windows loader simply searches the PATH for the first DLL that matches the name of the import library, an x64 application linked against the x64 import library for Boost Serialization might load the IA32 version at runtime. Most other tool vendors solve this one by attaching a 'x64' suffix to the import and DLL filenames. However, despite what the Boost Build documentation says, the tool name "vc-8_0-amd64" is not used when building the DLL file name. We get stuck with the same filename for both platforms. Simply rename the files? Nope, the binary import library contains decorated names prefixed with the DLL name. The best fix would be to make bjam do the right thing: boost_serialization-vc80-amd64-mt-gd-1_33_1.lib boost_serialization-vc80-amd64-mt-gd-1_33_1.dll Am I missing something here? Thanks in advance, Terence

1 0

Re: [boost] Boost pool allocator slower than STL allocator
by Robin 01 Feb '08

01 Feb '08

Hi I've been testing out boost pool allocator, and my results shows it's slower than the STL allocator. I'm using VSNet 2005 SP1. See test code below. Also, on a separate issue, I notice the pool_allocator uses a singleton with static member in a function (Meyer's singleton). While this avoid the static construction issue, it does not free the memory until the application quits. This would work fine only POD data, if the dtor depends on a system in the application, it won't work. Shouldn't there be a pool allocator which can be used like the object_pool? Robin Test code -------- With boost pool, timing on average is (0.03) vs STL (0.02) seconds in release mode. In debug mode, its boost (0.99) vs STL (0.8) #include <boost/pool/pool_alloc.hpp> #include <iostream> #include <vector> using namespace std; class A { int x, y; public: A () : x (0), y (0) {} }; #include <windows.h> class Timer { public: Timer() { reset(); } /// reset() makes the timer start over counting from 0.0 seconds. void reset() { unsigned __int64 pf; QueryPerformanceFrequency( (LARGE_INTEGER *)&pf ); freq_ = 1.0 / (double)pf; QueryPerformanceCounter( (LARGE_INTEGER *)&baseTime_ ); } /// seconds() returns the number of seconds (to very high resolution) /// elapsed since the timer was last created or reset(). double seconds() { unsigned __int64 val; QueryPerformanceCounter( (LARGE_INTEGER *)&val ); return (val - baseTime_) * freq_; } /// seconds() returns the number of milliseconds (to very high resolution) /// elapsed since the timer was last created or reset(). double milliseconds() { return seconds() * 1000.0; } private: double freq_; unsigned __int64 baseTime_; }; int main () { Timer timer; for (int i = 0; i < 10; ++i) { // Switch allocators // typedef vector <A> VectorA; typedef vector <A, boost::pool_allocator <A> > VectorA; VectorA vectorA; double startTime = timer.seconds (); for (int jj = 0; jj < 1000000; ++jj) { vectorA.push_back (A()); } double endTime = timer.seconds (); cout << "Time taken is " << i << " - " << endTime - startTime << endl; } return 0; } > On 30/12/2007, Robin <al(a)cyberversion.com> wrote: > >> _______________________________________________ >> Unsubscribe & other changes: >> http://lists.boost.org/mailman/listinfo.cgi/boost >> > > It seems your message got sent without any body text.

4 4

BoostBook/QuickBook
by brook＠biology.nmsu.edu 01 Feb '08

01 Feb '08

I am ready to markup the documentation for a library, but am lost with respect to getting started with the documentation tools BoostBook and QuickBook. I think I can understand the markup itself, but as far as I can tell there is no documentation on actually building and using the tools, the files produced, etc. Any guidelines would be very appreciated. Cheers, Brook

3 2

Re: [boost] [review] Review of Flyweight library started January 21 and still running!: Alternative/simpler configuration interface
by "JOAQUIN LOPEZ MU?Z" 31 Jan '08

31 Jan '08

"vicente.botet" ha escrito: > Maybe this should be managed orthogonally but, can the current design > managewith persistent flyweights? > Which policies will we reused and which ones added? Hi, Here is a basic example of how to make a persistent factory (not to be confounded with serializaing flyweight objects, which is an entirely different matter). The factory below is based on a std::set and loads and saves its contents upon construction/destruction: template<typename Entry,typename Value,const char* Filename> class serialized_set_factory_class: public boost::flyweights::factory_marker { typedef std::set<Entry,std::less<Value> > container_type; public: typedef typename container_type::iterator handle_type; typedef typename container_type::value_type entry_type; serialized_set_factory_class() { std::ifstream ifs(Filename); if(ifs){ boost::archive::text_iarchive ia(ifs); typename container_type::size_type s=0; ia>>s; for(typename container_type::size_type n=s;n--;){ Value v; ia>>v; cont.insert(cont.end(),Entry(v)); } std::clog<<"loaded "<<s<<" entries from "<<Filename<<"\n"; } } ~serialized_set_factory_class() { std::ofstream ofs(Filename); boost::archive::text_oarchive oa(ofs); typename container_type::size_type s=cont.size(); oa<<s; for(typename container_type::iterator it=cont.begin (),it_end=cont.end(); it!=it_end;++it){ oa<<static_cast<const Value&>(*it); } std::clog<<"saved "<<s<<" entries to "<<Filename<<"\n"; } handle_type insert(const entry_type& x) { return cont.insert(x).first; } void erase(handle_type h) { cont.erase(h); } const entry_type& entry(handle_type h){return *h;} private: container_type cont; }; template<const char* Filename> struct serialized_set_factory:boost::flyweights::factory_marker { template<typename Entry,typename Value> struct apply { typedef serialized_set_factory_class< Entry,Value,Filename > type; }; }; We can use it just like this: extern const char filename[]="fw.bd"; typedef flyweight< std::string, serialized_set_factory<filename>, no_tracking > fw_t; Note that we're using no_tracking: if the normal refcounted tracking were used, there would be no elements remaining in the factory by the time it is destroyed, and hence nothing to persist. The attached snippet exercises these ideas. It compiles and runs OK with GCC 3.4.4 under Cygwin. You need to link Boost.Serialization. Hope this addresses your concerns about the potential of the lib to accomodate persistent factories. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[build][wave] tools/wave link failure
by Stefan Seefeld 31 Jan '08

31 Jan '08

I have talked to multiple developers about this, yet none has assumed responsibility, so I'm not sure where to raise this: Building inside boost/tool/wave/build on trunk fails for me due to a link error, since wave wants to link to boost_thread, but doesn't link to -lpthread. (This is the default toolchain on my Fedora 8 box, i.e. GCC.) I'm not sure where the -lpthread needs to be added (I added it manually to the link command and it succeeded), or in fact, why wave links to boost_thread at all. It doesn't use threads underneath, or does it ? Another point I just touched on with Volodya on IRC is that all tools are built against the static boost libraries, presumably because Windows doesn't have the equivalent of -rpath. Could that be changed at least for non-Windows platforms that would allow it ? Thanks, Stefan PS: Thanks for changing the default to only build a single variant. It's *much* more pleasant to work with trunk now ! -- ...ich hab' noch einen Koffer in Berlin...

3 6