- Boost - lists.boost.org

[intrusive] Last step for Tru64/CXX support.
by Markus Schöpflin 19 Oct '07

19 Oct '07

Hello, by now I have intrusive pass all regression tests locally. There is one modification left, which I'm not sure off, therefore I would like to ask for some advice before committing. All remaining failures are due to the implementation of offset_from_pointer_to_member(): template<class Parent, class Member> inline std::size_t offset_from_pointer_to_member( const Member Parent::* ptr_to_member) { #if ... // 1 return *(const std::ptrdiff_t*)(void*)&ptr_to_member; #elif ... // 2 const Parent * const parent = 0; const char *const member = reinterpret_cast<const char*>(&(parent->*ptr_to_member)); return std::size_t(member - reinterpret_cast<const char*>(parent)); #else ... // 3 return (*(const std::ptrdiff_t*)(void*)&ptr_to_member) - 1; #endif } Currently, variant #3 is chosen, which is obviously wrong. I tried both variant #1 and #2, and both seem to work for CXX. (All tests pass, no crashes.) So which variant should I choose? TIA, Markus

2 2

[Thread] Failed to Link libboost_thread-vc80-mt-1_34_1.lib for Itanium
by Djalma Rosa dos Santos Filho 19 Oct '07

19 Oct '07

Hi, I've taken the thread_specific_ptr for a quick bug fixing, the problem is that now I am not being able to build the application for IA64 anymore (x64/x86 versions are working smoothly for weeks). I am using Visual Studio 2005 SP1 and got the following errors and warnings: >libboost_thread-vc80-mt-1_34_1.lib(tss_pe.obj) : warning LNK4078: multiple '.CRT' sections found with different attributes (C0408040) >libboost_thread-vc80-mt-1_34_1.lib(tss_pe.obj) : error LNK2003: gp relative fixup to symbol not in short data section '_tls_used' >LINK : fatal error LNK1165: link failed because of fixup errors Can anyone shed light on this, please? Is there a chance that I made a mistake in the boost building for ia64? Any help will be appreciated. TIA Djalma

1 1

boost range doc error?
by Neal Becker 19 Oct '07

19 Oct '07

The (recent svn) docs for range talk about boost_range_{begin,end,size}. Should't that be just range_{begin,end,size}? Method 2: provide free-standing functions and specialize metafunctions This procedure assumes that you cannot (or do not wish to) change the types that should be made conformant to a Range concept. If this is not true, see method 1. The primary templates in this library are implemented such that certain functions are found via argument-dependent-lookup (ADL). Below is given an overview of which free-standing functions a class must specify to be useable as a certain Range concept. Let x be a variable (const or mutable) of the class in question. Function Related concept boost_range_begin(x) Single Pass Range boost_range_end(x) Single Pass Range boost_range_size(x) Forward Range boost_range_begin() and boost_range_end() must be overloaded for both const and mutable reference arguments.

2 1

[math-toolkit] Expected release?
by Sohail Somani 19 Oct '07

19 Oct '07

Hi, When is the expected release for the Boost.Math toolkit that was recently accepted? Thanks, Sohail

5 10

Re: [boost] [review] Exception
by brass goowy 19 Oct '07

19 Oct '07

Emil Dotchevski wrote: >> 2. shared_ptr<> may be replaced by intrusive_ptr<> or home made equivalent. >> This (a) reduces dependency on other Boost part (shared_ptr does depend on >> quite few other libs) and (b) the atomic locking used by shared_ptr would be >> eliminated. This would help a little bit on multiprocessor systems - lock >> may be hundredths of cycles and during the time access to the memory bus is >> disabled. >(a) is a valid concern, OTOH shared_ptr is such a low level component >of Boost that -- as careful as I am in avoiding physical coupling -- I >don't consider it a real dependency; rather, it's a tool for avoiding >dependencies. Any reason for not using intrusive_ptr? Shared_ptr may be a low level part of Boost, but I'm not sure it should be lower level than this library. A library like this is overdue in my opinion. Brian Wood Ebenezer Enterprises www.webebenezer.net

3 3

PATCH: Various error and warning corrections (g++ 4.3.0 snapshot)
by Jens Seidel 19 Oct '07

19 Oct '07

