- Boost - lists.preview.boost.org

Fwd: [graph,python] 1.31.0 failures on MSVC6 [fix]
by Jeremy Siek 06 Feb '04

06 Feb '04

Begin forwarded message: > From: Jeremy Siek <jsiek(a)osl.iu.edu> > Date: February 6, 2004 4:42:48 PM EST > To: Raoul Gough <RaoulGough(a)yahoo.co.uk> > Subject: Re: [graph,python] 1.31.0 failures on MSVC6 [fix] > > Hi Raoul, > > Thanks! I've applied your patch. > > Cheers, > Jeremy > > On Feb 6, 2004, at 3:45 PM, Raoul Gough wrote: > >> Raoul Gough <RaoulGough(a)yahoo.co.uk> writes: >> >>> I note from the current regression test results at >>> http://boost.sourceforge.net/regression-logs/cs-win32.html that >>> adjacency_matrix_test is a "Fail" on MSVC++6, along with all but one >>> of the other graph library tests. This seems to have the knock-on >>> effect of breaking one of the Boost.Python modules, inheritance.cpp. >> >> Compile errors have been confirmed by various people. The fix to make >> inheritance.cpp work turns out to be very simple (patch below). Looks >> like the problem was introduced in revision 1.112.2.1 (21 Jan 2004). >> >> ----8<---- Patch for 1.112.2.3 (Version_1_31_0) -----8<---- >> >> Index: adjacency_list.hpp >> =================================================================== >> RCS file: /cvsroot/boost/boost/boost/graph/detail/adjacency_list.hpp,v >> retrieving revision 1.112.2.3 >> diff -w -d -u -r1.112.2.3 adjacency_list.hpp >> --- adjacency_list.hpp 2 Feb 2004 14:25:51 -0000 1.112.2.3 >> +++ adjacency_list.hpp 6 Feb 2004 20:29:13 -0000 >> @@ -1019,8 +1019,14 @@ >> // Placement of these overloaded remove_edge() functions >> // inside the class avoids a VC++ bug. >> >> + // O(E/V) or O(log(E/V)) >> void >> - remove_edge(typename Config::edge_descriptor e); >> + remove_edge(typename Config::edge_descriptor e) >> + { >> + typedef typename Config::graph_type graph_type; >> + graph_type& g = static_cast<graph_type&>(*this); >> + boost::remove_edge(source(e, g), target(e, g), *this); >> + } >> >> inline void >> remove_edge(typename Config::out_edge_iterator iter) >> @@ -1045,15 +1051,6 @@ >> } >> >> // O(E/V) or O(log(E/V)) >> - template <class Config> >> - inline void >> - >> bidirectional_graph_helper_with_property<Config>:: >> remove_edge(typename Config::edge_descriptor e) >> - { >> - typedef typename Config::graph_type graph_type; >> - graph_type& g = static_cast<graph_type&>(*this); >> - boost::remove_edge(source(e, g), target(e, g), *this); >> - } >> - // O(E/V) or O(log(E/V)) >> template <class EdgeOrIter, class Config> >> inline void >> remove_edge(EdgeOrIter e, >> >> -- >> Raoul Gough. >> export LESS='-X' >> > _______________________________________________ > Jeremy Siek <jsiek(a)osl.iu.edu> > http://www.osl.iu.edu.edu/~jsiek > Ph.D. Student, Indiana University Bloomington > C++ Booster (http://www.boost.org) > Office phone: (812) 856-1820 > _______________________________________________ > > _______________________________________________ Jeremy Siek <jsiek(a)osl.iu.edu> http://www.osl.iu.edu.edu/~jsiek Ph.D. Student, Indiana University Bloomington C++ Booster (http://www.boost.org) Office phone: (812) 856-1820 _______________________________________________

2 1

Re: [boost] variant - errors in mpl/less.hpp when bind.hpp isincludedbeforevariant.hpp with vc7.1
by Reece Dunn 06 Feb '04

06 Feb '04

Rene Rivera wrote: >Brock Peabody wrote: >>>-----Original Message----- >>>From: boost-bounces(a)lists.boost.org >>>[mailto:boost-bounces@lists.boost.org] >>>On Behalf Of Peter Dimov >> >>>Nice bug. I think that it's triggered by the "value<" sequence in the >>>code >>>below: >>> >>> enum >>> { >>> msvc71_wknd_ = ( BOOST_MPL_AUX_VALUE_WKND(T1)::value >>> < BOOST_MPL_AUX_VALUE_WKND(T2)::value ) >>> }; >>> >> >>>You can work around the problem by replacing the above with >>> >>> enum >>> { >>> msvc71_wknd_ = ( BOOST_MPL_AUX_VALUE_WKND(T2)::value >>> > BOOST_MPL_AUX_VALUE_WKND(T1)::value ) >>> }; >>> >>>I've commited the fix to the CVS HEAD as it seems fairly harmless (he >>>said >>>before breaking all other compilers). ;-) > >Shouldn't that be ">=" ??? No, the above is correct. Consider: a a Read either size backwards, noting the direction of the slant in the comparison operator. Regards, Reece _________________________________________________________________ Tired of 56k? Get a FREE BT Broadband connection http://www.msn.co.uk/specials/btbroadband

1 0

[Boost-bugs] [ boost-Bugs-891544 ] DevStudio 6.0 SP5 precompiledheaders and regex
by SourceForge.net 06 Feb '04

06 Feb '04

Bugs item #891544, was opened at 2004-02-05 23:30 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=891544&group_i… Category: regex Group: None Status: Open Resolution: None Priority: 5 Submitted By: gregg conklin (gconklin) Assigned to: John Maddock (johnmaddock) Summary: DevStudio 6.0 SP5 precompiled headers and regex Initial Comment: trying out the new boost_1_31_0 and i'm having problems using the updated regex library as a precompiled header. i was using 1.30.2 and had no troubles, though it seems more like a compiler problem (MSVC++ 6.0 SP5), so i don't know what can be done about it. ...\boost\regex\v4\perl_matcher_common.hpp(660) : fatal error C1001: INTERNAL COMPILER ERROR (compiler file 'msc1.cpp', line 1794) Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information to recreate in a tiny project, all i did was (within the msvc gui) File|New|Projects select win32 console app. Selected "A simple application" when asked what kind of console app i wanted to create. Opened stdafx.h and added the line: #include <boost\regex.hpp> right after the generated TODO: line Build|Rebuild All I'd be curious if the .Net compiler had the same problem, but I assume it doesn't. I can say that if I pull the regex.hpp out of stdafx.h and put it into each .h or .cpp file that references boost::regex, I get a clean compile. However, I have dozens of tiny projects that would require this change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=891544&group_i… ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

3 3

[graph,python] 1.31.0 failures on MSVC6
by Raoul Gough 06 Feb '04

06 Feb '04

I note from the current regression test results at http://boost.sourceforge.net/regression-logs/cs-win32.html that adjacency_matrix_test is a "Fail" on MSVC++6, along with all but one of the other graph library tests. This seems to have the knock-on effect of breaking one of the Boost.Python modules, inheritance.cpp. I keep thinking I must be making a mistake, but someone else has also reported Python build problems with the latest release on MSVC6. Am I missing something, or are boost.graph and boost.Python no longer functional on this compiler? http://boost.sourceforge.net/regression-logs/cs-win32-links.html#graph-adja… graph - adjacency_matrix_test - msvc Compiler output: adjacency_matrix_test.cpp C:\boost\site\boost/graph/detail/adjacency_list.hpp(1055) : error C2244: 'bidirectional_graph_helper_with_property<Config>::remove_edge' : unable to resolve function overload C:\boost\site\boost/graph/detail/adjacency_list.hpp(1057) : error C2954: template definitions cannot nest Compiling python/src/object/inheritance.cpp gives the same error, as well as errors in boost/mem_fn.hpp at lines 315 and 320 (complete errors posted recently on the Python C++-sig list). -- Raoul Gough. export LESS='-X'

1 1

looking for msvc problems
by Bronek Kozicki 06 Feb '04

06 Feb '04

Hi In case anybody has noticed problems with boost under MSVC platform, I would like to know about these problems and discuss possible solutions (on this list, if that will not go too far away from boost development). All insights are welcome. I'm not MS employee, but recently I got MVP and important part of my new role is to serve as communication channel with MS developers. Guys at MS are really interested in your insights; they actually asked me to gather your feedback! One problem that has been here for a while is inability to compile Windows headers with /Za switch - MS developers are currently searching for possible solutions (most recently this problem was noticed with Boost.Threads). B.

3 3

boost::shared_ptr classes across DLL boundaries on Win32 issue
by Greg Clayton 06 Feb '04

06 Feb '04

I have been using the boost::shared_ptr class to add large classes to STL containers as shared pointers. I use many DLLs that all share the same heap (they all use multi-threaded DLL runtimes), and shared_ptr's are passed between DLLs. I am currently running into an issue where DLL "A" can build up a shared_ptr in a local variable, and hand ownership over to DLL "B" (which stores the shared pointer in a STL container). I get a crash when the STL container class in DLL B later destructs if DLL A has been unloaded. It seems all virtual functions in the vtable of the shared pointers are bogus at this point. The crash occurs when attempting to call the "dispose()" virtual function as shown below: void release() // nothrow { { #if defined(BOOST_HAS_THREADS) mutex_type::scoped_lock lock(mtx_); #endif long new_use_count = --use_count_; if(new_use_count != 0) return; } dispose(); // <-- Crash is on function call to virtual "dispose" weak_release(); } the stack backtrace below: 0 - boost::detail::sp_counted_base::release() 1 - boost::detail::shared_count::~shared_count() 2 - boost::shared_ptr<T>::~shared_ptr<T>() .... Do I need to fully instantiate and export these template classes from the main DLL (which is DLL "B" in the above example)? Any hints would be most appreciated.

4 5

Re: [boost] [BGL] Using undirected adjacency_matrix.
by Cromwell Enage 06 Feb '04

06 Feb '04

Jeremy Siek wrote: > Thanks for the bug report. I've fixed the problem. > Mind if I add a modified version of your test > to the test directory? Go right ahead! Cromwell __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

1 0

Redirection problems with some docs
by Reece Dunn 06 Feb '04

06 Feb '04

