April 2005 - Boost - lists.boost.org

[boost] [shared_ptr] m68k and ia64 implementations by Ben Hutchings, RFC
by Peter Dimov 07 Apr '05

07 Apr '05

Ben Hutchings has kindly contributed the attached sp_counted_base implementations for g++ on IA64 and 68020+. The IA64 version of decrement should be changed to: Ben Hutchings wrote: >>> It isn't a memory barrier (unless you add .acq or .rel to it) but I >>> don't believe a barrier is needed for the simple increment and >>> decrement operations. It is always atomic, like lock xadd. >> >> For increment, no. For decrement, yes. It needs to be a release when >> the new value is nonzero, > > Oh yes, of course it does. > >> and an acquire when the new value is zero. > > Hmm, tricky. There would be need to be another instruction afterward > that creates the acquire barrier. Maybe this would do: > > __asm__ (" fetchaddl.rel %0=[%4],-1 \n" > " cmp.eq %2,%3=1,%0 \n" > "(%2) ldl.acq %0=[%4] " : > "=r"(rv), "=m"(*pw), "=c", "=c" : > "r"(pw) : > ); > > Don't ask me whether that's the most efficient way to do this! In your (Boost developers) opinion, 1. Do we need a platform-specific version for 68020+ at all? (It is my understanding that threads aren't very popular there ;-) but I may be wrong) 2. Should we try to get an IA64 version in 1.33 or should this be postponed for 1.34?

3 3

Lock-free shared_ptr on g++/x86, test/review needed
by Peter Dimov 07 Apr '05

07 Apr '05

I just added boost/detail/sp_counted_base_gcc_x86.hpp to the CVS. It is not enabled yet, i.e. sp_counted_base.hpp will not include it automatically. If you are interested, please take a look at the file and give it a test run. The easiest way to enable it is to do #include <boost/detail/sp_counted_base_gcc_x86.hpp> #define BOOST_DETAIL_SP_COUNTED_BASE_HPP_INCLUDED (or to copy it over sp_counted_base.hpp) before including shared_ptr.hpp. Any comments appreciated. As usual, thanks to Alexander Terekhov for all the help and patience. -- Peter Dimov http://www.pdimov.com

3 28

BOOST_STATIC_ASSERT and g++ 3.4
by Angus Leeming 07 Apr '05

07 Apr '05

The code below works as expected when compiled with g++ 3.4 as: $ g++ -I$HOME/boost/cvs -g -W -Wall -o static_test2 static_test2.cpp but it also produces this warning: static_test2.cpp: In static member function `static foo foo::set()': static_test2.cpp:15: warning: no return statement in function returning non-void Clearly, I could add a spurious return statement after the assert, but isn't g++ being a little over eager here? Can the warning not be silenced by the library? Regards, Angus #include <boost/static_assert.hpp> #include <iostream> class foo { public: enum state { state1, state2, state3 }; // Only the specializations (below) of this template will compile. template <int N> static foo set() { BOOST_STATIC_ASSERT( N == state2 ); } private: foo(state) { std::cout << "foo" << std::endl; } }; template <> foo foo::set<foo::state2>() { return foo::state2; } template <> foo foo::set<foo::state3>() { return foo::state3; } int main() { // Compiles, as expected. foo f1 = foo::set<foo::state2>(); foo f2(foo::set<foo::state2>()); // Fail to compile, as expected. // foo f3 = foo::set<foo::state1>(); // foo f4(foo::set<foo::state1>()); return 0; }

2 5

[Test] IsDebuggerPresent() failures on CodeWarrior 9.4 for Windows
by Doug Gregor 07 Apr '05

07 Apr '05

Many Boost tests are failing in the Test library on CW 9.4 due to the lack of IsDebuggerPresent(). Gennadiy? Doug

5 9

[Boost-bugs] [ boost-Bugs-1178259 ] Muss of "host" and "target"
by SourceForge.net 07 Apr '05

07 Apr '05

Bugs item #1178259, was opened at 2005-04-06 21:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1178259&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Muss of "host" and "target" Initial Comment: When I try build boost for crossplatform compiler (i386-mingw32msvc-gcc) on linux host. When I set tool to mingw, jam try build ".so" libraries (I use hack for set $OBJCOPY to i386-mingw32msvc-objcopy). When I set WINNT variable, jam try use windows directory delimiter. And in any case it fails build ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1178259&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[filesystem] large file support detection broken on Solaris (possibly others)
by Caleb Epstein 06 Apr '05

06 Apr '05

The file "operations_posix_windows.cpp" in the filesystem library defines the macro _FILE_OFFSET_BITS=64 in an attempt to enable large file support on POSIX platforms. Unfortunately, this definition comes too late for it to work properly on Solaris, so Boost.Filesystem incorrectly reports that large file support is unavailable (cf. http://tinyurl.com/44jvy) The _FILE_OFFSET_BITS macro definition needs to happen before the inclusion of <sys/types.h>, but this system header is being pulled in courtesy of <boost/config.hpp> which is included by <boost/filesystem/config.hpp>. I'm attaching the output of g++ -H on this file which lists header files as they are included, along with a nesting depth so you can see what is going on. Can this macro definition just be moved before any other includes? I think it should be harmless on any non-POSIX platform. I think defining it before ANY header is included or on the compiler command-line is the only way for to make this work reliably. -- Caleb Epstein caleb dot epstein at gmail dot com

2 6

[Boost-bugs] [ boost-Bugs-1178092 ] std::locale construction slows down convert_to_lower()
by SourceForge.net 06 Apr '05

06 Apr '05

Bugs item #1178092, was opened at 2005-04-07 00:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1178092&group_… Category: date_time Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrey Melnikov (nimnul) Assigned to: Jeff Garland (az_sw_dude) Summary: std::locale construction slows down convert_to_lower() Initial Comment: Replacing std::locale loc(""); with static const std::locale loc(""); improves speed a lot in VC7.1 and VC8.0 beta ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1178092&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Bugs-1178068 ] Past-the-end tokenization in parse_date()
by SourceForge.net 06 Apr '05

06 Apr '05

Bugs item #1178068, was opened at 2005-04-06 23:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1178068&group_… Category: date_time Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrey Melnikov (nimnul) Assigned to: Jeff Garland (az_sw_dude) Summary: Past-the-end tokenization in parse_date() Initial Comment: Loop termination condition is wrong. Comma is used instead of and operator: for(boost::tokenizer<>::iterator beg=tok.begin(); beg!=tok.end(), pos < spec_str.size(); ++beg, ++pos) Should read as for(boost::tokenizer<>::iterator beg=tok.begin(); beg!=tok.end() && pos < spec_str.size(); ++beg, ++pos) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1178068&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Proposed revised voting procedures
by christopher diggins 06 Apr '05

06 Apr '05

Still today, what variations should be merged has not been fully agreed upon. A continually changing ballot is neither fair nor accurate. In order to try and get this process out of the mud I propose we hold a new vote, with the following conditions (these are simply suggestions for guidelines this so that we have something to work with, I don't care if it is followed or not): 1) we agree for once and for all what the "variations" are, (it should be pretty obvious now) 2) the new list is posted with new numbers (and in order!), but *no* distinction is made for the variations (i.e. a ballot does not contain 51a, just 51) 3) the precise variation is chosen once a winner is chosen by the group working in conjunction with the logo maker. Just like what happens after a boost library is accepted for inclusion. 4) I think we should start the vote next monday, and go until friday. 5) new logo submissions can be enterered until sunday at midnight 6) the tally should not be displayed while the vote is going on. 7) votes can not be revised 8) ballots are made in the form readable by Jason Hise's computer program 9) the votes will be posted on line immediately after the vote closes, so that whoever is impatient like me, can do their own preemptive tally. Joel and Kalin has put a lot of effort into the vote up to now and are fair and open-minded. I suggest we elect them as cheerful benevolent dictators of the revised voting process. I think some leadership would make things work a little more smoothly. In other words, they will decide on the new voting guidelines with or without input from the community at their own disgression. Or they may choose not to, such being the nature of a dictatorship ;-) Christopher Diggins

2 1

Re: [boost] (Named) Parameter Library
by Cromwell Enage 06 Apr '05

06 Apr '05

The proposed changes should be okay with me. Was there anything wrong with my proposed extensions to provide the ability to return the type of the parameter argument? How should one improve on them, based on the new codebase? Cromwell D. Enage __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs

1 0