Hi, I tried to compile most of Boost's code from trunk by including all header files (except */detail/* ones as I noticed that these are internal ones) together with a int main() {} body :-) I still need to improve my script a little bit but nevertheless I found still many errors and a few warnings. I attached a patch which fixes the most obvious ones. Affected libraries: archive asio bimap circular_buffer date_time format fusion logic numeric and token_functions.hpp (don't know to which library it belongs). I used the following g++ snapshot g++ (Debian 20070916-1) 4.3.0 20070916 (experimental) [trunk revision 128522] with the flags -Wall -pedantic -Wno-uninitialized -Wcast-align -Wpointer-arith -Wextra I really wonder why broken code can be committed. I will try to automate my test even more so that a svn pre commit hook script can be used ... If there are questions about the compiler output without the patch I can send you the necessary information. PS: I hope this is the right list. The "Welcome to the \"Boost\" mailing list" mail contained "This list is for discussion of the www.boost.org web site and its contents." and nothing about development of Boost. Jens

2 1

Vera++
by Maciej Sobczak 19 Oct '07

19 Oct '07

I'm pleased to announce the availability of Vera++: http://www.inspirel.com/vera/ Vera++ is a programmable tool for verification, analysis and transformation of C++ source code. It relies on embedded scripting language for rule definition to provide maximum flexibility and extensibility. This tool might be of interest to the Boost community for two reasons: First, it uses boost::wave for parsing code. I would like to thank Hartmut Kaiser for this masterpiece. The second reason is this: http://www.inspirel.com/vera/ce/demo.html ;-) -- Maciej Sobczak * www.msobczak.com * www.inspirel.com

12 23

[Probability] manuscript and release of v0.4
by Brook Milligan 18 Oct '07

18 Oct '07

I have now released version 0.4 of the Probability library. As usual, it is available either from the Boost Vault (boost.probability-0.4.tar.gz) or from http://biology.nmsu.edu/software/probability/ The main difference from earlier versions is that a power function, pow(), is now available for both probability and likelihood types. In addition, several of the operators involving mixed domains or value types are handled correctly now, and the testing is even more thorough than before. More importantly, though, I have written a manuscript describing the motivation and conceptual framework for the library in greater detail than is given at the site above. I would welcome anyone who wishes to review the manuscript to do so. Please let me know and I will forward a copy. Finally, I would appreciate any comments on the existing code, compiler incompatibilities, etc. I think that this can be a valuable addition to Boost, and would like the feedback necessary to move it toward that goal. Cheers, Brook

2 1

An attempt to generalize the Pimpl idom with properly separated interface and implementation
by Vladimir Batov 18 Oct '07

18 Oct '07

Given I've been using this Pimpl idiom quite extensively lately I've noticed writing the same scaffolding over and over again. Being the lazy bugger as I am I looked around if there was anything available. Turns out there were proposals floated around (like Asger Mangaard's dated around May 2006). However, I did not see anything that would preserve idiom's original purpose/value - the separation of interface and implementation. So, I jogged something with that in mind. That seemed to do the job for me as something tedious like class Test { public: Test (int); Test (int, int); int get() const; bool operator==(Test const& p) const { return impl_ == p.impl_; } bool operator!=(Test const& p) const { return impl_ != p.impl_; } operator bool() const { return implementation_; } void swap(pimpl& that) { impl_.swap(that.impl_); } private: struct Internal; boost::shared_ptr<Internal> impl_; }; shrunk down do pure interface struct Test : public boost::pimpl<Test> { Test (int); Test (int, int); int get() const; }; with implementation details safely tacked away in an implementation file. However, it looked suspiciously easy. So, I am throwing it out for all the respected community to see (uploaded as vb_pimpl_0.1.zip) and to set me straight. Is there any value in that basic idea? Don't hold back your criticism. Regards, Vladimir.

9 21

Re: [boost] impl_ptr
by Peter Dimov 18 Oct '07

18 Oct '07

Vladimir Batov: > Peter, > > I am planning to re-visit and probably modify your impl_ptr. Namely, I > feel I need changes to op=() and op==(). Then, I'll be posting that in > addition to my thin pimpl wrapper. So, I have a few questions I was > hoping you might be kind to answer. > > 1. How do I do that properly so that I do not violate any copyrights of > your? > 2. Your code has non-boost disclaimer. Do you think we could change it to > the standard Boost v1.0 disclaimer? I hereby release the contents of the impl_ptr folder in the Yahoo groups file area under the Boost Software License, version 1.0. You can now use it as a starting point for a future Boost contribution of yours.

1 0