Hi all, If you go to the documents section of the boost-consulting website (http://boost-consulting.com/boost/libs/libraries.htm) and select either the: any array function ref signals variant links, you get a cyclyc redirection! Note that regex redirection works. Also, the conversion/numeric_cast and base-from-member docs do not appear in the "Libraries Listed Alphabetically" section. I have checked all the links on that page (I haven't checked the links on the library docs themselves). Regards, Reece _________________________________________________________________ Sign-up for a FREE BT Broadband connection today! http://www.msn.co.uk/specials/btbroadband

1 0

1.31.0 release candidate 3
by Beman Dawes 06 Feb '04

06 Feb '04

1.31.0 has been tagged (Version_1_31_0) for release. Release candidate 3 (.zip format only) is available at www.esva.net/~beman/boost_1_31_0_rc3.zip. Please report any problems right away. This will be the final release candidate unless a really major problem is discovered. The actual release won't be until tomorrow, to give more regression tests a chance to cycle, and to give people a chance to look at RC3 Thanks, --Beman

11 20

(no subject)
by com bio 06 Feb '04

06 Feb '04

hello, we have created many functions that are often used in genome analysis.we want to make a open library out of it. plz guide us how to go about we used borland c++ deepan ===== ------------------------------------------- center for biotechnology anna university chennai-25 india __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

1 0

[Boost-bugs] [ boost-Bugs-891499 ] Compiling problems with MSVC++ 7
by SourceForge.net 06 Feb '04

06 Feb '04

Bugs item #891499, was opened at 2004-02-05 21:07 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=891499&group_i… Category: regex Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Eddy (johneddy) Assigned to: John Maddock (johnmaddock) Summary: Compiling problems with MSVC++ 7 Initial Comment: hello VC++ will not compile the following code with the newest version of the regex library whereas it would with the previous version (g++ 3.2.2 does not have a problem with it). #include <locale> using namespace std; #include <boost/regex.hpp> int main (int argc, char **argv) { return 0; } The error produced is: regbase.hpp(120) : error C2955: 'std::collate' : use of class template requires template argument list The offending line of code is inside an enumeration declaration and looks like this: collate = ::boost::regbase::collate, It seems that VC++ cannot resolve the difference between the enumeration constant and the STL collate class. The same error can be produced with the following code (or anything like it). #include <vector> using namespace std; enum SomeEnum { vector = 0 }; int main (int argc, char **argv) { return 0; } I cannot think of a good way around this short of changing the collate constant name and re-building. The examples are boiled down and it would not be possible for me to change the order of the includes nor would it be easy remove the using delcaration. John ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=891499&group_i… ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

2 1

RE: [boost] Re: Re: future of boost.threads
by Hurd, Matthew 06 Feb '04

06 Feb '04

> On Behalf Of Michael Glassford > Subject: [boost] Re: Re: future of boost.threads > > I remember very long and involved discussions, but don't remember any > consensus being reached or any resolution being found to the difficult > issues involved. Am I mistaken? > > Mike > > > "Slawomir Lisznianski" <slisznianski(a)asyncnet.com> wrote in message > news:20040205190629.08537154D84@mail.messagingengine.com... > > Are there any plans to support handling of exceptions thrown during > > joinable thread execution? I recall Usenet discussions with > proposals > > varying from Futures to throwable join(): > > > > try { > > thread.join(); > > } > > catch (std::runtime_error& e) { > > ... > > } > > > > Any ideas? > > > > On Thu, 5 Feb 2004 09:59:03 -0500, "Michael Glassford" > > <glassfordm(a)hotmail.com> said: > > > > > > "Burc Arpat" <burch(a)stanford.edu> wrote in message <snip> There has been a specific group set up to discuss thread cancellation and exceptions w.r.t. std c++ on gmane. It is not straight forward is the overall impression I took away ;-) It is worth reading. Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________

2 1

problems with binary variant visitors in 1.31
by E. Gladyshev 06 Feb '04

06 Feb '04

Great job with the 1.31 release! Just wondering if anybody else observerved this kind of problems before. When compiling the code below with MSVC 7.1, I am getting this error: test.cpp(123) : error C2039: 'set' : is not a member of 'my_type::test1'. GCC 3.2.3 gives a compilation error as well. template< typename T > struct binary_variant_visitor : public ::boost::static_visitor<> { T& obj_; binary_variant_visitor( T& obj ) : obj_(obj) {} template< typename VT1, typename VT2 > void operator()( VT1& v1, VT2& v2 ) { obj_.visit( v1, v2 ); } }; struct my_type { struct test1 { test1(); ~test1(); }; struct test2 { ~test2(); template< typename T > void set( T& ); }; typedef ::boost::variant<test1,test2> var; var d_; template< typename U > void visit( test1& t, U& u ) //test1 doesn't have set() { } template< typename T, typename U > void visit( T& t, U& u ) { t.set(u); } const var& data() const { return d_; } }; main() { my_type t1, t2; binary_variant_visitor<my_type> v(t1); ::boost::apply_visitor(v, t1.data(), t2.data() ); } If I change the last line to ::boost::apply_visitor(v, t1.d_, t2.d_ ); it works fine on both compilers. I guess it has something to do with how apply_visitor derives the parameter types. Eugene __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

2 2

Re: problems with binary variant visitors in 1.31
by E. Gladyshev 06 Feb '04

06 Feb '04

Never mind. Sorry I didn't notice 'const' in data(). Everything is pefect now. Eugene --- "E. Gladyshev" <egladysh(a)yahoo.com> wrote: > Great job with the 1.31 release! > > Just wondering if anybody else observerved this kind of problems before. > When compiling the code below with MSVC 7.1, I am getting this error: > test.cpp(123) : error C2039: 'set' : is not a member of 'my_type::test1'. > GCC 3.2.3 gives a compilation error as well. > > template< typename T > > struct binary_variant_visitor : public ::boost::static_visitor<> > { > T& obj_; > > binary_variant_visitor( T& obj ) : obj_(obj) {} > > template< typename VT1, typename VT2 > > void operator()( VT1& v1, VT2& v2 ) > { > obj_.visit( v1, v2 ); > } > }; > > struct my_type > { > struct test1 > { > test1(); > ~test1(); > }; > struct test2 > { > ~test2(); > template< typename T > > void set( T& ); > }; > > typedef ::boost::variant<test1,test2> var; > > var d_; > > template< typename U > > void visit( test1& t, U& u ) //test1 doesn't have set() > { > } > > template< typename T, typename U > > void visit( T& t, U& u ) > { > t.set(u); > } > > const var& data() const { return d_; } > }; > > main() > { > my_type t1, t2; > > binary_variant_visitor<my_type> v(t1); > ::boost::apply_visitor(v, t1.data(), t2.data() ); > } > > If I change the last line to > ::boost::apply_visitor(v, t1.d_, t2.d_ ); > > it works fine on both compilers. > I guess it has something to do with how > apply_visitor derives the parameter types. > > Eugene > > > __________________________________ > Do you Yahoo!? > Yahoo! Finance: Get your refund fast by filing online. > http://taxes.yahoo.com/filing.html > __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

1 0

[Boost-bugs] [ boost-Bugs-891611 ] mpl::less<> doesn't compile
by SourceForge.net 06 Feb '04

06 Feb '04

Bugs item #891611, was opened at 2004-02-05 23:30 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=891611&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eugene (egladysh) Assigned to: Nobody/Anonymous (nobody) Summary: mpl::less<> doesn't compile Initial Comment: First of all, congratulations with v1.31! I am having a weird problem when compiling mpl/less.hpp in MSVC 7.1 The error message is: s:\boost\boost_1_31_0\boost\mpl\less.hpp(39) : error C2760: syntax error : expected ',' not ';' s:\boost\boost_1_31_0\boost\mpl\less.hpp(51) : see reference to class template instantiation 'boost::mpl::less<T1,T2>' being compiled s:\boost\boost_1_31_0\boost\mpl\less.hpp(39) : error C2144: syntax error : 'const bool' should be preceded by '}' s:\boost\boost_1_31_0\boost\mpl\less.hpp(39) : error C2062: type 'const bool' unexpected s:\boost\boost_1_31_0\boost\mpl\less.hpp(39) : error C2238: unexpected token(s) preceding ';' s:\boost\boost_1_31_0\boost\mpl\less.hpp(42) : error C2065: 'value' : undeclared identifier s:\Projects\notus\notus\libs\src\platform\win32 \notus_traits\winobj.cpp(150) : fatal error C1903: unable to recover from previous error(s); stopping compilation ***************** If I change enum { msvc71_wknd_ = ( BOOST_MPL_AUX_VALUE_WKND (T1)::value < BOOST_MPL_AUX_VALUE_WKND (T2)::value ) }; to enum { msvc71_wknd_ = BOOST_MPL_AUX_VALUE_WKND (T1)::value < BOOST_MPL_AUX_VALUE_WKND (T2)::value }; everything works. Somehow the parentheses break the compiler. Eugene ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=891611&group_i… ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

using lexical_cast with tuples.
by David Sankel 06 Feb '04

06 Feb '04

Hello, I'm guessing this has something to do with the unsetf(std::ios::skipws) call. Anyway, the following code seems contradictory since it's output is "Exception Thrown". Has anyone else come across this? #include <iostream> #include <boost/tuple/tuple.hpp> #include <boost/tuple/tuple_io.hpp> #include <boost/lexical_cast.hpp> int main() { boost::tuple<float,float> aTuple(2.2f,3.3f); std::string theString = boost::lexical_cast<std::string>(aTuple); try { boost::tuple<float,float> i = boost::lexical_cast<boost::tuple<float,float> > ( theString ); } catch(...) { std::cout << "Exception Thrown" << std::endl; } } Thanks, David J. Sankel

4 4

[Boost-bugs] [ boost-Bugs-891530 ] Documentation pointing to .htmfiles (not .html)
by SourceForge.net 06 Feb '04

06 Feb '04

Bugs item #891530, was opened at 2004-02-05 22:58 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=891530&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: gregg conklin (gconklin) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation pointing to .htm files (not .html) Initial Comment: At least a few places in the html docs point to .htm files such as items in "Libraries Listed Alphabetically" and "Libraries Listed by Categories" examples: Regex - points to libs/regex/index.htm Smart Pointer - points to libs/smart_ptr/index.htm but the file on disk is actually: Regex - libs/regex/index.html Smart Pointer - libs/smart_ptr/index.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=891530&group_i… ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[BGL] Using undirected adjacency_matrix.
by Cromwell Enage 05 Feb '04

05 Feb '04

Morning, all. When the attached source code is compiled as is, the program works as expected. If the first #if condition is set to 0, the program garbles some output before crashing. If second #if condition is then set to 1, the program outputs much less, but it still crashes. Without the undirectedS property tag, the program works as expected, regardless of the #if conditions. I'm using the MinGW compiler bundled with Dev-C++ 4.9.8.5 and linking to the Boost libraries downloaded from CVS as of today, 0830 EST. I don't use the adjacency_matrix class template except for testing, so this is no showstopper, but it does seem to put a crimp on genericity. Feedback appreciated! Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

2 1

Boost suugestion
by Mohammed 05 Feb '04

05 Feb '04

Hi... I am facing a problem with Boost. It is not a big problem but takes a long time to do. I use more than one library from Boost. I need to create a text file that contains all the Boost libraries header files paths. Adding these paths everytime I compile with gcc is time consuming. I am working on Windows XP and Boost library 1.30.0 is installed on drive C:. Mohammed

2 1

[Boost-bugs] [ boost-Bugs-891277 ] Graph Header Clashes With Format Header
by SourceForge.net 05 Feb '04

05 Feb '04

Bugs item #891277, was opened at 2004-02-05 19:38 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=891277&group_i… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gordon Smith (schmoo2k) Assigned to: Jeremy Siek (jsiek) Summary: Graph Header Clashes With Format Header Initial Comment: The following code produces many errors in MSVC71 #include <boost/format.hpp> #include <boost/graph/adjacency_list.hpp> int _tmain(int argc, _TCHAR* argv[]) { std::string s = (boost::format("%1% %2% % 3%") % "a" % "b" % "c").str(); return 0; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=891277&group_i… ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Relational Template Library -- incorrect link
by Arkadiy Vertleyb 05 Feb '04

05 Feb '04

Sorry, I provided an incorrect link to the library. The correct one is: http://groups.yahoo.com/group/boost/files/tables.zip Arkadiy _________________________________________________________________ What are the 5 hot job markets for 2004? Click here to find out. http://msn.careerbuilder.com/Custom/MSN/CareerAdvice/WPI_WhereWillWeFindJob…

2 2

Three cheers for Beman (was Re: [Boost-users] Boost release 1.31.0is available)
by Jeremy Siek 05 Feb '04

05 Feb '04

On Feb 5, 2004, at 9:44 AM, Jeff Garland wrote: > On Thu, 05 Feb 2004 09:12:06 -0500, Beman Dawes wrote > >> Thanks to everyone who helped with this release. The folks that run >> the >> regression tests and review the release candidates get a special pat >> on the back. > > I think you (Beman) deserve an extra huge thanks for coordinating this > whole > thing -- it isn't easy! I second that. Three cheers for Beman! -Jeremy _______________________________________________ Jeremy Siek <jsiek(a)osl.iu.edu> http://www.osl.iu.edu.edu/~jsiek Ph.D. Student, Indiana University Bloomington C++ Booster (http://www.boost.org) Office phone: (812) 856-1820 _______________________________________________

4 3

Release 1.31.0 available
by Beman Dawes 05 Feb '04

05 Feb '04

Release 1.31.0 is available. See the www.boost.org home page for latest news about what's in the release. Or go right to http://sourceforge.net/project/showfiles.php?group_id=7586 to download. The web site is already getting hit pretty hard, but it looks like the site update went OK. Let me know if there are any problems. Thanks to everyone who helped with this release. The folks that run the regression tests and look at the release candidates get a special pat on the back. --Beman

6 8

Simple examples for new iterator adaptors
by Neal D. Becker 05 Feb '04

05 Feb '04

I am trying to learn about the new iterator adaptors. I reviewed the docs and examples, but I didn't really find much that would qualify as the "hello world" simple example. I put some test together. Perhaps it might either A) serve as a intro to someone else or B) some of you more knowlegeable can tell me how to do better.

3 4

Printing documents from boost?
by Neal D. Becker 05 Feb '04

05 Feb '04

I know this is a little OT, but I'm viewing the lovely new boost iterator docs (using konq), and I'm wondering how I can get a printed version which would include all the pages that make up the whole iterator documentation? I seem to recall long ago a tool called html2ps or something like that would do it, but I can't seem to find anything.

3 2

1.31.0 date_time and VC7.1
by Victor A. Wagner, Jr. 05 Feb '04

05 Feb '04

I'm still getting undefined symbols attempting to use date_time library with Visual Studio.NET 2003 Since the program is so short to demonstrate the problem, I include it here: ================================================================== #include <iostream > #include <string> #include "boost/date_time/posix_time/posix_time.hpp" int main() { boost::posix_time::ptime now = boost::posix_time::second_clock::universal_time(); boost::posix_time::ptime cnow(boost::posix_time::second_clock::universal_time()); std::string xx = to_iso_string(now); std::cout << to_iso_string(boost::posix_time::second_clock::universal_time()) << std::endl; std::cout << now << std::endl; std::cout << xx << std::endl; std::cout << to_iso_string(cnow) << std::endl; return 0; } ================================================================== produces the following output: ------ Build started: Project: OneLineDateTime, Configuration: Debug Win32 ------ Linking... OneLineDateTime.obj : error LNK2019: unresolved external symbol "public: char const * __thiscall boost::gregorian::greg_month::as_long_string(void)const " (?as_long_string@greg_month@gregorian@boost@@QBEPBDXZ) referenced in function "public: static class std::basic_ostream<char,struct std::char_traits<char> > & __cdecl boost::date_time::month_formatter<class boost::gregorian::greg_month,class boost::date_time::iso_format>::format_month(class boost::gregorian::greg_month const &,class std::basic_ostream<char,struct std::char_traits<char> > &)" (?format_month@?$month_formatter@Vgreg_month@gregorian@boost@@Viso_format@date_time@3@@date_time@boost@@SAAAV?$basic_ostream@DU?$char_traits@D@std@@@std@@ABVgreg_month@gregorian@3@AAV45@@Z) OneLineDateTime.obj : error LNK2019: unresolved external symbol "public: char const * __thiscall boost::gregorian::greg_month::as_short_string(void)const " (?as_short_string@greg_month@gregorian@boost@@QBEPBDXZ) referenced in function "public: static class std::basic_ostream<char,struct std::char_traits<char> > & __cdecl boost::date_time::month_formatter<class boost::gregorian::greg_month,class boost::date_time::iso_format>::format_month(class boost::gregorian::greg_month const &,class std::basic_ostream<char,struct std::char_traits<char> > &)" (?format_month@?$month_formatter@Vgreg_month@gregorian@boost@@Viso_format@date_time@3@@date_time@boost@@SAAAV?$basic_ostream@DU?$char_traits@D@std@@@std@@ABVgreg_month@gregorian@3@AAV45@@Z) Debug/OneLineDateTime.exe : fatal error LNK1120: 2 unresolved externals Build log was saved at "file://c:\Projects\Programming\SeriousTesting\OneLineDateTime\Debug\BuildLog.htm" OneLineDateTime - 3 error(s), 0 warning(s) ---------------------- Done ---------------------- Build: 0 succeeded, 1 failed, 0 skipped Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

8 19

Missing include for boost::format
by Guillaume Melquiond 04 Feb '04

04 Feb '04

Hi, The Format headers in the main CVS are missing some #include for I/O streams. For example, if you try to compile this snippet: #include <boost/format.hpp> #include <string> int main() { std::string a = (boost::format("%1%") % 0).str(); } GCC will complain that error: base class `std::basic_ostream<char, std::char_traits<char> >' has incomplete type Regards, Guillaume

3 2

[serialization] void_cast patch
by Robert Ramey 04 Feb '04

04 Feb '04

This has been corrected in the next version. Robert Ramey > I believe that the attached patch should be applied to void_cast.cpp. > According to std::3.2/3 > > "An inline function shall be defined in every translation unit in > which it > is used" > > which means putting inline function is .cpp file is not okay. The problem > I > had is then with optimization on, those function were stipped, leading to > link errors. > > - Volodya

1 0

Relational Template Library: transactions, etc.
by Arkadiy Vertleyb 04 Feb '04

04 Feb '04

Dear Boosters, A while ago we introduced RTL the Relational Template Library a lightweight facility to create relational tables and perform relational operations on them. The main concept RTL operates with is a relation, which has two types of models: tables and operators. Tables can store, in a type safe manner, fields of any types that satisfy requirements imposed by a typical STL container. Operators store references to their arguments, and produce data on the fly. Both provide iterators that can be used in STL algorithms. Any relation (operator or table) can serve as an argument to yet another operator, thus forming an arbitrary complicated expression tree. A relation has a sort order, which is calculated at compile time based on the sort order of its arguments. Range queries are available, based on this sort order. RTL allows to index any relation, which again can be either a table or a relational operator. In this sense our indexing models the ORDERED BY feature, provided by SQL. Therefore a relational expression can contain any number of indexes, used to re-sort tuples to better suite a particular query or queries. The March issue of C/C++ users journal will contain our article about RTL, where we described the library in more depth. This article reflects the state of the library as of about a year ago. NEW FEATURES ============ This time we are offering a significantly enhanced version of the library. The main addition is the TRANSACTION facility, that allows for synchronized updates to one or more tables. The additional very powerful (in our opinion) benefit is the possibility of incremental index update. When a table is changed, all the indexes that depend on this table get invalidated, and need to be updated. RTL takes care of this by calculating deltas on each index, and applying only necessary changes incrementally. We also modified the library interface to use MPL sequences instead of our proprietary type list implementation, and replaced all our meta-programming code to also make use of MPL. RTL allows the user to choose between available table implementations, as well as define new ones. The current in-stock implementation is based on std::vector, and therefore is most appropriate when the updates dont happen too often. We also experimented with indexed_set library to define a set-based implementation. Since the indexed_set is not a part of boost yet, we do not currently supply this implementation. However we do have it, and if anybody has immediate interest, please let us know well make it available (you will have to download the indexed_set library). We struggled to support VC6 up to the last moment, when some of our tests failed to build with Boost release candidate 2. The problems are with quantitative limitations we are getting ISO, and have to brake down our tests in smaller units. Since Microsoft no longer supports this compiler, we also decided to stop supporting it (we may re-consider if there are significant objections). The library has been tested with VC7.1 and GCC 3.3. Here is the link: http://f2.grp.yahoofs.com/v1/ABchQJF130FfDvd2GnsXCEIYu6UWzEecAPEgRIXr6rS50A… As always, we are looking forward to any feedback. Arkadiy vertleyb(a)hotmail.com Dmitriy dmitriy_arapov(a)hotmail.com _________________________________________________________________ Scope out the new MSN Plus Internet Software optimizes dial-up to the max! http://join.msn.com/?pgmarket=en-us&page=byoa/plus&ST=1

1 0

BUG: dynamic_bitset - shift assignment operator
by Lester Gong 04 Feb '04

04 Feb '04

There is a bug in dynamic_bitset operator<<=(). Calling operator<<=() followed by operator>>=() may shift in non-zero bits from the left. For example, this sequence of statements ... dynamic_bitset<> b(std::string("0110"); b <<= 1; // gives "1100" b <<= 1; // gives "1000" b <<= 1; // gives "0000" b >>= 1; // gives "1000" !! b >>= 1; // gives "1100" !! b >>= 1; // gives "0110" Seems that some stray bits are not cleared when shifted beyond the lhs of the bitfield. Attached files: test_dynamic_bitset.cc Simple program that illustrates bug test_dynamic_bitset.out Output from simple test program dynamic_bitset.hpp.patch Patch that seems to fix the bug bitset_test.hpp.patch dyn_bitset_unit_tests2.cpp.patch Proposed changes to test programs that would catch this problem. -Lester #include <boost/dynamic_bitset.hpp> #include <iostream> #include <string> using boost::dynamic_bitset; using std::cout; using std::endl; int main(int argv, char** argc) { dynamic_bitset<> b(std::string("0110")); cout << "Original dynamic_bitset object:" << endl; cout << b << endl << endl; cout << "Shift left assignment (3 times):" << endl; b <<= 1; cout <>= 1; cout <>= 1; cout <>= 1; cout << b << endl; return 0; } Original dynamic_bitset object: 0110 Shift left assignment (3 times): 1100 1000 0000 Shift right assignment (3 times): 1000 1100 0110 *** dynamic_bitset.hpp.orig Mon Feb 2 12:48:52 2004 --- dynamic_bitset.hpp Mon Feb 2 15:25:52 2004 *************** *** 670,676 **** // div blocks are zero filled at the less significant end std::fill(this->m_bits, this->m_bits+div, static_cast<block_type>(0)); ! } --- 670,676 ---- // div blocks are zero filled at the less significant end std::fill(this->m_bits, this->m_bits+div, static_cast<block_type>(0)); ! m_zero_unused_bits(); } *** bitset_test.hpp.orig Mon Feb 2 13:10:26 2004 --- bitset_test.hpp Mon Feb 2 15:21:34 2004 *************** *** 365,370 **** --- 365,400 ---- BOOST_CHECK(lhs[I] == prev[I + pos]); } + static void shift_left_assignment_followed_by_shift_right_assignment(const Bitset& b, std::size_t pos) + { + Bitset lhs(b); + Bitset prev(lhs); + lhs <<= pos; + lhs >>= pos; + // Check that zeros replace bits shifted off the end of the bitset. + std::size_t N = lhs.size(); + for (std::size_t I = 0; I < N; ++I) + if (I < (N - pos)) + BOOST_CHECK(lhs[I] == prev[I]); + else + BOOST_CHECK(lhs[I] == 0); + } + + static void shift_right_assignment_followed_by_shift_left_assignment(const Bitset& b, std::size_t pos) + { + Bitset lhs(b); + Bitset prev(lhs); + lhs >>= pos; + lhs <<= pos; + // Check that zeros replace bits shifted off the end of the bitset. + std::size_t N = lhs.size(); + for (std::size_t I = 0; I < N; ++I) + if (I >= pos) + BOOST_CHECK(lhs[I] == prev[I]); + else + BOOST_CHECK(lhs[I] == 0); + } + static void set_all(const Bitset& b) { *** dyn_bitset_unit_tests2.cpp.orig Mon Feb 2 13:10:44 2004 --- dyn_bitset_unit_tests2.cpp Mon Feb 2 15:28:26 2004 *************** *** 130,135 **** --- 130,199 ---- Tests::shift_right_assignment(b, pos); } //===================================================================== + // Test operator<<= followed by operator>>= + { // case pos == 0 + std::size_t pos = 0; + boost::dynamic_bitset<Block> b(std::string("1010")); + Tests::shift_left_assignment_followed_by_shift_right_assignment(b, pos); + } + { // case pos == 1 + std::size_t pos = 1; + boost::dynamic_bitset<Block> b(long_string); + Tests::shift_left_assignment_followed_by_shift_right_assignment(b, pos); + } + { // case pos == <half of Block> + std::size_t pos = (sizeof(Block) * CHAR_BIT) / 2; + boost::dynamic_bitset<Block> b(long_string); + Tests::shift_left_assignment_followed_by_shift_right_assignment(b, pos); + } + { // case pos == <full Block> + std::size_t pos = sizeof(Block) * CHAR_BIT; + boost::dynamic_bitset<Block> b(long_string); + Tests::shift_left_assignment_followed_by_shift_right_assignment(b, pos); + } + { // case pos == size()/2 + std::size_t pos = long_string.size() / 2; + boost::dynamic_bitset<Block> b(long_string); + Tests::shift_left_assignment_followed_by_shift_right_assignment(b, pos); + } + { // case pos >= n + std::size_t pos = long_string.size(); + boost::dynamic_bitset<Block> b(long_string); + Tests::shift_left_assignment_followed_by_shift_right_assignment(b, pos); + } + //===================================================================== + // Test operator>>= followed by operator<<= + { // case pos == 0 + std::size_t pos = 0; + boost::dynamic_bitset<Block> b(std::string("1010")); + Tests::shift_right_assignment_followed_by_shift_left_assignment(b, pos); + } + { // case pos == 1 + std::size_t pos = 1; + boost::dynamic_bitset<Block> b(long_string); + Tests::shift_right_assignment_followed_by_shift_left_assignment(b, pos); + } + { // case pos == <half of Block> + std::size_t pos = (sizeof(Block) * CHAR_BIT) / 2; + boost::dynamic_bitset<Block> b(long_string); + Tests::shift_right_assignment_followed_by_shift_left_assignment(b, pos); + } + { // case pos == <full Block> + std::size_t pos = sizeof(Block) * CHAR_BIT; + boost::dynamic_bitset<Block> b(long_string); + Tests::shift_right_assignment_followed_by_shift_left_assignment(b, pos); + } + { // case pos == size()/2 + std::size_t pos = long_string.size() / 2; + boost::dynamic_bitset<Block> b(long_string); + Tests::shift_right_assignment_followed_by_shift_left_assignment(b, pos); + } + { // case pos >= n + std::size_t pos = long_string.size(); + boost::dynamic_bitset<Block> b(long_string); + Tests::shift_right_assignment_followed_by_shift_left_assignment(b, pos); + } + //===================================================================== // test b.set() { boost::dynamic_bitset<Block> b;

2 1

Re: 1.31.0 release candidate 3
by Stephan T. Lavavej 04 Feb '04

04 Feb '04

I have tested 1.31.0 RC3 by using it to compile the test suite for my personal library libnuwen. The compile was clean without errors or warnings, including shadow warnings. So everything looks fine from my perspective, although I don't come close to using all of Boost. Stephan T. Lavavej http://nuwen.net

4 3

OK to correct typo's in RC.1.31.0 branch docs?
by John Maddock 04 Feb '04

04 Feb '04

Beman and all, Neal Becker has spotted a couple of nasty errors in the regex docs (wrong namespace in one place, wrong type in another), is it OK to commit the corrected docs (4 files) at this late stage to the release, I would rather commit than not, otherwise the end user could possibly be mislead. Thanks, John.

2 2

Re: 4 more associative containers.
by Rich Sposato 04 Feb '04

04 Feb '04

Joaquín M López Muñoz wrote: > De: "David B. Held" > > "Jeremy Maitin-Shepard" <jbms(a)attbi.com> wrote in message > > news:87u128yr3g.fsf@jbms.ath.cx... > > > I believe that a library named ``indexed_set,'' which has been > > > proposed and is pending formal review, provides this functionality > > > in addition to supporting multiple indices. > > Are you sure it does the same thing? I was under the impression > > that Joaquin's library lets you define *additional* indexes, but what > > if you just want to use an existing index, but it is comparable to > > something other than the key_type? > indexed_set does provide this functionality > (multiple indices aside.) See > http://tinyurl.com/2vu5g, section "Special lookup operations". > See also > http://tinyurl.com/3dyzh, section "Index set operations" > for a formal definition of the kind of special lookup > operations provided. And so indexed_set does provide the ability to lookup by a type other than the key_type. Which means that if we compared the various set containers in terms of abilities, flex_set is a special case of indexed_set where the number of indexes == 1. >From what I just read about indexed_set, it seems that the best benefit to using flex_set instead of indexed_set is that flex_set is simpler and smaller. We can sort set container classes by abilities to get this: std::set < flex_set < indexed_set. We can also sort multiset containers by ability and get this: std::multiset < flex_multiset < indexed_set. Rich Sposato

2 1

Re: [boost] Getting rid of some warnings on gcc?
by Reece Dunn 04 Feb '04

04 Feb '04

Beman Dawes wrote: >At 10:50 AM 2/3/2004, Marshall Clow wrote: > > >I've noticed that a bunch of the gcc tests (Mac OS, Linux, Windows) > >have many, many warnings, and they're all the same: > >... > >So I tried adding "typename" in two spots. In the MacOS testing, it > >changed 30+ tests from "Warn" to "Pass". Here's the change: > > > >diff -r1.23 token_functions.hpp > >304c304 > >< tokenizer_detail::get_iterator_category< > >--- > >> typename > >>tokenizer_detail::get_iterator_category< > >396c396 > >< tokenizer_detail::get_iterator_category< > >--- > >> typename > >>tokenizer_detail::get_iterator_category< > >VC++ 6.0 fails with the added "typename", so it has to be placed in #if ... >#endif. But, yes, the change does clear a lot of gcc warnings. The change >seems so innocuous I went ahead and committed it to the CVS HEAD. Doesn't BOOST_DEDUCED_TYPENAME fix the compatibility with VC++ 6? Regards, Reece _________________________________________________________________ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger

2 1

[serialization] void_cast patch
by Vladimir Prus 04 Feb '04

04 Feb '04

I believe that the attached patch should be applied to void_cast.cpp. According to std::3.2/3 "An inline function shall be defined in every translation unit in which it is used" which means putting inline function is .cpp file is not okay. The problem I had is then with optimization on, those function were stipped, leading to link errors. - Volodya

1 0

another regex doc error
by Neal D. Becker 04 Feb '04

04 Feb '04

boost_1_31_0_rc2/libs/regex/doc/match_flag_type.html says: namespace std{ namespace regex_constants{ That should be boost, not std, at least for now :)

2 1

Doc error in regex?
by Neal D. Becker 04 Feb '04

04 Feb '04

I'm trying 1.31.0rc2. unsigned int flags = boost::match_default; while(regex_search(start, end, what, re, flags)) { ../Test/PlotComplex.cc:36: error: invalid conversion from `unsigned int' to ` boost::regex_constants::_match_flags' But this is exactly what the example: boost_1_31_0_rc2/libs/regex/doc/regex_search.html shows. Need to update the doc?

2 1

RE: [boost] Re: 1.31.0 release candidate 3
by Bjorn.Karlsson＠readsoft.com 04 Feb '04

04 Feb '04

> From: Douglas Paul Gregor [mailto:gregod@cs.rpi.edu] > > Thanks to everyone who has tried this. So it looks like it might be an > optimizer bug (did anyone else try with optimization on?). > This probably > isn't a showstopper bug if it is an optimizer problem > (especially if one > needs particularly high optimization settings to trigger it). > I'll try to > work around this problem tonight, but it won't make 1.31.0. > I've managed (pun intended) to reproduce the problem when compiling with /CLR (compiles to managed code). The cause is this overloaded function: namespace detail { namespace function { inline bool has_empty_target(...) { return false; } } } When this function is called in assign_to (upon construction of the boost::function), the returned result is true (!), which means that the perfectly valid function (object) is never assigned, and the boost::function is thus empty. Oops... One way around this compiler bug is to avoid the ellipsis function, changing the signature of has_empty_target to: namespace detail { namespace function { inline bool has_empty_target(const void* f) { return false; } } } Cheers, Bjorn Karlsson

1 0

Getting rid of some warnings on gcc?
by Marshall Clow 04 Feb '04

04 Feb '04

I've noticed that a bunch of the gcc tests (Mac OS, Linux, Windows) have many, many warnings, and they're all the same: >/mnt/rh73/home/grafik/CVSROOTs/Boost/boost/boost/token_functions.hpp:305: >warning: ` > typename > >boost::tokenizer_detail::get_iterator_category<Iterator>::iterator_category' > is implicitly a typename and >/mnt/rh73/home/grafik/CVSROOTs/Boost/boost/boost/token_functions.hpp:397: >warning: ` > typename > >boost::tokenizer_detail::get_iterator_category<InputIterator>::iterator_category > ' is implicitly a typename So I tried adding "typename" in two spots. In the MacOS testing, it changed 30+ tests from "Warn" to "Pass". Here's the change: diff -r1.23 token_functions.hpp 304c304 < tokenizer_detail::get_iterator_category< --- > typename >tokenizer_detail::get_iterator_category< 396c396 < tokenizer_detail::get_iterator_category< --- > typename >tokenizer_detail::get_iterator_category< -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> Hey! Who messed with my anti-paranoia shot?

2 1

RE: [boost] 4 more associative containers.
by Rich Sposato 03 Feb '04

03 Feb '04

Gary Powell wrote: > I'm interested. I ran into the same issues with std::set that you have > and because of it, switched to a map when it wasn't really necessary. > Regarding acceptance by boost... I'm interested and will take a look > at the code. The code works with the STL version for GCC, but does not play well with other implementations of the STL. Later, I would like Boost to adopt these classes, but right now, I am only asking if Boost members are interested in the abilities these containers afford. Some questions I want Boost to ask are: 1. Do you like the class names: flex_set, flex_map, flex_multiset, and flex_multimap? 2. How can I implement the classes to not just compile and run with multiple compilers, but also work with existing STL implementations? (I am in the midst of making a separate version of these containers to work with Microsoft's STL implementation. I much prefer making only one version of these.) 3. Do you think I overlooked anything when I implemented these? (One suggestion is writing the containers to use an equivalence function in the comparator.) Thanks, Rich Sposato

1 0

should boost::ref forward some operators?
by Neal D. Becker 03 Feb '04

03 Feb '04

I ran into the following problem. I have an algorithm which looks like: template<typename in_t, typename out_t> void Alg (in_t in, in_t inend, out_t out) { for (; in != inend; in++, out++) do_something() } Now if I want to call this algorithm more than once, it would be convenient to pass out by ref, so it would be incremented: Alg (v.begin(), v.end(), boost::ref (out)) that is, pass a reference to some kind of output iterator this fails, because boost::ref doesn't have operator++ defined for reference_wrapper. My question is, should boost::ref forward operators like ++ so that this would work?

4 3

Re: 4 more associative containers
by Rich Sposato 03 Feb '04

03 Feb '04

Stefan Slapeta wrote: > Rich Sposato wrote: > > 1. You can search on any type that is comparable to the key_type, rather > > than just the key_type. (The STL associative containers only allows > > searches on the same type as the key.) > BTW, there is also an extention in STLPort which supports comparisons like > this. When I asked about this at STLport, they said they don't have extensions to the STL. Maybe I did not ask the right question. > I often wondered why this isn't supported by the standard containers. > Any idea? I must caution that flex_set has a minor disadvantage, a problem which std::set does not have. For primitive types, flex_set will cause code-bloat, while std::set will not. I don't use flex_set with primitive types because the compiler will make 2 functions out of this code for flex_set< long >, while it only makes one function using std::set< long >. typedef std::set< long > bunchOfLongs; long a = 1; short b = 2; bunchOfLongs.erase( a ); bunchOfLongs.erase( b ); The compiler will see flex_set< long >::erase( const long & ); as different from flex_set< long >::erase( const short & ); But, a compiler will see both of those calls above as: std:set< long >::erase( const long & ); For that reason, I can't advocate changing std::set's functions to be templated the way flex_set functions are. I suppose if it had templated functions like flex_set, there would be no need for flex_set, and somebody would some day advocate using a less-templated class called no_bloat_set. :-) I actually consider the bloat issue as minor because most of the functions are inline and small. Also, I rarely do a search using more than one type anyway. My typical usage with flex_set and related classes is to insert using the key_type, and find, count, and erase using a different type. Sometimes, the amount of code actually decreases inspite of a little bloat because I don't have to construct a temporary anymore. I think that could answer why the associative containers like map do not have templated functions. As to the other container types, I don't think they will need templated search functions. If you use the sequential containers, you can use the stand-alone find, count, binary_search, etc... functions and pass in a predicate. Rich

1 0

Re: 4 more associative containers.
by Rich Sposato 03 Feb '04

03 Feb '04

Maxim Yegorushkin wrote: > I had difficulty storing and finding boost::intrusive_ptr<> in std::set<>. > When I wanted to check if an arbitrary pointer value was in that set like: > struct some {/*...*/}; > typedef boost::intrusive_ptr<some> some_ptr; > typedef std::set<some_ptr> some_set; > some_set set; > bool exists(some const* s) > { > return set.find(s) != set.end(); > } > void foo() > { > bool b = exists(reinterpret_cast<some*>(0xdeadbeaf)); // boom > } > as std::set::find() requires a key value, it ended up with constructing the > smart pointer from a bogus value trying to do add_ref() and then release() > on that value which led to runtime errors. > If std::set<> had been able to use not a key value for find() but a key > comparable value I would not have had any problems with that code. I had similar problems with a conversion constructor getting invoked when I wanted to pass a pointer or value into std::set::find or std::multiset::count. That was one of the dificulties which led me to create flex_set and its related classes. Since flex_set does not require a temporary object, it also does not silently invoke a conversion constructor. Rich

1 0

Re: 4 more associative containers.
by Rich Sposato 03 Feb '04

03 Feb '04

On Mon, Feb 02, 2004 at 11:50:45PM -0800, Rich Sposato wrote: > > The containers are called flex_set, flex_map, flex_multiset, and > > flex_multimap. They are similar to the 4 STL associative containers. > > There are two important differences between the STL containers and these: > > 1. You can search on any type that is comparable to the key_type, rather > > than just the key_type. (The STL associative containers only allows > > searches on the same type as the key.) > > 2. You do *not* need to create a temporary object of key_type to search > > through the containers. (The STL containers require you to create one > > temporary object to search for another.) > A good idea. I recall wishing for something like this a while ago; I > don't remember if it stemmed from an actual problem in practice or just > general unhappiness with the std:: interface in theory. > (It might be even more swell if comparators could know about > 'equivalence' as well, so you could test for equivalence using one > user-defined function, rather than two calls like !c(x,y)&&!c(y,x).) This seems like a good suggestion since it would provide a slight efficiency since the comparison will only be done once rather than twice. When I looked through flex_set implementation, I found only two places where equivalence is tested. Both of those are inside insert member functions. So, there is a benefit to adding an equivalence function to the comparison functor. Since there is no reason to templatize the insert functions, the equivalence function will not need to be overloaded as the function operators are. Using the Employee example to define an equivalence function, I guess it will look like this: struct CompareEmployees : std::binary_function< const Employee *, const Employee *, bool > { // rest of functor as shown in the introductory message. inline bool equivalent( const Employee * l, const Employee * r ) const { return ( l->GetName() == r->GetName() ); } }; Would anybody prefer a different function name beside equivalent? > Do you have have documentation of the new 'concepts'? Specifically it > seems like flex_xxxx<T> uses a new ComparableTo<T,U> concept to place > requirements on both the Comparator and the template arguments to > methods like find(). The only any documentation on it so far is what is on my website, and what I wrote for the journal, Overload. Most of my website's description of flex_set is already mentioned in the introductory post to this mail list. The ComparableTo< T, U > concept is enforced by the compiler and the comparator. In theory, the templated member functions can work with any type. But in practice, the compiler can only use one of the overloaded function operators in the comparator with a specific call to one of the templated member functions of flex_set. To designate that a specific type is comparable to the flex_set's key_type, just add another overloaded operator to the comparator. Say, if I wanted to compare an Employee object to a Customer object, I would just add two more functions like this: struct CompareEmployees : std::binary_function< const Employee *, const Employee *, bool > { // rest of functor as shown in the introductory message. inline bool operator () ( const Employee * l, const Customer * r ) const { return ( l->GetName() < r->GetName() ); } inline bool operator () ( const Customer * l, const Employee * r ) const { return ( l->GetName() < r->GetName() ); } }; Rich Sposato

1 0

Re: [boost] Re: 4 more associative containers.
by JOAQUIN LOPEZ MU?Z 03 Feb '04

03 Feb '04

----- Mensaje original ----- De: "David B. Held" <dheld(a)codelogicconsulting.com> Fecha: Martes, Febrero 3, 2004 8:00 pm Asunto: [boost] Re: 4 more associative containers. > "Jeremy Maitin-Shepard" <jbms(a)attbi.com> wrote in message > news:87u128yr3g.fsf@jbms.ath.cx... > > I believe that a library named ``indexed_set,'' which has been > > proposed and is pending formal review, provides this functionality > > in addition to supporting multiple indices. > > Are you sure it does the same thing? I was under the impression > that Joaquin's library lets you define *additional* indexes, but what > if you just want to use an existing index, but it is comparable to > something other than the key_type? > indexed_set does provide this functionality (multiple indices aside.) See http://tinyurl.com/2vu5g, section "Special lookup operations". See also http://tinyurl.com/3dyzh, section "Index set operations" for a formal definition of the kind of special lookup operations provided. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

4 more associative containers.
by Rich Sposato 03 Feb '04

03 Feb '04

Hi Everyone, This is my debut post on Boost, and I would like to introduce some container classes I made so they can be considered for inclusion into Boost. (I made a similar post on STLport, but members of STLport suggested that Boost would be a better forum because STLport only has standard containers.) The containers are called flex_set, flex_map, flex_multiset, and flex_multimap. They are similar to the 4 STL associative containers. There are two important differences between the STL containers and these: 1. You can search on any type that is comparable to the key_type, rather than just the key_type. (The STL associative containers only allows searches on the same type as the key.) 2. You do *not* need to create a temporary object of key_type to search through the containers. (The STL containers require you to create one temporary object to search for another.) The flex_set and related containers do not have these limitations because: a) several of the member functions are template member functions, b) and that allows the comparison functor used with the containers to be overloaded for each type that can be used for searching. Listing 1 shows the two limitations of std::set and the other associative containers. For this example, assume you have an Employee class, and you store them in a set which is ordered by employee name. Listing 1: class Employee { public: const std::string & GetName() const; // . . . other functions }; struct CompareEmployees : std::binary_function< const Employee *, const Employee *, bool > { // Can only do a comparison of one Employee record // to another Employee record. Can't compare to any // other type. inline bool operator () ( const Employee * l, const Employee * r ) const { return ( l->GetName() < r->GetName() ); } }; typedef std::set< Employee *, CompareEmployees > EmployeeSet; EmployeeSet employees; Employee * FindEmployee( const std::string & name ) { // This bogus object is just a temporary to find the real // object. All I want is to find an Employee record that // matches the given name, rather make such a record. Employee bogus( name ); EmployeeSet::iterator it( employees.find( &bogus ) ); return ( employees.end() == it ) ? 0 : *it; } Listing 2 shows all the member functions which are now templated. The non-templated versions of these functions inside std::set use the key_type. The Compare_Type template parameter in the flex_set functions is *not* one of the template parameters for the class itself. Listing 2: template < class Key, class Compare, class Alloc > class flex_set { // . . . other parts of flex_set class public: template< class Compare_Type > size_type erase( const Compare_Type & x ); template< class CompareType > size_type count( const CompareType & x ) const; template< class Compare_Type > iterator find( const Compare_Type & x ); template< class Compare_Type > const_iterator find( const Compare_Type & x ) const; template< class Compare_Type > iterator lower_bound ( const Compare_Type & x ); template< class Compare_Type > const_iterator lower_bound( const Compare_Type & x ) const; template< class Compare_Type > iterator upper_bound( const Compare_Type & x ); template< class Compare_Type > const_iterator upper_bound( const Compare_Type & x ) const; template< class Compare_Type > pair< iterator, iterator > equal_range( const Compare_Type & x ); template< class Compare_Type > pair< const_iterator, const_iterator > equal_range( const Compare_Type & x ) const; }; Other than accepting a reference to a const Compare_Type in some functions, the flex_set class is identical to the std::set. Even the basic implementation is the same. Like the std::set class, flex_set uses the comparison functor as a little policy class to determine how the elements are sorted. Although the std::set has no need for an overloaded functor, the flex_set's real flexibility comes into play when using overloaded functors. I can design into my functor the mechanism by which an Employee record can be compared to a std::string or to a C-style string. Listing 3 shows the overloaded comparison functor. Listing 3: struct CompareEmployees : std::binary_function< const Employee *, const Employee *, bool > { inline bool operator () ( const Employee * l, const Employee * r ) const { return ( l->GetName() < r->GetName() ); } inline bool operator () ( const Employee * l, const std::string & r ) const { return ( l->GetName() < r ); } inline bool operator () ( const std::string & l, const Employee * r ) const { return ( l < r->GetName() ); } inline bool operator () ( const Employee * l, const char * r ) const { return ( l->GetName() < r ); } inline bool operator () ( const char * l, const Employee * r ) const { return ( l < r->GetName() ); } }; The example shown in Listing 1 now becomes the function shown in Listing 4. Listing 4: typedef flex_set< Employee *, CompareEmployees > EmployeeSet; EmployeeSet employees; Employee * FindEmployee( const std::string & name ) { // No unnecessary temporary objects here! // And the code shows my intent of searching by name. EmployeeSet::iterator it( employees.find( name ) ); return ( employees.end() == it ) ? 0 : *it; } I just published an article describing these containers in issue #58 of Overload magazine http://www.accu.org/c++sig/public/Overload.html. The article explains various design decisions about the classes, and goes into more detail about the containers. You can also find a zip file of my implementation at http://www.richsposato.com/FlexSet.html along with a zip file containing a demo project. The implementation was made as a drop-in replacement for the associative containers that come with the GCC compiler. I made the demo project using MinGW. Because my implementation was designed for GCC's version of the STL, the classes don't compile cleanly with some other implementations of the STL. For that reason, they will be reimplemented for Boost, if they are accepted. Thanks for your consideration, Rich Sposato

6 7

RE: [boost] [filesystem] size() on directory?
by Beman Dawes 03 Feb '04

03 Feb '04

At 12:48 PM 2/3/2004, Powell, Gary wrote: >Beman wrote: > >How should size( "foo" ) behave if "foo" is a directory? > >1) Throw. The function should be renamed file_size(). > >2) Return 0. Directories don't strictly speaking have a size. > >3) Return the number of entries in the directory. Directories are really >just containers; so of course they have a size. >------------------------------------------------- >Gary Replies: > #1, while an OS can implement directories as a file of information, I >think its conceptually wrong for this function to ask for its "size". When >iterating through a file system you should first guarantee that the file >name is a file and not that of a sub directory. > > The 4th answer would be to return the total size of all the files within >the directory. But I think that's also conceptually confusing as well. Agreed. (1) is the behavior in the preliminary version that is now in CVS. --Beman

1 0

[test] typos in documentation
by Jonathan Turkanis 03 Feb '04

03 Feb '04

Hello, Looking through the Boost.Test docs, I see that execution_monitor.htm contains two occurrences of 'overwrite' which probably should be 'override' or 'implement'. Also, test_tools.htm contains five occurrences of 'conformation message' which should probably read 'confirmation message' and one occurrence of 'massages' which should probably be 'messages'. Jonathan

2 2

RE: [boost] [filesystem] size() on directory?
by Powell, Gary 03 Feb '04

03 Feb '04

Beman wrote: How should size( "foo" ) behave if "foo" is a directory? 1) Throw. The function should be renamed file_size(). 2) Return 0. Directories don't strictly speaking have a size. 3) Return the number of entries in the directory. Directories are really just containers; so of course they have a size. ------------------------------------------------- Gary Replies: #1, while an OS can implement directories as a file of information, I think its conceptually wrong for this function to ask for its "size". When iterating through a file system you should first guarantee that the file name is a file and not that of a sub directory. The 4th answer would be to return the total size of all the files within the directory. But I think that's also conceptually confusing as well. Yours, -Gary-

1 0

RE: [boost] 4 more associative containers.
by Powell, Gary 03 Feb '04

03 Feb '04

I'm interested. I ran into the same issues with std::set that you have and because of it, switched to a map when it wasn't really necessary. Regarding acceptance by boost... I'm interested and will take a look at the code. -Gary-

1 0

RE: [boost] should boost::ref forward some operators?
by Powell, Gary 03 Feb '04

03 Feb '04

-------------------------------------------- I ran into the following problem. I have an algorithm which looks like: template<typename in_t, typename out_t> void Alg (in_t in, in_t inend, out_t out) { for (; in != inend; in++, out++) do_something() } Now if I want to call this algorithm more than once, it would be convenient to pass out by ref, so it would be incremented: Alg (v.begin(), v.end(), boost::ref (out)) that is, pass a reference to some kind of output iterator this fails, because boost::ref doesn't have operator++ defined for reference_wrapper. My question is, should boost::ref forward operators like ++ so that this would work? ---------------------------------------------- Gary Replied: I think you need a different tool, either FC++ or Lambda. "ref()" is just a simple wrapper to make something act like a reference. What you need is the whole operator set and Lambda and FC++ have those. Alg(v.begin(), v.end(), boost::lambda::var(out) ); Should work as you want. Yours, -Gary-

1 0

[filesystem] file_size() added
by Beman Dawes 03 Feb '04

03 Feb '04

I've added a file_size() function to the CVS HEAD. It has been tested only on Windows. It hasn't even been compiled on other systems. Testing is a bit difficult. The regular operations_test has been updated to cover several cases, but it would place a burden on testers to test the cases of file sizes requiring 32-bit and greater than 32-bit representations. In other words: * File sizes between 2,147,483,648 and 4,294,967,295. * File sizes greater than 4,294,967,295. boost-root/libs/filesystem/example now contains a program file_size.cpp and a simple Jamfile to build it. Of course it can also be build with your favorite make tool or IDE. When invoked from the command line with a (native) file path, it will display the size of the file in bytes. To know if the value is correct, you have to look at the file size with some system specific tool such as "dir", "ls", or a graphical file explorer. It works with large files on Windows, using Borland 0x0564, CodeWarrior 8.3, GCC 3.3.1 cygming special, Intel 8.0, Microsoft 7.0 and 7.1. It fails to compile on VC++6.0 because of limited 64-bit support. I'd appreciate hearing test results on other systems, particularly a variety of POSIX systems. If it doesn't work for large files on your system, suggestions to get it working will be much appreciated. Thanks, --Beman

1 0

Borland c++6 is compatible with random lib
by Narendran 03 Feb '04

03 Feb '04

Sir, I tried random number generation using boost random. I used uniform_int for my random generation. When I tried with the Borland c++ 6.0 personal it worked correctly. Again same code I tried to compile in Borland c++ 6.0 professional it is showing the error as follows: " [C++ Error] uniform_int.hpp(210): E2404 Dependent type qualifier 'boost::is_float<long>' has no member type named 'value' " Will you please give suggestion in this error. Thanks & Regards, Narendran.

2 1

1.31.0 closed for changes without permission
by Beman Dawes 03 Feb '04

03 Feb '04

Please make no more changes to the RC_1_31_0 branch without the release manager's permission. The one exception is removal of is_abstract code. We need to be totally stable so that the regression tests can cycle one last time. --Beman PS: For the next release, we need to define written "release discipline". What kind of changes are allowed at various points, such as after branch, after release candidates start, etc.

7 21

shared_pointer for C-allocated object?
by Neal D. Becker 03 Feb '04

03 Feb '04

I have some legacy C code that returns a pointer: fftw_plan fftw_create_plan(int n, fftw_direction dir, int flags); where fftw_plan is a pointer. Can I use shared_pointer to wrap it? I guess the issue is that eventually delete will be called on this pointer, but it wasn't allocated with new. Is this a problem?

6 11

Re: [boost] Re: [filesystem] size() on directory?
by Beman Dawes 03 Feb '04

03 Feb '04

At 04:00 AM 2/3/2004, Christoph Ludwig wrote: >I don't know about other filesystems, but in the examples above it >makes perfectly sense to ask for the size of a directory (rather than >the sum of the size of its content). It isn't available on other systems. Windows reports 0, for example. --Beman

1 0

Re: class static constants, mpl, and linker problems
by David Abrahams 03 Feb '04

03 Feb '04

Daniel Krügler <dsp(a)bdal.de> writes: > - Assumption one: Boost does not provide the definitions of > potential static constants hidden by the BOOST_STATIC_CONSTANT > definition (I used only the headers of the library, so my potential > testing bug would be that I had to include the corresponding > translation units of boost providing the constant's definitions, > but sorry - I did not find them!). In general BOOST_STATIC_CONSTANT is used within templates, so the definition of a corresponding member may be given in the header file: template <int N> struct int_ { BOOST_STATIC_CONSTANT(int, value = N); }; #ifndef BOOST_NO_INCLASS_MEMBER_INITIALIZATION template <int N> int const int_<N>::value; #endif > As I said: If this assumption is false, please blame me straight > for incomplete testing and for trying to spread bad rumors on this > (really!) great library. It's probably not false in most cases. > - Assumption two: Even if Boost does provide these definitions, > there may occur problems due to the VC7.1 flags /Za and /Ze (aka > disabling and enabling language extensions), which I will explain > in the following. The same point applies as to assumptions one, if > I did incomplete testing or testing with rather old boost libraries. > > The nasty thing concerning the /Ze flag is that it effectively does > not "extend" the language in every case. A small testing case is the > following program: > > a.h: ------------------------- > #ifndef A_H_INC > #define A_H_INC > struct A > { > static const int val = 42; // Declaration of a static member variable > }; > #endif > ------------------------- > > a.cpp -------------------- > #include "a.h" > const int A::val; // Definition might be needed, if the program accesses > // the adress of A::val > ------------------------- > > main.cpp -------------------- > #include "a.h" > int main() > { > } > ------------------------- > > Although this is a C++ Standard compliant program, it will not > successfully link with the /Ze flag enabled, which is to my opion a > real compiler bug (which I already posted to m.p.v.language, but got > no reasonable response yet). The obtained error message is: > > error LNK2005: "private: static int const A::val" (?val@A@@0HB) already > defined in a.obj > error LNK2005: "private: static int const A::val" (?val@A@@0HB) already > defined in main.obj Looks like a bug to me. > Question: Is this special deficiency of the VC7.1 compiler taken > account in the current boost library? I doubt it. How would we do that? > I think, it is impossible to demand, that users are enforced to use > either only /Ze or only /Za, because each of these choices has some > considerable drawbacks (at least on Windows systems...) Well, it seems to me that we can only respond to actual problems. Do you have an actual case of using a Boost library where these issues cause you trouble? -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 9

[filesystem] On POSIX, any reliable way to find file size?
by Beman Dawes 02 Feb '04

02 Feb '04

There have been requests for a Boost.Filesystem function which returns file size. But I don't want to provide such a function if it will be unreliable. On POSIX compliant 32-bit systems, is there any reliable way to find the size of a file? It looks to me as if stat::st_size's type of off_t isn't large enough on 32-bit systems to cope with large file sizes. Am I wrong, or missing something? How big is the largest possible file on, say, Linux? Isn't it larger than the 2 gigs a 32-bit signed integer can represent? --Beman

5 10

1.31.0 Win32 Graph/graph failures?
by Beman Dawes 02 Feb '04

02 Feb '04

Damn! Win32 Graph/graph has been failing for Intel and Microsoft since sometime Friday! That's a showstopper. Quick response would be greatly appreciated. --Beman The VC++7.1 error message begins: D:\boost-snapshot\boost\graph\detail\adjacency_list.hpp(1325) : error C2440: 'initializing' : cannot convert from 'std::_Tree<_Traits>::const_iterator' to 'std::_Tree<_Traits>::iterator' with [ _Traits=std::_Tset_traits<boost::detail::adj_list_gen<boost::adjacency_list<boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>>,boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>,boost::no_property,boost::listS>::config::StoredEdge,std::less<boost::detail::adj_list_gen<boost::adjacency_list<boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>>,boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>,boost::no_property,boost::listS>::config::StoredEdge>,std::allocator<boost::detail::adj_list_gen<boost::adjacency_list<boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>>,boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>,! boost: : no_property,boost::listS>::config::StoredEdge>,false> ] and [ _Traits=std::_Tset_traits<boost::detail::adj_list_gen<boost::adjacency_list<boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>>,boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>,boost::no_property,boost::listS>::config::StoredEdge,std::less<boost::detail::adj_list_gen<boost::adjacency_list<boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>>,boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>,boost::no_property,boost::listS>::config::StoredEdge>,std::allocator<boost::detail::adj_list_gen<boost::adjacency_list<boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>>,boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>,! boost: : no_property,boost::listS>::config::StoredEdge>,false> ] No constructor could take the source type, or constructor overload resolution was ambiguous

3 5

[filesystem] adding path equality and path equivalence
by Beman Dawes 02 Feb '04

02 Feb '04

Equality -------- The path relational operators will be defined purely in terms of string comparison between the textual representation of the two paths. There are two ways to do this: (1) string comparison using std::string relational operators or (2) string comparison using std::lexicographical_compare. Given two paths, "foo.bar" and "foo/bar", (1) will order them: foo.bar foo/bar While (2) will order them: foo/bar foo.bar The primary use case I know of for operator<() is default ordering for paths used as keys in associative containers. I can't see that either approach is superior for this use, so unless someone comes up with a compelling argument, (1) will be used. Equivalence ----------- Two paths will be considered equivalent if they resolve to the same physical directory or file. Question 1: What is a use case that requires this function? Verifying that source and target files are different before some modifying operation is the only one I've come up with. I guess that is sufficient to justify adding the function. Question 2: What if neither exist? Only one exists? My initial thought is that these are likely to be errors, so treat them as such. It could be argued that if either or both don't exist, they can't be equivalent, so return false. Question 3: The implementation on Windows (see below) leaves a small hole in that duplicated media (such as two CD's) mounted on devices with the same device id on two different networked machines would be reported as equivalent. POSIX requires that such networked devices have different device id's, avoiding the problem. Is the fact that Windows and POSIX implementations would perform slightly differently on this corner case a showstopper? I think not. Windows logic for path equivalent: same device id AND same media volume serial number AND same physical location on disk AND same creation time. This works even in degenerate cases like camera formatted FAT flash memory cards or floppy disks with volume serial numbers incorrectly initialized to 0. POSIX logic: same device id AND same physical location on disk AND same modification time. The modification time is in theory redundant, but is an added protection in case the device id on networked devices failed to meet the POSIX specs. --Beman

6 16

value_initialized, deep const, and template instantiation
by Jim Apple 02 Feb '04

02 Feb '04

value_initialized has non-deep (shallow?) const semantics. const value_initialized<T> is supposed to be const. Unfortunately, due to compiler errors in VC++ and Borland, it has operator T &() const instead of operator T&() operator const T&() const which breaks const-correctness in a big way. I'd like for there to be a config macro that identifies this error. I would make one, as well as a test for it, myself, but I only have access to icc and gcc on linux, both of which pass the test, so it's hard trying to identify the extent of the overloading selection failure. After creating this macro, we could use it to make a const correct value_initialized class for users with more advanced compilers. For those compilers, I think there would be value to adding operator-> for the invocation of member functions, like boost::optional. As an alternative, deep-copy would break const expectations in generic functions that take a const T &, but it would preserve it elsewhere, so it may be worth some more thought. Finally, I have come up with a similar class (which I wrote with deep const sematics, although I am open to argument about shallow const) for solving the following problem: ---------------------------------------------------------------------- #include <iostream> template<typename T> struct wrap { static const T joe; }; template<typename T> const T wrap<T>::joe; struct call_out { int num; call_out() : num(77) {} }; template<typename T> struct check_call { check_call() { std::cout << wrap<T>::joe.num << std::endl; } }; check_call<call_out> x; int main(){} ----------------------------------------------------------------------- This outputs 0, not 77, on gcc 3.3.2, intel 8, and vc6. I don't know if that's correct, 14.7.1/1 says: "... in particular, the initialization (and any associated side effects) of a static data member does not occur unless the static data member is itself used in a way that requires the definition of the static data member to exist." If this is std-conforming behavior, or not, i have a workaround that allows: ------------------------------------------------------------------------ #include <iostream> #include "can_init.hpp" template<typename T> struct wrap { static can_init<const T> joe; }; template<typename T> can_init<const T> wrap<T>::joe; struct call_out { int num; call_out() : num(77) {} }; template<typename T> struct check_call { check_call() { wrap<T>::joe.ensure_init(); std::cout << wrap<T>::joe->num << std::endl; } }; check_call<call_out> x; int main(){} ----------------------------------------------------------------------- which obviously uses deep const. Is there any interest in including this in boost/utility/? Should it have shallow or deep const semantics? Jim

2 5

Output Formatters [update]
by Reece Dunn 02 Feb '04

02 Feb '04

There are now Jamfiles for the examples and test facility :) that has been tested on Boost.Build V2. I am currently working on developing a regression test facility that has been posted to the sandbox CVS (this is still experimental, but is quite stable). Feedback? When you run one of the test programs, they will produce a results.xml file, or add to it if the file already exists. To work as intended, the programs need to be moved to a directory that contains the view.xsl file then run seperately for each compiler/library configuration you are testing. I am looking at how to do this within the Jamfile :). Aside from that, I have been working on bugs and completing the read/input facilities. I have fixed it now so that sequential, set and associative containers are read properly. The only defect remaining (thus far) is reading string types: The string handling code has been dropped from basic_object as this intefered with wrapped_object, causing the serialization example to fail. I am currently working on getting strings properly supported and will upload it when it is working. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

1 0

compile-time array count
by Gennaro Prota 02 Feb '04

02 Feb '04

Having a look to some old list messages I've seen there has been some discussion about discovering the number of elements of an array in compile-time. Sorry if I have simply misunderstood something here (I'm rapidly catching up with old threads), but isn't this enough? http://article.gmane.org/gmane.comp.lib.boost.devel/3216 That's for expressions, of course, not type-ids. Genny.

4 8

Re: [boost] Re: Boost Digest, Vol 622, Issue 5
by John Maddock 02 Feb '04

02 Feb '04

> How about using Boost.Thread's call_once function? I realize it requires > extra code, but something along these lines seems like it should both > avoid too much locking and still work: > Aha, good thinking, yes that's a good idea. John.

2 1

Liohyjdxevcm
by jewillco＠osl.iu.edu 02 Feb '04

02 Feb '04

The message cannot be represented in 7-bit ASCII encoding and has been sent as a binary attachment.

1 0

Re: problem with new iterators in 1.31 Release candidate # 2
by Robert Ramey 02 Feb '04

02 Feb '04

Dave Abrahams wrote: >Robert Ramey wrote: >> it seems to me that it is implemented for non - random access >> iterators by incrementing one iterator until it equals the other and >> return the number of times the increment occured. >Yeah, it's a mistake. It shouldn't use distance, but operator-. >That way neither one of your subtractions would compile. >From the documentation: counting_iterator requirements The Incrementable argument shall be Copy Constructible and Assignable. If iterator_category is convertible to forward_iterator_tag or forward_traversal_tag, the following must be well-formed: Incrementable i, j; ++i; // pre-increment i == j; // operator equal Suppose I had used a different iterator as a base - not an input iterartor but some kind of forward transveral iterator. Would that have been ok? Now if I understand correctly? the only difference between the single pass transveral and forward transversal is the ability to "rewind". As far as I can see the ability doesn't affect the requirement stated above. Are sure that the requirement isn't too strong. The fact that it "accidently" works seems to suggest this. from the nomenclature, example, other "counting iterators", and common sense, I would expect an example such as the one I presented to function as I expected. And in fact it did in the previous release candidate. That is, its natural to expect the following to function std::fstream is; std::input_iterator begin(is), end(); int filesize = end - begin; Can the design and implement (of off course document) be adjusted to permit this? If such a seemingly natural usage is not possible, it should be trapped at compile time (as you suggested) and the reason why it can't be supported described in the documentation. Robert Ramey

2 1

Re: problem with new iterators in 1.31 Release Candidate # 2 (repost)
by Robert Ramey 01 Feb '04

01 Feb '04

I didn't get the formating correct on this so I want to repost it so it makes more sense. >David Abrahams wrote: >>Robert Ramey <ramey(a)rrsd.com> writes: >> I have a problem with the latest version of the new iterators. >> This is illustrated in the following example. >> >> #include <strstream> >> #include <iterator> >> #include <boost/iterator/counting_iterator.hpp> >> >> main(){ >> std::istrstream is("abcdefg"); >> typedef boost::counting_iterator<std::istream_iterator<char> > ci; >> const ci end = std::istream_iterator<char>(); // note the const !!! >I don't see why the const should be relevant. >From looking at the code for counting iterator it seems to me that it is implemented for non - random access iterators by incrementing one iterator until it equals the other and return the number of times the increment occured. (I concede that I've had difficulty following the implementation so I could be wrong). So if one of the iterators is const - that one can't be the one that's incremented. >> ci begin = std::istream_iterator<char>(is); >Hmm, the implicit conversions from istream_iterator to the >counting_iterator above are troubling. I think those constructors >should be explicit. Hmmm - From looking at the documentation and the code, I get absolutly no indication that the counting iterator requires a random access iterator. In fact, looking at the code suggests that there is code especially included to handle any forward transversal iterators. And the first invocation below DOES work - I can't believe that's an accident. >> unsigned int size; >> >> // the following should fail at compilation ? >Why? OK, maybe it would be better to make it fail because the >iterator is not in fact a random-access iterator. > // in fact it compiles are returns a value of -7 !!! > size = begin - end; > > // the following should compile and return a value of 7 > // in fact, it compiles but goes into an infinite loop > size = end - begin; > } My mistake - I wrongly presumed that only the second iterator would be incremented and since its const it should fail. It looks like the code intends to select which iterator to increment depending on const. So this first case looks ok to me now. >I don't see why you think the first should compile but the second >should not. If they're not random-access iterators, it seems to me >that there's no reason you should be able to subtract them in any >order. If they were random-access iterators, it would be unreasonable >to expect the compiler to detect which one had an earlier position >and disallow one subtraction. So my position is that both compile (as they should). The first works as one would expect while the second results in an infinite loop. I'm sorry but I don't see how this can be correct. >> Note that this problem did not appear with the first release candidate. > >> Also, if one follows the links from the main documentation page, one >> is directed to the documentation of the old iterators. This is >> extremely confusing. This has been pointed out before. >That's a serious problem which I'll fix immediately. Robert Ramey

1 0

[config] BOOST_EXPLICIT_TEMPLATE_TYPE_SPEC
by Gennaro Prota 01 Feb '04

01 Feb '04

A while ago I pointed out that BOOST_EXPLICIT_TEMPLATE_TYPE_SPEC and its three variations (in config/suffix.hpp) are useless for VC6 (the only compiler, IIRC, for which the non-_SPEC versions were introduced). http://article.gmane.org/gmane.comp.lib.boost.devel/23486/ I thought they had been removed but I see that they are still there. There's one usage, in variant/detail/forced_return.hpp. Is it really needed? Why? Genny.

1 0

Re: problem with new iterators in 1.31 Release candidate # 2
by Robert Ramey 01 Feb '04

01 Feb '04

Robert Ramey <ramey(a)rrsd.com> writes: > I have a problem with the latest version of the new iterators. > This is illustrated in the following example. > > #include <strstream> > #include <iterator> > #include <boost/iterator/counting_iterator.hpp> > > main(){ > std::istrstream is("abcdefg"); > typedef boost::counting_iterator<std::istream_iterator<char> > ci; > const ci end = std::istream_iterator<char>(); // note the const !!! I don't see why the const should be relevant. >From looking at the code for counting iterator it seems to me that it is implemented for non - random access iterators by incrementing one iterator until it equals the other and return the number of times the increment occured. (I concede that I've had difficulty following the implementation so I could be wrong). So if one of the iterators is const - that one can't be the one that's incremented. > ci begin = std::istream_iterator<char>(is); Hmm, the implicit conversions from istream_iterator to the counting_iterator above are troubling. I think those constructors should be explicit. Hmmm - From looking at the documentation and the code, I get absolutly no indication that the counting iterator requires a randome access iterator. In fact, looking at the code suggests that there is code especially included to handle any forward transversal iterators. And the first invocation below DOES work - I can't believe that's an accident. > unsigned int size; > > // the following should fail at compilation ? Why? OK, maybe it would be better to make it fail because the iterator is not in fact a random-access iterator. > // in fact it compiles are returns a value of -7 !!! > size = begin - end; > > // the following should compile and return a value of 7 > // in fact, it compiles but goes into an infinite loop > size = end - begin; > } My mistake - I wrongly presumed that only the second iterator would be incremented and since its const it should fail. It looks like the code intends to select which iterator to increment depending on const. So this first case looks ok to me now. I don't see why you think the first should compile but the second should not. If they're not random-access iterators, it seems to me that there's no reason you should be able to subtract them in any order. If they were random-access iterators, it would be unreasonable to expect the compiler to detect which one had an earlier position and disallow one subtraction. So my position is that both compile (as they should). The first works as one would expect while the second results in an infinite loop. I'm sorry but I don't see how this can be correct. > Note that this problem did not appear with the first release > candidate. > > Also, if one follows the links from the main documentation page, one > is directed to the documentation of the old iterators. This is > extremely confusing. This has been pointed out before. That's a serious problem which I'll fix immediately. Robert Ramey

2 1

mpl lambda question
by Eyal Farago 01 Feb '04

01 Feb '04

hi, I'm trying to use mpl lambda on vc.6.5, it seems that for some reason when applying lambda on the expression the compiler tries to instantiate the wrong specialisation(the one with the boost::mpl::arg<1> as a template parameter. this is the test program: #include <boost/mpl/lambda.hpp> #include <boost/tuple/tuple.hpp> template< class T_ > struct head_type { typedef typename T_::head_type type; BOOST_MPL_AUX_LAMBDA_SUPPORT( 1, head_type, ( T_ ) ); }; void main() { typedef boost::tuples::tuple< int > int_tuple_t; typedef head_type< int_tuple_t >::type head_of_int_tuple_t; typedef head_type< boost::mpl::_1 > exp_t; typedef boost::mpl::lambda< exp_t >::type exp_lambda_t; //this line causes the compilation error typedef boost::mpl::apply1< exp_lambda_t, int_tuple_t >::type int_tuple_head_type; } and this is the compiler's output: --------------------Configuration: boost_tests - Win32 Debug-------------------- Compiling... main.cpp C:\c++\boost_tests\main.cpp(7) : error C2039: 'head_type' : is not a member of 'arg<1>' c:\c++\boost_1_30_0\boost\mpl\aux_\preprocessed\msvc60\arg.hpp(28) : see declaration of 'arg<1>' c:\c++\boost_1_30_0\boost\type_traits\is_convertible.hpp(64) : see reference to class template instantiation 'head_type<struct boost::mpl::arg<1> >' being compiled c:\c++\boost_1_30_0\boost\type_traits\is_convertible.hpp(80) : see reference to class template instantiation 'boost::detail::does_conversion_exist<struct head_type<struct boost::mpl::arg<1> > &>::result_<struct boost::detail::int_convertible >' being compiled c:\c++\boost_1_30_0\boost\type_traits\is_convertible.hpp(184) : see reference to class template instantiation 'boost::detail::is_convertible_basic_impl<struct head_type<struct boost::mpl::arg<1> > &,struct boost::detail::int_convertible>' be ing compiled c:\c++\boost_1_30_0\boost\type_traits\is_convertible.hpp(239) : see reference to class template instantiation 'boost::detail::is_convertible_impl<struct head_type<struct boost::mpl::arg<1> > &,struct boost::detail::int_convertible>' being co mpiled c:\c++\boost_1_30_0\boost\type_traits\is_enum.hpp(54) : see reference to class template instantiation 'boost::is_convertible<struct head_type<struct boost::mpl::arg<1> > &,struct boost::detail::int_convertible>' being compiled c:\c++\boost_1_30_0\boost\type_traits\is_enum.hpp(91) : see reference to class template instantiation 'boost::detail::is_enum_helper<0>::type<struct head_type<struct boost::mpl::arg<1> > &>' being compiled c:\c++\boost_1_30_0\boost\type_traits\is_enum.hpp(108) : see reference to class template instantiation 'boost::detail::is_enum_impl<struct head_type<struct boost::mpl::arg<1> > >' being compiled c:\c++\boost_1_30_0\boost\type_traits\is_scalar.hpp(30) : see reference to class template instantiation 'boost::is_enum<struct head_type<struct boost::mpl::arg<1> > >' being compiled c:\c++\boost_1_30_0\boost\type_traits\is_scalar.hpp(50) : see reference to class template instantiation 'boost::detail::is_scalar_impl<struct head_type<struct boost::mpl::arg<1> > >' being compiled c:\c++\boost_1_30_0\boost\type_traits\is_class.hpp(78) : see reference to class template instantiation 'boost::is_scalar<struct head_type<struct boost::mpl::arg<1> > >' being compiled c:\c++\boost_1_30_0\boost\type_traits\is_class.hpp(93) : see reference to class template instantiation 'boost::detail::is_class_impl<struct head_type<struct boost::mpl::arg<1> > >' being compiled c:\c++\boost_1_30_0\boost\mpl\aux_\has_rebind.hpp(32) : see reference to class template instantiation 'boost::is_class<struct head_type<struct boost::mpl::arg<1> > >' being compiled c:\c++\boost_1_30_0\boost\mpl\aux_\preprocessed\msvc60\template_arity.hpp(27) : see reference to class template instantiation 'boost::mpl::aux::has_rebind<struct head_type<struct boost::mpl::arg<1> > >' being compiled c:\c++\boost_1_30_0\boost\mpl\aux_\preprocessed\msvc60\lambda_no_ctps.hpp(150) : see reference to class template instantiation 'boost::mpl::aux::template_arity<struct head_type<struct boost::mpl::arg<1> > >' being compiled C:\c++\boost_tests\main.cpp(17) : see reference to class template instantiation 'boost::mpl::lambda<struct head_type<struct boost::mpl::arg<1> >,1>' being compiled Error executing cl.exe. boost_tests.exe - 1 error(s), 0 warning(s) eyal.

2 1

ICE with is_abstract on VC 7.0
by Robert Ramey 01 Feb '04

01 Feb '04

When I compile anything that includes is_abstract.hpp I get a compiler ICE with VC 7.0 since is_abstract.hpp is included by type_traits.hpp it means that a large part of boost 1.31 release candidate 2 is now uncompilable on this platform. is_abstract was known to test the limits of many platforms. It is incredible to me that this could be dropped into "release candidate # 2" without having been part of the development tree for a reasonable amount of time. When can we expect 1.31 release candidate # 3? Robert Ramey

5 6

1.31.0 Release candidate 2 available
by Beman Dawes 01 Feb '04

01 Feb '04

Release candidate 2 is available at http://www.esva.net/~beman/boost_1_31_0_rc2.zip Feedback appreciated! Boost developers should limit changes to the RC_1_31_0 branch to fixes for showstoppers. Anything less should go in the next release. --Beman

14 25

problem with new iterators in 1.31 Release candidate # 2
by Robert Ramey 01 Feb '04

01 Feb '04

I have a problem with the latest version of the new iterators. This is illustrated in the following example. #include <strstream> #include <iterator> #include <boost/iterator/counting_iterator.hpp> main(){ std::istrstream is("abcdefg"); typedef boost::counting_iterator<std::istream_iterator<char> > ci; const ci end = std::istream_iterator<char>(); // note the const !!! ci begin = std::istream_iterator<char>(is); unsigned int size; // the following should fail at compilation ? // in fact it compiles are returns a value of -7 !!! size = begin - end; // the following should compile and return a value of 7 // in fact, it compiles but goes into an infinite loop size = end - begin; } Note that this problem did not appear with the first release candidate. Also, if one follows the links from the main documentation page, one is directed to the documentation of the old iterators. This is extremely confusing. This has been pointed out before. This above example is using 1.31. "release candidate" #2 compiled with VC 7.0 Robert Ramey

2 1

Re: [boost] [filesystem] On POSIX, any reliable way to find file size?
by Beman Dawes 31 Jan '04

31 Jan '04

At 01:29 PM 1/31/2004, Christoph Ludwig wrote: >I don't know whether there is a solution within any formally defined >Unix or Posix standard. But according to >http://www.suse.de/~aj/linux_lfs.html the Linux 2.4 kernel supports >the Large File Support (LFS) interface. There is also a link to the >LFS specification: >http://ftp.sas.com/standards/large.file/x_open.20Mar96.html Thanks. I think that is a bit dated, but Jens' reply seems reflect actual practice and that should be enough to get started with. --Beman

1 0

boost_1_31_0_rc2 - Missing files,
by Joe Gottman 31 Jan '04

31 Jan '04

I discovered that there are a couple of missing html files in the rc2: \boost_1_31_0_rc2\libs\iterator\doc\iterator_traits.html and \boost_1_31_0_rc2\libs\iterator\doc\interoperable.html Joe Gottman

2 1

Linux RC_1_31_0 regression test questions
by Beman Dawes 31 Jan '04

31 Jan '04

Looking at http://boost.sourceforge.net/regression-logs/cs-Linux-RC_1_31_0.html to make sure we are in good shape for RC2 from the Linux perspective, I've got some (probably dumb) questions: * gcc 3.4 20040124 (prerelease) has 21 errors compared to 3 errors for gcc 3.3.1 and 3.3.2. Has anyone looked at the 3.4 errors and reported them to the appropriate gcc or Boost lists? Here are the three tests failing gcc 3.3.1 and 3.3.2: * iterator interoperable_fail * python embedding * type_traits is_abstract_test Do any of these raise alarm bells? Or are they all to be expected? --Beman

4 4

Re: [Type Traits] is_array and remove_bounds bug
by Jonathan Turkanis 31 Jan '04

31 Jan '04

"John Maddock" <john(a)johnmaddock.co.uk> wrote in message news:005801c3e27a$a6c4d1f0$4b580352@fuji... > > I have noticed that is_array and remove_bounds do not seem to work > > with array types of unknown bounds; e.g., > > > > BOOST_STATIC_ASSERT(!boost::is_array< int[] >::value); > > BOOST_STATIC_ASSERT((boost::is_same< boost::remove_bounds< int[] > > >::type, int[]>::value)); > > > > compile on GCC 3.2 and VC7.1. Is this the desired behavior? > > No, not at all. > > Thanks for the patches, No trouble. > ... this seems to be a strange corner case: VC7.1 > doesn't need the patches (it does the right thing without them), but gcc > does, while Borland doesn't compile the patched version, or do the right > thing without the patches... sigh. That's funny. My installation of VC7.1 defintely doesn't work with the unpatched version. > > Anyway, I've patched the headers and extended the test cases on my local cvs > copy, I've got the type traits regression tests running now, assuming > everything is OK, then I'll commit your patches when cvs comes back online. > How did the regressions turn out? BTW, while we're on the subject of remove_bounds, I think the documentation is slightly misleading. All the remove_xxx traits have a note under 'compiler requirements' essentially stating that the traits don't work correctly without partial specialization, 'except as noted below'. AFAICT, the note refers to the use of the macro BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION; however, this macro does not provide specializations of remove_bounds (and probably can't, efficiently). I therefore think it might be appropriate to remove 'except as noted below' from the remove_bounds documentation. I am I wrong? Thanks. Jonathan

2 1

Re: [boost] Re: Re: BOOST_STD_EXTENSION_NAMESPACE and dinkumware stdlib313
by John Maddock 31 Jan '04

31 Jan '04

> That's interesting. Since the compiler is determined before the > standard library, it would still be possible to put the definition in > boost/config/stdlib/dinkumware.hpp, like so > > #if defined(BOOST_MSVC) && (BOOST_MSVC >= 1310) > #define BOOST_STD_EXTENSION_NAMESPACE stdext > #endif > > Maybe one should check _CPPLIB_VER for good measure. This sounds > reasonable. What do you think? That sounds reasonable, I'll commit the changes to the main development branch when I get a chance, Intel uses Microsoft's headers (at least I think they do), so it'll be the same for them, but other vendors that use Dinkumware don't necessarily do the same thing (although again it's hard to be definitive). Thanks, John

1 0

Re: [boost] Fast-test-cycle Proposal [was 1.31.0 Progress (or lack thereof)]
by John Maddock 31 Jan '04

31 Jan '04

> > Would this be useful and worthwhile? Yes absolutely. John.

1 0

Incorrect link on the mailing lists page.
by Angus Leeming 31 Jan '04

31 Jan '04

http://www.boost.org/more/mailing_lists.htm Boost.Spirit lists Spirit has two additional mailing lists. Spirit-general for Spirit users and Spirit-devel for Spirit developers (open to anyone who wishes to hang out with Spirit coders). Both have GMane NNTP access (Spirit-general and Spirit-devel) with searchable archives ( Spirit-general and Spirit-devel). ^^^^^^^^^^^^^^ Both the searchable archives point to gmane.comp.parsers.spirit.devel Incidentally, when I go to the first 'Spirit-general' link: https://lists.sourceforge.net/lists/listinfo/spirit-general and click on To see the collection of prior postings to the list, visit the Spirit-general Archives. I get: ERROR Either your mailing list name was misspelled or your mailing list has not been archived yet. If this list has just been created, please retry in 2-4 hours Regards, Angus

5 8

Re: Very odd Comeau C++ behavior
by Comeau Computing 30 Jan '04

30 Jan '04

At 08:40 PM 1/26/2004 +0200, Peter Dimov wrote: >While implementing operator== for boost::mem_fn, I found that the following >program, which I expected to print '1' six times, mysteriously outputs 1 0 1 >1 0 1 under Comeau C++, causing all mem_fn equality tests to fail: > >#include <iostream> > >struct X >{ > int mf0_1() { return 0; } > int mf0_2() { return 0; } >}; > >struct mf0 >{ > typedef int (X::*F) (); > F f_; > > explicit mf0(F f): f_(f) {} > > bool operator==(mf0 const & rhs) const > { > return f_ == rhs.f_; Thanks for the report, it appears you've uncovered a problem. It's being looked into further. For now, this should work: return f_ == rhs.f_ ? true : false; > } > > bool operator!=(mf0 const & rhs) const > { > return f_ != rhs.f_; As well as here: return f_ != rhs.f_ ? true : false; > } >}; > >int main() >{ > std::cout << ( &X::mf0_1 == &X::mf0_1 ) << std::endl; > std::cout << ( mf0(&X::mf0_1) == mf0(&X::mf0_1) ) << std::endl; > std::cout << ( mf0(&X::mf0_1).f_ == mf0(&X::mf0_1).f_ ) << std::endl; > > std::cout << "--\n"; > > std::cout << ( &X::mf0_1 != &X::mf0_2 ) << std::endl; > std::cout << ( mf0(&X::mf0_1) != mf0(&X::mf0_2) ) << std::endl; > std::cout << ( mf0(&X::mf0_1).f_ != mf0(&X::mf0_2).f_ ) << std::endl; >} > >Output: > >C:\Documents and Settings\pdimov\My Documents\Projects\testbed>como >testbed.cpp >Comeau C/C++ 4.3.0.1 (Aug 21 2002 15:45:32) for MS_WINDOWS_x86 >Copyright 1988-2002 Comeau Computing. All rights reserved. >MODE:strict errors C++ > > >C:\Documents and Settings\pdimov\My Documents\Projects\testbed>aout.exe >1 >0 >1 >-- >1 >0 >1 > >Is this a known issue with Comeau C++ 4.3? Or is there something wrong with >the code? ------- Comeau C/C++ 4.3.3: Check out the $43.30 limited time offer Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90. Comeau C/C++ with Dinkumware's Libraries. Have you tried it? comeau(a)comeaucomputing.com http://www.comeaucomputing.com

1 0

Re: [boost] [Function] Implemented operator== and operator!=
by Peter Dimov 30 Jan '04

30 Jan '04

Douglas Gregor wrote: >> On the main branch, I've implemented operator== and operator!= for >> Boost.Function (but not in the form you expect). I am getting a C4800 warning from MSVC 7.1 ('int' forced to true/false) in function_template.hpp:299: bool equal = BOOST_FUNCTION_COMPARE_TYPE_ID(typeid(Functor), *type); return (equal? functor_ptr : make_any_pointer(reinterpret_cast<void*>(0))); That's because type_info::operator= returns an int (for ABI reasons, I presume.) This is a regression. The fix is trivial: return BOOST_FUNCTION_COMPARE_TYPE_ID(typeid(Functor), *type)? functor_ptr: make_any_pointer(reinterpret_cast<void*>(0)); The definition of BOOST_FUNCTION_COMPARE_TYPE_ID is: # define BOOST_FUNCTION_COMPARE_TYPE_ID(X,Y) (X==Y) It should be: # define BOOST_FUNCTION_COMPARE_TYPE_ID(X,Y) ((X) == (Y)) Also, I'm not really sure whether we should pre-emptively "fix" type_info::operator= like this. Bugfixes should be in response to actual bug reports.

3 2

Re: move_ptr
by David B. Held 30 Jan '04

30 Jan '04

Daniel, I got your email about the move policy and I replied to it. However, I have a flaky DNS entry for my domain, so your school's mail server was not able to resolve my email address and rejected my message. Anyway, thanks for the code, and I'll definitely look it over. Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.571 / Virus Database: 361 - Release Date: 1/26/2004

1 0

Line ending woes
by Beman Dawes 30 Jan '04

30 Jan '04

Here is some fresh information: * The reason the inspection program wasn't detecting more line ending problems was a really stupid bug by me - the files were not being read in binary mode. That made it look like the program was working, because it worked on a corner case which happened to be the case tested during development. Not only that, but html files weren't in the list of extensions being checked. Anyhow, both problems have been fixed in CVS. * Running the corrected inspect program shows 148 files with invalid line endings, in both the current CVS RC_1_31_0 branch and the release candidate. * Here are the RC2 counts by library: build 16 date_time 2 dynamic_bitset 1 graph 4 inspect 1 integer 2 math 7 mpl 1 python 1 spirit 113 * The current CVS head has 190 invalid line endings, with all of the increase coming in Spirit. That's worrisome; does it mean that some Spirit files are missing from the RC_1_31_0 branch? I'm not too worried about the scattered bad line ends in other libraries, but I'm definitely worried about Spirit. Before Joel or anyone makes wholesale fixes, I'd like to see one file fixed and checked. I'm also concerned that because we aren't 100% sure exactly what happened, it will bite us again. --Beman

2 2

Re: [boost] Re: impl(ementations) - keeping it simple
by Reece Dunn 30 Jan '04

30 Jan '04

John Torjo wrote: >Maybe to simplify the process, in boost-root (where boost-build.jam file >exists), we could have a makefile which automatically builds bjam from the >source files and the invokes it with a given configuation. > >like: >make msvc >(instead of bjam "-sTOOLS=msvc") > >Unfortunately, I don't have any makefile knowledge. I am knowledgeable in makefiles, but this leads to a problem: you need to configure the makefile to handle all the various compiler and platform combinations - something bjam already handles, so why duplicate this effort? Is there a bjam file for bjam?! That way it could be bootstrapped. But then why not just download a pre-built version of bjam? Regards, Reece _________________________________________________________________ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger

4 9

[bind] nested call of bind not compiled
by Alexey Nikitin 30 Jan '04

30 Jan '04

I try to compile next code: ===== my_test.cpp ===== #include <functional> #include <boost/bind.hpp> using namespace std; using namespace boost; struct my_assign_if { typedef void result_type; template<class T, class P> void operator()(T& dst, T const& src, P const& to_assign) const { if (to_assign()) dst = src; } }; int main() { int a=1, b=0; bind(my_assign_if(), ref(a), 0, _1)(bind(less<int>(), cref(b), 1)); // compiled bind(my_assign_if(), ref(a), 0, bind(less<int>(), cref(b), 1))(); // not compiled return 0; } ==================== and take next errors: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86 Copyright (C) Microsoft Corporation 1984-2002. All rights reserved. my_test.cpp my_test.cpp(11) : error C2064: term does not evaluate to a function taking 0 arguments C:\Alnik\heap\boost\boost-dev\boost\bind.hpp(335) : see reference to function template instantiation 'void my_assign_if::operator ()<T,boost::_bi::result_traits<R,F>::type>(T &,const T &,const P &) const' being compiled with [ T=int, R=boost::_bi::unspecified, F=std::less<int>, P=boost::_bi::result_traits<boost::_bi::unspecified,std::less<int>>::type ] C:\Alnik\heap\boost\boost-dev\boost\bind\bind_template.hpp(21) : see reference to function template instantiation 'R boost::_bi::list3<A1,A2,A3>::operator ()<boost::_bi::bind_t<boost::_bi::unspecified,F,L>::result_type,F,boost::_bi ::list0>(boost::_bi::type<T>,F,A &)' being compiled with [ R=boost::_bi::bind_t<boost::_bi::unspecified,my_assign_if,boost::_bi::list3< boost::_bi::list_av_3<boost::reference_wrapper<int>,int,boost::_bi::bind_t,boost::_bi::list2<boost::_bi::list_av_ 2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B1,boost::_bi::list_av_3<boost::reference_wrapper<int>,int ,boost::_bi::bind_t<boost::_bi::unspecified,std::less<int>,boost::_bi::list2 <boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B2,boost::_bi::list_av_3<boost::reference_wrapper<int>,int ,boost::_bi::bind_t<boost::_bi::unspecified,std::less<int>,boost::_bi::list2 <boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B3>>::result_type, A1=boost::_bi::list_av_3<boost::reference_wrapper<int>,int,boost::_bi::bind_ t<boost::_bi::unspecified,std::less<int>,boost::_bi::list2<boost::_bi::list_ av_2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B1, A2=boost::_bi::list_av_3<boost::reference_wrapper<int>,int,boost::_bi::bind_ t<boost::_bi::unspecified,std::less<int>,boost::_bi::list2<boost::_bi::list_ av_2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B2, A3=boost::_bi::list_av_3<boost::reference_wrapper<int>,int,boost::_bi::bind_ t<boost::_bi::unspecified,std::less<int>,boost::_bi::list2<boost::_bi::list_ av_2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B3, F=my_assign_if, L=boost::_bi::list3<boost::_bi::list_av_3<boost::reference_wrapper<int>,int, boost::_bi::bind_t<boost::_bi::unspecified,std::less<int>,boost::_bi::list2< boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B1,boost::_bi::list_av_3<boost::reference_wrapper<int>,int ,boost::_bi::bind_t<boost::_bi::unspecified,std::less<int>,boost::_bi::list2 <boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B2,boost::_bi::list_av_3<boost::reference_wrapper<int>,int ,boost::_bi::bind_t<boost::_bi::unspecified,std::less<int>,boost::_bi::list2 <boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B3>, T=boost::_bi::bind_t<boost::_bi::unspecified,my_assign_if,boost::_bi::list3< boost::_bi::list_av_3<boost::reference_wrapper<int>,int,boost::_bi::bind_t,boost::_bi::list2<boost::_bi::list_av_ 2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B1,boost::_bi::list_av_3<boost::reference_wrapper<int>,int ,boost::_bi::bind_t<boost::_bi::unspecified,std::less<int>,boost::_bi::list2 <boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B2,boost::_bi::list_av_3<boost::reference_wrapper<int>,int ,boost::_bi::bind_t<boost::_bi::unspecified,std::less<int>,boost::_bi::list2 <boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B3>>::result_type, A=boost::_bi::list0 ] C:\Alnik\heap\boost\boost-dev\boost\bind\bind_template.hpp(19) : while compiling class-template member function 'boost::_bi::bind_t<R,F,L>::result_type boost::_bi::bind_t<R,F,L>::operator ()(void)' with [ R=boost::_bi::unspecified, F=my_assign_if, L=boost::_bi::list3<boost::_bi::list_av_3<boost::reference_wrapper<int>,int, boost::_bi::bind_t<boost::_bi::unspecified,std::less<int>,boost::_bi::list2< boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B1,boost::_bi::list_av_3<boost::reference_wrapper<int>,int ,boost::_bi::bind_t<boost::_bi::unspecified,std::less<int>,boost::_bi::list2 <boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B2,boost::_bi::list_av_3<boost::reference_wrapper<int>,int ,boost::_bi::bind_t<boost::_bi::unspecified,std::less<int>,boost::_bi::list2 <boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B3> ] my_test.cpp(18) : see reference to class template instantiation 'boost::_bi::bind_t<R,F,L>' being compiled with [ R=boost::_bi::unspecified, F=my_assign_if, L=boost::_bi::list3<boost::_bi::list_av_3<boost::reference_wrapper<int>,int, boost::_bi::bind_t<boost::_bi::unspecified,std::less<int>,boost::_bi::list2< boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B1,boost::_bi::list_av_3<boost::reference_wrapper<int>,int ,boost::_bi::bind_t<boost::_bi::unspecified,std::less<int>,boost::_bi::list2 <boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B2,boost::_bi::list_av_3<boost::reference_wrapper<int>,int ,boost::_bi::bind_t<boost::_bi::unspecified,std::less<int>,boost::_bi::list2 <boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B3> ] My question: why? or that can not be used by this way? Regards, Alexey.

2 1

RE: [boost] Re: Re: Boost.Thread : IO multiplexing
by Darryl Green 30 Jan '04

30 Jan '04

> -----Original Message----- > From: Jeremy Maitin-Shepard [mailto:jbms@attbi.com] > Sent: Thursday, 29 January 2004 7:03 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: Re: Boost.Thread : IO multiplexing > > > "Hurd, Matthew" <hurdm(a)sig.com> writes: > > >> On Behalf Of Sean Kelly > >> > >> What remains an issue in my mind is how far to take this. > Socket and > >> file classes for each platform at least... what else? > > > Waitable timers would be the other "main" one I'd guess. > > Unfortunately, I do not believe that it is possible to wait on both a > timer and a file descriptor on POSIX platforms, so this is the same > situation as mutexes (see below). It is easy enough to do this - for example see ACE's Reactor Notify for details. If you care about other threads you need the notify interface to force a wake-up when a new timeout needs to be calculated, otherwise just calculating the timeout parameter from the head of the timer queue before blocking is enough. > > > Some process abstractions might be straight forward for > "kill" signals > > and the windows equivalent. > > Signal handling abstraction is probably best done by a separate > library. Signals are useful for dealing with asynchronous > i/o on POSIX > platforms, but I would recommend that non-blocking, but not > asynchronous I/O be used by the library on those platforms. > > > I would still like to see mutexes, timers, socket i/o and > file i/o all > > with similar acquisition concepts so there is a hope of > marrying them > > down the track if it is not done up front. > > I believe it has been concluded that there is pretty much no > way at all > of efficiently waiting on both a mutex and a file descriptor on most > POSIX platforms, including Linux and BSD. Furthermore, it is also > inefficient on Windows, since it requires use of > WaitForMultipleObjects, which doesn't scale well. I would not > recommend that an i/o multiplexing attempt to handle mutexes and > timers. > I don't see why the library shouldn't be generic enough to allow a unification on a platform that supports it. It may not be all that mythical - I'm sure there was some discussion and patches on lkml some time back suggesting that it is possible to extend epoll to work with futexes. On the opposite side of the coin, Linux 2.6 has extended aio in the kernel that should make aio a pretty reasonable option for that platform and at least tries to address most of the negatives mentioned re using aio on Posix platforms. Haven't tried to actually use it yet though! Regards Darryl. ########################################################################## This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. ##########################################################################

3 2

Re: [Function] Implemented operator== and operator!=
by Raoul Gough 30 Jan '04

30 Jan '04

Raoul Gough <RaoulGough(a)yahoo.co.uk> writes: > <#part type="text/plain" filename="d:/TEMP/gcc_296_err.txt" disposition=attachment > description="g++ 2.96 compiler output"> > <#/part> I guess I don't know how to drive my news reader! Here's the error output as inline text: g++ -fPIC -ftemplate-depth-120 -w -DNDEBUG -O3 -DBOOST_PYTHON_MAX_BASES=2 -DBOOST_PYTHON_SOURCE -I/foo/boost -I/usr/local_cci/Python-2.2.1t/include/python2.2 -c -o boost/libs/python/src/converter/arg_to_python_base.os /foo/boost/libs/python/src/converter/arg_to_python_base.cpp /foo/boost/boost/function/function_template.hpp: In method `void boost::function0<R, Allocator>::assign_to (const boost::reference_wrapper<FunctionObj> &, boost::detail::function::function_obj_ref_tag) [with FunctionObj = void (*) (), R = void, Allocator = allocator<boost::function_base>]': /foo/boost/boost/function/function_template.hpp:427: instantiated from `boost::function0<R, Allocator>::assign_to (Functor) [with Functor = boost::reference_wrapper<void (*) ()>, R = void, Allocator = allocator<boost::function_base>]' /foo/boost/boost/function/function_template.hpp:289: instantiated from `boost::function0<R, Allocator>::function0 (Functor, typename boost::enable_if_c<boost::type_traits::ice_not<boost::is_integral<Functor>::value>::value, int>::type) [with Functor = boost::reference_wrapper<void (*) ()>, R = void, Allocator = allocator<boost::function_base>]' /foo/boost/boost/python/errors.hpp:29: instantiated from `boost::python::handle_exception (T) [with T = void (*) ()]' /foo/boost/boost/python/errors.hpp:36: instantiated from here /foo/boost/boost/function/function_template.hpp:511: Internal error #373. /foo/boost/boost/function/function_template.hpp:511: confused by earlier errors, bailing out scons: *** [boost/libs/python/src/converter/arg_to_python_base.os] Error 1 scons: building terminated because of errors. /bar/build % g++ --version g++ --version 2.96 -- Raoul Gough. export LESS='-X'

1 0

Re: [Function] Implemented operator== and operator!=
by Raoul Gough 30 Jan '04

30 Jan '04

<#part type="text/plain" filename="d:/TEMP/gcc_296_err.txt" disposition=attachment description="g++ 2.96 compiler output"> <#/part> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (windows-nt) Cancel-Lock: sha1:mbn75GX0BrE0mKdP1bjMm9VxSrg= Douglas Gregor <gregod(a)cs.rpi.edu> writes: > On Tuesday 20 January 2004 01:29 pm, Douglas Gregor wrote: >> On the main branch, I've implemented operator== and operator!= for >> Boost.Function (but not in the form you expect). > > It's now documented. > > I've also checked in some changes to handle reference_wrapper logically: I just tried upgrading to the CVS mainline and got an internal compiler error in function_template.hpp when compiling one of the Python lib modules with gcc 2.96 linux. Reverting to RC_1_31_0 fixes the error. Recent lossage? /foo/boost/boost/python/errors.hpp:29: instantiated from `boost::python::handle_exception (T) [with T = void (*) ()]' /foo/boost/boost/python/errors.hpp:36: instantiated from here /foo/boost/boost/function/function_template.hpp:511: Internal error #373. /foo/boost/boost/function/function_template.hpp:511: confused by earlier errors, bailing out Compiler bug is documented at: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=57466 See attachment for more compiler output. -- Raoul Gough. export LESS='-X'

2 1

Graph: edge(u,v,g) isn't O(log(E/V)) as promised
by Alan Stokes 30 Jan '04

30 Jan '04

For an adjaceny_list which uses sets for its edges, edge(u, v, g) is supposed to be O(log(E/V)), as you would expect for a lookup in a set. (See http://www.boost.org/libs/graph/doc/using_adjacency_list.html#sec:choosing-….) But in fact it is linear in the number of out edges. This is because in graph/detail/adjacency_list.hpp (line 1325 in revision 1.113), in the edge_dispatch function that handles the disallow_parallel_edge_tag case, the code reads: i = std::find(g.out_edge_list(u).begin(), g.out_edge_list(u).end(), StoredEdge(v)), when it should probably be: i = g.out_edge_list(u).find(StoredEdge(v)), as it was in revisions 1.59 and previous. As an aside, it's not that obvious from the documentation that adjacency_list supports edge(u, v, g). AFAICT it's defined only in the AdjacencyMatrix concept, which adjacency_list is not documented as being a model of. [This is a repost - the original was in message 31695 on the 21st of January. But I foolishly reported two different problems with the same subject & in the same thread, only one of which was addressed. I'm assuming the other one was overlooked and so repeating it. I apologise if this assumption is incorrect.] - Alan

2 2

value_initialized added to libraries.htm
by Fernando Cacciola 30 Jan '04

30 Jan '04

Both on the main trunk and 1.31.0 RC2 Fernando Cacciola SciSoft

1 0

boost_1_31_rc2 - documentation glitches in tools/build/v2/
by Bronek Kozicki 30 Jan '04

30 Jan '04

1. GIF picture is corrupted: boost_1_31_0_rc2\tools\build\v2\c++boost.gif 2. two HTML files have bad "src" path to this picture: boost_1_31_0_rc2\tools\build\v2\doc\architecture.html boost_1_31_0_rc2\tools\build\v2\doc\extending.html B.

3 3

Who is the current maintainer of boost.thread?
by Roland 30 Jan '04

30 Jan '04

Some weeks ago Michael Glassford posted a question about the same subject. But as far as I can remeber without any answer. Did I miss something? Mike stated, that the original author silently disappeared from the list. The last relevant CVS commits have been done by a person named bill_kempf 11 months ago. Is this just a nickname for William Kempf? I like to restate the question, and also would offer to spend some of my time for helping in maintainance of the thread library. The submission_process.htm page also deals with Lifecycle, and says: "If you no longer can or wish to maintain your library, please post a message on the Boost developers mailing list and help someone else take over as the library maintainer." Does this also imply, that the only way to deal with an obviously silent maintainer, is to submit a totally new review request for a replacement library to move on with an otherwise stalled library? Regards, Roland

4 6

[graph] RC_1_31_0 bfs VC++ 7.1 failing metacomm only
by Beman Dawes 30 Jan '04

30 Jan '04

graph bfs VC++ 7.1 is passing on my machine but failing at runtime in Metacomm's tests. The only output is "EXIT STATUS: 666". Any ideas? --Beman

1 0

RE: [boost] Boost.Thread request: event object
by Sean Kelly 30 Jan '04

30 Jan '04

On Mon, 26 Jan 2004, Hurd, Matthew wrote: > > So are you saying that multiple threads calling WaitForSingleObject for > the same event is not safe or is the lack of safety elsewhere in the > windows event mechanism. I wouldn't mind a source url or something for > this if you have one so I can come up to speed. Aside from the papers linked to in the Boost.Thread documentation, the best thing to do is search comp.programming.threads for "windows" and "event." The discussion has come up there quite a few times, including some of the original talk about the Boost.Thread implementation. Alexander Terekhov (from this list) is involved in most of the discussions so you could search on his name as well. One such link is here: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=3e2ae910%240%245… By the way, I'm not saying that WaitForMultipleObjects is broken so much as that Windows events seem to be broken once you get beyond the fairly simple cases. Waiting on a mutex in Windows uses the WaitForObject calls as well, so I don't think the function itself is at issue. > I think WSFU if a crimson herring, best to forget about it. I don't think I'd ever want to require a customer to install WSFU to use my application, but from the documentation it seems quite solid. Rather than Win32 wrappers (ala Cygwin) it's actually an entire subsystem that contains a full posix implementation. I haven't done much more than skim the docs, but it's at least worth some play-time. As for the rest... I like to come to my own conclusions and an still reading up on the details in my rather limited free time. I will freely admit that I would be more likely to use the Boost condvar implementation everywhere rather than in just the complcated cases if I could safely do away with a large chunk of the code. I guess what I want is for someone to prove to me that the solution really does need to be as complex as it seems :) Sean

2 1

RE: [boost] Re: Re: Boost.Thread : IO multiplexing
by Darryl Green 30 Jan '04

30 Jan '04

> -----Original Message----- > From: Jeremy Maitin-Shepard [mailto:jbms@attbi.com] > I may be mistaken, but it seems that the new asynchronous I/O > completion system at least currently cannot be used with sockets. You are correct - I thought I saw a changelist somewhere that said otherwise but I must have been dreaming... Regards Darryl. ########################################################################## This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. ##########################################################################

1 0

(no subject)
by darin＠bentspoon.com 30 Jan '04

30 Jan '04

1 0

RE: [boost] Re: Re: Boost.Thread : IO multiplexing
by Hurd, Matthew 30 Jan '04

30 Jan '04

> On Behalf Of Sean Kelly > > What remains an issue in my mind is how far to take this. Socket and > file classes for each platform at least... what else? Waitable timers would be the other "main" one I'd guess. Some process abstractions might be straight forward for "kill" signals and the windows equivalent. I would still like to see mutexes, timers, socket i/o and file i/o all with similar acquisition concepts so there is a hope of marrying them down the track if it is not done up front. The other thing I'd like to see is a substitutable framework, like the synch stuff I posted a while ago, where you can develop to a particular policy concept, for example a shareable mutex, then substitute a single threaded or null mutex or anything else in. ACE has had something similar for many years and it is straight forward. The current interface does not support such use AFAICT, hence the synch wrapper I use. I'd be happy to document and clean this up if there is interest. Regards, Matt Hurd. IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

4 4

:Guess_Toolset in build.bat failed for mingw. Failed even correctthis one. please help as well.
by Herbert Yu 29 Jan '04

29 Jan '04

Not sure now. I downloaded version 1.30.2 of boost. The build.bat file in {root}\tools\build\jam_src cannot work correctly with mingw as it says. First I have to add following to build.bat for it can guess mingw call :Test_Path gcc.exe if not errorlevel 1 ( set BOOST_JAM_TOOLSET=mingw set BOOST_JAM_TOOLSET_ROOT=%FOUND_PATH%..\ goto :eof) setlocal & endlocal It guess first? Should use my environment first! I have set both BOOST_JAM_TOOLSET and TOOLS! set TOOLS=mingw Set BOOST_JAM_TOOLSET=mingw Even build.bat can guess my mingw, it failed as following: execunix.c: In function `execcmd': execunix.c:214: warning: passing arg 3 of `spawnvp' from incompatible pointer type C:\DOCUME~1\hyu\LOCALS~1\Temp/ccKYiaaa.o(.text+0x12f):timestamp.c: undefined reference to `file_time' C:\DOCUME~1\hyu\LOCALS~1\Temp/ccKYiaaa.o(.text+0x2cd):timestamp.c: undefined reference to `file_archscan' C:\DOCUME~1\hyu\LOCALS~1\Temp/ccKYiaaa.o(.text+0x315):timestamp.c: undefined reference to `file_dirscan' C:\DOCUME~1\hyu\LOCALS~1\Temp/ccCOkaaa.o(.text+0x131c):builtins.c: undefined reference to `file_dirscan' gcc -o bin.mingwx86\jam -DNDEBUG -DOPT_HEADER_CACHE_EXT -DOPT_GRAPH_DEBUG_EXT -DOP T_SEMAPHORE -DOPT_FIX_TARGET_VARIABLES_EXT -DOPT_IMPROVED_PATIENCE_EXT -DYYSTACKSIZE=5000 -s -O3 -finline-functions -DMINGW command.c compile.c exp and.c glob.c hash.c hcache.c headers.c hdrmacro.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c parse.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c execunix.c fileunix.c pathunix.c ...failed .cc bin.mingwx86\jam... ...failed updating 1 target... ...updated 2 targets... Can anyone help me? I am not on the list. Please reply to my email address as well. Thanks Herbert Yu

1 0

lightweight mutex for MacOS
by Martin Taylor 29 Jan '04

29 Jan '04

Hi I would like to put forward an implementation of a lightweight mutex for MacOS. I have tested it with shared_ptr_mt_test.cpp without problem. It's fairly short, so I hope you don't mind me posting it directly here for review. I should add also that I didn't really write this code (that's not a disclaimer - Howard Hinnant cooked it up after I asked the Codewarrior newsgroup for help!) Anyway, here's the code: #if __MACH__ #include <sched.h> #else #include <Multiprocessing.h> #endif namespace boost { namespace detail { class lightweight_mutex { private: volatile int a_; lightweight_mutex(lightweight_mutex const &); lightweight_mutex & operator=(lightweight_mutex const &); public: lightweight_mutex(): a_(0) { } class scoped_lock; friend class scoped_lock; class scoped_lock { private: lightweight_mutex & m_; scoped_lock(scoped_lock const &); scoped_lock & operator=(scoped_lock const &); void yield_thread() { #if __MACH__ sched_yield(); #else MPYield(); #endif } public: explicit scoped_lock(lightweight_mutex & m); ~scoped_lock() { m_.a_ = 0; } }; }; inline lightweight_mutex::scoped_lock::scoped_lock(lightweight_mutex & m) : m_(m) { register volatile int *p = &m_.a_; register int f; register int one = 1; asm { loop: lwarx f, 0, p cmpwi f, 0 bne- yield stwcx. one, 0, p beq+ done } yield: yield_thread(); goto loop; done: ; } } // namespace detail } // namespace boost Martin

6 14

Gmane archive problems
by Gennaro Prota 29 Jan '04

29 Jan '04

FYI, this is a notice that appears at the top of Gmane's homepage (http://gmane.org) ------------- Problems January 29th 2004: By mistake Gmane ran an expiry process last night, which means that most of the articles are gone from the spool. They are now being rescued from backup, but this process will likely take a few days. ------------------- Genny.

1 0

Re: 1.31.0 Release candidate 2 available - some nitpicks
by Baptiste Lepilleur 29 Jan '04

29 Jan '04

----- Original Message ----- From: "Joel de Guzman" <joel(a)boost-consulting.com> To: "Baptiste Lepilleur" <blepctc(a)free.fr> Sent: Thursday, January 29, 2004 11:53 AM Subject: Re: 1.31.0 Release candidate 2 available - some nitpicks > Baptiste Lepilleur wrote: > > >>>Joel de Guzman wrote: > >>> > >>> > >>>>Pavel Vozenilek wrote: > >>>> > >> > >>[...] > >>I see no empty blank lines. Could someone else please confirm this? > > > > > > Line ending of all HTML files of spirit are of the form '\r\r\n' (just look > > at them with a binary editor). It's likely the result of a checking in unix > > file format from a windows platform (or something like that). You need to > > run some tools to fix line endings. > > That's actually the first thing that I did. Check out the link I > gave [http://tinyurl.com/2tokp] See if you can find double \r. > As I said, I think the problem is with the zip file. The CVS version > is clean. You're correct, but the line endings of the CVS are already wrong. They are '\r\n' (dos), but the cvs is running on a linux box, it should be '\n'... When it get checked out on windows, '\n' becomes '\r\n' and therefore '\r\n' becomes '\r\r\n'. Running a line ending clean up tools to conform the local platform, and checking the files back in would fix the issue. Baptiste. > > Regards, > -- > Joel de Guzman > http://www.boost-consulting.com > http://spirit.sf.net >

1 0

1_31_0_rc2 python2.3 warning (nit)
by Neal D. Becker 29 Jan '04

29 Jan '04

Any use of 1_31_0_rc2 with python2.3 gives: /usr/include/python2.3/pyconfig.h:847:1: warning: "_POSIX_C_SOURCE" redefined In file included from /usr/include/limits.h:26, from /usr/lib/gcc-lib/i386-redhat-linux/3.3.2/include/limits.h:122, from /usr/lib/gcc-lib/i386-redhat-linux/3.3.2/include/syslimits.h:7, from /usr/lib/gcc-lib/i386-redhat-linux/3.3.2/include/limits.h:11, from /usr/local/src/boost_1_31_0_rc2/boost/python/detail/wrap_python.hpp:27, from /usr/local/src/boost_1_31_0_rc2/boost/python/detail/prefix.hpp:13, from /usr/local/src/boost_1_31_0_rc2/boost/python/class.hpp:9, from /usr/local/src/boost_1_31_0_rc2/boost/python/suite/indexing/indexing_suite.hpp:10, from /usr/local/src/boost_1_31_0_rc2/boost/python/suite/indexing/vector_indexing_suite.hpp:10, from Test.cc:1:

2 1

Re: [boost] Re: 1.31.0 Release candidate 2 available - some nitpicks
by Reece Dunn 29 Jan '04

29 Jan '04

Joel de Guzman wrote: >Pavel Vozenilek wrote: >>2. Spirit 1.8 docs: each line in code snippets is appended >> by empty line. Seems as CSS problem (unless its feature). > >Hmmm... which code snippets? I can't find them. I have had a look at the docs. For example, libs/spirit/doc/scanner.html has the following code snippet: template< typename IteratorT = char const*, typename PoliciesT = scanner_policies<> > class scanner; The problem is in the html sources where every line is folloowed by a blank line, e.g.: <html> <head> <title>The Scanner and Parsing</title> ... -- this seems to be a problem with the HTML code generator. Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

10 14

bjam docs for boost developers?
by Jeremy Siek 29 Jan '04

29 Jan '04

Hi All, Are there bjam docs for boost developers that explain how to write a Jamfile in the style of the Jamfiles in the existing boost libraries? I already know about: http://www.boost.org/tools/build/jam_src/index.html but that doesn't cover stuff like "run" and "compile" and "link-fail". -Jeremy ------------------------------------------------------------------------ ----------------- Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: jsiek(a)osl.iu.edu C++ Booster (http://www.boost.org) office phone: (812) 856-1820 ------------------------------------------------------------------------ -----------------

4 6

boost_1_31_0_rc2 link check results
by Neal D. Becker 29 Jan '04

29 Jan '04

LinkChecker 1.10.3 Copyright ?2000-2004 Bastian Kleineidam LinkChecker comes with ABSOLUTELY NO WARRANTY! This is free software, and you are welcome to redistribute it under certain conditions. Look at the file `LICENSE' within this distribution. Get the newest version at http://linkchecker.sourceforge.net/ Write comments and bugs to calvin(a)users.sourceforge.net Start checking at 2004-01-29 09:11:04-004 URL http://www.boost.org/LICENSE_1_0.txt Name www.boost.org/LICENSE_1_0.txt Parent URL file:///usr/local/src/boost_1_31_0_rc2/index.htm, line 465, col 21 Real URL http://www.boost.org/LICENSE_1_0.txt Check Time 0.253 seconds Result Error: 404 Not Found Thats it. 1 error in 129 links found Stopped checking at 2004-01-29 09:11:19-004 ( 14.760 seconds)

1 0

RE: [boost] Re: Re: Boost.Thread : IO multiplexing
by Hurd, Matthew 29 Jan '04

29 Jan '04

> On Behalf Of Sean Kelly > Subject: Re: [boost] Re: Re: Boost.Thread : IO multiplexing > > IOCP works for both file and socket operations. Perhaps not a poll > method but I'm not much interested in the low-end solutions anyway. Small point. Please don't knock the pollster ;-) Polling trades CPU for latency gain. Polling is a high end solution for low latency requirements, which covers a lot of my issues (not the psychological ones though ;-)). Not so good for high throughput systems, but it can be. A combined approach, poll for a while you can then wait for an interrupt ( a bit like spin-locks ), can be especially beneficial for supercomputer oriented frameworks as plenty of research shows. A polling, single threaded architecture is often best for the style of performance oriented apps I develop. I have also seen some neat SAN software developed with polling that wouldn't have otherwise worked at all well. Regards, Matt Hurd. IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

3 2

Index.html for 1.31.0 and spirit
by Russell Hind 29 Jan '04

29 Jan '04

Is the index.html complete for 1.31.0? I think something could be mentioned for spirit as to what version it is now, and also the fact that it nolonger supports bcc32 compilers just to give people a warning that they are best to stick with 1.30.2 if they use spirit and borland compilers. (Or replace the spirit directory with the one from 1.30.2) Cheers Russell

3 3

[1.31 RC2, format] BCB problem
by Pavel Vozenilek 29 Jan '04

29 Jan '04

Borland C++ 6, patch 4, format_implementation.hpp: template< class Ch, class Tr> basic_format<Ch, Tr>& basic_format<Ch, Tr>:: operator= (const basic_format& x) { if(this == &x) return *this; (basic_format(x)).swap(*this); <<<=== here it fails return *this; } [C++ Error] format_implementation.hpp(93): E2102 Cannot use template 'basic_format<Ch,Tr>' without specifying specialization parameters Adding template parameters helped here: (basic_format<Ch, Tr>(x)).swap(*this); /Pavel

3 2

Re: [boost] Re: Re: Boost.Thread : IO multiplexing
by Roland 29 Jan '04

29 Jan '04

(Michael Glassford <glassfordm(a)hotmail.com>) wrote: > Sean Kelly wrote: > > I'm not sure that much if anything would need to be done to provide > > support for IO multiplexing in Boost. ... > That, of course, would be the best solution. Have you looked at the > code in the orignal post to see if such a solution would solve his > problem? > ... > > I guess the question > > becomes, is there a need for such an IO library in Boost? The > nature > > of the project would demand a good bit of custom code for each > > platform, which isn't typical of Boost components. I have been off for a few days now, and I like to see that I have arrived at the very same conclusions than you. 1) I believe now that most likely everything can be done with boost.thread as is (question still is performance) 2) I used an approach as 1 thread / WFMO instead beeing able to directly wait on condvars _and_ IO simulateneously. (Altough this approach isn't easily portable, as it contains a lot of platform dependencies. Also this approach does not scale very well for the multiplexing case since WMFO/select scenarios are limited in the number of waitable things. This is where IO completion should enter the scene.) 3) I agree that the real question should be whether there should be a such an IO library in boost. Personally I would vote for such a thing, perhaps based on already existing "C" async_io libs, much like the pthreads lib. If anyone is interseted I could try to post my files, but I am not sure where I should post them since they are more a bit of example appliaction code than library code. Would the boost files area be adequate? Roland

4 9

Re: [boost] 1.31.0 Release candidate 2 available
by Jeremy Siek 29 Jan '04

29 Jan '04

Hi Beman, On Wed, 28 Jan 2004, Beman Dawes wrote: bdawes> Good catch! adj-matrix-graph2.gif, subgraph.gif, and bdawes> undir-adj-matrix-graph2.gif are checked in a regular rather than binary bdawes> files. bdawes> bdawes> Jeremy? Ok, I think I got those fixed. Also, I fixed the bad figure references in adjacency_list.html and adjacency_matrix.html. Cheers, Jeremy ---------------------------------------------------------------------- Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: jsiek(a)osl.iu.edu C++ Booster (http://www.boost.org) office phone: (812) 856-1820 ----------------------------------------------------------------------

1 0

RE: [boost] Boost.Thread request: event object
by Hurd, Matthew 29 Jan '04

29 Jan '04

> On Behalf Of Daryle Walker > Subject: Re: [boost] Boost.Thread request: event object > > >> > >> if( lock const& l = lock(guard,t)) > > > > I like this last one, though I suspect I'll end up with > > > > if (lock lk(guard,t)) > > > > in my code as it will be the first thing I'll think of. > [TRUNCATE] > > Did you see my last message in this thread? I said that the rules of C++ > _FORBID_ creation of multiple objects and/or use of the constructor call > syntax when using object creation with the condition of an "if" or > "while". > The single object syntax with "=" is the only one allowed. > > -- > Daryle Walker Quite right. My sloppiness. Thanks Daryle. Matt Hurd. IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

The quick_allocator not-a-memory-leak
by Darren Cook 28 Jan '04

28 Jan '04

I've a class using the boost quick_allocator like this: class Chain{ //... void* operator new(std::size_t sz){ return boost::detail::quick_allocator<Chain>::alloc(sz); } void operator delete(void *p,std::size_t sz){ boost::detail::quick_allocator<Chain>::dealloc(p,sz); } //... }; I've started using valgrind ( http://valgrind.kde.org/ ) to look for memory problems in my unit tests and it is complaining that the memory is never released. Now I understand this: // "Listen to me carefully: there is no memory leak" // -- Scott Meyers, Eff C++ 2nd Ed Item 10 But is there some function I can call at the end of my program to: a) confirm I've called dealloc() for every alloc() and that the next pointer is currently at start b) release the memory. Valgrind supports suppressing the complaint but the check of deallocs matches allocs would be a useful test anyway. Darren

2 2

RE: [boost] Re: 1.31.0 Release candidate 2 available - some nitpicks
by Reece Dunn 28 Jan '04

28 Jan '04

Pavel Vozenilek wrote: >2. Spirit 1.8 docs: each line in code snippets is appended > by empty line. Seems as CSS problem (unless its feature). I'm not sure (haven't checked the Spirit source), but if they use <pre> elements, the fix is: <pre style = "margin-bottom: 0px">...</pre> or using CSS: pre{ margin-bottom: 0pc; } Regards, Reece _________________________________________________________________ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger

1 0

Re: impl(ementations) - keeping it simple
by Russell Hind 28 Jan '04

28 Jan '04

David Abrahams wrote: > > 2. We have no control over compiler flags or other settings that > may be neccessary for the library to work, nor that different > libraries are compiled with compatible options > But for this, implementing pre and post fix headers for other compilers as John Maddock has done for Borland and Microsoft compilers can get around this. Without these, if users build the libraries using bjam, they are required to look in the bjam sources to see which options were used, and use them in their project, or as I have done for 1.30.2, create a set of wrapper headers which push the bjam compiler options, include the original boost header, then pop the new options to reset them back to project default. I now only every include the wrapper headers, never the boost headers directly. Cheers Russell

2 1

RE: [boost] Re: Re: BOOST_STD_EXTENSION_NAMESPACE and dinkumware stdlib313
by Richard_Cox＠Dell.com 28 Jan '04

28 Jan '04

On Tuesday, January 27, 2004 12:05 AM, Reece Dunn said: > > I agree. The question is, should the test be BOOST_MSVC >= 1310 or > BOOST_MSVC == 1310, likewise for the _CPPLIB_VER test. I say > this because a > future version of VC may move hash_xxx back into the std > namespace for > future standard library conformance (does TC1 have hash_map, etc.?). Looking at the "Whidbey" technical preview (the next version of Visual Studio... including the next version of VC++), this has not changed (yet). Richard -- All opinions are personal and do not represent the views of my employer.

2 1

Re: [boost] [review] Review Request: "Wave: a Standards conformant C++ preprocessor library"
by Daryle Walker 28 Jan '04

28 Jan '04

On 1/26/04 1:28 AM, "Hartmut Kaiser" <hartmutkaiser(a)t-online.de> wrote: [SNIP] > The main goals for the Wave project are: > > . full conformance with the C++ standard (ISO/IEC 14882:1998) and with the > C99 standard (INCITS/ISO/IEC 9899:1999) [TRUNCATE] You can set these on strict-mode (i.e. no extensions), right? Obviously, the strict C++98 and strict C99 modes have to be distinct. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1

A new version of "more_io"
by Daryle Walker 28 Jan '04

28 Jan '04

Besides some tweaks, did the following big changes/additions: * Replaced "multi_deliminator" with its separate input and output parts, "multi_basic_newer" and "multi_basic_skipper". (So "multi_newer" now calls "multi_basic_newer" and "multi_skipper" now calls "multi_basic_skipper".) * Added a 'form'-based manipulator "basic_ios_form". You create a manipulator object, change its stream settings, and those changed settings are applied on a stream for an one-time use on a streamable object. It uses complex C++, so not all systems may accept it. * Added a new stream for constant values "value_stream". A dual to null-streams, it simulates "/dev/zero" by always returning '\0' for input operations, and does nothing but EOF for output operations. (The character returned can be configured at construction time.) It is at <http://groups.yahoo.com/group/boost/files/more_io_3b.zip>. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

Re: [boost] Re: move_ptr
by Peter Dimov 28 Jan '04

28 Jan '04

Howard Hinnant wrote: > On Jan 26, 2004, at 4:59 PM, Daniel Wallin wrote: > >> Howard Hinnant wrote: >>> <snip> >>> And I submit that: >>> S<T[], my_deleter> >>> is more elegant syntax than: >>> S_array<T, my_deleter> >> >> FWIW, I'm not sure it's a good idea to design the interface around >> partial specialization. std::vector<> replaces almost every possible >> need for array allocation, so does this use case really need to be >> less verbose? Is it worth dropping support for older compilers? > > Need to be? No. But I still like it. <shrug> I was convinced > because that's how a newbie expected it to work. I'm starting to not like it. :-) The problem is: template<class X> void f(S_ptr<X> px); where f doesn't support arrays. A reasonably common occurence. S_array<> doesn't match, but S_ptr<T[]> does. The author of f would need to learn about enable_if to prevent array pointers from being passed to f. This is not good, although the exact degree of not-goodness is somewhat debatable.

6 8

Re: [boost] move_ptr
by Daryle Walker 28 Jan '04

28 Jan '04

On 1/26/04 6:42 PM, "Howard Hinnant" <hinnant(a)twcny.rr.com> wrote: [SNIP] > for me. Does that address your concern, or have I missed your point? Yes. No. (You did address the concern and not missed the point.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

Re: [boost] Boost.Thread request: event object
by Daryle Walker 28 Jan '04

28 Jan '04

On 1/26/04 4:50 PM, "Hurd, Matthew" <hurdm(a)sig.com> wrote: >> On Behalf Of Sean Kelly [SNIP] >> or better yet: >> >> if( lock const& l = lock(guard,t)) > > I like this last one, though I suspect I'll end up with > > if (lock lk(guard,t)) > > in my code as it will be the first thing I'll think of. [TRUNCATE] Did you see my last message in this thread? I said that the rules of C++ _FORBID_ creation of multiple objects and/or use of the constructor call syntax when using object creation with the condition of an "if" or "while". The single object syntax with "=" is the only one allowed. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

Re: [boost] [administrative] Formal Review Process
by Daryle Walker 28 Jan '04

28 Jan '04

On 1/26/04 10:33 AM, "David Abrahams" <dave(a)boost-consulting.com> wrote: [SNIP] > I think we should: > > a. Make being a review manager or a moderator or a wizard one of the > conditions of having a library in boost [TRUNCATE] This might create a barrier (anyone that wants a writer hat to have an admin hat forced on them) that discourages contributions. Let's not blur the line between writers and admins. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

Re: [boost] impl(ementations) - keeping it simple
by Daryle Walker 28 Jan '04

28 Jan '04

On 1/25/04 11:23 PM, "John Torjo" <john.lists(a)torjo.com> wrote: > Again, I'm pretty frustrated that some libraries have source files that > need to be compiled separately (using bjam). > > I was thinking that we could have a directory '/boost/impl', and each > library that has sourse files could have an .hpp file that includes all > of its source files (that would normally need to be compiled separately). > > This way, any user, even not having bjam, can include the implementation > of a library, as simple as: > // this is included in ONLY one source file > #include <boost/impl/filesystem.hpp> We have some implementation files as *.cpp for a reason. Some implementations were _never_ meant to be forced through the #include system (structure-wise, not just size-wise). If the files are large, the compilation time can go up dramatically. > As a regular user, I'd rather have the above, than having to use bjam to > build a library. You wouldn't know it from how most talk about it here, but you don't need to use Bjam (I don't). You can include the appropriate Boost files (or search directories) directly in your IDE project file. For mandatory source, finding the file initially, or knowing that they're needed, is the problem. > If people agree, I volunteer to create the /boost/impl directory for all > the libraries that now need to be compiled separately, somewhere this week. I wouldn't agree. But I do think we need a top-level "src", "boost_src", "source", or "boost_source" directly that all the mandatory source files will be moved to for easy access. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

Re: [boost] Re: impl(ementations) - keeping it simple
by Robert Ramey 28 Jan '04

28 Jan '04

Reece Dunn wrote: >John Torjo wrote: >>Maybe to simplify the process, in boost-root (where boost-build.jam file >>exists), we could have a makefile which automatically builds bjam from the >>source files and the invokes it with a given configuation. >> >>like: >>make msvc >>(instead of bjam "-sTOOLS=msvc") >> >>Unfortunately, I don't have any makefile knowledge. ahhh - we've come full circle. >I am knowledgeable in makefiles, but this leads to a problem: you need to >configure the makefile to handle all the various compiler and platform >combinations - something bjam already handles, so why duplicate this effort? >Is there a bjam file for bjam?! That way it could be bootstrapped. But then >why not just download a pre-built version of bjam? Bascally I think the whole purpose of bjam is to address the concerns of the original poster. Unfortunately, this is not obvious from the information on bjam that comes with the system. I realise that the information is available - its just that is spread around in several places. Bjam is a large subject and requires almost a book to explain it. BUT it (or something like it is necessary for boost - as was obvious to the original poster. The central purpose of the bjam system is to specify how to build programs in a generic way independent of any particular platform while at the same time specify how each platform handles particular aspects of the application developement. This is a very ambitious concept and has resulted (not surprisingly) in a system that is pretty elaborate. A very ambitiuos effort. In one important way, its not ambitious enough. Unlike the rest of boost, it seems directed a bit narrowly to building and testing boost libraries. I get this impression from the fact that much effort is being invested in the code but relatively little in producing a complete, coherent and well organised explanation of how to make best usage of it. Maybe we can sucker someone in writing an O'Reilly book on this which would include the bjam system? Of course this would need a more polished system. I'm sorry go on about this, the thing just drives me crazy. John Torjo - bjam is exactly what you're looking for - its just not clear from the explanation. Robert Ramey

2 1

Re: [administrative] Formal Review Process
by Dave Gomboc 28 Jan '04

28 Jan '04

] David Abrahams wrote: ] ] ] Dave Gomboc <dave(a)cs.ualberta.ca> writes: ] ] ] ] It's a good idea, but I have to ask: is this a bicycle shed ] ] discussion? Does tweaking the seconding process really ] solve any of ] ] Thomas' problems? ] ] At least it's my shed. I think it can reduce the workload for ] the review wizard. ] ] Thomas Quoting issue here: that was Dave A.'s text, not mine. Dave

1 0

Re: [administrative] Formal Review Process
by David Abrahams 28 Jan '04

28 Jan '04

Dave Gomboc <dave(a)cs.ualberta.ca> writes: > ] I suggest that such a requirement be added to the formal > ] review process, with a specific (low, ie, 3) number of > ] "formal seconds" required for a formal review request in > ] order for it to reach the schedule. It should be explicitly > ] noted that "seconding" a review request does not imply a vote > ] to accept, nor a commitment on the part of the person > ] seconding to participate in the review. > > I also like the idea, but with a twist: it should be explicitly > noted that seconding a review request _does_ imply a commitment to > review the library should a review be scheduled for it. It's a good idea, but I have to ask: is this a bicycle shed discussion? Does tweaking the seconding process really solve any of Thomas' problems? -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

Re: [boost] Re: [administrative] Formal Review Process
by Jeff Garland 28 Jan '04

28 Jan '04

On Mon, 26 Jan 2004 22:10:23 -0800, Thomas Witt wrote > > Jeff Garland wrote: > > I don't like the idea of a mailing list to solve this problem. > > Why? Really I just want to know. Because the primary issue is a lack of time and I don't see how complicating things with another mailing list solves that problem. Also, if review comments either intentionally or accidently wind up on a review list then there is a third list I now have to search when looking into the archive -- I've had to look on the dev and user groups a few times because I can't remember where a particular discussion occurred. > There is more to the filtering than meets the eye. The usual process > up to know was that somebody posted a request. That request usually > lead to some discussion. As a result in quite a few cases the Which is one reason why I believe this needs to stay on the dev list... > library author decided to tackle the issues before the request. I've > been following these discussions in order to see whether the request > is likely to be withdrawn or not. The net effect of all this a lot > of postings use review in the subject line and are neither requests > nor formal review related. I am not criticising poeple for doing > this I just try to present the current situation. Yep. > Another issue that is related to this problem is that we are already > close to having more review requests than we can handle. (I am not > talking about the wizard here, just the list and the reviewers). I don't agree. There were more reviews in 2002 (15) than 2003 (~10) by my count. My guess is that about 1 full review per month is about what can be reasonably done. I, for example, have not been a review manager for a year so I don't feel over-worked. >In the past we already had reviews where there was very little feedback. That is an issue for the review manager to handle. I would leave it up to the judgement of the review manager to decide if there has been enough participation. If the participation is too low then the library should probably be rejected for lack of interest. But again that is the judgement of the review manager to make. As for the number of review requests, > In my opinion we need some kind of staging in order to streamline > the influx of libraries in the formal review process and to improve > the quality of reviewed libraries. Thus making failure for trivial > reasons more unlikely. I don't recall any specific examples of this. We already have a multi-stage review process. Sure there are examples of people just joining and throwing out a library for formal review before it is ready, but someone then provides guidance on the process. > I think the idea of a separate mailing list fits into this staging > strategy. I.e. the review list would be reserved for review and > review only. One idea might be to require a pre review on the > developers list or required 2-5 people to second the review request. Sure, but it complicates life for users trying to decide which lists to subscribe to, post to, and search. There won't be anything to stop someone from posting a half-baked library on the new list or accidentally posting a review request on the dev list... > > I think some simple additions to the submission process would solve the > > 'heads-up' to the review manager problem: > > A copy of the Review Request posting should be sent directly to > > the review wizard (email here). If the review wizard does not > > respond with an acknowledgement within 48 hours another request > > should be made. > > As explained not every request leads to a review. Sure, but at least the submitter would be aware that you are paying attention. So the acknowledgement is not a date for the review, but just a little "hello, I see your request, have you read the submission guidelines" sort of mail. > > Also, note that the entire discussion of the Review Wizard is on > > the Formal schedule the review. > > I would really appreciate it if you could make that change. Sure. > > Finally, it seems to me the real solution is to either split the duties or > > find another review wizard volunteer. > > As of now I don't have a good idea how things can be split up. Perhaps you can offload the monitoring or organization of a particular upcoming review -- I'm sure we can figure something out. > > I'm willing to spend a couple hours a > > month on this if it would help, so Thomas send me an email > > off-list if you have something you want to offload on me. > > Thanks Jeff! I'll shoot you an email as soon as I see clearer. Let me know. Jeff

3 3

Re: [boost] Re: [administrative] Formal Review Process
by Douglas Gregor 28 Jan '04

28 Jan '04

On Tuesday 27 January 2004 01:20 am, Thomas Wenisch wrote: > This idea of seconding a review request is an extremely good idea. It > adds formality to what is captured in the current process as "post to list > and see if there is interest". The fact that someone seconds a review > request demonstrates that there is interest in the library, and that there > are people who are following the review list that might be inclined to > review. > > I suggest that such a requirement be added to the formal review process, > with a specific (low, ie, 3) number of "formal seconds" required for a > formal review request in order for it to reach the schedule. It should be > explicitly noted that "seconding" a review request does not imply a vote > to accept, nor a commitment on the part of the person seconding to > participate in the review. It just is an indication that a library is > interesting and worthy of review (and worthy of consuming time on the > schedule that could be used reviewing other libraries). I too like the idea of seconding a formal review request, but I'd rather that "seconding" imply that someone has looked over the library and found that it is in reasonably good shape for a formal review. Otherwise, we'll still have the problem Thomas W. is describing where a formal review is requested, several people "second" because they are interested, but the formal review won't happen because the library isn't ready. Doug

2 1

bccx and lambda (possible config problem)
by Russell Hind 28 Jan '04

28 Jan '04

Using 1.31-RC1, I have successfully made use of some of boost with Borland's bccx compiler. (I think John Maddock has done the work for this, so thanks). But I can't use the bind from Lambda with the new compiler with functions that return void. e.g. this won't compile (error is "lambda_functors.hpp": a void function may not return a value at line 159) #include <boost/function.hpp> #include <boost/lambda/lambda.hpp> #include <boost/lambda/bind.hpp> using namespace boost::lambda; void test(int a, int b) { } int main(int argc, char * argv[]) { boost::function<void (int a, int b)> f(bind(test, 10, _1)); return 0; } Has anyone any ideas if the config for bccx needs updating, or is this just a bug in the compiler and so we'll have to wait for an update to it? Thanks Russell

1 0

Re: Detection of wchar_t for Intel compiler
by Giovanni Bajo 28 Jan '04

28 Jan '04

Guillaume Melquiond wrote: > There was a recent change to the config/compiler/intel.hpp file in > order to change (one more time) the way the detection of wchar_t works. I did it, and discussed it on this very list. > So I've committed a trivial fix to CVS head. However it was a bit > annoying to note that a patch had been committed to such an important > place carefreely (otherwise the bug would have been found). This is my > first concern: the configuration of a compiler had been changed > without even being tested. You're implying way too much. There was a typo on my part, sure, but it wasn't detected under Windows. I *did* test it, and we did discuss the patch on the list. I never commit untested patches. > Second concern: since the patch was not tested on this > compiler/platform configuration, is it sure it behaves sanely? Please, review our discussion on the topic. > Sincethere was a lot of > changes in this area, shouldn't a specific test file be added in order > to finally ensure the correct detection of wchar_t? I can also > directly exercise some testcases if provided; I can test with ICC 7 > and 8 for Linux. We need to do a detection through the preprocessor. > Finally, my third concern: shouldn't such changes be committed to the > release branch since they directly involve the configuration of an > existing compiler? Again, please review the discussion. I told that I would commit it to the release branch after a few days, to not destabilize the branch. In fact, I was awaiting fallouts on different platforms, just like the one you fixed. If I had committed it to the release branch immediatly, I would have broken it as well. > Sorry for this long mail, but since release time draws near, I wanted > to point out this problem. Thank you for the fix. -- Giovanni Bajo

2 1

Re: [constant] New version + YANL- tests with MS 7.1
by David Abrahams 28 Jan '04

28 Jan '04

"Paul A. Bristow" <boost(a)hetp.u-net.com> writes: > However, the major snag is MS lack of __typeof__. Until this is solved, it is a > non-starter :-(( The problem isn't with the MS compiler, but with the library. Libraries that rely on nonstandard language extensions are non-starters at Boost. -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

Re: class static constants, mpl, and linker problems
by David Abrahams 28 Jan '04

28 Jan '04

Matthias Troyer <troyer(a)itp.phys.ethz.ch> writes: > Dear Daniel, > > If you use BOOST_STATIC_CONSTANT you need to additionally provide a > definition on conforming compilers. The correct usage is like in: > > // declaration > class A { > BOOST_STATIC_CONSTANT(int , x=1); > }; > > .... > > //definition > #ifndef BOOST_NO_INCLASS_MEMBER_INITIALIZATION > int A::x; > #endif > > > I hope that clarifies this issue, Another approach is to use mpl::int_<n> or integral_c<T,n> which supply the definitions themselves. -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 3

Re: class static constants, mpl, and linker problems
by Daniel Krügler 28 Jan '04

28 Jan '04

Hello Matthias, Matthias Troyer schrieb: > Dear Daniel, > > If you use BOOST_STATIC_CONSTANT you need to additionally provide a > definition on conforming compilers. The correct usage is like in: > > // declaration > class A { > BOOST_STATIC_CONSTANT(int , x=1); > }; > > .... > > //definition > #ifndef BOOST_NO_INCLASS_MEMBER_INITIALIZATION > int A::x; > #endif > > > I hope that clarifies this issue, No, it doesn't, please read the original thread carefully. I am aware of the fact, that an integral or enumeration type static member needs a corresponding definition and I hope my contribution has made that clear to everyone. Your answer implies, that users of the boost library are responsible for providing these definitions for boost constants. If so, I think that would be bad news. Consider those many hidden constants in whatever boost::details namespace or other implementation-dependent data items. How should the boost user correctly provide the necessary definitions? To my opinion boost should at least provide in the libs section source files with possibly necessary definitions of all externally accessible constants, which the user can translate if necessary. I also want to add, that although my example seems artifical, it should show a basic problem. Consider a simple "algorithm" like std::max which takes constant references as arguments. You cannot demand, that boost users must watch out for those or similar expressions in their code and take proper resolutions by hand?? Second, your response did not take into account the problems with the effects of the /Ze and /Za flags of the current VC7.1 compiler which I also think is a very important issue. Daniel

2 2

RE: [boost] Re: Re: [administrative] Formal Review Process
by Powell, Gary 28 Jan '04

28 Jan '04

] I suggest that such a requirement be added to the formal ] review process, with a specific (low, ie, 3) number of ] "formal seconds" required for a formal review request in ] order for it to reach the schedule. It should be explicitly ] noted that "seconding" a review request does not imply a vote ] to accept, nor a commitment on the part of the person ] seconding to participate in the review. I also like the idea, but with a twist: it should be explicitly noted that seconding a review request _does_ imply a commitment to review the library should a review be scheduled for it. Dave --------------------------------------------------- I agree with Dave and Doug, seconding implies both a commitment to review the library and a preliminary review such that you agree that the library is ready for review. The point being that you are expressing an interest in the library and that some sort of vetting has been done to insure that the rest of us won't all say, "Great but needs a heap of work." One can always post a "I'm thinking about getting my code ready is there enough interest to bother" email and gauge whether anyone cares. Those posting do not imply that you'll second it or approve it but that you think there's at least potential. Otherwise people won't waste their time reviewing, or documenting, or developing uninteresting stuff. BTW, Go ahead and add me to the list of review managers. It seems like a long time since I've been asked, so I'm guessing I've dropped off the list. -Gary- PS As for having my name on a web site, I seem to be inundated with spam merely by being on this list, so I doubt it will get much worse.

2 1

Re: [boost] Re: impl(ementations) - keeping it simple
by John Torjo 28 Jan '04

28 Jan '04

> I'm opposed to this idea because: > > 0. Testing this configuration is a burden on developers > > 1. It gives an implied guarantee that it will work for the user > (see 2) > > 2. We have no control over compiler flags or other settings that > may be neccessary for the library to work, nor that different > libraries are compiled with compatible options > > 3. If we don't need that control for some libraries today, but we > need it tomorrow, we'll have to take the feature of being able > to do the big #include back from the user > Ok, I give up ;) I did look at the existing jamfiles, etc. I still think that from all the users using boost, there is quite a little percentage that are willing to use bjam to compile the libraries needing separate compilation (of course, that's just my fild guess). Maybe to simplify the process, in boost-root (where boost-build.jam file exists), we could have a makefile which automatically builds bjam from the source files and the invokes it with a given configuation. like: make msvc (instead of bjam "-sTOOLS=msvc") Unfortunately, I don't have any makefile knowledge. Best, John

1 0

Re: [boost] Re: [administrative] Formal Review Process
by John Torjo 28 Jan '04

28 Jan '04

> I don't want to waste review manager capacity. It takes a lot of effort > being a review manager. > >> >> Having a [review] tag in the subject for the formal reviews seems >> pretty ok. I tend to agree with Jonathan - I think the discussion >> should still happen in the main list, > > > Why? If not, people would have to subscribe to yet one more list. I'm afraid, compared to how many subscribers the boost list has today, the new review list would have much less. Therefore, we might end up with much less reviewing than before. Or maybe, everyone already subscribed to boost could be automatically subscribed to the boost-review list. This would make much more sense. Best, John

1 0

Re: [boost] Indexed set library
by JOAQUIN LOPEZ MU?Z 27 Jan '04

27 Jan '04

Hi Arkadiy, Thanks for your praises! ----- Mensaje original ----- De: Arkadiy Vertleyb <vertleyb(a)hotmail.com> Fecha: Martes, Enero 27, 2004 9:04 pm Asunto: [boost] Indexed set library [snip] > > I am wondering what the current state of the library is. I > thought the > formal review has been requested -- is this correct? Anything new > sincethen? > Formal review was requested in December. The pending list is rather long, so I don't know when/if I'll be admitted for review. In the meantime the library is being augmented in two directions: * There was a query some months ago about the possibility of having "sequence sets" implemented with indexed_set (see http://lists.boost.org/MailArchives/boost/msg58666.php for details). I wrote a fast sketch of a new type of index called "sequenced" with which sequence sets can easily be constructed (see http://tinyurl.com/3dto3) Currently I'm growing this sketch into a full-fledged implementation for future inclusion into the library. The main problem is a lot of doc rewriting is necessary, since the original documentation was too focused on regular set-like indices. * A volunteer has begun studying the possibility of implementing hashed indices. I cannot say how long this will take. Regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [boost] Re: Cutting over to MPL - some progress.
by Phil Richards 27 Jan '04

27 Jan '04

On Fri, 23 Jan 2004 16:54:14 -0500, David Abrahams wrote: [I wrote:] >> I'll have a look at zip_view, but on first looks it doesn't exactly look >> simple :-) > Replacing lambda expressions with metafunction classes would be my first > strategy. Well, I replaced zip_view with transform and got the following (non-scientific) results: % time g++ -Wall -W -I. -I/home/pgr/src/boost -DWITH_ZIP_VIEW pq.cpp -c real 0m59.201s user 0m56.444s sys 0m0.475s [without zip_view, using transform] % time g++ -Wall -W -I. -I/home/pgr/src/boost pq.cpp -c real 0m14.074s user 0m13.418s sys 0m0.372s Well, that's much better. (Though there is probably still some room for improvement yet - it's still 3 or 4 fold slower than without the MPL.) How difficult would it be to produce a full family of mpl transform functions? Currently, there are the 1 and 2 sequence forms, but I could use a 3 sequence version :-) (The multi-sequence version is what I would have called "zip_with" from my old F.P. days...) Given the progress I've made, I will put together yet another release of my library. This version allows user choice of the base units in their dimensional analysis (so if you want bananas/second you can have it). It still uses fixed-size vectors of powers, though - so if you have a banana-system and you want to multiply a banana-system-based quantity by a "physical system"-based quantity, it won't let you. Personally, that's the way I like it... phil -- change name before "@" to "phil" for email

1 0

Re: boost::optional issue with borland-5.6.4
by Fernando Cacciola 27 Jan '04

27 Jan '04

Samuel Krempp <krempp(a)crans.ens-cachan.fr> wrote in message news:1074872783.4142.160.camel@marvin.localdomain... > boost::format compilation fails with what seems to be a boost::optional > issue. > http://boost.sourceforge.net/regression-logs/cs-win32_metacomm/links.html#f… .6.4 > says : Fixed in Main CVS. I'll merge it to 1.31.0RC2 as soon as I can test it with VC7.1 and GCC3.3.1 Fernando Cacciola SciSoft

1 1

Indexed set library
by Arkadiy Vertleyb 27 Jan '04

27 Jan '04

Hi all, I was just playing with the indexed set library (to provide alternative, set-based, implementation for our RTL tables), and my first impression is that it is very useful. I didn't have any problems in achieving my goal, either with the documentation (which is very clear), or with the library itself. Although I was using the simplest form of indexed_set (I only needed the "compatible predicate" feature missing from std::set), I still think that the idea of having multiple synchronized indexes is very useful (based on my past experience, when I could greatly benefit from such library), and that this library could eventialy become a great addition to Boost. I am wondering what the current state of the library is. I thought the formal review has been requested -- is this correct? Anything new since then? Arkadiy

1 0

Re: [Function] Implemented operator== and operator!=
by David Abrahams 27 Jan '04

27 Jan '04

Douglas Gregor <gregod(a)cs.rpi.edu> writes: > where deref does something like: > > template<typename Pointer, typename Pointee = typename Pointer::element_type> > struct do_deref > { I suggest template< typename Pointer , typename Pointee = typename pointee<Pointer>::type > struct do_deref { }; Or even leaving out the Pointee parameter altogether. See boost/pointee.hpp. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Re: 1.31.0 Progress (or lack thereof)
by David Abrahams 27 Jan '04

27 Jan '04

"John Maddock" <john(a)johnmaddock.co.uk> writes: >> Heh, not my department. I'm actually shocked that we're wedging >> is_abstract into the release branch. > > Normally a really bad idea, but in this case it's straight addition: it has > no impact on existing code, and I know that some folks who develop with the > release versions are asking for it. Sure, but it adds tests, which as we've seen subsequently add delays. It's a feature addition; no two ways about it. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Re: [administrative] Formal Review Process
by David Abrahams 27 Jan '04

27 Jan '04

Thomas Witt <witt(a)acm.org> writes: >> b. Use a regular rotating schedule for review managers. If you're >> not going to be available when your time comes up, it should be >> your responsibility to find someone to swap with. > > From my experience strict rotating works almost never due to time > constraints or library topic. Yeah, but the result is that people would know well in advance when they're scheduled and what library they're scheduled for, and... > I am unsure whether this is not too much pressure to put it on highly > skilled volunteers. ... it would take the pressure off of *you* to find replacement reviewers. But if you're willing to keep that part of the pressure, so much the better for the rest of us. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Re: [administrative] Formal Review Process
by David Abrahams 27 Jan '04

27 Jan '04

Thomas Witt <witt(a)acm.org> writes: >> I don't think automating would help here. >> How about having the email' addresses of all the review managers on >> the formal_review_process.html page? >> (and update this page as review managers are added or deleted) > > I think having names and email adresses on the website is at least > controversial, if only for mail address harvesters. Though it might be > a good idea to have the author care for a manager. This could be done > on a mailing list. Mail addresses are easy enough to obfuscate in ways that are transparent to humans. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Another compressed_pair issue
by David Abrahams 26 Jan '04

26 Jan '04

Just for the sake of completeness, it would probably be a good idea to note that the use of compressed_pair wouldn't be transparent on an implementation where a class with virtual functions can be empty. Of course, I doubt any such implementation exists, but it is possible. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0