- Boost - lists.preview.boost.org

RE: [boost] Review Wizard Status Report
by Rozental, Gennadiy 04 Aug '04

04 Aug '04

> 2) Algorithm Mini-Reviews > > If there are no objections, I will also schedule a > mini-review of some of the algorithms from wiki > starting September15, 2004. The format of the boost > algorithms review has yet to be established and will > evolve over time. > > Please contact me if you have any suggestions as to > how this first boost algorithms review proceeds. Does my submission get into this picture? > 3) Review Managers Needed > > Please contact me if you would like to serve as a > review manager for a library > under consideration for inclusion into boost. It > would be greatly appreciated > and is a great way for you to network with other boost > users. I am ready to help, though it's subject to schedule conflicts resolution. > > Tom Brinkman > Boost Review Wizard Gennadiy.

1 0

Re:[boost] [serialization] CW8 status...
by Robert Ramey 04 Aug '04

04 Aug '04

Rene Rivera wrote: >A quick summary of what your recent changes did for CW8, in case the >metacomm tests don't soon: >* test_delete_pointer pass. >* test_demo_auto_ptr pass. >* test_deque pass. >* test_diamond pass. >* test_map pass. >* test_non_default_ctor pass. >* test_non_intrusive pass. >* test_optional pass. >* test_private_ctor pass. >* test_split pass. >* test_vector pass. >I only tested the previous failures. And for some the metacomm tests >show a failure for things were previously fixed. Also it looks like some >of the failures are now different, meaning you fixed something only to >have it fail on something else. Oh yeah - sometimes you get more than one issue per test - sort of a free bonus. Several compilers/platforms/combinations have problems with wide character i/o. These are CW, Comeau, Darwin/GCC. I'm looking at this - I believe it may be an error in the utf8 codecvt facet. (interestingly, this doesn't occur with the column marked "CW" hmmmm) I have a problem with my own cwpro9 installation in that for some programs I get multiply defined symbols at link time. The resulting exectutable goes kind of haywire. The column marked "CW" doesn't show this problem and I hopeful that it will pass almost 100% on the next round of tests. I suspect there is issue with build/jamfile for cwpro8/9. Test_list has an issue with slist.hpp and iterators of all things. This effects all CW versions. Its possible its an slist issue on all platforms for all I know. As far as CW is concerned - I'm smelling blood and feel that I'm closing in on final victory. Anyone who wants to take a look at any of the above issues is free to do so. Robert Ramey

1 0

RE: [boost] RE: Re: DLL library (Was: Re: additional boost libraries?)
by Reece Dunn 04 Aug '04

04 Aug '04

Vladimir Prus wrote: >Reece Dunn wrote: > >>I also wonder if it makes sense to sumbit just "dll" library, or some > >>additional plugin support need to be developed first. > > > > What sort of plugin support are you looking for? Do you mean something > > like COM/CORBA support or wrapper, e.g. something that can target both > > (and others like them) in one implementation? > >I'm not CORBA expert, but I think it's entirely different beast. To use >CORBA object you use stub generated from IDL, how it's related to plugins? >While there are some ways to find object dynamically, it's different >mechanism from shared libraries, isn't it? I am not sure how CORBA works. COM generally uses a different mechanism to load COM objects via CoCreateInstance, although DirectX exposes creation functions that circumvent this. I was thinking about being able to use COM/CORBA as a platform for object lifetime and dll lifetime management (as well as things like interface extension, etc.). >I though more about at least some kind of map<string, BasePlugin*> which is >updated automatically when you load new DLLs. So the dll implements some function: __declspec(dllexport) BasePlugin * GetMyPlugin(); so you can do something like: void load_plugins( map< string, BasePlugin * > & pi ) { for( map< string, BasePlugin * >::iterator i = pi.begin(); i != pi.end(); ++i ) { boost::dll plugin(( *i ).first ); ( *i ).second = plugin.import< ... >( "GetMyPlugin" ); } } It is possible to keep the DLL in memory until all instances of a class (or set of classes) by incrementing/decrementing a global object count variable on construction/deconstruction as is done when using COM. You then check this variable in the DllCanUnload function. You may need some reference counting mechanism to keep the plugin alive, but this is not necessary if you load all plugins on startup and release them at the end of the run. It should be possible to implement these facilities in a library, e.g.: class object_counter { private: static int objectCount = 0; public: inline int get_object_count(){ return( objectCount ); } public: inline object_counter(){ ++objectCount; } // make MT aware inline ~object_counter(){ --objectCount; } // make MT aware }; class reference_counter { private: int refCount; public: inline void add_ref(){ ++refCount; } // make MT aware inline void dec_ref() { if( --refCount == 0 ) // make MT aware { delete this; } } public: inline reference_counter( int rc ): refCount( rc ){} inline ~reference_counter(){} }; allowing: class plugin: public object_counter, public reference_counter, public BasePlugin { // ... }; __declspec(dllexport) BOOL DllCanUnload() { return( object_counter::get_object_count() == 0 ); } I'm not sure what the Linux equivalent would be. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

5 6

range & mpl
by Rob Lievaart 04 Aug '04

04 Aug '04

Hi All, The workaround test of the range library is failing for gcc 3.2 and 3.3 and for mingw with gcc 3.2. This seams to be caused by an incorrect placement of some macro's in mpl/if.hpp However, I do not know the correct placement. I've tried a few locations, but they all result in other errors, so I do not know what the right place is. mpl/if.hpp contains the follwoing code: ...snip... #if !defined(BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION) BOOST_MPL_AUX_AGLORITHM_NAMESPACE_BEGIN ...snip... #else // no partial class template specialization ...snip... #endif // BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION BOOST_MPL_AUX_AGLORITHM_NAMESPACE_END ...snip... The value of BOOST_MPL_AUX_AGLORITHM_NAMESPACE_XXX depends on wheter we are using gcc ( >=3) or not. So the _BEGIN is set inside the #if and the and the _END outside. I tried putting the begin before the #if but that din't work, and the _END inside before the #else but that didn't work either. Looking at the other mpl files it seems things are not as simple as that :-(, but I have no idea how the mpl works, so I do not know what the correct solution is. Rob Lievaart.

2 1

RE: [boost] Re: Windows MSVC thread exit handler for staticly linkedBoost.Threadn
by Richard_Cox＠Dell.com 04 Aug '04

04 Aug '04

> -----Original Message----- > From: Aaron W. LaFramboise [mailto:aaronrabiddog51@aaronwl.com] > Sent: Tuesday, August 03, 2004 4:20 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: Windows MSVC thread exit handler for > staticly linkedBoost.Threadn > The only concern I have--I don't know how important this is--is that > when a thread is killed with TerminateThread, I think neither TLS > callbacks nor DllMain()s will be called. This would cause > the TLS count > to never reach zero, and for TlsFree to never be called. > > These threads might not even be associated with the Boost TSS at all. > For example, another third party library in some DLL might be using > TerminateThread, and the application programmer may not even > know about > this, so it may be suprising to him when the reference count never > reaches zero for apparently no good reason. > I don't think cleanup after a TerminateThread would make any sense. TerminateThread does zero cleanup to start with (e.g. the threads is not freed). It would be inconsistent if any TLS cleanup was done in this case). Richard All opinions are mine and do not represent in any way the position of Dell Corporation.

1 0

RE: [boost] [build_monitor] again
by Rob Lievaart 04 Aug '04

04 Aug '04

Oops, it looks like I spoke to soon. _Assuming_ the ftp server is reporting file times in local time somewhere in the (middle of) the US, then the regression script did upload the results. In that case, the failing tests were stopped and it was just the error message that hung around. Wat remains is that monitor kills other windows that have error in the name on Windows 200 SP5. Other reports were from XP IIRC. I do not have nay problem with long lived processes being killed when they shouldn't be. Kind regards, Rob Lievaart. > I am having some trouble with the build monitor, it works fine > most of the time, but: > 1) Yesterday I locked the screen of the computer, this morning > when I returned the division by 0 errors were showing, and they > were not killed build_monitor, so the tests blocked. > > 2) As reported earlier, any window with error in the title is killed. > > This is on Windows 2000, SP5.

1 0

[build_monitor] again
by Rob Lievaart 04 Aug '04

04 Aug '04

Hi, I am having some trouble with the build monitor, it works fine most of the time, but: 1) Yesterday I locked the screen of the computer, this morning when I returned the division by 0 errors were showing, and they were not killed build_monitor, so the tests blocked. 2) As reported earlier, any window with error in the title is killed. This is on Windows 2000, SP5. Kind regards, Rob Lievaart. PS. I'll try to look into it in more detail this evening, but I am kind of busy at the moment, so I may not get around to it.

1 0

[serialization] CW8 status...
by Rene Rivera 04 Aug '04

04 Aug '04

Robert, A quick summary of what your recent changes did for CW8, in case the metacomm tests don't soon: * test_delete_pointer pass. * test_demo_auto_ptr pass. * test_deque pass. * test_diamond pass. * test_map pass. * test_non_default_ctor pass. * test_non_intrusive pass. * test_optional pass. * test_private_ctor pass. * test_split pass. * test_vector pass. I only tested the previous failures. And for some the metacomm tests show a failure for things were previously fixed. Also it looks like some of the failures are now different, meaning you fixed something only to have it fail on something else. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

1 0

serialization test all fail on darwin
by Robert Ramey 04 Aug '04

04 Aug '04

I'm getting all failures in the serialization library on Darwin - gcc 3.1 A few days ago I got all passes for this platform(exception wide char xml - a separate issue). I had hoped it my go away spontaneously - as it arrived - but no luck. Does anyone have a suggestion on how to address this? Robert Ramey ld: multiple definitions of symbol boost::unit_test::(anonymous namespace)::first_failed_assertion() /Volumes/stuff/users/alexy/__boost_regressions/results/bin/boost/libs/test/b uild/libboost_test_exec_monitor.a/gcc-3.1-darwin/debug/libboost_test_exec_mo nitor.a(unit_test_log.o) definition of boost::unit_test::(anonymous namespace)::first_failed_assertion() in section (__TEXT,__text) /Volumes/stuff/users/alexy/__boost_regressions/results/bin/boost/libs/test/b uild/libboost_test_exec_monitor.a/gcc-3.1-darwin/debug/libboost_test_exec_mo nitor.a(supplied_log_formatters.o) definition of boost::unit_test::(anonymous namespace)::first_failed_assertion() in section (__TEXT,__text)

3 2

RE: [boost] serialization test all fail on darwin
by Rozental, Gennadiy 03 Aug '04

03 Aug '04

Ok I will commit these later today. Gennadiy.

1 0

[string algo] Documentation errors
by Jeff Garland 03 Aug '04

03 Aug '04

I've been writing some code with string algorithms and I noticed a couple documentation issues: 1) First example: #include <boost/string_algo.hpp> should be #include <boost/alogorithm/string.hpp> 2) In the 'split' section example: typedef vector< string > split_vector_type; split_vector_type SplitVec; // #2: Search for tokens split( SplitVec, str1, is_any_of<char>("-*") ); // SplitVec == { "hello abc","ABC","aBc goodbye" } This doesn't work for me on gcc3.3.2 Linux (passes all regression tests) and it conflicts with the documentation of is_any_of which takes a collection not a char string as the parameter. Jeff

2 2

Looking for a simple example of instantiating normal_distribution from the random library correctly
by Kuntz, David A 03 Aug '04

03 Aug '04

> I am instantiating normal_distribution from the random library > incorrectly and looking for a simple example of how to do it > correctly. > > I compiled, built and ran random_test.cpp and can see when I > step through the normal_distribution () operator that _r1 and _r2 have > values < 1. > > Here are the relevant excerpts from my incorrect attempt at > instantiation and calling the () operator: > > typedef boost::mt19937 base_generator_type; > > boost::uint32_t x = 42u; > Ideal4045EsmModel::base_generator_type base_generator(x); > > double randomDrawResult; > > boost::normal_distribution<double> boostNormalRand; > > boostNormalRand.reset(); > > randomDrawResult = boostNormalRand(base_generator); > > This compiles, builds, and runs, but when I step through the > normal_distribution () operator, _r1 and _r2 have very large positive > values, resulting in an attempt to take the log of a negative number > and an Indefinite value being returned. > > I am a relatively inexperienced C++ developer. I have built and > stepped through random_test.cpp > (http://www.boost.org/libs/random/random_test.cpp) and can see that > its gets correct results, but I found it quite difficult to follow. Is > there anyone out there who could show me a simpler way? > > Thanks, > > Dave > > > >

1 0

Re:[boost] Re: [program_options / g++ 3.3.3] Problem with UTF-8codecvt facet
by Robert Ramey 03 Aug '04

03 Aug '04

Tilman Kuepper >If a new version of the UTF-8 facet is available it may find its way >into other libraries, e. g. program_options, serialization etc. We have agreed to use Vladimir's version of this library. The serialization library has its own copy but that will disappear when I get some unrelated issues sorted out. Robert Ramey

1 0

3 important Intel regressions and some other stuff
by Stefan Slapeta 03 Aug '04

03 Aug '04

The following regressions seem to be special to Intel 8: - numeric/uBLAS The only way to solve this seems at the moment not to use the "Multithreaded Debug DLL" runtime. When we can isolate the problem, Intel should investigate. - Python The slice test case is failing! Any ideas? - random error: no operator "<<" matches these operands I've not heard any comment in the last days about that. Any ideas? Aleksey, could we have a link to http://boost.sourceforge.net/regression-logs/developer/python.html on the boost regression site? I can't find any link to this page anywhere. I'm now going to leave now and I'll return on Sunday. I don't know if I can manage to get the regressions being run automatically, otherwise you get the next results for Intel 8 + CW 9 on Sunday. Stefan

5 16

[multi_index] spurious error in CW 9
by Joaquín Mª López Muñoz 03 Aug '04

03 Aug '04

This test occasionally fails: http://tinyurl.com/72xcb but there's no error output or any failure indication, nothing. The problem shows only at times, so I guess it'll have to do with the compiler being low on resources, but couldn't say for sure. Any idea? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 3

[regression] Discrepancy with display and results...
by Rene Rivera 03 Aug '04

03 Aug '04

I just noticed a discrepancy between the regression tables, the MetaComm one's, and the output reported for the failure. If one looks at the Spirit summary: http://www.boost.org/regression-logs/cs-win32_metacomm/developer/spirit.html Boost regression: spirit/CVS main trunk There are two failures, action_tests and action_tests_debug. But if one looks at either for the failure, you see that there is no failure: Boost regression - test run output: spirit - action_tests / cwpro8 Compiler output: call "C:\Program Files\Metrowerks\CodeWarrior\Other Metrowerks Tools\Command Line Tools\cwenv.bat" -quiet mwcc -maxerrors 5 -maxwarnings 20 -c -warn on,nounusedexpr,nounused -cwd include -DNOMINMAX -nowraplines -lang c++ -g -O0 -inline off -prefix UseDLLPrefix.h -runtime dmd -iso_templates on -I"C:\Users\Administrator\boost\main\results\bin\boost\libs\spirit\test" -I"..\libs\spirit" -I".." -I- -I"C:\Users\Administrator\boost\main\boost" -o "C:\Users\Administrator\boost\main\results\bin\boost\libs\spirit\test\action_tests.test\cwpro8\debug\unit_test.obj" "..\libs\spirit\test\./actor/unit_test.cpp" Linker output: call "C:\Program Files\Metrowerks\CodeWarrior\Other Metrowerks Tools\Command Line Tools\cwenv.bat" -quiet mwld -search -maxerrors 5 -maxwarnings 20 -export dllexport -nowraplines -g -subsystem console -o "C:\Users\Administrator\boost\main\results\bin\boost\libs\spirit\test\action_tests.test\cwpro8\debug\action_tests.exe" @"C:\Users\Administrator\boost\main\results\bin\boost\libs\spirit\test\action_tests.test\cwpro8\debug\action_tests.CMD" Run output: Running 14 test cases... *** No errors detected EXIT STATUS: 0 -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

3 7

Another project based on Boost Graph
by Jonah Beckford 03 Aug '04

03 Aug '04

I would like to thank the Boost Graph implementers (and the general Boost community) for coming up with a great set of patterns for dealing with graphs. I have started something similar for Scheme (a Lisp dialect), and would like to acknowledge where the great ideas came from. Keep up the good work! Jonah http://www.nongnu.org/rgraph/ README excerpt: Rooster Graph is a graph library for Scheme. Patterned after the popular Boost Graph Library for C++, it allows for a very clean separation between the graph container and graph algorithms. It does not have the complete functionality of the Boost Graph Library, but it does go a bit further by having both strict- and lazy-evaluated methods; the user of the graph has pause/continue/stop control and is not constrained by memory. Rooster Graph uses Scheme macros to get the benefit of speed while having generic operations. It has only been implemented on CHICKEN Scheme, although porting it to other Scheme implementations would be quite easy.

1 0

[program_options] Current status
by Vladimir Prus 03 Aug '04

03 Aug '04

I've leaving on vacation until Aug 23, so I though I'd explain the current release status of program_options. I believe that most failures are addressed. The Boost-wide table shows a lot of yellow cells, but I'm sure I've added explicit markup for most of them, and indeed the results for win32 are much better. The only two unexpected yellow cells are for intel- win32- 7.1- vc6- stlport- 4.5.3 at http://boost.sourceforge.net/regression-logs/cs-win32_metacomm/developer/pr… These are fresh problem and I'm not sure how I've missed them, or when they are introduced. In any case, it's too late to fix them. Another problem is that I still not sure about Darwin. All tests fail because of Boost.Test problem, and I'm not sure if Gennadiy is going to do anything about it. I think this is very bad situation, and would say that reverting the problematic change in Boost.Test is an option, but can't press for it. Apart from the above, during last week I've applied numerous editorial changes to the docs (big thanks to Charles Brockman), revived the remaining examples, and added new sections to the "howto" section, so I hope docs are in a good shape as well. If during the release process anybody would want to fix something, feel free to commit the change, making sure it does not breaks anything else, and dropping me a note by personal email. Thanks again to everyone who already sent patches for the library! - Volodya

2 3

RE: problem with subexpressions
by Jadhav, Rahul (Rahul) 03 Aug '04

03 Aug '04

Thanks a lot for your reply. Problem solved. Rahul Jadhav.

1 0

Numeric Interval failing with __USE_ISOC99 environment (plus fix)
by Michael Stevens 03 Aug '04

03 Aug '04

I am just testing Boost uBLAS and Interval on an X86_64 architecture machine. The compilation environment (GCC on Linux) is defining __USE_ISOC99, and not __i386__ which seems reasonable! Looking at 'hw_rounding.hpp'' I have confirmed that on this environment the following code branch is being taken. # include <boost/numeric/interval/detail/c99_rounding_control.hpp> With this setup 'test_float.cpp' is failing badly when compiled with the following errors: In file included from /boost_CVS/boost /numeric/interval.hpp:18, from /boost_CVS/libs/ numeric/interval/test/test_float.cpp:11: /boost_CVS/boost/numeric/interval/rounding.hpp: In instantiation of `boost::numeric::interval_lib::save_state<boost::numeric::interval_lib::rounded_arith_opp<float, boost::numeric::interval_lib::rounding_control<float> > >': /boost_CVS/boost/numeric/interval/hw_rounding.hpp:40: instantiated from here /boost_CVS/boost/numeric/interval/rounding.hpp:78: error: no type named `rounding_mode' in `struct boost::numeric::interval_lib::rounded_arith_opp<float, boost::numeric::interval_lib::rounding_control<float> >' /boost_CVS/boost/numeric/interval/rounding.hpp: In instantiation of `boost::numeric::interval_lib::save_state<boost::numeric::interval_lib::rounded_arith_opp<double, boost::numeric::interval_lib::rounding_control<double> > >': /boost_CVS/boost/numeric/interval/hw_rounding.hpp:45: instantiated from here etc.. Could it be that 'struct c99_rounding_control' should be inheriting from 'c99_rounding'. This seems to fix the problem although I am not sure it is the correct solution! Michael ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

1 0

regressions in como-win32-4.3.3-vc7.1
by JOAQUIN LOPEZ MU?Z 03 Aug '04

03 Aug '04

Please see http://tinyurl.com/5f7ba "C:\Comeau\libcomo\cnames\cstring", line 31: error #247: function "std::strlen" has already been defined extern "C++" inline size_t strlen(const char *arg) { return ::strlen(arg); } ^ "C:\Comeau\libcomo\cnames\cstring", line 31: error #247: function "std::strlen" has already been defined extern "C++" inline size_t strlen(const char *arg) { return ::strlen(arg); } ^ 2 errors detected in the compilation of "..\libs\multi_index\test\test_basic_main.cpp". The problem has nothing to do with Boost.MultiIndex, actually, as test_basic_main.cpp does not do anything more than including <boost/test/included/test_exec_monitor.hpp> These tests used to pass one or two days ago. I've inspected Boost.Test for recent changes and found none. Other libraries are affected by this problem: algorithm/minmax algorithm/string program_options ... Thanks Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[preprocessor] Digital Mars port
by Daniel James 03 Aug '04

03 Aug '04

I've ported the preprocessor library to the Digital Mars preprocessor. The patch is at: http://myweb.tiscali.co.uk/calamity/patches/preprocessor-1.patch.gz With it, the only test which doesn't pass is the BOOST_PP_LINE test in debug.cpp, because the preprocessor has problems with macro expansion in #line statements. Would it be possible to add this to CVS after the release? Unless I've made a mistake, it won't interfere with any other preprocessors. The patch works around two bugs in the preprocessor. First, in a statement like this: #define FOO(pred, x) BAR(pred(x)) pred(x) won't get expanded. There are several ways to work around this, the one I've mostly used is to write: #define FOO(pred, x) BAR(pred##(x)) You can also use: #define CALL(pred, x) pred(x) #define FOO(pred, x) BAR(CALL(pred, x)) And, with the patch: #define FOO(pred, x) BAR(BOOST_PP_EXPAND(pred(x))) But, I think those two could cause problems with recursion. The other bug is with the preprocessors handling of whitespace. In the following example, neither concatenations work, both give '1 1' instead of '11'. #define EMPTY #define TRAILING_WHITESPACE(x) x EMPTY #define LEADING_WHITESPACE(x) EMPTY x BOOST_PP_CAT(TRAILING_WHITESPACE(1), 1) BOOST_PP_CAT(1, LEADING_WHITESPACE(1)) This causes subtle bugs with macros like this: #define BOOST_PP_LESS(x, y) BOOST_PP_IIF( \ BOOST_PP_NOT_EQUAL(x, y), \ BOOST_PP_LESS_EQUAL, 0 BOOST_PP_TUPLE_EAT_2)(x, y) This leaves a white space after the 0 when x and y are equal which prevents concatenation. This is mainly a problem with BOOST_PP_WHILE, BOOST_PP_FOLD_LEFT etc. It is possible to remove the whitespace by concatenating it to a macro which expands to nothing, but that is only possible when you know that there is definitely going to be whitespace. thanks, Daniel

3 6

RE: [boost] build_monitor.exe: a cure worse than the disease
by Aleksey Gurtovoy 03 Aug '04

03 Aug '04

Victor A. Wagner Jr. writes: > I have NO idea what criteria build_monitor uses to killing > processes, Two conditions: 1) They have to be spawned by 'bjam.exe' executable. 2) They have to be running for more than 5 minutes or show an error dialog window. > but when I awoke this morning, it had managed to kill: the dnet > "run in the background" ORG process, Pirch (my IRC client), a > proxy that lets me get dcc's through my hardware firewall, > Trillian (the instant message program), SpyBot resident..... > I think you get the picture. How did you determine that it's build_monitor that caused all that? While there is always a possibility of a program having bugs, it's hard to believe that this particular one started to misbehave all of a sudden after a year of stable work and no changes to the source code. > this thing just walked through my system like a hoard of Vandals > (or was it Visigoths). whatever I'm sorry to hear about the whole thing, but let's get to the roots of it. First of all, why do you think it was build_monitor? Second, what operating system are you running? -- Aleksey Gurtovoy MetaCommunications Engineering

2 2

build_monitor.exe: a cure worse than the disease
by Victor A. Wagner Jr. 03 Aug '04

03 Aug '04

I have NO idea what criteria build_monitor uses to killing processes, but when I awoke this morning, it had managed to kill: the dnet "run in the background" ORG process, Pirch (my IRC client), a proxy that lets me get dcc's through my hardware firewall, Trillian (the instant message program), SpyBot resident..... I think you get the picture. this thing just walked through my system like a hoard of Vandals (or was it Visigoths). whatever DO NO RUN THIS PROGRAM ON YOUR SYSTEM UNTIL IT'S FIXED my results will be delayed as a result of my stopping the -monitored tests because I'll have to manually click through the modal dialogs (may their creator roast in hell) so the tests will finish. Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

5 6

problem with subexpressions
by Jadhav, Rahul (Rahul) 03 Aug '04

03 Aug '04

> -----Original Message----- > From: Jadhav, Rahul (Rahul) > Sent: Tuesday, August 03, 2004 12:33 PM > To: 'boost(a)lists.boost.org' > Subject: problem with subexpressions > > Hi All, > I am not sure if I m doing wrong or there is some problem with library. I want to extract "f23" and "this is corresponding text" from string "f23 : this is corresponding text" > so I have written regular expression "(f[0-9]{1,})\\s*:\\s*(.*)" so that in match[0] is should have index information for first subexpression and should give me indices of "f23" > but it gives me whole string as first subexpression. > > It may be my mistake but I have spent 2 days and nights on this thing so I thought I should post it. Also I tried to find out a topic related to subexpressions on the mailing list but could not find one. below is the code. > > regex_t preg; > regmatch_t match[3]; > > if(regcompW(&preg,L"(f[0-9]{1,})\\s*:\\s*(.*)",REG_ICASE|REG_EXTENDED)==0) > AfxMessageBox(L"successful"); > CString str=L"f23 : this is corresponding text"; > > wchar_t* ptr=str.GetBuffer(str.GetLength()); > > if(regexecW(&preg,ptr,3,match,0)!=REG_NOMATCH) > { > int i=0; > while(i<3) > { > wchar_t arr[200]; > wcsncpy(arr,(ptr+match[i].rm_so),match[i].rm_eo-match[i].rm_so); > arr[match[i].rm_eo-match[i].rm_so]='\0'; > ptr=ptr+match[i].rm_eo; > AfxMessageBox(arr); > //AfxMessageBox(ptr); > i++; > } > } > > > Thanks > Rahul Jadhav > > > > >

1 0

Re:[boost] [serialization] More CW8 fixes
by Robert Ramey 03 Aug '04

03 Aug '04

Rene Rivera wrote: >I checked in some more minor fixes to remove more failures of this >library. But, most of the remaining failures are affecting both CW8 and >CW9. Which leads me to believe that it's a more serious problem with the >library. >And I don't have more time to continue looking at this. >PS. I guess I won't be using this lib anytime soon, no matter how much I >wanted to :-( Don't give up hope - I've been working on things at this end and have made much progress. I have CW9 installed. I will be checking in my updates soon and I believe things will be much better. I believe that this can be made to pass 100%. Stay tuned. Robert Ramey

2 1

[serialization] More CW8 fixes.
by Rene Rivera 03 Aug '04

03 Aug '04

I checked in some more minor fixes to remove more failures of this library. But, most of the remaining failures are affecting both CW8 and CW9. Which leads me to believe that it's a more serious problem with the library. And I don't have more time to continue looking at this. PS. I guess I won't be using this lib anytime soon, no matter how much I wanted to :-( -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

1 0

RE: [boost] Re: counting_iterator_test.hpp fails on aC++
by DY, JERRY U (SBCSI) 03 Aug '04

03 Aug '04

Dave, aC++ didn't like it. This is CR JAGaf33512 -- aC++ tries to instantiate template member functions even if it's unused. Pls. see attachment. I've addressed the problems you mention below. Although I don't know what you mean by a patch?? Let me know if it's good enough for check in. Thanks for being patient with me, I'm a stone-age C++ programmer who just got transported into the 21st century and I'm still trying to get my feet wet. It's a lot of material to absorb in a short time. Regards, -Jerry -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams Sent: Friday, July 30, 2004 9:39 AM To: boost(a)lists.boost.org Subject: [boost] Re: counting_iterator_test.hpp fails on aC++ "DY, JERRY U $SBCSI$" <jd2419(a)sbc.com> writes: > Dave, > See attachment. Thanks! Thank you! There are a number of problems with it: 1. It's not a patch as requested (nit; it was probably easier for me to handle than a patch would've been) 2. It defines an implementation detail function in the boost:: namespace 3. It uses ALL_CAPS identifiers for non-macro names (TR1, TR2) Instead of fixing the patch I used a simpler static assertion that should only fail to work on compilers that don't support is_convertible (CWPro7 and earlier), which I've already dropped support for IIRC. Let me know if aCC becomes happy. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

RE: [boost] Re: White cells
by Rozental, Gennadiy 02 Aug '04

02 Aug '04

> > ######################################## > > > > local test-dir = > > "$(BOOST_ROOT)$(SLASH)libs$(SLASH)test$(SLASH)test$(SLASH)" > > ; > > > > run ifstream_line_iterator_test.cpp > <lib>../build/boost_unit_test_framework > > : #args > > : $(test-dir)test_files/ifstream_line_iterator.tst1 > > $(test-dir)test_files/ifstream_line_iterator.tst2 ; > > > > What is wrong here? > > 1. It's ugly. If I am not mistaken it was you or Beman who introduced this var, because local reference (../test or ./) did not work. > 2. I'm not certain that BOOST_ROOT will always be set (though it > probably will). I think it is. And it still unclear why it's failing then. Gennadiy.

2 1

How to test multiple versions of a library?
by Michael Glassford 02 Aug '04

02 Aug '04

Currently the Boost.Threads regression tests only test the dynamically linked version of the library. On Win32, at least, there are fairly significant differences between the dynamically linked and statically linked versions (due to thread-specific-storage cleanup), so it would be good to run at least some of the tests for both versions. How do I do this? Mike

4 4

RE: [boost] Re: White cells
by Rozental, Gennadiy 02 Aug '04

02 Aug '04

> The way libs/test/test/Jamfile refers to input files is broken. > > there should be no use of $(test-dir). > > tests are always run from the directory of the Jamfile. If this would be the case it should work, I think. Here related part of Jamfile: ######################################## local test-dir = "$(BOOST_ROOT)$(SLASH)libs$(SLASH)test$(SLASH)test$(SLASH)" ; run ifstream_line_iterator_test.cpp <lib>../build/boost_unit_test_framework : #args : $(test-dir)test_files/ifstream_line_iterator.tst1 $(test-dir)test_files/ifstream_line_iterator.tst2 ; What is wrong here? Gennadiy.

2 1

Re:Re: [thread] barrier.cpp don't compile with msvc60 & stlport]
by Robert Ramey 02 Aug '04

02 Aug '04

>cool - i use the same configuration! So every has to work ;-)) >Why does it compiles on meta-comm and not on my machine? I tried it on >two differend machines. (but both with the same stlport) >So what's different? >I use the ms-iostream - what kind of iostreams is the regressiontest using? I use msvc + stlport 4.5.3 compiled with streams and it builds the serialization library on my machine w/o problems. The daily tests show what seems to be a similar configuration which fails to build with a compile error in spirit. Sooo one or more of the following is true a) something is different - its not clear what b) spirit 1.6 - needs some sort of tweak - I'm not sure this will ever happen. c) Its really annoying to see a column of all failures knowing that the issue is fixable but not by me. Robert Ramey

3 2

Broken toolset config on Meta-Comm Darwin results?
by Jeff Garland 02 Aug '04

02 Aug '04

I'm wondering what toolset is being used for the Meta-Comm Darwin tests. Seems like there is a configuration issue for shared libraries since all the date_time dll tests fail. See http://www.meta-comm.com/engineering/boost-regression/developer/date_time.h… Also, 'gcc' doesn't really give much about the compiler being used. Based on the other failures I'm guessing a variant of 2.95.x? Note that in the other Darwin tests with gcc 3.3.x date_time passes all tests... http://boost.sourceforge.net/regression-logs/cs-Darwin.html Jeff

2 1

Boost-wide reports: Time to join in!
by Aleksey Gurtovoy 02 Aug '04

02 Aug '04

Now that we have Boost-wide reports up and running [1], I'd like to encourage all regression runners who's results are not represented there yet take a tiny bit of time to join in. The setup procedure is documented in http://tinyurl.com/4pnfd. It's very short and painless, too! It's crucial that we have an objective picture of the codebase when/before we release, and Boost-wide reports is the only instrument that is able to provide us with it. So please, join in! [1] http://www.boost.org/regression-logs/developer -- Aleksey Gurtovoy MetaCommunications Engineering

11 28

[numeric/conversion] CW8 duplicate resolution errors.
by Rene Rivera 02 Aug '04

02 Aug '04

I just put in some fixes for the following type of errors: # Error: # ambiguous access to overloaded function # 'std::log10(float)' # 'std::log10(float)' The problem was the direct use of "boost/compatibility/cpp_c_headers/cmath" instead of doing the standard "#include <cmath>"... =================================================================== RCS file: /cvsroot/boost/boost/boost/numeric/conversion/converter_policies.hpp,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- converter_policies.hpp 25 Jul 2004 16:58:06 -0000 1.2 +++ converter_policies.hpp 1 Aug 2004 16:01:18 -0000 1.3 @@ -12,7 +12,7 @@ #include <typeinfo> // for std::bad_cast -#include "boost/compatibility/cpp_c_headers/cmath" // for std::floor and std::ceil +#include <cmath> // for std::floor and std::ceil #include "boost/type_traits/is_arithmetic.hpp" =================================================================== RCS file: /cvsroot/boost/boost/libs/numeric/conversion/test/test_helpers.cpp,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- test_helpers.cpp 24 Jun 2004 11:59:25 -0000 1.1 +++ test_helpers.cpp 1 Aug 2004 16:05:07 -0000 1.2 @@ -16,7 +16,7 @@ // from the Numeric Conversions Library // // -#include "boost/compatibility/cpp_c_headers/cmath" +#include <cmath> #include "boost/limits.hpp" #include "boost/utility.hpp" =================================================================== That makes all the tests pass in CW8. This might fix other failures in other toolsets. Tests for VC7.1 and Mingw still all pass. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

2 1

RE: [boost] build_monitor.exe: a cure worse than the disease
by Victor A. Wagner Jr. 02 Aug '04

02 Aug '04

At Sunday 2004-08-01 16:37, you wrote: >Victor A. Wagner Jr. writes: > > I have NO idea what criteria build_monitor uses to killing > > processes, > >Two conditions: > >1) They have to be spawned by 'bjam.exe' executable. how do you know? >2) They have to be running for more than 5 minutes or show an > error dialog window. these other things run 100% of the time on my system. in the middle of the night they may even go for 5 minutes with NO I/O. > > but when I awoke this morning, it had managed to kill: the dnet > > "run in the background" ORG process, Pirch (my IRC client), a > > proxy that lets me get dcc's through my hardware firewall, > > Trillian (the instant message program), SpyBot resident..... > > I think you get the picture. > >How did you determine that it's build_monitor that caused all >that? While there is always a possibility of a program having bugs, >it's hard to believe that this particular one started to misbehave >all of a sudden after a year of stable work and no changes to the >source code. > > > this thing just walked through my system like a hoard of Vandals > > (or was it Visigoths). whatever > >I'm sorry to hear about the whole thing, but let's get to the roots >of it. First of all, why do you think it was build_monitor? Second, >what operating system are you running? 1) My system has run flawlessly for over a year also and two days ago was when I first installed monitoring..... the first time it ran a bunch of stuff wasn't working in the morning, but I'd been very tired when I went to bed and figured MAYBE I'd shut them down (unlikely as I _never_ _NEVER_ shut down the dnet client)...but I let it go... I made some changes to regression.py so it would work better here then manually ran the system that afternoon...no problems. I let it run automatically again overnight and "bam" all these things that are ONLY started at login time and NEVER touched by me are missing again.... the _logical_ place to look is at "what's new?"... what's new is -monitored on the test line in my script. btw, this morning I also noticed that build_monitor had it's own window open and was spewing out TONS or data to it... is that normal? I took out the teststreams test (I think) but this afternoon's run had already started... but I chose ignore when the modal dialog (may the .....) popped up. btw, tho my log clearly shows them sent to the ftp site, they're not on the website yet... the date is Sunday the time 21:30:03 in the xml file I'd be more than happy to help find this as any problems in running the regression tests will just mean less folks willing to run them. if you get back to me quickly, I can turn on the "-monitored" again... the run starts in just over 2 hours (on the 1/2 hour) (still missing teststreams at this point). 2) WinXPpro sp1 >-- >Aleksey Gurtovoy >MetaCommunications Engineering >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

3 3

serialization - test/compiler status
by Robert Ramey 02 Aug '04

02 Aug '04

I've been working to make changes in the serialization system to support more platforms and pass more tests. I'm approaching the end of what I can do. The following comments reflect the state of the library as I recently uploaded and so may not be reflected by the current test tables. Windows platforms from http://www.meta-comm.com/engineering/boost-regression/developer/serializatio n.html Metroworks CodeWarrior 9.2. - all test failures are related to one of the following three pending issues: a) slist test doesn't compile. The error is related to the internals of the slist implementation which I've been unable to decipher. b) link errors/warnings of replicated symbols. A number of tests - all those that use export and perhaps others generate duplicate symbol warnings for i/o streams. The generated executables also fail with unexpected messages. I suspect an issue with the compiler configuration files cwpro9.hpp for this platform. c) tests using non-intrusive serialization fail to find overload for serialization functions. (Commeau also has this problem). I suspect a compiler bug. So far I've been unable to resolve these issues and would be very appreciative if someone who has and interest and experience with this compiler would like to investigate this issues. MSVC-STLPORT a) In some environments - has a problem compiling spirit 1.6.1. I believe this has to be resolved by tweaking spirit. Borland Passes most tests - certain test failure indicate features which are not ever going to be usable on this platform - basically automatic serialization of arrays. MSVC 6.0/7.0 Pass mosts tests - certain test failure indicate features which are not ever going to be usable on this platform - basically automatic serialization of arrays. These are documented in the manual. VC 7.1 Passing 100 % VC 8.0 Small problem with compile error in library build - I'm hoping that this will build and pass 100 % Gcc 3.x Passing 100 %. Tests on platforms which don't support wide char i/o (e.g. cygwin and mingw). show failure for the related tests This is a feature of the build/bjam system and are not to be considered failures. Intel 7.1 This fails when export is used with invalid dynamic cast. This is unresolvable by me as I don't have this compiler on my system. Anyone with and interest in this compiler is invited to jump in. Intel 8.0 Passing 100 % MACOS - Darwin from http://www.meta-comm.com/engineering/boost-regression/developer/serializatio n.html Previous test results show failure with wide-char i/o. I believe I have addressed this and hoped that next results will show 100 %. Current test results suggest an issue outside my influence. The program links with messages which suggest some sort of issue related to the test_exec_monitor. I would be very appreciative if anyone else want's to take a look at this. Linux - from http://boost.sourceforge.net/regression-logs/cs-Linux/developer/serializatio n.html Gcc 3.2.3, 3.3.2, 3.3.3 Pass 100% Gcc 2.95 This system doesn't support new style streams. This might be made to work but I can't justify the effort. Gcc 2.95 - stlport This probably could be made to work without tooo much problem - but as before its hard to justify the effort given the availability of a free upgrade to gcc 3.3+. As in the case of all the stlport tests, its not clear whether or not the version of stlport is built with streams and in some case which version is being used. GCC 3.4.1 This always passed 100 % - I made and corrected an obscure error while working on other platforms. I'm hoping for 100% next time Intel 7.1 Same as above for gcc 3.4.1 Intel 8.0 Hmmmm this passes 100% in windows and I believe has passed before. This situation is much confused by the policy of frequent releases of compiler updates. We label all of these intel 8.0 even though they are not the same. This os/compiler combination exhibits problems with the array test and export. I see it as unresolvable by me. Interested parties are invited to jump in. Other platforms - from http://boost.sourceforge.net/regression-logs/ AIX This is hung up in the compilation of large mpl expression. Working around this would require access to such a compiler platform which I don't have. This will only get resolved if someone has sufficient interest/necessity to invest the required effort. HP-UX/PARISC - aCC These compiles fail to build the library. The error messages suggest that these compilers don't support enough C++ template syntax to be useable without undertaking heroic efforts and having direct access to the compiler/platrom. IRIX64 This libraries aren't being tested frequently enough to be useful for resolving problems of library implementation. I am marking these platforms unusable for the serialization library. Robert Ramey

2 1

Re:[boost] [serialization] use of iterator_facade, CW8 build
by Robert Ramey 01 Aug '04

01 Aug '04

Rene Rivera wrote: >In another painfully hunt to fix the problems with the seriazation lib >issues in CW8... I tracked the problem down to another instance of: >static_cast<const&>(x) where x is a template with template ctors. The >problem was in iterator_facade, and not directly in the serialization >lib which made it even harder to find :-( >Anyway, I applied this change (figured since this is a known problem by >now with an easy portable solution it would not be a problem)... Hats off - I know this was hard to find. BTW it didn't show up on my test machine which was running CW Pro 9 . Also it looks like someone (B. Dawes? Or perhaps the tester) modified the build so that we don't get a lot of link errors. I believe I'm making progress in understanding an issue with broken function template overloads which breaks non-intrusive serialization. We'll see. Robert Ramey

1 0

[build] bjam crash
by Bertolt Mildner 01 Aug '04

01 Aug '04

I just had a bjam crash: "... instruction at 0x0040d4bd tried to access memory at 0x00000040 ..." current public CVS snapshot bjam built with MSVC 6.5 (build.bat msvc) Win2k SP4 (german) gcc 3.3.1 (cygming special) TOOLS = gcc BUILD=debug release commandline: bjam clean (in \libs\thread\build) Tried to run bjam several times, but always got the same crash. Deleting .jamdeps in \bin solved the problem. After the secessful clean i restored .jamdeps and ran "bjam clean" again, but it did not crash again. I have attached the (winzipped) .jamdeps Bertolt -- Free Crypto Token - FCT www.FreeCryptoToken.org ***************************************************************************** ** ** ** WARNING: This email contains an attachment of a very suspicious type. ** ** You are urged NOT to open this attachment unless you are absolutely ** ** sure it is legitmate. Opening this attachment may cause irreparable ** ** damage to your computer and your files. If you have any questions ** ** about the validity of this message, PLEASE SEEK HELP BEFORE OPENING IT. ** ** ** ** This warning was added by the IU Computer Science Dept. mail scanner. ** *****************************************************************************

1 0

VC 7.1 level 4 warnings (thread, lexical_cast)
by Johan Nilsson 01 Aug '04

01 Aug '04

[Should this really go to boost.users instead?] Hi, loads of warnings are generated when compiling code with VC 7.1 using Boost.Thread and lexical_cast with the warning level set to 4. I use Boost 1.31.0, but at a quick look at the latest versions they seem to have the same problem * Boost.Thread generates numerous C4275 and C4251 (both related to dll-interface), examples: --- ../../../deps\boost\boost\thread\exceptions.hpp(29) : warning C4275: non dll-interface class 'std::logic_error' used as base for dll-interface class 'boost::lock_error' d:\VS.NET_2003\Vc7\include\stdexcept(14) : see declaration of 'std::logic_error' ../../../deps\boost\boost\thread\thread.hpp(78) : warning C4251: 'boost::thread_group::m_threads' : class 'std::list<_Ty>' needs to have dll-interface to be used by clients of class 'boost::thread_group' --- * lexical_cast generates C4511, C4512 + C4127, examples: -- ../../../deps\boost\boost\lexical_cast.hpp(180) : warning C4512: 'boost::detail::lexical_stream<Target,Source>' : assignment operator could not be generated ... ../../../deps\boost\boost\lexical_cast.hpp(180) : warning C4511: 'boost::detail::lexical_stream<Target,Source>' : copy constructor could not be generated ... ../../../deps\boost\boost\lexical_cast.hpp(133) : warning C4127: conditional expression is constant --- Would it be possible to get rid of those using pragmas in the header files? I wouldn't mind disabling C4511/4512 globally but the other ones I'd prefer not to. Selectively disabling the other warnings when including the files is practically impossible. I guess this has been discussed before, but why not compile with warning level 4 + warnings as errors by default? // Johan

3 3

lexical cast and locale
by Martin 01 Aug '04

01 Aug '04

This might be a stupid question but I couldn't find anything in the documentation about it. How do I control the locale used in lexical cast? More specificly I want to control the decimal separator.

2 2

Review Wizard - Status Report
by Tom Brinkman 01 Aug '04

01 Aug '04

I'm currently attempting to contact the authors of the eight remaining libraries to be reviewed. I will start the reviews immediately after the next release of boost is completed. If you are one of the eight authors, and I have not contacted you yet, please contact me directly, and tell me what your availability is. I will schedule the reviews in the months of August, September and October. Please tell me if you have a suggestion for a review manager for your library or if you have any questions about the review process. I will research them for you. Tom Brinkman Review Wizard reportbase(a)yahoo.com __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo

3 2

[algorithm/string] predicate failure for CW8
by Rene Rivera 31 Jul '04

31 Jul '04

It took some digging but I figured out what the problem with the failure on this test is for CW8. Basically CW8 is doing a copy construction on the use of static_cast for a reference when the type of the reference is itself a template typename. In all other cases it does the cast correctly. The work-around is to do the cast on the pointer type and dereference instead of the cast on the reference directly: =================================================================== RCS file: /cvsroot/boost/boost/boost/algorithm/string/classification.hpp,v retrieving revision 1.4 diff -u -r1.4 classification.hpp --- classification.hpp 15 Jul 2004 21:48:25 -0000 1.4 +++ classification.hpp 29 Jul 2004 21:32:49 -0000 @@ -236,8 +236,8 @@ const predicate_facade<Pred2T>& Pred2 ) { return detail::pred_andF<Pred1T,Pred2T>( - static_cast<const Pred1T&>(Pred1), - static_cast<const Pred2T&>(Pred2) ); + *static_cast<const Pred1T*>(&Pred1), + *static_cast<const Pred2T*>(&Pred2) ); } //! predicate 'or' composition predicate @@ -257,8 +257,8 @@ const predicate_facade<Pred2T>& Pred2 ) { return detail::pred_orF<Pred1T,Pred2T>( - static_cast<const Pred1T&>(Pred1), - static_cast<const Pred2T&>(Pred2)); + *static_cast<const Pred1T*>(&Pred1), + *static_cast<const Pred2T*>(&Pred2)); } //! predicate negation operator @@ -273,7 +273,7 @@ inline detail::pred_notF<PredT> operator!( const predicate_facade<PredT>& Pred ) { - return detail::pred_notF<PredT>(static_cast<const PredT&>(Pred)); + return detail::pred_notF<PredT>(*static_cast<const PredT*>(&Pred)); } } // namespace algorithm =================================================================== Those changes make it work on CW8, and it still works on VC7.1 and MinGW. OK to commit?? -- I'll assume the answer is *yes* after a few hours ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

3 5

[serialization] use of iterator_facade, CW8 build fixed.
by Rene Rivera 31 Jul '04

31 Jul '04

In another painfully hunt to fix the problems with the seriazation lib issues in CW8... I tracked the problem down to another instance of: static_cast<const&>(x) where x is a template with template ctors. The problem was in iterator_facade, and not directly in the serialization lib which made it even harder to find :-( Anyway, I applied this change (figured since this is a known problem by now with an easy portable solution it would not be a problem)... =================================================================== RCS file: /cvsroot/boost/boost/boost/iterator/iterator_facade.hpp,v retrieving revision 1.26 retrieving revision 1.27 diff -u -r1.26 -r1.27 --- iterator_facade.hpp 31 Jul 2004 18:10:00 -0000 1.26 +++ iterator_facade.hpp 31 Jul 2004 22:56:49 -0000 1.27 @@ -814,8 +814,8 @@ is_interoperable< Derived1, Derived2 >::value \ )); \ return_prefix iterator_core_access::base_op( \ - static_cast<Derived1 const&>(lhs) \ - , static_cast<Derived2 const&>(rhs) \ + *static_cast<Derived1 const*>(&lhs) \ + , *static_cast<Derived2 const*>(&rhs) \ , BOOST_ITERATOR_CONVERTIBLE(Derived2,Derived1) \ ); \ } =================================================================== After that the serialization lib builds, and tests run. Of course not all tests pass ;-) VC7.1 and Mingw behave as before also. PS. There was one other minor change to the libs/serialization/test/Jamfile to account for locale requirement. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

1 0

[Graph] New branch for graph library development (graph_devel)
by Doug Gregor 31 Jul '04

31 Jul '04

I've started a new branch for further development of the graph library, graph_devel. At the moment it contains only a small amount of work (Brandes' algorithm for betweenness centrality and the Kamada-Kawai spring layout for undirected graphs), but it will be used for more aggressive development as well. Algorithms will be merged to mainline so long as we _aren't_ planning a release in the next few days, but any infrastructure changes will remain on the branch for a bit longer. I've only branched the boost/graph and libs/graph directories. Doug

1 0

[thread] barrier.cpp don't compile with msvc60 & stlport]
by Sven Johannsen 31 Jul '04

31 Jul '04

Hi, with the current cvs-version (7/23/2004) i can't build the thread library with stlport 4.5.3 and msvc60. I use the following bjam command: bjam "-sTOOLS=msvc-stlport" "-sSTLPORT_PATH=D:\develop\STLPort" "-sSTLPORT_VERSION=4.5.3" and get the following errortext: ...\boost-23072004\libs\thread\build\..\src\barrier.cpp(21) : error C2440: 'type cast' : 'char [22]' kann nicht in 'class _STL::invalid_argument' konvertiert werden Quelltyp konnte von keinem Konstruktor angenommen werden, oder die Ueberladungsaufloesung des Konstruktors ist mehrdeutig Sorry about the german error-text. it's something about: can't convert char[22] to 'class _STL::invalid_argument' I don't know that wrong about: throw std::invalid_argument("count cannot be zero."); because the StlPort defines invalid_argument as: class _STLP_CLASS_DECLSPEC invalid_argument : public logic_error { public: invalid_argument(const string& __arg) : logic_error(__arg) {} # ifdef _STLP_OWN_IOSTREAMS ~invalid_argument() _STLP_NOTHROW_INHERENTLY; # endif }; With the microsoft stl everything compile fine. (bjam "-sTOOLS=msvc") Sven

5 10

Boost-wide report -- explicit failure markup not working?
by Jeff Garland 31 Jul '04

31 Jul '04

Looking at the boost-wide reports today, testmicrosec_time_clock is marked as failing red on a whole series of compilers. However, they should be 'green' (and have been in past reports) as they have been explicitly marked as failing: http://www.meta-comm.com/engineering/boost-regression/developer/date_time.h… <test name="testmicrosec_time_clock"> <mark-failure> <toolset name="msvc"/> <toolset name="vc7"/> <toolset name="vc7.1"/> <toolset name="cwpro8"/> <toolset name="borland-5.6.4"/> <toolset name="gcc"/> <toolset name="borland"/> <toolset name="mingw"/> <toolset name="meta-como-win32-4.3.3-msvc"/> <note author="B. Garst" refid="22"/> </mark-failure> </test> Seems like there is something amiss in the results reporting... Jeff

5 5

Re: [boost] Re: Boost-wide reports: Time to join in!
by JOAQUIN LOPEZ MU?Z 31 Jul '04

31 Jul '04

----- Mensaje original ----- De: "Victor A. Wagner Jr." <vawjr(a)rudbek.com> Fecha: Jueves, Julio 29, 2004 7:52 pm Asunto: Re: [boost] Re: Boost-wide reports: Time to join in! > > > >I'd be extremely grateful if you could run MSVC 8.0 tests to > >check a fix I just commited, even if you don't upload the results to > >the Boost-wide reports page (of course, if you do that too so much > >the better.) > > I just started a rerun my testing > Big thanks! Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 8

RE: [boost] Re: Re: Re: Javascript Tree Control [was: SerializationMenu]
by Reece Dunn 31 Jul '04

31 Jul '04

Jonathan Turkanis wrote: > > If we do this, then it should be possible to do something like: > > > > <span onclick = "follow_link(1.5)">Chapter 1.5</span> > >This would be embedded in an anchor element, to allow links to work on >no-script browsers? I think this should work. I'll see if I can get frames/tree_control working in Boost.Book and start experimenting with the code. > > With regards to the page refreshing, this happens when you select >"sync" > > anyway. > >Yes, but I was thinking that "sync" would be used relatively >infrequently, whereas following links within a page is common. Sure. > > Is it possible to use '#' instead of '?', so the browsers won't > > refresh the docs. > >If we use Rene's idea of displaying the tree in the content frame, >then yes (I think). Otherwise, the url with the correct fragement >identifier won't be displayed in the address bar. Okay. >Including the tree in the content frame is a big problem, though. When >I replied to Rene I was mostly worried about download times when >viewing the docs online. But if a large part of the docs eventually >use trees, it could unnecessarily increase the size of the Boost >distribution. We could use iframes, but this won't work for old >browsers. Sure. It would be a good idea to have a working XSLT for Boost.Book/tree_control first so we can try out the various ideas. >I'd like to focus on: > > 1. Providing a tree control which library authors can add to >hand-written docs > 2. Allowing docs generated with Boost.Book to have a built-in tree >control, with automatic synchronization if possible > >1) is basically done, unless someone has an idea how to eliminate the >need for [sync] >2) is doable, with hitch that linking within a page causes a reload >(unless I misunderstood your suggestion) The main steps for writing the Boost.Book XSLT code are: 1. Disabling section ToC's; 2. Overriding the default ToC mechanism in favour of the tree control menu; 3. Providing "chunks" for the main frame page and the ToC page; 4. Iterating over the various sections and extracting the names of the "chunks" to use as the links; 5. Modifying the way sections are generated if necessary to accommodate the new control; 6. Anything I've forgotten. >I think only time will tell whether it's more annoying to have to >manually [sync] the documentation or to reload the docs when linking >within a page. So I'd say two variants of 2) should be pursued: one >which produces docs using the existing tree component, and one which >produces auto-syncing docs. Once the code is written it should be possible to play around with what it generates to test the ideas that you and Rene are suggesting. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

1 0

RE: [boost] White cells
by Rozental, Gennadiy 31 Jul '04

31 Jul '04

> > - test: ifstream_line_iterator_test > > Commented out by the author -- > http://cvs.sourceforge.net/viewcvs.py/boost/boost/libs/test/te st/Jamfile?r1=1.23&r2=1.24 > I'm not sure whether this is a good practice. I'd say that if the test > failure indicates a real issue with the library on a particular set of > compilers -- even if that set includes most of them -- then marking it up as an "expected failure" with a corresponding note would be more fair. > Michael? Gennadiy? Above test actually should pass on almost all compilers (as it does locally). For some reason it fails during regression test. Something about couldn't find pattern file. So, because 1. I do not know how to fix that. 2. Nobody responded on my request 3. This test is not critical for this release 4. We have enough on our plates already I decided to comment it out for now. I plan to reinclude it after release. Gennadiy.

2 1

RE: [boost] Re: Re: Javascript Tree Control [was: Serialization Menu]
by Reece Dunn 31 Jul '04

31 Jul '04

Jonathan Turkanis wrote: >"Rene Rivera" <grafik.list(a)redshift-software.com> wrote in message >news:410B0839.1030106@redshift-software.com... > > Jonathan Turkanis wrote: > > > > I'd love synchronization to be automatic but I just don't see how > > > to do it. > > > > It's possible but only if you invert the relation between the frames and > > the documents. If instead of making a frameset with the tree and the > > document you could instead make the document inline the tree frame > > inside the document page and hence the URL would always be direct > > (using iframe tag). This might be contrary to one of the intrusion > > principles, but it would solve the problem. > >I've thought a bit more about this, and it occured to me that if the >tree is displayed in the same frame as the content, it's state will >not be preserved when a link is followed unless this info is added to >the url. So it appears this idea suffers from the same problems as >Reece's suggestion. The question here is: are we going to place the emphasis on auto-generated docs? If we do this, then it should be possible to do something like: <span onclick = "follow_link(1.5)">Chapter 1.5</span> With regards to the page refreshing, this happens when you select "sync" anyway. Is it possible to use '#' instead of '?', so the browsers won't refresh the docs. This might require a standard naming scheme for <a name = "..."/> marked sections, but this would be easier to do if the docs are auto-generated. For older docs that want to keep their HTML structure but move over to the treeview control, it should be easy to do if: 1. They are compatible with XHTML (i.e. they can be loaded in an XML client and manipulated via an XSLT stylesheet, e.g. using xsltproc). NOTE: This should be trivial if the HTML has been run through htmltidy. 2. The section format follows a regular pattern, e.g. h1 elements for level 1, h2 for level 2, etc. This would allow you to: 1. Insert and generate the treeview control by making a pass over the hN tags. 2. Clean up sections of the form: <a name = "..."/><hN>...</hN> Issues would be: 1. Do we remove the ToC provided in the HTML doc (can we detect and remove/use it?) 2. Have we detected the document structure correctly? 3. Other issues I've missed. Regards, Reece Dunn _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

2 1

Re: Threads Rewrite?
by Tonko Juricic 31 Jul '04

31 Jul '04

> Dayton wrote: > ... I tend to think in the similar direction. Threads class happens to be the first one that I tried to use as a newcomer to boost++ so I ended up 'complaining' here. In particular, losing features that one learns to take for granted on some platforms (like thread stop, suspended start) is not motivating. Also, relying on OS notifications (like DLL_THREAD_DETACH on Win32) for TLS cleanup, and extra code required to support boost threads static library on Win32 is not my favourite, despite a rather ingenious implementation. I think it would be best if we can completely avoid using Win32 DLL process/thread notifications and make TLS cleanup part of the thread function object. I already expressed, somewhat radical I guess, opinion that, at least on Win32, TLS functionality is probably not worth the trouble of existing cleanup support code. Tony __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail

9 24

Threads Rewrite?
by David Abrahams 31 Jul '04

31 Jul '04

Hi Boosters, I've tried several times to contact Bill Kempf about moving forward with threads, even leaving him messages on his home answering machine. I've had no reply. It's important that we make an effort to move Boost towards a uniform licensing scheme, and the threads library is an especially important one to do that for. We've been talking about significant restructuring in this library; is it likely that we'll get to a point where the original code can be thrown out? That may be the only way we'll be able to change the license. IMO the docs really *need* to be thrown out and re-done, even if the design were to stay substantially the same. Thoughts? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

15 40

release status?
by Pavol Droba 31 Jul '04

31 Jul '04

Hi, What is the current status of the release? I have just returned from vacation and I can't find out what is happening. Thanks, Pavol

2 1

Re: [Spirit-devel] Re: Spirit: Some more regressions
by Joel de Guzman 31 Jul '04

31 Jul '04

David Abrahams wrote: > Joel de Guzman <joel(a)boost-consulting.com> writes: > > >>2) VC8: http://tinyurl.com/3jmem > > > VC8 isn't released yet so problems there can't be considered > regressions. > > Also, I think you can download a free public beta so you the compiler > need not remain inaccessible to you. Ok, thanks. I downloaded it and I am using it for testing now. AFAICT, there's no problem with Spirit code and the errors above (which is ok on all compilers, including Comeau) seem to be VC8.0 bugs. For that matter, wouldn't it make sense for VC8.0 in the test reports be named as VC8.0 Beta to avoid confusion? << Now I notice more and more compilers added in the reports. Cool! Yet... arghhh! More yellows!!! >> Thanks! -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

1 0

Range/workaround test: SFINAE defect on EDG?
by Stefan Slapeta 31 Jul '04

31 Jul '04

First of all, the most important question: Why do we test workarounds for partial spezialization on compiler which don't need these workarounds? I've isolated the problem with the failing range/workaround testcase on Intel 8. IMO it's a compiler defect because the function template in is_array should be disabled by SFINAE. This code fails to compile with the current comeau release, too. template <class T> struct wrap {}; // this one should disabled because it's not allowed to return an array: template< typename T > T(* is_array_tester1(wrap<T>) )(wrap<T>); char is_array_tester1(...); void f() { sizeof(is_array_tester1(wrap<int[42]>()); } Shall a submit a DR? Stefan

5 5

White cells
by Stefan Slapeta 31 Jul '04

31 Jul '04

Please could anybody explain me what the reason for white cells in the regression tests is and why these tests are not executed? Concrete examples are: - test: ifstream_line_iterator_test - numeric/ublas: test7 Thanks, Stefan

2 1

Javascript Tree Control [was: Serialization Menu]
by Jonathan Turkanis 31 Jul '04

31 Jul '04

Dear All, There was a discussion a couple weeks ago about the javascript menu in Robert Ramey's serialization docs. I suggested making a menu component available Boost-wide and testing it on a large number of browsers to address portability issues. I've written a preliminary version, documented here: http://tinyurl.com/6a9ym and downloadable from here (its a bit large because it contains a bunch of screenshots): http://tinyurl.com/6w56v (tree_control.zip) You can see the control in action here: http://tinyurl.com/6tdvy I've verified that it works -- with varying levels of functionality -- on 26 browsersincluding some antiques such as IE3.02.

8 25

typeof: automatic ID generation and GCC problems
by Arkadiy Vertleyb 31 Jul '04

31 Jul '04

Hi everybody, I modified the code to automatically generate IDs of registration groups. The registration now is as simple as: #include BOOST_TYPEOF_INCREMENT_REGISTRATION_GROUP() BOOST_TYPEOF_REGISTER_TYPE(...); BOOST_TYPEOF_REGISTER_TEMPLATE(...); ... I also added some tests that should cause the ODR violation (see odr.hpp, odr1.cpp, odr2.cpp). VC7.1 is fine with them, however I can't make GCC 3.3 to compile this, and it stops much before the ODR could be diagnosed. Looks like this compiler totally can't handle the case when I try to use typeof (native or not) inside a template. When I force the typeof emulation, I am getting: "sorry, unimplemented: `method_call_expr' not supported by dump_expr" on every attempt to use my encoding/decoding stuff inside a template. From searching the web it looks like this is some kind of known bug related to improper handeling of sizeof(). Since sizeof() is the central part of all this, I don't really know how to work it around... This would probably be OK, since GCC has the native typeof support. However, when I use the native support, I run into a different problem that can be illustrated by the following code: template<class T, class U> typeof(T() + U()) sum(const T& t, const U& u) { return t + u; } main() { sum(5, 3.14); // this is line 9 return 0; } The compile of this code fails with following message: a.cpp:9: internal compiler error: in write_type, at cp/mangle.c:1555 GCC appears to be fine when the native typeof is used inside _class_ templates, though. I would really appreciate if anybody shed some light on any of these problems... The code is in the Spirit CVS and at: http://groups.yahoo.com/group/boost/files/typeof.zip Again, eveything is working fine in VC7.1. If anybody could try any other compiler (to build main.cpp, odr1.cpp, and odr2.cpp together), I would really appreciate this. Thanks, Arkadiy

5 6

Boost.Python -- Works With Qt?
by Robert Bell 30 Jul '04

30 Jul '04

Hi boosters- I have some Qt widgets that I need exported to Python for use with PyQt. I've been looking into sip, but I'm also curious if boost.python is up to the task. Has anyone tried this? Bob

2 2

Boost Threads Link Problem
by Joel de Guzman 30 Jul '04

30 Jul '04

Hi, Has all the Boost.Threads problems been solved yet? I am still having link problems with Threads on intel-win32-7.1 -vc6 (w/ or w/out stlport- 4.5.3): http://tinyurl.com/5c2dg Any clues? TIA, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

5 11

Exception safety guarantie
by Pavol Droba 30 Jul '04

30 Jul '04

Hi, During the review of the string_algo library, there was a request for better specification of exception safety in the lib. I have put some info into the docs, but I'm not sure if it is correct and sufficient. Could some of you, that had lead the discussion about this topic (namely David Abrahams or David B. Held) check it out and tell me your opinion? I'm open to any suggestions. I want to make it reasonable and correct. I have written a general paragraph about the basic guarantee here: http://tinyurl.com/639ex and there are notes besides several algorithms like this: http://tinyurl.com/4yqp8 Thanks, Pavol

4 36

RE: [boost] Re: counting_iterator_test.hpp fails on aC++
by DY, JERRY U (SBCSI) 30 Jul '04

30 Jul '04

Dave, See attachment. Thanks! -Jerry -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams Sent: Friday, July 30, 2004 7:22 AM To: boost(a)lists.boost.org Subject: [boost] Re: counting_iterator_test.hpp fails on aC++ "DY, JERRY U $SBCSI$" <jd2419(a)sbc.com> writes: > Sorry. This is the correct version of the new static assertion. > > // workaround for aC++ CR JAGaf33512 > # define BOOST_ITERATOR_ADAPTOR_ASSERT_TRAVERSAL(cat) \ > iterator_adaptor_assert_traversal<my_traversal, cat>(); > // typedef int > assertion[sizeof(detail::static_assert_convertible_to<cat>(my_traversal( > )))]; > > -Jerry Please post a patch as an attachment. I don't know how to evaluate this otherwise (especially not during my vacation ;->). -- Dave Abrahams Boost Consulting http://www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Mini-reviews
by Tom Brinkman 30 Jul '04

30 Jul '04

Mini-reviews would be very useful. I�m shur that each boost developer/user could contribute a few small, useful algorithms. It would be a great way to increase the level of participation by developers who want to contribute but don�t have the time to write a complete library. To get things started, as Review Manager, I could start by collecting submissions by other boost members and present them to the group monthly or bi-monthly. We could call this the Monthly Boost Algorithms review. (I have at-least ten algorithms that I could contribute for consideration for the first few reviews.) We should also discuss to where to place the algorithms /code within the boost namespace. I could create a document that lists all the algorithms under consideration with a small summary. The boost members could than accept/reject each algorithm and offer suggestions. More to follow in the next few day� Any thoughts? Tom Brinkman reportbase(a)yahoo.com Review Wizard On May 23, 2004, at 6:06 AM, Gennadiy Rozental wrote: >> I added several algorithms that extent STL algorithms set. I use them in my Boost.Test development. But since they seems to be generic and IMO should be present in STL I propose to push them in boost/algorithm.hpp (or under boost/algorithm). I remember there was a discussion already about these algorithms. On Fri, 23 Jul 2004 Herv� Br�nnimann` wrote: >> There was an idea of mini-reviews tossed around. This wouldn't include range / container traits (as Thorsten Ottosen or John Torjo are doing) since it's a much bigger scope, but for one or two functions, a single header, it seems an overkill to have a review. Can we have an Algorithms Review Manager under the Review Manager (as he see fits to forward requests) for the subspace boost::algorithm? _______________________________ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com

8 11

RE: [boost] Re: Threads Rewrite?
by Glen Knowles 30 Jul '04

30 Jul '04

> From: Roland [mailto:roland.schwarz@chello.at] > > It is fine to hear, that there are serious attempts now to > move forward with the threads library. > > However it would be too bad if we needed a _complete_ rewrite > of the threading library. Could anyone please drop me some > lines why this should be necessary at all? > Is the new license thus incompatible to the old one? This is entirely about licensing. The thread library needs to be under the boost license and it is not. All attempts to date to contact the copyright holder (William Kempf) have failed, without his permission we are in the position of needing to rewrite it into compliance. Glen Knowles Centor Software Corporation

4 3

typeof
by Arkadiy Vertleyb 30 Jul '04

30 Jul '04

Thanks to the workaround independently suggested by Daniel and Aleksey, the test now compiles successfully in both VC7.1 and GCC 3.3. The workaround actually also took care of the case when typeof is emulated. The bottomline -- GCC doesn't like typeof to be used in the return type of a function template, whether this is a native typeof, or emulated one :-) (after I performed some simplifications of my code, the error I ended up with is: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11869, which is a duplicate of another error, which is "SUSPENDED". But, since the native typeof also doesn't work in the same context, and since the same workaround works for both, I consider the issue resolved) Neither compiler reported any ODR violation. So I invite you to take another look at the simplified registration process. Another small addition was two macros: BOOST_TYPEOF_TPL(expr), and BOOST_AUTO_TPL(var, expr) that are intended to be used in templates, when the expression depends on template parameters. These macros take care of adding or not adding the "typname" keyword depending on whether typeof is emulated, or the native one is used. http://groups.yahoo.com/group/boost/files/typeof.zip (or Spirit CVS) Thanks again for helping me with GCC issue. Arkadiy

2 1

Re:[boost] Javascript Tree Control [was: Serialization Menu
by Reece Dunn 30 Jul '04

30 Jul '04

Robert Ramey wrote: >Jonathan Turkanis > > >There was a discussion a couple weeks ago about the javascript > >menu in Robert Ramey's serialization docs. I suggested making a menu > >component available Boost-wide and testing it on a large number of > >browsers to address portability issues. I've written a preliminary > >version, documented here: > > >I've verified that it works -- with varying levels of functionality -- > >on 26 browsersincluding some antiques such as IE3.02. > >I'm still looking at this but I have some preliminary questions >observations > >c) The boost "rule" no javascript. This should be re-formulated to be "all >documentation should be usable on any browser that supports frames". This >can be implemented using the approach b) above. If you are using Boost.Book, it should be possible to set up a parameter to control frames/no-frames generation to produce this style navigation (frames=yes or toc-navigation=tree) and the existing one (frames=no or toc-navigation=default). >d) The control presented is a very nice job - but I was hoping this might >take a slightly different direction. What I would like to see is: > >"Boost Documentation Navigator" > >1) a two frame page. Left frame containing a expandable/collapsible index >implemented by a control such as yours. The right page would be the >current >boost documentation pages. > >2) This "Navigator" would be automatically generated from the Boost.Book >xml >files using XSLT or some other appropriate tool. It should be easy to implement in XSL:T. >Boost.book might have to add a little bit to support this. Boost.Book would need to override how DocBook generates ToC's. The XSL:T code would need to generate the relevant code - which will be easy to do - for the main ToC and suppress the generation of sub-section ToC's. The only problem I forsee in writing the code will be getting the HTML file for the document chunk (I would need to look into how DocBook does this). >While I'm on the subject of Boost.book. I would hope that the formatting >is >in a .css so that I might replace it with my preferred look and feel. (I >prefer the "classic" one). I believe this would resolve the essentially >irresolvable about esthetics. It already is. The CSS is located at: $(boost-root)/doc/html/boostbook.css. When generating the navigation pane, Boost.Book should use tree.css instead of boostbook.css. The new look and feel has modified the way the top section is rendered, so it might look different when using the "classic" L&F. It also renders navigation controls at the top and bottom in Spirit style layout. To get the old-style header, you will need to add the following XSL:T parameters to the command-line: nav.border='Boost' (default: 'none') nav.flow='DocBook' (default: 'Spirit') I am not sure how nav.border=Boost interacts with the "classic" stylesheet. NOTE: There is also a nav.layout parameter that controls the "Home | ... | More" contents: 'horizontal' (default) - renders in "classic" Boost style 'vertical' - renders in a vertical box like in the "Getting Started" page 'none' - do not display the links. NOTE: this will display the Boost logo. For "standalone" docs. nav.flow also has the value 'none' so it does not display any navigation. This is useful for generating the "getting started" page and other standalone pages. This information should really be added to the Boost.Book documentation (e.g. under "controlling documentation generation"). There is a summary of these parameters, their values and a description in the navbar.xsl file. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

2 1

Re:[boost] Javascript Tree Control [was: Serialization Menu
by Robert Ramey 30 Jul '04

30 Jul '04

Jonathan Turkanis >There was a discussion a couple weeks ago about the javascript >menu in Robert Ramey's serialization docs. I suggested making a menu >component available Boost-wide and testing it on a large number of >browsers to address portability issues. I've written a preliminary >version, documented here: >I've verified that it works -- with varying levels of functionality -- >on 26 browsersincluding some antiques such as IE3.02. I'm still looking at this but I have some preliminary questions observations a) Visually as displayed in the demo it looks very nice. b) I think that testing on 26 browsers and asserting it works on 95% of those in use is the wrong way to look at it. I believe it should be a requirement. "Works on all browsers" - has "more" functionality on browsers that support it. In the case of my implementation - it displays fully expanded unless its one of the three browsers known to work properly. c) The boost "rule" no javascript. This should be re-formulated to be "all documentation should be usable on any browser that supports frames". This can be implemented using the approach b) above. d) The control presented is a very nice job - but I was hoping this might take a slightly different direction. What I would like to see is: "Boost Documentation Navigator" 1) a two frame page. Left frame containing a expandable/collapsible index implemented by a control such as yours. The right page would be the current boost documentation pages. 2) This "Navigator" would be automatically generated from the Boost.Book xml files using XSLT or some other appropriate tool. This would have the following advantages. 1) Usage of this "Navigator" would be optional. Lots of times its interesting to send a page without the frame. Searching through pages without the "Navigator" would be the same as it now - tedious but relieable. 2) it would be "free". The contents/index would be automatically generated without my having to go through another layer of documentation and preparing an index by hand. Those using boost book would get a complete index while old documentation would have just an entry into the top level. 3) it would provide much incentive for boost authors to move their documentation over to boost.book Boost.book might have to add a little bit to support this. While I'm on the subject of Boost.book. I would hope that the formatting is in a .css so that I might replace it with my preferred look and feel. (I prefer the "classic" one). I believe this would resolve the essentially irresolvable about esthetics. Robert Ramey

3 2

[assign, python, range] New inspection errors..
by Rene Rivera 30 Jul '04

30 Jul '04

Latest results of running the inspection tests: * Thorsten Ottosen you need to fix your editor to not insert TABS into code, see: http://www.boost.org/regression-logs/inspection_report.html#assign - and, http://www.boost.org/regression-logs/inspection_report.html#range * Joel de Guzman you need to fix your editor and possibly CVS setup to insert consistent end-of-lines, see: http://www.boost.org/regression-logs/inspection_report.html#python -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

4 5

RE: [boost] Re: counting_iterator_test.hpp fails on aC++
by DY, JERRY U (SBCSI) 30 Jul '04

30 Jul '04

Sorry. This is the correct version of the new static assertion. // workaround for aC++ CR JAGaf33512 # define BOOST_ITERATOR_ADAPTOR_ASSERT_TRAVERSAL(cat) \ iterator_adaptor_assert_traversal<my_traversal, cat>(); // typedef int assertion[sizeof(detail::static_assert_convertible_to<cat>(my_traversal( )))]; -Jerry -----Original Message----- From: DY, JERRY U (SBCSI) Sent: Tuesday, July 27, 2004 12:54 PM To: 'boost(a)lists.boost.org' Subject: RE: [boost] Re: counting_iterator_test.hpp fails on aC++ Dave, As you suggested, an auxiliary function template is defined (outside of the iterator_adaptor class - aC++ doesn't like it if it's a member function): // workaround for aC++ CR JAGaf33512 template <typename TR1, typename TR2> inline void iterator_adaptor_assert_traversal () { typedef int assertion[sizeof(detail::static_assert_convertible_to<TR2>(TR1()))]; } Then the old static assertion is replaced like so: # define BOOST_ITERATOR_ADAPTOR_ASSERT_TRAVERSAL(cat) \ iterator_adaptor_assert_traversal<my_traversal, random_access_traversal_tag>(); // typedef iterator_adaptor_assert_traversal<my_traversal, cat> assert_traversal_t; I tested this by adapting an ordinary pointer to a forward traversal iterator and if the program calls the operator+= (calling the adaptor's advance member function and triggering the static assertion), the compile fails, the compile succeeds otherwise. There should be no additional overhead incurred due to the workaround because the function itself is inlined and all it does is a typedef. Is this workaround acceptable for check-in? Thanks! -Jerry

2 1

shared_ptr question
by Andrew Shiels 30 Jul '04

30 Jul '04

Im very new to boost, and have just started to intergrate the shared_ptr smart pointer into one of my applications. I am storing a lot of pointers (to objects) in a std::vector. typedef boost::shared_ptr<CMyClass> my_shared_ptr; typedef std::vector<my_shared_ptr> my_shared_ptr_vector; What i need to do is to additionally store a reference to the same objects (in the vector) in a CListCtrl (MFC). The CListCtrl allows you to associate a pointer with each item (row) in the list control. Before i used shared_ptr i used to add the data as below: CMyClass pItem = new CMyClass(); my_vector->push_back(pItem); CListCtrl::SetItemData->SetItemData(iItemNumber, (DWORD)pItem); Now using shared_ptr (see below) i get a compiler error saying that it cannot convert from my_shared_ptr to DWORD. my_shared_ptr myPtr (new CMyClass(); my_shared_ptr_vector->push_back(myPtr); CListCtrl::SetItemData->SetItemData(iItemNumber, reinterpret_cast<DWORD_PTR>(myPtr)); My second question is if i was able to add the item data as ... CListCtrl::SetItemData->SetItemData(iItemNumber, reinterpret_cast<DWORD_PTR>(myPtr)); ...would the internal reference counter be incremented in shared_ptr? My vector may be destroyed before my CListCtrl and I dont want the item data to be deleted until both are out of scope. Thanks Andy

3 3

pqs - new...improved with angles
by Andy Little 30 Jul '04

30 Jul '04

Latest version of pqs is available at my site. Now incorporating angles: URL<http://www.servocomm.freeserve.co.uk/Cpp/pqs-2-00-01/download.html> regards Andy Little

1 0

[tokenizer] default tokenizer function
by Vladimir Prus 30 Jul '04

30 Jul '04

The current CVS still has char_delimiter_separator as default tokenizer function, while documentation says that class is deprecated. Any chance this will be fixed? It's very weird, and I'd also prefer escaped_list_separator to be default. (I know string_algo has splitter too, but for now it does not work on all compilers where program_options work -- for example, borland and intel 7.1) - Volodya

1 0

String Algo bug.
by John Maddock 30 Jul '04

30 Jul '04

There seems to be a bug in the string algorithm library that results in a valid container iterator being compared to a "singular" default constructed iterator: this operation is not supported by the iterator requirements and results in an assertion being thrown when testing with VC7.1+STLPort (or any other compiler with STLPort for that matter). The call stack is: stlport_vc71_stldebug46.dll!_STL::__stl_debug_engine<bool>::_Terminate() Line 324 C++ stlport_vc71_stldebug46.dll!_STL::__stl_debug_engine<bool>::_Assert(const char * __expr=0x0057420c, const char * __f=0x00574180, int __l=0x0000012d) Line 308 C++ regex_test.exe!_STL::operator==<_STL::_Nondebug_string<char,_STL::char_trait s<char>,_STL::allocator<char> > >(const _STL::_DBG_iter_base<_STL::_Nondebug_string<char,_STL::char_traits<char>,_ST L::allocator<char> > > & __x={...}, const _STL::_DBG_iter_base<_STL::_Nondebug_string<char,_STL::char_traits<char>,_ST L::allocator<char> > > & __y={...}) Line 301 + 0x2e C++ regex_test.exe!boost::algorithm::iterator_range<_STL::_DBG_iter<_STL::_Nonde bug_string<char,_STL::char_traits<char>,_STL::allocator<char> >,_STL::_Const_traits<char> > >::operator==<_STL::_DBG_iter<_STL::_Nondebug_string<char,_STL::char_traits< char>,_STL::allocator<char> >,_STL::_Const_traits<char> > >() Line 119 + 0x47 C++ regex_test.exe!boost::algorithm::find_iterator<_STL::_DBG_iter<_STL::_Nondeb ug_string<char,_STL::char_traits<char>,_STL::allocator<char> >,_STL::_Const_traits<char> > >::equal(const boost::algorithm::find_iterator<_STL::_DBG_iter<_STL::_Nondebug_string<char, _STL::char_traits<char>,_STL::allocator<char> >,_STL::_Const_traits<char> > > & Other={...}) Line 147 + 0x12 C++ regex_test.exe!boost::iterator_core_access::equal<boost::algorithm::find_ite rator<_STL::_DBG_iter<_STL::_Nondebug_string<char,_STL::char_traits<char>,_S TL::allocator<char> >,_STL::_Const_traits<char> > >,boost::algorithm::find_iterator<_STL::_DBG_iter<_STL::_Nondebug_string<cha r,_STL::char_traits<char>,_STL::allocator<char> >,_STL::_Const_traits<char> > > >() Line 518 C++ regex_test.exe!boost::operator==<boost::algorithm::find_iterator<_STL::_DBG_ iter<_STL::_Nondebug_string<char,_STL::char_traits<char>,_STL::allocator<cha r> >,_STL::_Const_traits<char> > >,boost::algorithm::iterator_range<_STL::_DBG_iter<_STL::_Nondebug_string<ch ar,_STL::char_traits<char>,_STL::allocator<char> >,_STL::_Const_traits<char> > > const ,boost::forward_traversal_tag,boost::algorithm::iterator_range<_STL::_DBG_it er<_STL::_Nondebug_string<char,_STL::char_traits<char>,_STL::allocator<char> >,_STL::_Const_traits<char> > > const &,int,boost::algorithm::find_iterator<_STL::_DBG_iter<_STL::_Nondebug_string <char,_STL::char_traits<char>,_STL::allocator<char> >,_STL::_Const_traits<char> > >,boost::algorithm::iterator_range<_STL::_DBG_iter<_STL::_Nondebug_string<ch ar,_STL::char_traits<char>,_STL::allocator<char> >,_STL::_Const_traits<char> > > const ,boost::forward_traversal_tag,boost::algorithm::iterator_range<_STL::_DBG_it er<_STL::_Nondebug_string<char,_STL::char_traits<char>,_STL::allocator<char> >,_STL::_Const_traits<char> > > const &,int>(const boost::iterator_facade<boost::algorithm::find_iterator<_STL::_DBG_iter<_STL: :_Nondebug_string<char,_STL::char_traits<char>,_STL::allocator<char> >,_STL::_Const_traits<char> > >,boost::algorithm::iterator_range<_STL::_DBG_iter<_STL::_Nondebug_string<ch ar,_STL::char_traits<char>,_STL::allocator<char> >,_STL::_Const_traits<char> > > const ,boost::forward_traversal_tag,boost::algorithm::iterator_range<_STL::_DBG_it er<_STL::_Nondebug_string<char,_STL::char_traits<char>,_STL::allocator<char> >,_STL::_Const_traits<char> > > const &,int> & lhs={...}, const boost::iterator_facade<boost::algorithm::find_iterator<_STL::_DBG_iter<_STL: :_Nondebug_string<char,_STL::char_traits<char>,_STL::allocator<char> >,_STL::_Const_traits<char> > >,boost::algorithm::iterator_range<_STL::_DBG_iter<_STL::_Nondebug_string<ch ar,_STL::char_traits<char>,_STL::allocator<char> >,_STL::_Const_traits<char> > > const ,boost::forward_traversal_tag,boost::algorithm::iterator_range<_STL::_DBG_it er<_STL::_Nondebug_string<char,_STL::char_traits<char>,_STL::allocator<char> >,_STL::_Const_traits<char> > > const &,int> & rhs={...}) Line 819 + 0x32 C++ regex_test.exe!boost::iterator_adaptor<boost::transform_iterator<boost::algo rithm::detail::copy_iterator_rangeF<_STL::basic_string<char,_STL::char_trait s<char>,_STL::allocator<char> >,_STL::_DBG_iter<_STL::_Nondebug_string<char,_STL::char_traits<char>,_STL:: allocator<char> >,_STL::_Const_traits<char> > >,boost::algorithm::find_iterator<_STL::_DBG_iter<_STL::_Nondebug_string<cha r,_STL::char_traits<char>,_STL::allocator<char> >,_STL::_Const_traits<char> > >,boost::use_default,boost::use_default>,boost::algorithm::find_iterator<_ST L::_DBG_iter<_STL::_Nondebug_string<char,_STL::char_traits<char>,_STL::alloc ator<char> >,_STL::_Const_traits<char> > >,_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> >,boost::use_default,_STL::basic_string<char,_STL::char_traits<char>,_STL::a llocator<char> >,boost::use_default>::equal<boost::transform_iterator<boost::algorithm::det ail::copy_iterator_rangeF<_STL::basic_string<char,_STL::char_traits<char>,_S TL::allocator<char> >,_STL::_DBG_iter<_STL::_Nondebug_string<char,_STL::char_traits<char>,_STL:: allocator<char> >,_STL::_Const_traits<char> > >,boost::algorithm::find_iterator<_STL::_DBG_iter<_STL::_Nondebug_string<cha r,_STL::char_traits<char>,_STL::allocator<char> >,_STL::_Const_traits<char> > >,boost::use_default,boost::use_default>,boost::algorithm::find_iterator<_ST L::_DBG_iter<_STL::_Nondebug_string<char,_STL::char_traits<char>,_STL::alloc ator<char> >,_STL::_Const_traits<char> > >,_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> >,boost::use_default,_STL::basic_string<char,_STL::char_traits<char>,_STL::a llocator<char> >,boost::use_default>() Line 297 + 0x12 C++ regex_test.exe!boost::iterator_core_access::equal<boost::transform_iterator< boost::algorithm::detail::copy_iterator_rangeF<_STL::basic_string<char,_STL: :char_traits<char>,_STL::allocator<char> >,_STL::_DBG_iter<_STL::_Nondebug_string<char,_STL::char_traits<char>,_STL:: allocator<char> >,_STL::_Const_traits<char> > >,boost::algorithm::find_iterator<_STL::_DBG_iter<_STL::_Nondebug_string<cha r,_STL::char_traits<char>,_STL::allocator<char> >,_STL::_Const_traits<char> > >,boost::use_default,boost::use_default>,boost::transform_iterator<boost::al gorithm::detail::copy_iterator_rangeF<_STL::basic_string<char,_STL::char_tra its<char>,_STL::allocator<char> >,_STL::_DBG_iter<_STL::_Nondebug_string<char,_STL::char_traits<char>,_STL:: allocator<char> >,_STL::_Const_traits<char> > >,boost::algorithm::find_iterator<_STL::_DBG_iter<_STL::_Nondebug_string<cha r,_STL::char_traits<char>,_STL::allocator<char> >,_STL::_Const_traits<char> > >,boost::use_default,boost::use_default> >() Line 518 C++ regex_test.exe!boost::operator!=<boost::transform_iterator<boost::algorithm: :detail::copy_iterator_rangeF<_STL::basic_string<char,_STL::char_traits<char >,_STL::allocator<char> >,_STL::_DBG_iter<_STL::_Nondebug_string<char,_STL::char_traits<char>,_STL:: allocator<char> >,_STL::_Const_traits<char> > >,boost::algorithm::find_iterator<_STL::_DBG_iter<_STL::_Nondebug_string<cha r,_STL::char_traits<char>,_STL::allocator<char> >,_STL::_Const_traits<char> > >,boost::use_default,boost::use_default>,_STL::basic_string<char,_STL::char_ traits<char>,_STL::allocator<char> >,boost::forward_traversal_tag,_STL::basic_string<char,_STL::char_traits<cha r>,_STL::allocator<char> >,int,boost::transform_iterator<boost::algorithm::detail::copy_iterator_rang eF<_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> >,_STL::_DBG_iter<_STL::_Nondebug_string<char,_STL::char_traits<char>,_STL:: allocator<char> >,_STL::_Const_traits<char> > >,boost::algorithm::find_iterator<_STL::_DBG_iter<_STL::_Nondebug_string<cha r,_STL::char_traits<char>,_STL::allocator<char> >,_STL::_Const_traits<char> > >,boost::use_default,boost::use_default>,_STL::basic_string<char,_STL::char_ traits<char>,_STL::allocator<char> >,boost::forward_traversal_tag,_STL::basic_string<char,_STL::char_traits<cha r>,_STL::allocator<char> >,int>(const boost::iterator_facade<boost::transform_iterator<boost::algorithm::detail::c opy_iterator_rangeF<_STL::basic_string<char,_STL::char_traits<char>,_STL::al locator<char> >,_STL::_DBG_iter<_STL::_Nondebug_string<char,_STL::char_traits<char>,_STL:: allocator<char> >,_STL::_Const_traits<char> > >,boost::algorithm::find_iterator<_STL::_DBG_iter<_STL::_Nondebug_string<cha r,_STL::char_traits<char>,_STL::allocator<char> >,_STL::_Const_traits<char> > >,boost::use_default,boost::use_default>,_STL::basic_string<char,_STL::char_ traits<char>,_STL::allocator<char> >,boost::forward_traversal_tag,_STL::basic_string<char,_STL::char_traits<cha r>,_STL::allocator<char> >,int> & lhs={...}, const boost::iterator_facade<boost::transform_iterator<boost::algorithm::detail::c opy_iterator_rangeF<_STL::basic_string<char,_STL::char_traits<char>,_STL::al locator<char> >,_STL::_DBG_iter<_STL::_Nondebug_string<char,_STL::char_traits<char>,_STL:: allocator<char> >,_STL::_Const_traits<char> > >,boost::algorithm::find_iterator<_STL::_DBG_iter<_STL::_Nondebug_string<cha r,_STL::char_traits<char>,_STL::allocator<char> >,_STL::_Const_traits<char> > >,boost::use_default,boost::use_default>,_STL::basic_string<char,_STL::char_ traits<char>,_STL::allocator<char> >,boost::forward_traversal_tag,_STL::basic_string<char,_STL::char_traits<cha r>,_STL::allocator<char> >,int> & rhs={...}) Line 820 + 0x32 C++ regex_test.exe!_STL::__vector<_STL::basic_string<char,_STL::char_traits<char >,_STL::allocator<char> >,_STL::allocator<_STL::basic_string<char,_STL::char_traits<char>,_STL::allo cator<char> > > >::_M_range_initialize<boost::transform_iterator<boost::algorithm::detail::c opy_iterator_rangeF<_STL::basic_string<char,_STL::char_traits<char>,_STL::al locator<char> >,_STL::_DBG_iter<_STL::_Nondebug_string<char,_STL::char_traits<char>,_STL:: allocator<char> >,_STL::_Const_traits<char> > >,boost::algorithm::find_iterator<_STL::_DBG_iter<_STL::_Nondebug_string<cha r,_STL::char_traits<char>,_STL::allocator<char> >,_STL::_Const_traits<char> > >,boost::use_default,boost::use_default> >() Line 535 + 0x17 C++ regex_test.exe!_STL::__vector<_STL::basic_string<char,_STL::char_traits<char >,_STL::allocator<char> >,_STL::allocator<_STL::basic_string<char,_STL::char_traits<char>,_STL::allo cator<char> > > >::_M_initialize_aux<boost::transform_iterator<boost::algorithm::detail::cop y_iterator_rangeF<_STL::basic_string<char,_STL::char_traits<char>,_STL::allo cator<char> >,_STL::_DBG_iter<_STL::_Nondebug_string<char,_STL::char_traits<char>,_STL:: allocator<char> >,_STL::_Const_traits<char> > >,boost::algorithm::find_iterator<_STL::_DBG_iter<_STL::_Nondebug_string<cha r,_STL::char_traits<char>,_STL::allocator<char> >,_STL::_Const_traits<char> > >,boost::use_default,boost::use_default> >() Line 231 C++ regex_test.exe!_STL::__vector<_STL::basic_string<char,_STL::char_traits<char >,_STL::allocator<char> >,_STL::allocator<_STL::basic_string<char,_STL::char_traits<char>,_STL::allo cator<char> > > >::__vector<_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator< char> >,_STL::allocator<_STL::basic_string<char,_STL::char_traits<char>,_STL::allo cator<char> > > ><boost::transform_iterator<boost::algorithm::detail::copy_iterator_rangeF<_ STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> >,_STL::_DBG_iter<_STL::_Nondebug_string<char,_STL::char_traits<char>,_STL:: allocator<char> >,_STL::_Const_traits<char> > >,boost::algorithm::find_iterator<_STL::_DBG_iter<_STL::_Nondebug_string<cha r,_STL::char_traits<char>,_STL::allocator<char> >,_STL::_Const_traits<char> > >,boost::use_default,boost::use_default> >() Line 248 C++ regex_test.exe!_STL::vector<_STL::basic_string<char,_STL::char_traits<char>, _STL::allocator<char> >,_STL::allocator<_STL::basic_string<char,_STL::char_traits<char>,_STL::allo cator<char> > > >::vector<_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<ch ar> >,_STL::allocator<_STL::basic_string<char,_STL::char_traits<char>,_STL::allo cator<char> > > ><boost::transform_iterator<boost::algorithm::detail::copy_iterator_rangeF<_ STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> >,_STL::_DBG_iter<_STL::_Nondebug_string<char,_STL::char_traits<char>,_STL:: allocator<char> >,_STL::_Const_traits<char> > >,boost::algorithm::find_iterator<_STL::_DBG_iter<_STL::_Nondebug_string<cha r,_STL::char_traits<char>,_STL::allocator<char> >,_STL::_Const_traits<char> > >,boost::use_default,boost::use_default> >() Line 164 + 0x93 C++ regex_test.exe!boost::algorithm::iter_find<_STL::vector<_STL::basic_string<c har,_STL::char_traits<char>,_STL::allocator<char> >,_STL::allocator<_STL::basic_string<char,_STL::char_traits<char>,_STL::allo cator<char> > > >,_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > const ,boost::algorithm::detail::find_regexF<boost::reg_expression<char,boost::reg ex_traits<char>,_STL::allocator<char> > > >(_STL::vector<_STL::basic_string<char,_STL::char_traits<char>,_STL::allocat or<char> >,_STL::allocator<_STL::basic_string<char,_STL::char_traits<char>,_STL::allo cator<char> > > > & Result={...}, const _STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > & Input={...}, boost::algorithm::detail::find_regexF<boost::reg_expression<char,boost::rege x_traits<char>,_STL::allocator<char> > > Finder={...}) Line 97 + 0x7e C++ regex_test.exe!boost::algorithm::find_all_regex<_STL::vector<_STL::basic_str ing<char,_STL::char_traits<char>,_STL::allocator<char> >,_STL::allocator<_STL::basic_string<char,_STL::char_traits<char>,_STL::allo cator<char> > > >,_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> >,char,boost::regex_traits<char>,_STL::allocator<char> >(_STL::vector<_STL::basic_string<char,_STL::char_traits<char>,_STL::allocat or<char> >,_STL::allocator<_STL::basic_string<char,_STL::char_traits<char>,_STL::allo cator<char> > > > & Result={...}, const _STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > & Input={...}, const boost::reg_expression<char,boost::regex_traits<char>,_STL::allocator<char> > & Rx={...}, boost::regex_constants::_match_flags Flags=match_default) Line 429 + 0x2b C++ regex_test.exe!find_test() Line 68 + 0x16 C++ regex_test.exe!test_main(int __formal=0x00000001, int __formal=0x00000001) Line 134 C++ regex_test.exe!`anonymous namespace'::call_test_main() Line 37 + 0x12 C++ regex_test.exe!boost::unit_test::function_test_case::do_run() Line 138 + 0x2b C++ regex_test.exe!boost::unit_test::ut_detail::unit_test_monitor::function() Line 77 + 0x14 C++ regex_test.exe!boost::execution_monitor::run_function() Line 188 + 0x54 C++ regex_test.exe!boost::detail::catch_signals(boost::execution_monitor & exmon={...}, bool __formal=true, bool __formal=true) Line 472 C++ regex_test.exe!boost::execution_monitor::execute(bool catch_system_errors=true, int timeout=0x00000000) Line 211 + 0x11 C++ regex_test.exe!boost::unit_test::ut_detail::unit_test_monitor::execute_and_t ranslate(boost::unit_test::test_case * target_test_case=0x009c9990, void (void)* f=0x0047d339, int timeout=0x00000000) Line 43 + 0x13 C++ regex_test.exe!boost::unit_test::test_case::run() Line 145 + 0x6c C++ regex_test.exe!main(int argc=0x00000001, char * * argv=0x009c6bb8) Line 83 C++ And the actual problem I think is caused by (iter_find.hpp#98): transform_iter_type itBegin= make_transform_iterator( find_iterator_type( begin(Input), InputEnd, Finder ), copy_range_type()); transform_iter_type itEnd= make_transform_iterator( find_iterator_type(), // end iterator is default constructed here!! copy_range_type()); SequenceSequenceT Tmp(itBegin, itEnd); // assertion here There may be other occurances of course, this is just the first assertion to be triggered... John.

5 23

RE: [boost] Re: Lock unification [move]
by Batov, Vladimir 30 Jul '04

30 Jul '04

Howard, Thank you for your time to get the spec. together. A must to move forward. A few comments. 1. explicit scoped_lock(mutex_type& m); 2. scoped_lock(mutex_type& m, locking_enum lock_it); 3. scoped_lock(mutex_type& m, blocking_enum block_it); 4. scoped_lock(mutex_type& m, const elapsed_time& elps_time); Do we need (3)? Isn't is covered by (4) with elps_time = INFINITE (blocking) and - 0 (non blocking)? If it is intended as a "convenience" interface, my expectation would be that average users would use thin and more explicit wrappers around the general lock. Like try_lock and timed_lock. Then, those thin wrappers would address the "convenience" issue better. (1) and (2) overlap as (1) is (2) with lock_it = true. Does not it mean that some functionality will have to be duplicated in (1) and (2)? How about avoiding the overlap with 1. explicit scoped_lock(mutex_type& m); 2. scoped_lock(mutex_type& m, deferred_t); Then, every constructor would do just one thing. My 2c. Best, V. > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Howard Hinnant > Sent: Sunday, 18 July 2004 2:32 PM > To: boost(a)lists.boost.org > Subject: [boost] Re: Lock unification [move] > > I have attempted a specification of moving > scoped_lock/read_lock/upgradable_read_lock/write_lock at: > > http://home.twcny.rr.com/hinnant/cpp_extensions/threads.html > > This is an attempt to look forward to locks+move semantics, taking into > account the recent discussions. Because of the length of the > specification I put it in an html on my personal website instead of > stuffing it into an email. Comments welcome. Any response from me is > likely to be delayed by several days due to travel. > > -Howard > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

8 36

Spirit: Some more regressions
by Joel de Guzman 30 Jul '04

30 Jul '04

Hi, The CVS (Boost) state for Spirit is very good. However, there are still some few regressions remaining. I do not understand some of the reports on compilers that I do not have access to. I wonder if some of you guys can help out. I'd appreciate that a lot. Help might mean as simple as peeking into the reports and forming an educated guess. TIA... <http://www.meta-comm.com/engineering/boost-regression/developer/spirit.html> 1) Comeau: http://tinyurl.com/5h5f6 2) VC8: http://tinyurl.com/3jmem The other errors are either boost.threads errors (still) or similar to the 2 above. I'll inquire about the threads errors in a separate post. Ah, yes, intel- win32- 7.1- vc6- stlport- 4.5.3 has runtime failures (e.g. http://tinyurl.com/4tfq6) Hartmut diagnosed these: <q> These two are easy. The reason for these errors comes from the fact, that the STLPort library is compiled independently from the test application and the command line options, which define, whether the wchar_t is an intrinsic type or not are different for the two compilation units. As a result the wrong std::numeric_limits specialisation gets picked during the compilation of the test program, which at runtime leads to the failed assertion. For a long time it wasn't possible to detect from inside a program (while compiled with the Intel on the Windows platfrom), whether it is compiled with wchar_t as an intrinsic time or not (for the Intel V8 this fact fixed recently), so I don't see a way to fix the problems right now </q> Any ideas, anyone? Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

1 0

Re: Re: Threads Rewrite?
by Tonko Juricic 29 Jul '04

29 Jul '04

Stefan Seefeld wrote: > That's often impossible: objects and threads are > orthogonal by nature: you don't always control what > thread executes your code. But as it is your code > that needs TLS you may have to inject TLS variables > in *any* thread that comes your way, and so it has > to be cleaned up in a uniform way. Let me try to understand it better. We start with the fact that some parts of your code can be executed by both boost and non-boost threads. A stumbling block in my case is understanding how can your code be executed by a non-boost thread unless, at some level, you explicitly make it possible. So, if I didn't completely miss the point, TLS cleanup for non-boost threads is there to spare the programmer from having to analyze complex scenarious and calling sequences which may lead to a non-boost thread visiting the 'unsuspecting' method on your object. Tony __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

4 3

Algorithm/minmax lib missing copyrights
by John Maddock 29 Jul '04

29 Jul '04

The following files are missing copyrights in the minmax lib: libs/algorithm/minmax/example/minmax_ex.cpp libs/algorithm/minmax/example/minmax_timer.cpp libs/algorithm/minmax/test/minmax_element_test.cpp libs/algorithm/minmax/test/minmax_test.cpp Can the Author please fix? Many thanks, John Maddock.

2 1

[assign][multi_array] possible problem with both libs together?
by JOAQUIN LOPEZ MU?Z 29 Jul '04

29 Jul '04

I thought I'd bring this mail from the users list to your attention: http://lists.boost.org/MailArchives/boost-users/msg07311.php Joaquín M López Muñoz Telefónica, Investigación y Desarrollo Original message To: boost-users@xxxxxxxxxxxxxxx Subject: [Boost-users] Assign and MultiArray conflict with precompiledheaders From: Bruno Martínez Aguerre <br1@xxxxxxxxxxxxxxx> Date: Wed, 28 Jul 2004 16:49:42 -0300 Reply-to: boost-users@xxxxxxxxxxxxxxx Sender: news <news@xxxxxxxxxxxxx> User-agent: Opera M2/7.51 (Win32, build 3798) -------------------------------------------------------------------------------- Hi. I'm trying out the recently accepted Assign library, and also the MultiArray library, which is new to me. I'm in VC7.1, and using the post review version of Assign. Depending on the order I include the libraries in my precompiled header, the linker complains about double definition of MultiArray's extents object. Here are the files that reproduce the problem. //stdafx.h #pragma once #include "boost/multi_array.hpp" #include "boost/assign.hpp" //main.cpp #include "stdafx.h" int main() { boost::multi_array<int, 2> t(boost::extents[3][4]); } I couldn't find relation between the two libraries. Thanks in advance, Bruno Martínez

1 0

Re:Re: Re:Javascript Tree Control [was: Serialization Menu
by Robert Ramey 29 Jul '04

29 Jul '04

Jonathan Turkanis >I agree with all of this. But I think that having a tree control component >is still useful: I didn't mean to suggest otherwise. My experience with this was a) fiddling around with Javascript and DOM (IE and Netscape) to get things to work. b) making my own tree by hand. Basically both of these were hacks and I'm happy to see a) done in a professional way. b) was really tedious and I saw the need to automate this process which seemed very much in the spirit of Boost Book (which I havn't spent any time with either) Basically we've got a) we need a)+b). I'm happy to leave the details to you guys as you know much more about it and it seems that there is broad agreement on the basic idea. Robert Ramey

2 1

Re: [boost] Re: Javascript Tree Control [was: Serialization Menu]
by Reece Dunn 29 Jul '04

29 Jul '04

Jeff Garland wrote: >On Wed, 28 Jul 2004 09:41:22 -0600, Jonathan Turkanis wrote > > "Jeff Garland" <jeff(a)crystalclearsoftware.com> wrote in message > > news:20040728115709.M55567@crystalclearsoftware.com... > > > On Tue, 27 Jul 2004 21:19:38 -0600, Jonathan Turkanis wrote > > > (I was able to do it with right mouse on the right pane, open in new > > > window/tab). However, is there a way to get the address bar to > > point to the > > > right frame instead of the left pane so that the current URL is > > immediately > > > accessible? My major objection to frames is that I can't see and > > grab the > > > current URL... > > > > I agree. See http://tinyurl.com/3sdu6. > >Thanks, for the pointer on sync. I didn't read all the rationale. I wish I >could come up with a more intuitive name -- it didn't hit me at first what >sync was for. Anyway, I was using Firefox 0.9.1 on Linux. I tested a >couple >more browsers: Galeon 1.3.12 and Epiphany 1.0.7 automatically sync -- very >cool! Konqueror 3.2.0 does not :( Would it be possible to do the sync automatically via the JavaScript control? It could be possible to do something like: <a href = "javascript:tree.load('id.1.2')">Chapter 1.2: Cool Stuff!</a> With load performing the URL redirection and synchronisation. I am not sure how portable this would be, but having it done automatically would mean that there would be less confusion and a simpler interface. >Oh, and I'm of course in support of boost-book initiatives to generate >these >capabilties -- after all, transformation to various forms is the whole >point >of getting the docs into xml... Exactly. Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

2 1

property map, boost::identity_property_map
by Val Samko 29 Jul '04

29 Jul '04

Hi, is there any reason, why boost::identity_property_map implementation in <boost\property_map.hpp> is completely different from how it is documented in http://www.boost.org/libs/property_map/identity_property_map.html ? As mentioned in the implementation, boost::identity_property_map is a property map that applies the identity function to integers. On the other hand, documentation clearly states that one can use identity_property_map with any types. Valentin Samko http://val.samko.info

2 1

BOOST_MPL_AUX_AGLORITHM_NAMESPACE_END in wrong place
by Jonathan Wakely 29 Jul '04

29 Jul '04

In boost/mpl/if.hpp the BOOST_MPL_AUX_AGLORITHM_NAMESPACE_BEGIN macro is inside a test for BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION, but the corresponding BOOST_MPL_AUX_AGLORITHM_NAMESPACE_END is after the #endif that matches the test. This doesn't cause an error, since those macros only expand to anything meaningful for GCC3, which enters the first branch of the #if, so the begin/end macros are balanced - but it ain't right. Bug was found due to an error with missing #endif, which made GCC3 take a different path through that file and error. Note also those macros are spelled "AGLORITHM" not ALGORITHM. Untested patch attached. jon -- "Faith strikes me as intellectual laziness." - Robert Heinlein

2 2

Python / extract.cpp: disable warning
by Stefan Slapeta 29 Jul '04

29 Jul '04

This warning in the extract test case should also be disabled for Intel 8: ..\libs\python\test\extract.cpp(59): warning #473: returning reference to local temporary return extract<std::string const&>(x); ^ BTW, is this a compiler defect? S.

5 10

libboost_regex, FreeBSD problems
by Steve Bobrowski 29 Jul '04

29 Jul '04

Hi, I did some development with libboost_regex-gcc.so (1.31.0) on a Linux platform: no problems. However, when I try to compile on FreeBSD, I get the following errors: g++ -o myprog Unit1.o Unit2.o /usr/local/lib/libboost_regex-gcc.so /usr/local/lib/libboost_regex-gcc.so: undefined reference to 'pthread_mutex_unlock' /usr/local/lib/libboost_regex-gcc.so: undefined reference to 'pthread_mutex_destroy' /usr/local/lib/libboost_regex-gcc.so: undefined reference to 'pthread_mutex_lock' /usr/local/lib/libboost_regex-gcc.so: undefined reference to 'pthread_mutex_init' I've installed Boost on the FreeBSD platform using both the ports package available from freebsd.org and the source from boost.org. Both yield the same results. Any ideas appreciated, as I am not that experienced with C++, Boost, and cross-platform deployment. Thanks, Steve

4 5

Normalizing file names in bcp
by Daniel James 29 Jul '04

29 Jul '04

Hi, When bcp is searching for files to copy, it doesn't normalize the path, so if a file is referenced from two different locations using relative paths it doesn't work. This happens when it is used on the preprocessor library. The following patch fixes this by normalizing the path in bcp_implementation::add_path. It also updates bcp's Jamfile.v2. Daniel Index: Jamfile.v2 =================================================================== RCS file: /cvsroot/boost/boost/tools/bcp/Jamfile.v2,v retrieving revision 1.1 diff -u -r1.1 Jamfile.v2 --- Jamfile.v2 29 Aug 2003 07:51:22 -0000 1.1 +++ Jamfile.v2 27 Jul 2004 18:55:59 -0000 @@ -4,9 +4,9 @@ : add_path.cpp bcp_imp.cpp copy_path.cpp file_types.cpp fileview.cpp main.cpp path_operations.cpp scan_cvs_path.cpp licence_info.cpp scan_licence.cpp output_licence_info.cpp - ../../libs/filesystem/build//boost_filesystem - ../../libs/regex/build//boost_regex - ../../libs/test/build//prg_exec_monitor + /boost/filesystem//boost_filesystem + /boost/regex//boost_regex + /boost/test//boost_prg_exec_monitor : <define>BOOST_REGEX_NO_LIB=1 : Index: add_path.cpp =================================================================== RCS file: /cvsroot/boost/boost/tools/bcp/add_path.cpp,v retrieving revision 1.6 diff -u -r1.6 add_path.cpp --- add_path.cpp 14 Jul 2004 10:59:37 -0000 1.6 +++ add_path.cpp 27 Jul 2004 18:56:00 -0000 @@ -21,10 +21,13 @@ void bcp_implementation::add_path(const fs::path& p) { - if(fs::exists(m_boost_path / p) && fs::is_directory(m_boost_path / p)) - add_directory(p); + fs::path normalized_path = p; + normalized_path.normalize(); + if(fs::exists(m_boost_path / normalized_path) + && fs::is_directory(m_boost_path / normalized_path)) + add_directory(normalized_path); else - add_file(p); + add_file(normalized_path); } void bcp_implementation::add_directory(const fs::path& p)

2 1

redefinition of BOOST_WINDOWS in filesystem/path_posix_windows.cpp error
by Toon Knapen 29 Jul '04

29 Jul '04

When compiling boost/libs/filesystem/src/path_posix_windows.cpp on windows, a compilation error occurs because BOOST_WINDOWS is redefined. path_posix_windows.cpp has its own definition of BOOST_WINDOWS but this symbol is also defined in win32.hpp which is included by config.hpp. IMMO the definition of BOOST_WINDOWS should be removed and boost/config.hpp should be included instead. toon PS, how it is possible that the regression tests on windows show success for all filesystem tests is a mistery to me. It does not compile on my machine anyway.

2 1

std::sort(zip_iterator...) does not compile
by Gunter Winkler 29 Jul '04

29 Jul '04

Hello, I tried to use boost::zip_iterator to sort 2 parallel arrays. Unfortunatly gcc does not compile the appended example because it can not convert boost::detail::iterator_category_with_traversal<std::input_iterator_tag, boost::random_access_traversal_tag> to either std::bidirectional_iterator_tag or std::random_access_iterator_tag. Thus it cannot dispatch the correct stl::__copy_backward() procedure. Is sort() not yet supported? mfg Gunter PS: please CC your replies to my eMail. 8<-----------part of error log--------------- /usr/include/c++/3.3/bits/stl_algobase.h: In static member function `static _BidirectionalIter2 std::__copy_backward_dispatch<_BidirectionalIter1, _BidirectionalIter2, _BoolType>::copy(_BidirectionalIter1, _BidirectionalIter1, _BidirectionalIter2) [with _BidirectionalIter1 = boost::zip_iterator<boost::tuples::tuple<__gnu_cxx::__normal_iterator<int*, std::vector<int, std::allocator<int> > >, __gnu_cxx::__normal_iterator<int*, std::vector<int, std::allocator<int> > >, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> >, _BidirectionalIter2 = boost::zip_iterator<boost::tuples::tuple<__gnu_cxx::__normal_iterator<int*, std::vector<int, std::allocator<int> > >, __gnu_cxx::__normal_iterator<int*, std::vector<int, std::allocator<int> > >, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> >, _BoolType = __false_type]': [...] /usr/include/c++/3.3/bits/stl_algobase.h:392: error: no matching function for call to `__copy_backward( boost::zip_iterator<...>&, boost::zip_iterator<...>&, boost::detail::iterator_category_with_traversal<std::input_iterator_tag, boost::random_access_traversal_tag>)' /usr/include/c++/3.3/bits/stl_algobase.h:360: error: candidates are: _BidirectionalIter2 std::__copy_backward(_BidirectionalIter1, _BidirectionalIter1, _BidirectionalIter2, std::bidirectional_iterator_tag) /usr/include/c++/3.3/bits/stl_algobase.h:371: error: _BidirectionalIter std::__copy_backward(_RandomAccessIter, _RandomAccessIter, _BidirectionalIter, std::random_access_iterator_tag) 8<-----------zip_iter.cpp------------ // sort 2 parallel arrays #include <boost/iterator.hpp> #include <boost/iterator/zip_iterator.hpp> #include <boost/tuple/tuple.hpp> #include <boost/tuple/tuple_comparison.hpp> #include <vector> #include <iostream> int main(int argc, char *argv[]) { typedef std::vector<int> VEC; typedef boost::zip_iterator< boost::tuple<VEC::iterator, VEC::iterator> > zip_iter; VEC v1(10); VEC v2(10); zip_iter iter( boost::make_tuple(v1.begin(), v2.begin()) ); zip_iter iter_end( boost::make_tuple(v1.end(), v2.end()) ); std::sort(iter, iter_end); return EXIT_SUCCESS; }

3 14

Illegal specialisation in boost/mpl/math/is_even.hpp
by Jonathan Wakely 29 Jul '04

29 Jul '04

boost/mpl/math/is_even.hpp contains a specialisation of a template in a different namespace to the original declaration. This causes an error with GCC 3.4 (and should fail with Comeau in strict mode). I believe the attached patch should fix it, but haven't yet been able to run the tests again to find out. jon -- "We are the Music Makers, and we are the Dreamers of Dreams." - Arthur William Edgar O'Shaughnessy

2 1

Proposal for String Algorithms Library
by zaufi＠sendmail.ru 29 Jul '04

29 Jul '04

hi boosters I would like to propose one more algorithm to SAL -- squeeze. It removes leading/trailing spaces and duplicate spaces between words. So sample string " This is \n\n a test \n" become "This is\na test". I use this function with XML/HTML related code to 'normalize' content... Hope this will help to smbd else ;) Have fun!

2 1

[Important For All Boost Contributors] BSL Status Update
by Stephan T. Lavavej 29 Jul '04

29 Jul '04

I figured out how to use bcp. See the results at: http://stl.nuwen.net/bsl.html I ran it on all of the directory names in libs, in current Boost CVS, except for CVS, python, and serialization - the last two gave errors. Low-hanging fruit is thus revealed: * I know I've seen the following people post to the Boost list recently. They should be contacted about adding themselves to blanket-permission.txt. Andrei Alexandrescu Gennadiy Rozental Joaquín Mª López Muñoz Vladimir Prus Robert Ramey - http www rrsd com Howard Hinnant Thorsten Ottosen Joel de Guzman (I just compared "Authors we need to move to the BSL" to the last couple of pages of Boost list archives, visually.) * Some people have files under the BSL, but not all of them. Example (I'm picking on him because I've talked to him): Jeff Garland. He's listed as having files under the BSL, and he's not in "Authors we need for the BSL", so he doesn't have any non-BSL files. However, many date_file files are listed in "Files With No Recognisable License". * The following people ARE in blanket-permission.txt, but have used these alternate names in Boost code. Their names should be changed to their canonical forms. (And then the appropriate files should be BSLed.) Dave Abrahams Doug Gregor Dr John Maddock David Moore Jeremy G Siek John R Bandela * "Files that could be converted to the Boost Software License" should be. There are a lot of files there. * Some non-BSL files display copyrights by: Boost org boost org It should be figured out who actually wrote these. I don't think "boost org" is a real organization. * From what I've heard on the list, "William E Kempf" hasn't been seen in quite some time. He should be contacted. * The following organizations (or people with really, really weird names) hold copyrights to non-BSL libraries. They should be contacted. Cadenza New Zealand Ltd CrystalClear Software Inc Free Software Foundation Inc Grenoble Hewlett-Packard Company Housemarque Oy Indiana University Silicon Graphics Computer Systems Inc The Trustees of Indiana University Universite Joseph Fourier University of Notre Dame iMAGIS-GRAVIR UJF uBLAS developers * Why are new libraries, such as Boost Algorithm, being accepted without the BSL? At the very least, Boost could try to not move backwards. * Some files - boost/iterator_adaptors.hpp, a huge (all?) chunk of boost/mpl, and lots of stuff in libs/config/test - have no recognizable copyright holder. That should be fixed. * Maybe bcp could add "Percent Converted" to the report? It'd be nice to see how many files have been converted to the BSL out of how many files there are, total. Stephan T. Lavavej (Microsoft Software Design Engineer who really, really wants to use Boost at work)

11 19

Regressions: timeout for compile and run
by Stefan Slapeta 28 Jul '04

28 Jul '04

CW 9 and Intel 8 regressions did not run (better: finish) for some days because I've been away and had no chance to confirm the popups of assertion failures which were produced by some test cases!@!@! Is there no possibility to set a timeout after the compile/run process is killed by bjam? I don't see any sense behind giving a test case more than 5 minutes to run! Stefan

4 15

[range] doc nit
by Jonathan Turkanis 28 Jul '04

28 Jul '04

Thorsten, In a couple of places the docs for Boost.Range talk about 'nested typedefs': 1) In the first paragraph of boots_range.html: "The subset deals mostly with iterator returning functions and nested typedefs." 2) In the first paragraph of external_concepts.html: "The concept can be specified as a set of member functions with well-defined semantics and a set of nested typedefs with well-defined properties." In both cases, I think it would be more appropriate to talk about 'nested types.' The subject of the first sentence is standard library containers, whose iterators can be nested classes. The second sentence is about generic programming in general so the same considerations should apply. The article 'Generic Programming Techniques' says that associated types are 'typically' member typedefs or associated externally throught traits, which I think is slightly more accurate. Jonathan

2 1

Off topic:making replies threaded
by Tonko Juricic 28 Jul '04

28 Jul '04

I use http://news.gmane.org/gmane.comp.lib.boost.devel to read group archives and I send my replies from Yahoo mail. After trying several variations on mail Subject prefixes I still can not make my replies appear as the part of the thread, when viewed from Gmane. I am sure some will find those 'detached' replies as annoying as I do so any suggestion on how to fix it would be much appreciated. Tony __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail

3 2

filesystem thoughts/issues
by Jeff Flinn 28 Jul '04

28 Jul '04

I'm now getting into using the filesystem library. Of course the first thing I've run into is the need to generate lexically relative paths. Having the luxury of being able to discount links, I have a working solution, atleast for windows. Some issues that arose are related to a path as a sequence container. While not show stoppers, the lack of some sequence container member functions - such as size(), assign(itr,itr) - required that existing templated classes be refactored to allow use of path as a template argument. Additionally lacking is a const_iterator type. size() is used to determine the 'shorter' of two paths whose path::iterator are passed to std::mismatch as the controlling (beg,end] arguments. The pair of iterators returned by std::mismatch are used to populate the common, first_remainder and second_remainder paths. If there is interest in this code I can post it. Any thoughts on providing additional sequence container member functions and typedefs in a post 1.32 release? Also any plans on incorporating Richard Johnson's globiter facilities? It would be nice to have a filtered_directory_iterator in any case. Something like: filtered_directory_iterator ( const fs::path& , boost::function1<bool,const std::string&> ) as a convenience class based on the boost::filter_iterator. Then I could: std::for_each ( filtered_directory_iterator( aPath, bind( extension, _1 ) == ".hpp" ) , filtered_directory_iterator() , SomeFnc ); Then perhaps 'globbing' would be better supported as an additional regex syntax_option_type? This would keep filesystem from depending on regex. Jeff F

1 0

Range/compat2 is not correct
by Stefan Slapeta 28 Jul '04

28 Jul '04

compat2.cpp is failing on VC 7.1 and the compiler seems to be right: there is a 'typename' missing! Stefan ..\libs\range\test\compat2.cpp(45) : warning C4346: 'range_iterator<Container>::pts<C>::type' : dependent name is not a type prefix with 'typename' to indicate a type

2 2

difference_type for int in numeric_traits
by DY, JERRY U (SBCSI) 28 Jul '04

28 Jul '04

In boost/detail/numeric_traits.hpp, integer_traits can be used to find the difference_type for an int type, in aC++, I get a long long -- I don't think that's the correct result, but can somebody please tell me why not? Thanks! integer_traits<int>::difference_type // long long?? I expect this to be an int Here's why: template <class Integer, bool = true> struct integer_traits { ... typedef typename if_true<(int(x::is_signed) // true && (!int(x::is_bounded) // true || (int(x::digits) + 1 >= digit_traits<boost::intmax_t>::digits))) // false >::template then< Integer, typename if_true<(int(x::digits) + 1 < digit_traits<signed int>::digits)>::template then< // false signed int, typename if_true<(int(x::digits) + 1 < digit_traits<signed long>::digits)>::template then< // false signed long, // else intmax_t // this is long long >::type>::type>::type difference_type; ... } -Jerry

1 0

Missing '\' in boost/serialization/export.hpp ?
by Jonathan Wakely 28 Jul '04

28 Jul '04

Should there be a backslash at the end of line 235 in boost/serialization/export.hpp ? jon

1 0

Intel: uBLAS and range go DR, random still unresolved
by Stefan Slapeta 28 Jul '04

28 Jul '04

I've submitted a Intel 8 DR for two obvious compiler defects: test2 in uBLAS and the iterator_range in iterator (ICE). Is there nobody feeling competent/responsible to give any hint for the random failure? I don't know if I can find it on my own. Stefan

1 2

VC 7.1 warning in linear_congruential.hpp
by Stefan Slapeta 28 Jul '04

28 Jul '04

in rand48::operator () [...]\linear_congruential.hpp(218) : warning C4244: 'return' : conversion from 'boost::uint64_t' to 'boost::int32_t', possible loss of data Patch attached. Stefan RCS file: /cvsroot/boost/boost/boost/random/linear_congruential.hpp,v retrieving revision 1.18 diff -u -r1.18 linear_congruential.hpp --- linear_congruential.hpp 27 Jul 2004 03:43:32 -0000 1.18 +++ linear_congruential.hpp 28 Jul 2004 15:09:10 -0000 @@ -215,7 +215,7 @@ void seed(uint64_t x0) { lcf.seed(x0); } template<class It> void seed(It& first, It last) { lcf.seed(first,last); } - int32_t operator()() { return lcf() >> 17; } + int32_t operator()() { return static_cast<int32_t>(lcf() >> 17); } // by experiment from lrand48() static bool validation(int32_t x) { return x == 1993516219; }

1 0

RE: [boost] Boost Test Library: Bug in floating-point comparison?
by Rozental, Gennadiy 28 Jul '04

28 Jul '04

> Hi, > > I want to use the boost::test floating-point comparison > algorithms (Boost > 1.31.0) and wrote the following simple lines of code: > > double d1 = 0.2; > double d2 = 0.8; > double d3 = d2-d1-d1-d1-d1; // d3 should be zero > > bool b = boost::test_toolbox::check_is_closed( d3, 0., 1e-3 ); > > To my surprise, the return value b is FALSE, although d3 > should be _very_ > close to zero (and is 5.55112e-17 on my machine). > > Am I missing something or is this a bug in the test library? > > Thanks, > Michael > > -- > Michael Kettner > kettner(a)ive.uni-hannover.de Read algorithm description. The algorithm compare "relative errors". In your case it's 1 and infinity. Definitely more then 1e-03. It you want to compare absolute values (which is not recommended in real life applications) you either could write you own predicate or wait a bit, while I am considering adding BOOST_IS_SMALL tool that will be responsible namely for this kind of test. Gennadiy.

2 1

RE: [boost] Re: RE: Re: DLL library (Was: Re: additional boostlibraries?)
by Reece Dunn 28 Jul '04

28 Jul '04

Vladimir Prus wrote: >Bronek Kozicki wrote:mechanism Garland wrote: > >> This isn't really a re-invention of either -- just a very small library >that > >> does someskeletonsilar to what both do -- without all the baggage. COM > >> is a > >> Windows only option, for example. Both are big frameworks with gobs of > >> stuff not needed to load a dll and call a function. > > > > I think that similar motivation drove YAMI project, see > > http://www.msobczak.com/prog/yami/ > >Do you mean "without all the baggage" by "similar motivation"? What I see >on >the page is still very complex -- some network communication and the like. > >I want just portable mechanism to access objects from shared libraries. >This >is much more lightweight than CORBA, which requires IDL, stubs, skeletons, >supports talking to objects on other machines, a lots of other stuff. Frameworks like COM and CORBA are designed to be language independent: this is why they use IDL for describing interfaces. Since what you require is C++-specific, you can skip the IDL language and use abstract base classes and/or virtual functions, which is what Volodya is doing. The frameworks also provide some means of generic exception handling. COM skips this by returning an error code (HRESULT) value because of the issues of dealing with exceptions across language borders (e.g. C++ to C). The C++ exception mechanism is fine for what Volodya wants because there will be no cross-language problems. The frameworks may provide some means of automation. COM uses a discriminant union type (VARIANT) and a dispatch interface to achieve this, as well as providing direct access via the interfaces. I don't think scripting is an important issue in this case, but it should be possible to implement using Boost.Spirit :). The frameworks provide a mechanism for managing object lifetimes. COM does this by the base interface supporting AddRef/Release with the DLL responsible for construction (via exposed object types) and the object responsible for deconstruction (deleting itself once the reference count is 0). As I see it, this is intended to be implemented using shared_ptr's, the issue being *how* to load the objects and DLL's. In COM the object is responsible for keeping the DLL alive (via a reference count on the DLL as has been mentioned in other posts). If there are two objects from the DLL alive, then the DLL's reference count is two (unless it is explicitly locked to keep it alive). The MS documentation on DllMain says: During initial process startup or after a call to LoadLibrary, the system scans the list of loaded DLLs for the process. For each DLL that has not already been called with the DLL_PROCESS_ATTACH value, the system calls the DLL's entry-point function. Thus, if the DLL is already loaded by a process, it will not reload it on successive calls to LoadLibrary. The documentation on FreeLibrary says: The FreeLibrary function decrements the reference count of the loaded dynamic-link library (DLL). When the reference count reaches zero, the module is unmapped from the address space of the calling process and the handle is no longer valid. Thus, there is no easy way to reload a DLL. The best solution would be to release the instance of the plugin you have loaded and let the system unload the DLL. It is best to only be concerned about the DLL when loading the plugin. If you want to alter plugins at run-time (e.g. removing or adding a plugin), just remove all references to the plugin to delete it or load the plugin into the plugin map from the DLL. The frameworks provide other facilities, but I think these are the main (core) facilities. I am not sure how this will map to Linux or MacOS systems. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

2 1

Building Libraries in Boost
by Jody Hagins 28 Jul '04

28 Jul '04

Most of boost is implemented in header files (as most is based on templates). However, what are the guidelines for splitting code into compilable units? For example, if a library is not a template library, should the author strive to implement it entirely in headers as inline functions, or should it be implemented as part inline functions and part a compiled library? A fair amount of code uses the PIMPL pattern to reduce header complexity, reduce interface and implementation exposure, and to reduce compile times. However, this requires, in large part, separate compiled libraries. What is the Boost position in this regard? Thanks!

2 1

sporadic bjam crashes on WinXP box
by Gennadiy Rozental 28 Jul '04

28 Jul '04

When I run Boost.Test unit test for 10 compilers in crashes sometimes (but quite regularly). How could I track the issue? Looks like it depend on amount target it actually need to update with current run. Gennadiy.

4 5

Re: [boost] RE: Re: DLL library (Was: Re: additional boost libraries?)
by Robert Ramey 28 Jul '04

28 Jul '04

Vladimir Prus wrote: >I know next to nothing about COM, so can't on this idea. In all cases, I >think it's a bit beyond the scope. I have some experience writing applications that use COM. Reading through this discussion makes me wonder if this isn't a re-invention of the COM wheel. I don't know anything about CORBA. I has always presumed it was similar to COM. COM starts out as simple in principle and ends up being very complex. It seems that Microsoft has now rolled up that functionality into Dot Net and no longer promotes COM. I would think a careful study of COM/CORBA would be key to pursuing this line of inquiry. Robert Ramey

4 3

Re: Threads Rewrite?
by Tonko Juricic 28 Jul '04

28 Jul '04

Michael Glassford wrote: > The next release will clean up TLS right after the > thread function exits, but that doesn't work for > threads that aren't created by Boost.Threads. If > that's good enough for you, good! However, if you > need TLS cleanup for threads not created by > Boost.Threads, the DLL_THREAD_DETACH or some other > approach is still necessary. I see your point! I guess this is more of a taste/philosophy issue. Leaning toward "less code is better" philosophy I would tend to take a position : you are not using boost threads? Then it's yours, rather than boost code responsibility, to clean up TLS. I don't see anything particularly productive coming out of discussing such issues here so let's put it in IMHO folder. Regards, Tony __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

2 1

BOOST_BIG_ENDIAN
by Jody Hagins 28 Jul '04

28 Jul '04

This macro (and its friend BOOST_LITTLE_ENDIAN) definition appears in boost/detail/limits.hpp. However, that file is included only if boost/limits.hpp does not detect the standard <limits>. Thus, it does not get defined for more standard compilers. The serialization library makes use of this macro (in a test), so I wonder how it works on standard compilers. I could use the ENDIAN macros in some of my code to provide compile time performance options (linux provides something similar). Is it possible to move the ENDIAN macros into some other header so that they are more easily obtained, and also do not force including a limits workaround? I also imagine if they were actually included in more compilations, that they could get checked for correctness and the maintenance of newer platforms would increase. Thanks!

6 8

RE: [boost] Building Libraries in Boost
by Reece Dunn 27 Jul '04

27 Jul '04

Jody Hagins wrote: >Most of boost is implemented in header files (as most is based on >templates). However, what are the guidelines for splitting code into >compilable units? As far as I know, anything sensible. >For example, if a library is not a template library, should the author >strive to implement it entirely in headers as inline functions, or >should it be implemented as part inline functions and part a compiled >library? If the code is non-template and is non-trivial, it should really be a part of a compiled library. For trivial functions (e.g. returning data information), these should be inlined. Boost uses the Boost.Build system to compile the libraries (see the installation docs for information on how to setup and configure either V1 or V2). You will need to create a Jamfile that describes the library so that it can be built (this will normally be in libs/<library>/build), with the source in libs/<library>/src. I suggest that you take a look at the existing libraries that have built components: Boost.DateTime; Boost.RegEx; Boost.Signals; Boost.Graph; Boost.Thread; Boost.FileSystem and Boost.ProgramOptions. If you get stuck with Boost.Build you can contact the Boost.Build mailinglist. >A fair amount of code uses the PIMPL pattern to reduce header >complexity, reduce interface and implementation exposure, and to reduce >compile times. However, this requires, in large part, separate compiled >libraries. Whether or not to use PIMPL should be a design decision based on the library requirements. There are also non-class functions that may be a part of a library that exist in a compiled unit (see Boost.FileSystem). Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

1 0

Why I couldn't compare optional<int> and optional<long>
by Rozental, Gennadiy 27 Jul '04

27 Jul '04

IMO relational operators in optional implementation should have two template parameters Gennadiy.

1 0

RE: [boost] Re: counting_iterator_test.hpp fails on aC++
by DY, JERRY U (SBCSI) 27 Jul '04

27 Jul '04

Dave, As you suggested, an auxiliary function template is defined (outside of the iterator_adaptor class - aC++ doesn't like it if it's a member function): // workaround for aC++ CR JAGaf33512 template <typename TR1, typename TR2> inline void iterator_adaptor_assert_traversal () { typedef int assertion[sizeof(detail::static_assert_convertible_to<TR2>(TR1()))]; } Then the old static assertion is replaced like so: # define BOOST_ITERATOR_ADAPTOR_ASSERT_TRAVERSAL(cat) \ iterator_adaptor_assert_traversal<my_traversal, random_access_traversal_tag>(); // typedef iterator_adaptor_assert_traversal<my_traversal, cat> assert_traversal_t; I tested this by adapting an ordinary pointer to a forward traversal iterator and if the program calls the operator+= (calling the adaptor's advance member function and triggering the static assertion), the compile fails, the compile succeeds otherwise. There should be no additional overhead incurred due to the workaround because the function itself is inlined and all it does is a typedef. Is this workaround acceptable for check-in? Thanks! -Jerry -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams Sent: Saturday, July 24, 2004 8:20 AM To: boost(a)lists.boost.org Subject: [boost] Re: counting_iterator_test.hpp fails on aC++ Probably the right way to fix this is to indirect through an auxilliary function template that does the assertion. I presume _that_ wouldn't be instantiated unless it was actually called.

1 0

Re: [config] seems like VC 8.0 needs BOOST_NO_MEMBER_TEMPLATE_FRIENDS
by Michael Stevens 27 Jul '04

27 Jul '04

On Tuesday 27 July 2004 00:42, JOAQUIN LOPEZ MU?Z <joaquin(a)tid.es> wrote: > error C2888: 'void boost::multi_index::safe_mode::detach_equivalent_iterators(Iterator &)' : symbol cannot be defined within namespace 'detail' The error seems to indicate a namespace problem rather then something specific to member template friends? > > I've searched through the VC 2005 beta docs and, > allegedly, member template friends are supported, so this > particular problem could be a bug rather than complete > lack of support for this feature. Maybe someone with > local access to VC 8.0 can test the above code and > see what happens (I currently don't have the time > and resources to try myself.) Maybe the problem is related to namespace handling in VC 8.0 Boost.numeric.interval library fails when included in uBLAS due to a curious namespace problem. http://www.meta-comm.com/engineering/boost-regression/developer/output/Rudb… The same problem effect VC 7.1 as well. Why the compilers think the 'lower' 'upper' symbols are ambiguous I have no idea! -- Michael ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

6 9

Boost Test Library: Bug in floating-point comparison?
by Michael Kettner 27 Jul '04

27 Jul '04

Hi, I want to use the boost::test floating-point comparison algorithms (Boost 1.31.0) and wrote the following simple lines of code: double d1 = 0.2; double d2 = 0.8; double d3 = d2-d1-d1-d1-d1; // d3 should be zero bool b = boost::test_toolbox::check_is_closed( d3, 0., 1e-3 ); To my surprise, the return value b is FALSE, although d3 should be _very_ close to zero (and is 5.55112e-17 on my machine). Am I missing something or is this a bug in the test library? Thanks, Michael -- Michael Kettner kettner(a)ive.uni-hannover.de

1 0

RE: [boost] Re: Lock unification [move]
by Batov, Vladimir 27 Jul '04

27 Jul '04

How 'bout scoped_lock lk1(m, defer); scoped_lock lk2(m, try); > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of David Abrahams > Sent: Friday, 23 July 2004 1:15 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: Lock unification [move] > > Howard Hinnant <hinnant(a)twcny.rr.com> writes: > > > scoped_lock lk1(m, deferred); > > scoped_lock lk2(m, tried); > > > > <shrug> I disliked "tried" more than I liked "deferred". And I also > > felt that the benefit of symmetry was important to make the interface > > easier to learn. > > You only need part-of-speech symmetry. "deferred" is an adjective, so > "non_blocking", "optional", "permeable",... would work find for the > other one, from a grammatical point of view. I don't think "try" > makes a very good adjective, and adding "_lock" to the end of it > doesn't help. So I don't see the symmetry in > "try_lock"/"deferred_lock" other than the suffix :vP > > -- > Dave Abrahams > Boost Consulting > http://www.boost-consulting.com > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

10 18

Re: Boost Digest, Vol 801, Issue 2
by Michael Stevens 27 Jul '04

27 Jul '04

On Tuesday 27 July 2004 12:18, "Victor A. Wagner Jr." <vawjr(a)rudbek.com> > >Maybe the problem is related to namespace handling in VC 8.0 > > > >Boost.numeric.interval library fails when included in uBLAS due to a curious > >namespace problem. > >http://www.meta-comm.com/engineering/boost-regression/developer/output/Rudb… > > > >The same problem effect VC 7.1 as well. Why the compilers think the 'lower' > >'upper' symbols are ambiguous I have no idea! > > because there are two different ones to choose from > Did I miss the :-) here? If only things were so simple. The error occurs in interval/io.hpp. Here a templated operator definition is being defined in the boost::numeric namespace. The definitions of lower/upper we are looking for are in this same boost::numeric namespace. The definitions which VC is getting confused with in the boost::numeric::ublas namespace can only be found by argument dependant (Konig) lookup. We could look this up in the ISO standard. Circumstantial evidence from several other compilers suggests VC 7.1 / 8.0beta is doing the wrong thing here. Which is why I suspect these compilers do not implement namespace perfectly. Michael

1 0

Unit test could usefully output more significant digits to log files?
by Paul A Bristow 27 Jul '04

27 Jul '04

In setting up a test for math function accuracy, I incorrectly coded thus: BOOST_CHECK_EQUAL(sin(0.5), 0.479426); and got the somewhat puzzling - apparently wrong - message error in "call_test_main": test sin(0.5) == 0.479426 failed [0.479426 != 0.479426] On most days of the week, one would expect [0.479426 == 0.479426]! I should of course have written BOOST_CHECK_EQUAL(sin(0.5), 0.47942553860420301); (or used BOOST_CHECK_CLOSE(sin(0.5), 0.47942553860420301, 1e-16);) But I wonder if the test program would be even more helpful if it output all possibly significant digits. In test_tools.hpp, I have added an increase to the ostream precision (default only 6 digits) int print_log_value thus template<typename T> struct print_log_value { void operator()( std::ostream& ostr, T const& t ) { if(std::numeric_limits<T>::is_specialized && std::numeric_limits<T>::radix == 2) { // Show all possibly significant digits (for example, 17 for 64-bit double). ostr.precision(2 + std::numeric_limits<T>::digits * 301/1000); } ostr << t; // by default print the value. } }; so that the message is no longer test sin(0.5) == 0.479426 failed [0.47942553860420301 != 0.47942600000000002] and my folly obvious. And after the original mistake is corrected BOOST_CHECK_EQUAL(sin(0.5), 0.47942553860420301); The log file reports: info: sin(0.5) == 0.47942553860420301 passed. Paul PS (It does not appear to possible to change the precision 'externally' by calling cout.precision(17); myTestLog.precision(17); probably because ostr in test is contructed with default precision). Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow(a)hetp.u-net.com

3 4

FW: pool cleanup
by Aviad Rozenhek 27 Jul '04

27 Jul '04

I am using the object_pool interface, Calling on the object_pool::free () function. On more scrutiny it came down to this: I am not freeing the objects in reverse order of their creation. When I explicitly change the design to make it so, The pool works fine. It also works fine when I wait for the ~object_pool () To clean it up. So these problems remain: 1. when deallocating objects only once in the running of the program (on ~object_pool) and avoiding the cleanup problem stating earlier the pool classes still actually cause a minor downgrade of peformance rather than boosting it. This is the case both in ms-windows port (using Doug Lee's malloc to circumvent microsoft terrible malloc) And on linux port. 2. when not deallocating objects in the reverse order The penalty is overwhelming. For isntance when I turn off all pooling In my application the cleanup make take 3 seconds. Turning on pooling causes cleanup to take an excess of 10 mins ( I give up after that) Possible causes: 1. its not thrashing, because I tested it on a large memory machine. 2. perhaps it's the simple_segragated_storage::find_prev function Because its run time is linear with the size of the chunk. ------------------------------ Message: 5 Date: Thu, 22 Jul 2004 23:48:53 -0700 From: Mark Deric <laguna(a)laguna1.com> Subject: Re: [boost] performance: pool cleanup takes too long To: boost(a)lists.boost.org Message-ID: <20040722234853.09879c08.laguna(a)laguna1.com> Content-Type: text/plain; charset=US-ASCII On Wed, 21 Jul 2004 17:59:40 +0200 "AviadR" <aviadr(a)pob.huji.ac.il> wrote: > the cleanup part (which consists only of calling the pool release > methods on allocated objects) > on the other hand, takes many minutes (I usually give up after 5 > minutes) Are you freeing each on the allocated chunks using pool.free(), or pool.release()? They would need simple_segregated_storage.nextof() Or are you calling ~pool()? The call to ~pool() doesn't use nextof() and should be pretty quick.

1 0

[License] Request for volunteers: converting to the Boost Software License
by Doug Gregor 27 Jul '04

27 Jul '04

The bcp tool is now capable of automatically converting files over to the Boost Software License. However, we need volunteers to verify that the transformation is correct. I have (locally) converted 1256 files that need to be verified, and am asking for volunteers to verify chunks of 100 files each (it won't take all that long...). If you would like to help, please send me e-mail _privately_ and I'll assign a chunk to you. Please tell me which file numbers in the chunk are fine (so I can commit them) and which file numbers are incorrect. To verify a particular file, go to: http://www.boost.org/all-report.html#bsl-converted (It's an 8MB file; you've been warned). Then locate your file numbers (e.g., 1-100) and look at the "before" (left) and "after" (right) chunks of the file. The changed parts are highlighted in bold. Two things need to be verified for a file to be correct (everything else is automatic and correct already): 1) The entirety of the original license must have been removed. 2) Copyrights, author names, etc. have not been destroyed by the transformation. For instance, look at file #1 (boost/assert.hpp): the old license (on the left) has been completely highlighted and replaced by the Boost Software License (on the right), so this transformation is fine. On the other hand, look at file #66 (boost/lambda/detail/bind_functions.hpp): the old license has a clause "This software is provided 'as is'..." that has not been highlighted on the left, and was retained by the transformation. That's a problem: this transformation is not correct. When sending back replies once you've finished a chunk, try to use this form if you could: Correct: 1-10 15-55 Incorrect: 11-14 56-70 We'll need to iterate the process a bit (as we fix up the heuristics to get everything right), but with a little work from everyone I'm sure we can get much of Boost converted over to the BSL in a relatively short time. Doug

2 3

Problems compiling program_options on vacpp
by Matthias Troyer 27 Jul '04

27 Jul '04

Dear Boosters, I have encountered the following problem compiling program_options on the IBM Visual Age compiler 6.0. There seems to be a problem with exception declarations: xlC -DHAVE_CONFIG_H -I../../src -I../../src -DNDEBUG -I/users/matroyer/boost -DNDEBUG -q32 -qlanglvl=extended -O2 -c -M /users/matroyer/boost/libs/program_options/src/convert.cpp -o convert.o "/users/matroyer/boost/boost/program_options/detail/ utf8_codecvt_facet.hpp", line 144.17: 1540-1163 (S) The exception-specification for "int boost::program_options::detail::utf8_codecvt_facet_wchar_t:: do_length(mbstate_t &, const char *, const char *, std::size_t) const" is less restrictive than the exception-specification for "int std::codecvt<wchar_t,char,char *>::do_length(_St &, const _To *, const _To *, size_t) const throw()". Can the throw() declaration be added to do_length()? Matthias

2 3

ANN: Synopsis 0.7 - a source code inspection tool
by Stefan Seefeld 26 Jul '04

26 Jul '04

Synopsis 0.7 released ===================== I'm happy to announce the release of Synopsis 0.7. This is a major feature enhancement and bug fix release. Among the more important new features: * refactored Cpp processor (now a stand-alone processor) * new C processor * feature enhancements and bug fixes in the C++ processor * cleanup and bug fixes in the HTML formatter (now generates valid XHTML) * new SXR cross referencer (see http://synopsis.fresco.org/sxr/files/ for an example) * new C++ API for easier C++ backend programming * Synopsis has been ported to (native) windows An ongoing efford is to produce correct (and useful) documentation for the boost libraries (http://boost.org) You may have a look at the current status of this efford at http://synopsis.fresco.org/boost, containing a reference manual for boost::python (this site is quite large !). For information, see http://synopsis.fresco.org For (developer) documentation, see http://synopsis.fresco.org/docs.html To contact the developers, see http://synopsis.fresco.org/mailinglists.html To report bugs, see http://synopsis.fresco.org/issues/bug About Synopsis ============== Synopsis is a source code inspection framework supporting a variety of languages (right now C++, C, IDL, and Python). Its main focus is source code documentation, but effords are being made to support other forms of introspection such as code generation. Synopsis provides a framework of processors that can (via a simple and straight-forward scripting interface) be used to construct sophisticated pipelines to process abstract syntax trees (ASTs). Regards, Stefan

3 3

[multi_index] mbergal tests
by JOAQUIN LOPEZ MU?Z 26 Jul '04

26 Jul '04

mbergal tests (see http://www.meta-comm.com/engineering/boost-regression/developer/multi_index…) fail for multi_index, but the error messages are not any helpful: a couple of warnings followed by Failure while executing 'cl' compiler ...email Comeau for advice. Any clue about what to about this? Thank you. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

RE: [boost] Mini-reviews
by Reece Dunn 26 Jul '04

26 Jul '04

Tom Brinkman wrote: >Mini-reviews would be very useful. Im shur that each >boost developer/user could contribute a few small, >useful algorithms. It would be a great way to >increase the level of participation by developers who >want to contribute but dont have the time to write a >complete library. I agree. What about small/simple classes, e.g. an object_counter class that keept track of the number of instances of all objects derived from it? This would also make it easier to extend existing libraries like mpl and filesystem (directory iterator). Is there a streamlined system for restructuring a library or changing its interface, e.g. Boost.Random and Boost.Iterator? >We should also discuss to where to place the >algorithms /code within the boost namespace. This would depend upon the type of functions. I can think of the reciprocal trigonometric functions: sec x = 1 / cos x csc x = 1 / sin x cot x = 1 / tan x = cos x / sin x These would best reside in boost::math. Others would fit in different places. I suggest that any mathematics-related algorithms be placed in boost::math, string manipulation algorithms boost::algorithm::string and the others in boost::algorithm. General classes would go in the boost namespace. If the algorithm/class is an extension of an existing library, that should reside in the library's namespace. If the developer wants the algorithm(s)/class to go into a different namespace, a rational should be given. >I could create a document that lists all the >algorithms under consideration with a small summary. >The boost members could than accept/reject each >algorithm and offer suggestions. It would also be worth considering where the algorithms/classes should reside (w.r.t. the files section and the boost-sandbox). It would also be useful to post the algorithms/classes and their descriptions in the review e-mail to facilitate discussion with a link to the code. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

1 0

[config] seems like VC 8.0 needs BOOST_NO_MEMBER_TEMPLATE_FRIENDS
by JOAQUIN LOPEZ MU?Z 26 Jul '04

26 Jul '04

Tests at RudbekAssociates for multi_index in VC 8.0 show this recurrent error: error C2888: 'void boost::multi_index::safe_mode::detach_equivalent_iterators(Iterator &)' : symbol cannot be defined within namespace 'detail' The code causing the problem has the following form: ***********BEGIN CODE*********** namespace boost{ namespace multi_index{ namespace safe_mode{ template<typename Iterator> inline void detach_equivalent_iterators(Iterator& it) { ... } }// namespace boost::multi_index::safe_mode namespace detail{ class safe_iterator_base { ... template<typename Iterator> friend void safe_mode::detach_equivalent_iterators(Iterator&); }; } // namespace boost::multi_index::detail } // namespace boost::multi_index } // namespace boost ***********END CODE*********** which AFACIS seems to indicate that VC 8.0 does *not* support member template friends (VC 7.1 didn't support them either) and thus BOOST_NO_MEMBER_TEMPLATE_FRIENDS should be defined for it (it isn't). I've searched through the VC 2005 beta docs and, allegedly, member template friends are supported, so this particular problem could be a bug rather than complete lack of support for this feature. Maybe someone with local access to VC 8.0 can test the above code and see what happens (I currently don't have the time and resources to try myself.) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: DLL library (Was: [boost] Re: additional boost libraries?)
by Reece Dunn 26 Jul '04

26 Jul '04

Vladimir Prus wrote: >Hi Mattias, > > On Fri, 23 Jul 2004 13:49:22 +0400, Vladimir Prus <ghost(a)cs.msu.su> >wrote: > > > static imported_function<void()> apiFunc( "ApiFunc", "OSLib" ); > > > > Couldn't find a nice point in the thread at which to insert this > > comment, so I'll just spit it out: Since we have both the name of the > > function and the function type, and given that a lib such as this > > should provide a platform-independent interface, would it be useful if > > the library automatically mangled the name according to the type? > >I think you've missed something ;-) Even my initial reply inthe "additional >boost libraries" thread mentioned the possibility of calling functions >which >are not "extern "C". At least two other persons seems to want this. I find >this would be nice, though not critical at all. Would it be possible to have a mangle function, then you could do something like: static imported_function<void()> apiFunc( mangle::mwcw( "ApiFunc" ), "OSLib" ); This would mean that imported_function need only know how to get the function (e.g. using GetProcAddress in Win32) and not worry about the name mangling scheme used. The name mangling could then be handled by a mangler/demangler library that would be useful in diagnostics, e.g.: template< typename T > inline void print_type( const T & t ) { std::cout << demangle::gcc3( typeid(t).name()); } Also, wouldn't it be better to have import as a function of shared_library, so you could do something like: boost::shared_library mylib( "user32.dll" ) typedef ... msgboxA_fn; msgboxA_fn mbA = mylib.import< msgboxA_fn >( "MessageBoxA" ); msgboxW_fn mbW = mylib.import< msgboxW_fn >( "MessageBoxW" ); With the possible Win32 implementation of, but using boost::function: namespace boost { class shared_library { private: HANDLE hDLL; public: template< typename Function > inline Function * import( const char * fn ) { if( hDLL == 0 ) return( 0 ); return( reinterpret_cast< Function * >( ::GetProcAddress( hDLL, fn ))); } public: inline shared_library( const char * fn ): hDLL( ::LoadLibrary( fn )) { } inline ~shared_library() { if( hDLL ) { ::FreeLibrary( hDLL ); hDLL = 0; } } }; } Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

3 2

Serialization bug
by Matthias Troyer 26 Jul '04

26 Jul '04

There is a bug in serialization which becomes apparent on 64-bit machines, such as an AMD Opteron: /asgard/home/phys/troyer/src/boost/boost/archive/ polymorphic_oarchive.hpp:66: error: `virtual void boost::archive::polymorphic_oarchive::save(int64_t)' and `virtual void boost::archive::polymorphic_oarchive::save(long int)' cannot be overloaded /asgard/home/phys/troyer/src/boost/boost/archive/ polymorphic_oarchive.hpp:67: error: `virtual void boost::archive::polymorphic_oarchive::save(uint64_t)' and `virtual void boost::archive::polymorphic_oarchive::save(long unsigned int)' cannot be overloaded long and int64_t are the same when using the gcc compiler on a 64-bit machine and this overload fails. Matthias

1 0

Re:[boost] [multi_index] regrssion with Intel 8.0 for Linux.
by Robert Ramey 26 Jul '04

26 Jul '04

Joaqu?n M? L?pez Mu?oz wrote: Intel will let you download the lastest compiler version on a trial basis for free for 30 days. I did it and it was very helpful - (sadly, my license has now expired) You could do that if all else fails. Robert Ramey

1 0

Re:[boost] Re: question regarding vacpp tests and mpl
by Robert Ramey 26 Jul '04

26 Jul '04

Toon Knapen wrote: Message: 13 Date: Mon, 26 Jul 2004 15:02:27 +0200 From: Toon Knapen <toon.knapen(a)fft.be> >Aleksey Gurtovoy wrote: >> I think the most practical way to >> approach the error is to simplify the above to the bare minimum >> (ignoring the semantics for now), and see how the compiler reacts. For >> instance, >> >> #if BOOST_WORKAROUND(__IBMCPP__, BOOST_TESTED_AT(600)) >> typedef >> BOOST_DEDUCED_TYPENAME mpl::apply_if< >> is_base_and_derived<basic_traits, T>, >> traits_class_level<T>, >> mpl::int_<object_serializable> >> >::type type; >> #else >> // original code ... >> >> #endif >> >I tried Aleksey's suggestion above and it seems to improve the situation >for the serialization lib on vacpp. I suggest to apply the suggested modif. The problem is that the rest of the library depends upon the semantics of the operation. So, I can't just roll in the modification and declare victory. I can see experimenting as a way to discover an equivalent formulation that will compile under vacpp. But doing this isn't practical for me with a one day test turnaround. So I feel I have no choice but to set it aside for now. Of course, if "someone" wants to entertain himself with this little puzzle and has convenient access to the compiler - then I would be very appreciative. Thanks for your help. Robert Ramey

1 0

[multi_index] regrssion with Intel 8.0 for Linux.
by Joaquín Mª López Muñoz 26 Jul '04

26 Jul '04

One out of the 18 tests is making ICC 8.0 go wild, please see http://tinyurl.com/6u4og icc: error: Fatal error in /opt/intel_cc_80/bin/mcpcom, terminated by segmentation violation compilation aborted for ../libs/multi_index/test/test_update_main.cpp (code 1) . /opt/intel_cc_80/bin/iccvars.sh icc -c -w1 -g -O0 -I"../bin/boost/libs/multi_index/test" -I"/boost/head-regression/boost" -o "../bin/boost/libs/multi_index/test/test_update.test/intel-8.0-linux/debug/test_update_main.o" "../libs/multi_index/test/test_update_main.cpp" Anyone has any idea what to do about this? The offending test is not more complicated than the others, so this is most bizarre. If anyone with local access to the compiler could try commenting out code to see which particular piece of the test is making ICC bang, I'd much appreciate it. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 3

RE: [boost] Re: DLL library (Was: Re: additional boost libraries?)
by Reece Dunn 26 Jul '04

26 Jul '04

Vladimir Prus wrote: >Reece Dunn wrote: > > Would it be possible to have a mangle function, then you could do > > something like: > > > > static imported_function<void()> apiFunc( mangle::mwcw( "ApiFunc" >), > > "OSLib" ); > > > > This would mean that imported_function need only know how to get the > > function (e.g. using GetProcAddress in Win32) and not worry about the >name > > mangling scheme used. > >I though more about a policy function/class. Something like: > > boost::dll my_dll("foo", cpp_mangler); > boost::dll my_dll2("foo", c_mangler); The problem with this is if you need different mangling schemes for the same library then you will have several instances of the same library loaded (not sure how Windows handles this). A possibility is to have the mangler specified in the constructor (defaulting to extern "C" functions) be the default mangler and have another function where you can explicitly state which mangler you need: boost::dll mylib( "mylib", gcc3_mangler ); mylib.import< ... >( "get_id" ); // use GCC3 mangling mylib.import< ... >( "factorial", c_mangler ); // use extern "C" mangling > > The name mangling could then be handled by a > > mangler/demangler library that would be useful in diagnostics, e.g.: > > > > template< typename T > > > inline void print_type( const T & t ) > > { > > std::cout << demangle::gcc3( typeid(t).name()); > > } > >That's for sure. And in other contexts too. True. If you go for an external policy-based mangler like above then you don't need to worry about name mangler support (e.g. does the library have VC or GCC3 mangling?) immediately. You can provide a base set and add to that set later. >I also wonder if it makes sense to sumbit just "dll" library, or some >additional plugin support need to be developed first. What sort of plugin support are you looking for? Do you mean something like COM/CORBA support or wrapper, e.g. something that can target both (and others like them) in one implementation? Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

2 1

DLL library (Was: [boost] Re: additional boost libraries?)
by Vladimir Prus 26 Jul '04

26 Jul '04

Hi Sven, > > Probably, you could start by explaining your vision of the library first. > > Of three points you've given: > > The problems I would like to solve for myself are: > > 1) Often you need to write progams that need to work on different versions > of a particular OS, with later versions having additional API calls that > you could use. > void MyAPIStub() > { > static imported_function<void()> apiFunc( "ApiFunc", "OSLib" ); > > if ( !apiFunc ) > { > // do something here > } > > apiFunc(); I think this is reasonable use case. I wanted something similiar recently. I have a library which calls user-provided 'userinit' function. To allow the user to not provide the function, the library has its own definition. So, when the library's version is called, it call 'dlsym' to find the 'next' definition of 'userinit' and if it exists, calls it. But I'm afraid this semantic (find the next definition of symbol) is Unix-specific. I'm not even sure if two symbols with the same names in different DLLs are allowed on Windows. > Altough I acknowlege that the locking required in multi-threaded progams > would clutter the syntax (more than) a little. I'm not sure it's necessary, unless the called function is not thread-safe. > 2) When creating plugin interfaces, having to go through extern "C" is a > bit ugly to me. At the same time it ditches the C++ type safety. Being able > to export a C++ plugin function and have the import library figure out the > name mangling for me would improve the both the readability and the > correctness of the program I don't care that much about type safety of a single function, given that implementing that type-safety can be hard. But, of course, this would be a nice addition if you want to code it ;-) I'm more interested in nice interface to declare plugins. For example, on Unix static initialisers in a library are run when it's opened, so you can do something like this: extern std::map<std::string, Codegen*> codegens; // defined somewhere in application class Codegen1 {}; class Codegen2 {}; RegisterHelper<Codegen1> X(codegens, "1"); RegisterHelper<Codegen1> X(codegens, "2"); But will this work for Windows? Can DLL have unresolved external references? Are static initializers run when DLL is opened? If not, we'd have to do much less nice: void init_codegens(std::map<....>& m) { m["1"] = new Codegen1; m["2"] = new Codegen2; } It's less nice, because the first approach allows to register different codegens in different translation units. BTW, I think if you want typesafety, not don't need overloading, you can do this: // caller typedef void (right_type)(int, foo, bar); void* fp = ... get raw pointer to function ...; ((right_type*)fp)(....., typeid(right_type).name()); // callee typedef void (right_type)(int, foo, bar); void func(int, foo, bar, char* sig) { assert(strcmp(sig, typeid(right_type).name()) == 0); ..... } > > boost::function<void (void)> f > > = static_cast<void (*void)>dlsym(h, "whatever") > > > > - Volodya > > Yeah, yesterday morning I was already thinking more of something like this > > boost::function<void()> f1 = import<void()>( "lib", "whatever" ); > boost::function<void()> f2 = import<void()>( lib, "whatever" ); > boost::function<void()> f3 = import<void()>( lib, "whatever", > some_decorator () ); Yes, I think that's just as fine. I'm a bit suspicious about passing library name as string -- you'd need to keep a list of all opened dll handles somewhere. Maybe just class 'dll' with method 'import'? > As far as the cdecl decorator and the tool is concerned. I have always > considered it very likely that I would fail and not achieve what I want, > but that won't stop me from trying. ;-) Just keep us informed somehow... I'd be interested in working on this too, though won't have any time till September. - Volodya

7 10

Re: question regarding vacpp tests and mpl
by Toon Knapen 26 Jul '04

26 Jul '04

Aleksey Gurtovoy wrote: > Robert Ramey writes: > >>The serialization library is failing all tests with IBM visual age compiler. >>Errors occur within mpl. > > > Not quite, I am afraid. Considering that the 'apply_if' test itself > compiles without an error, this looks more like a problem with the > particular context where the facility is used: > > "/home/tk/boost_regression/boost/boost/serialization/level.hpp", line > 44.9: 1540-0038 (S) The name "typename mpl::apply_if< > boost::is_base_and_derived< boost::serialization::basic_traits, > boost::serialization::nvp<A[9]> >, > boost::serialization::implementation_level< > boost::serialization::nvp<A[9]> >::traits_class_level< > boost::serialization::nvp<A[9]> >, boost::mpl::int_<3> >::type" is > not a type. > > Looking at the code in "level.hpp", this is one complicated typedef! > > typedef > BOOST_DEDUCED_TYPENAME mpl::apply_if< > is_base_and_derived<basic_traits, T>, > traits_class_level<T>, > //else > BOOST_DEDUCED_TYPENAME mpl::apply_if< > is_fundamental<T>, > mpl::int_<primitive_type>, > //else > BOOST_DEDUCED_TYPENAME mpl::apply_if< > is_class<T>, > mpl::int_<object_class_info>, > //else > BOOST_DEDUCED_TYPENAME mpl::apply_if< > is_array<T>, > #if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x564)) > mpl::int_<not_serializable>, > #else > mpl::int_<object_serializable>, > #endif > //else > BOOST_DEDUCED_TYPENAME mpl::apply_if< > is_enum<T>, > #if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x564)) > mpl::int_<not_serializable>, > #else > mpl::int_<object_serializable>, > #endif > //else > mpl::int_<not_serializable> > >::type > >::type > >::type > >::type > >::type type; > > > It's inefficient, too (you don't need all these '::type's except the > very last one), but in any case: I think the most practical way to > approach the error is to simplify the above to the bare minimum > (ignoring the semantics for now), and see how the compiler reacts. For > instance, > > #if BOOST_WORKAROUND(__IBMCPP__, BOOST_TESTED_AT(600)) > typedef > BOOST_DEDUCED_TYPENAME mpl::apply_if< > is_base_and_derived<basic_traits, T>, > traits_class_level<T>, > mpl::int_<object_serializable> > >::type type; > #else > // original code ... > > #endif > I tried Aleksey's suggestion above and it seems to improve the situation for the serialization lib on vacpp. I suggest to apply the suggested modif. Sorry for the late response but I was on vacation. Toon

1 0

Attention Doug: Tabs in files...
by Rene Rivera 26 Jul '04

26 Jul '04

Doug, Please fix your editor so that you don't introduce tabs into code... http://www.boost.org/regression-logs/inspection_report.html#bcp Boost Inspection Report -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

2 1

Moving to the Boost Software License
by Doug Gregor 26 Jul '04

26 Jul '04

We know we'd like to move over to the Boost Software License (BSL), but doing so is a bit of a pain. I've just updated John Maddock's bcp tool to add three new things to the HTML report it generates: (1) A list of files that can be converted over to the BSL at any time (but we need someone or something to do it) (2) A list of files that CAN NOT be converted because we don't have permission from one of the authors (3) A list of authors that we need to contact before files can be converted over to the BSL We have several things we need to do to make this happen. First, we need to contact the authors that prevent Boost code from being converted to the BSL. Second, we need to convert files that show up in the "can be converted" list over to the BSL, by replacing the existing licenses with the BSL. A solution to do this mechanically would be greatly appreciated; we can probably hack bcp to do it, but it's not entirely trivial; I'm slightly concerned it might not be legal and that we might need human volunteers to do it. Just looking at boost/function.hpp, here is the list of authors we need to contact. If you are on this list and would like to give your permission to move any of your code in Boost to the Boost Software License, version 1.0, please do one of the following: (A) Add your name and an e-mail address to more/blanket-permission.txt in CVS, or (B) Reply to the mailing list stating that you agree to allow your copyrighted code to be converted to the Boost Software License; I'll add you to the aforementioned file with a message time stamp. Adobe Systems Inc Bill Kempf Boost org Brad King Christof Meerwald Dan Watkins Darin Adler Dave Abrahams Doug Gregor Gennaro Prota Guillaume Melquiond Housemarque Oy Howard Hinnant Jaakko J rvi Jeremy Siek Jesse Jones Lie-Quan Lee Markus Schöpflin Martin Wille Mat Marcus Multi Media Ltd Paul Mensonides Steve Cleary Synge Todo The Trustees of Indiana University Toon Knapen (Note there are some near-misses that can easily be fixed, e.g. "Dave Abrahams" and "Doug Gregor", who are in the blanket permission file as "David Abrahams" and "Douglas Gregor"; in this case, we should probably just normalize the names in the source files). Doug

7 10

TT_AUX_IS_CONVERTIBLE_FROM_FLOAT_CV_SPEC in type_traits/is_convertable.hpp
by Aaron W. LaFramboise 26 Jul '04

26 Jul '04

These three lines near the end of boost/type_traits/is_convertable.hpp: TT_AUX_IS_CONVERTIBLE_FROM_FLOAT_CV_SPEC(float) TT_AUX_IS_CONVERTIBLE_FROM_FLOAT_CV_SPEC(double) TT_AUX_IS_CONVERTIBLE_FROM_FLOAT_CV_SPEC(long double) don't compile on GCC 3.4.1 when -pedantic is specified. This is actually sort of strange, because it compiles without warnings when -std=c++98 -Wall -W are specified, and -pedantic itself is not supposed to generate errors, only warnings. So, there is probably at least a GCC bug here. Does anyone have any idea what this is about? $ g++ -pedantic -I../boost -c stuff.cpp In file included from stuff.cpp:1: ../boost/boost/type_traits/is_convertible.hpp:274: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:274: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:274: error: redefinition of `struct boost::is_convertible<float, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:274: error: previous definition of `struct boost::is_convertible<float, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:274: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:274: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:274: error: redefinition of `struct boost::is_convertible<const float, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:274: error: previous definition of `struct boost::is_convertible<const float, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:274: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:274: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:274: error: redefinition of `struct boost::is_convertible<volatile float, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:274: error: previous definition of `struct boost::is_convertible<volatile float, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:274: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:274: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:274: error: redefinition of `struct boost::is_convertible<const volatile float, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:274: error: previous definition of `struct boost::is_convertible<const volatile float, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:275: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:275: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:275: error: redefinition of `struct boost::is_convertible<double, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:275: error: previous definition of `struct boost::is_convertible<double, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:275: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:275: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:275: error: redefinition of `struct boost::is_convertible<const double, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:275: error: previous definition of `struct boost::is_convertible<const double, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:275: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:275: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:275: error: redefinition of `struct boost::is_convertible<volatile double, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:275: error: previous definition of `struct boost::is_convertible<volatile double, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:275: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:275: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:275: error: redefinition of `struct boost::is_convertible<const volatile double, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:275: error: previous definition of `struct boost::is_convertible<const volatile double, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:276: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:276: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:276: error: redefinition of `struct boost::is_convertible<long double, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:276: error: previous definition of `struct boost::is_convertible<long double, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:276: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:276: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:276: error: redefinition of `struct boost::is_convertible<const long double, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:276: error: previous definition of `struct boost::is_convertible<const long double, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:276: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:276: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:276: error: redefinition of `struct boost::is_convertible<volatile long double, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:276: error: previous definition of `struct boost::is_convertible<volatile long double, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:276: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:276: error: long, short, signed or unsigned used invalidly for `type name' ../boost/boost/type_traits/is_convertible.hpp:276: error: redefinition of `struct boost::is_convertible<const volatile long double, int64_t>' ../boost/boost/type_traits/is_convertible.hpp:276: error: previous definition of `struct boost::is_convertible<const volatile long double, int64_t>' Pentium 4 on Windows XP Pro gcc 3.4.1 on mingw32 binutils 2.15 mingwrt 3.3 Thanks for your attention, Aaron W. LaFramboise

2 2

Re: [boost] Re: [test] regression with latest change tolibs/test/src/test_tools.cpp
by JOAQUIN LOPEZ MU?Z 26 Jul '04

26 Jul '04

Hi Gennadiy ----- Mensaje original ----- De: Gennadiy Rozental <gennadiy.rozental(a)thomson.com> Fecha: Domingo, Julio 25, 2004 9:55 pm Asunto: [boost] Re: [test] regression with latest change tolibs/test/src/test_tools.cpp > > FYI, latest changes to the aforementioned > > file seem to break things for msvc-stlport, > > as shown for instance at: > > Dave tried to use "using namespace std" solution. It's already > fixed in cvs. > Thanks for the quick response! Let's see if this fixes things up in the next testing cycle. Best, Joaquín M López Muñoz Telefónica, Ingectigación y Desarrollo

3 5

Re: [boost] [Important For All Boost Contributors] BSL Status Update
by Stephan T. Lavavej 26 Jul '04

26 Jul '04

[Stephan T. Lavavej] > I ran it on all of the directory names in libs, in current > Boost CVS, except for CVS, python, and serialization - the > last two gave errors. [Doug Gregor] > Thanks! Sure. I had to copy a .css file to a different directory to get bcp to work in the first place. I don't know why bcp was complaining about python and serialization, and I didn't know enough to hack around it. [Stephan T. Lavavej] > The following people ARE in blanket-permission.txt, but have > used these alternate names in Boost code. > Doug Gregor [Doug Gregor] > This one should now be fixed... Great! [Stephan T. Lavavej] > * "Files that could be converted to the Boost Software > License" should be. There are a lot of files there. [Doug Gregor] > I'll see if I can come up with a program to do this > automagically. We have to be _very_ careful with this, > though. Ok. I agree, that's something that can't be screwed up. [Stephan T. Lavavej] > I don't think "boost org" is a real organization. [Doug Gregor] > I'll take care of this. Awesome! [Stephan T. Lavavej] > * The following organizations (or people with really, really > weird names) hold copyrights to non-BSL libraries. They > should be contacted. > Free Software Foundation Inc [Doug Gregor] > They're not going to agree to the BSL, that's for sure :) The Boost site says that all libraries in Boost, even those not under the BSL, conform to Boost licensing requirements (which excludes the GPL and friends). So the FSF code in Boost shouldn't be under the GPL or any of its derivatives. From my decidedly non-lawyer point of view, the BSL is just a precise statement of the Boost licensing requirements. So the FSF may not be ideologically opposed to BSL conversion. But I don't know what the FSF code in Boost is actually licensed under. > This only affects the Graphviz parser in the BGL, which is > due for a rewrite soon anyway. Ok. This does not personally affect me (I'm real interested in bind and smart_ptr for work), but it should be cleared up. Thanks for looking into some of the [quasi-]organizations I listed. > We should make this a requirement, I think. Agreed. > Probably just a form of license not matched by one of the > regexes in bcp. Easily fixed, with a little time investment. > it might be more useful to have that scorecard showing which > libraries are completely under the BSL. Both are easy enough > to implement. Such a scorecard would be excellent (something to point Microsoft's Big Scary Lawyers at). Thanks for your continuing great work! Stephan T. Lavavej

4 3

additional boost libraries?
by Aleksander Demko 26 Jul '04

26 Jul '04

I, like billions of other developers, have a medium sized project that for various reasons, invented its own thread, io, etc libraries. I'm thinkin of switching over to boost stuff for all my utility needs, but I'm wondering if boost has/possibly will have/is open to the possibility of adding/ or will never have the following facilities: serialization/object persistance (via iostreams) network socket iostreams UUID stuff (sometimes know as GUIDs) interface to dlls/.so loading url parsing (something like the filesystem lib) and, just out of curiosity: xml/html parsing Thanks in advance. -- // scopira.org | ninjacoder.com //

14 25

[program_options] unicode_test regressions for CW8
by Rene Rivera 26 Jul '04

26 Jul '04

Volodya, Did some more investigation and the basic reason for the failure is that the CW8 lexer doesn't do phase 1 translations of the universal character names. So for string like: L"--foo=\u044F", the "\u044F" is translated into 'u'+'0'+'4'+'4'+'F'. The workaround, which should apply to any compiler that doesn't do universal character names, is to use "\x044F" instead: =================================================================== RCS file: /cvsroot/boost/boost/libs/program_options/test/unicode_test.cpp,v retrieving revision 1.2 diff -u -r1.2 unicode_test.cpp --- unicode_test.cpp 26 Jun 2004 11:33:02 -0000 1.2 +++ unicode_test.cpp 24 Jul 2004 14:49:23 -0000 @@ -32,12 +32,12 @@ ; vector<wstring> args; - args.push_back(L"--foo=\u044F"); + args.push_back(L"--foo=\x044F"); variables_map vm; store(wcommand_line_parser(args).options(desc).run(), vm); - BOOST_CHECK(vm["foo"].as<wstring>() == L"\u044F"); + BOOST_CHECK(vm["foo"].as<wstring>() == L"\x044F"); } // Test that unicode input is property converted into @@ -56,7 +56,7 @@ ; vector<wstring> args; - args.push_back(L"--foo=\u044F"); + args.push_back(L"--foo=\x044F"); variables_map vm; store(wcommand_line_parser(args).options(desc).run(), vm); @@ -82,7 +82,7 @@ variables_map vm; store(command_line_parser(args).options(desc).run(), vm); - BOOST_TEST(vm["foo"].as<wstring>() == L"\u044F"); + BOOST_TEST(vm["foo"].as<wstring>() == L"\x044F"); } // Since we've already tested conversion between parser encoding and @@ -100,7 +100,7 @@ ("foo", po::value<string>(), "unicode option") ; - std::wstringstream stream(L"foo = \u044F"); + std::wstringstream stream(L"foo = \x044F"); variables_map vm; store(parse_config_file(stream, desc), vm); =================================================================== Those changes let the test pass on CW8, and they still work on VC7.1. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

2 1

Re:Re: [boost] Re: serialization:question regarding test
by Robert Ramey 26 Jul '04

26 Jul '04

Aleksey Gurtovoy wrote: >Robert Ramey writes: >> I don't see that this should be a problem. Just follow the instructions in >> the release notes: >> >> a) Download spirit 1.61 from SourceForge.net to a local directory. On my >> machine its c:/spirit161 >> >> b) Define (export) environmental variable SPIRIT_ROOT=c:/spirit161. >> >> The build/test jamfile set up is sensitive to the SPIRIT_ROOT >> variable and will put it in the include path for those systems that >> are known to require it. Right not that is msvc 6.0 and all tested >> borland compilers. Other compilers just work with the latest >> version of spirit from the CVS Tree. This works on my system >> without any other special adjustments other than the above. So I'm >> asking that the testers set up their environment as above before >> running the tests. I don't think that's an unreasonable request. >It's not unreasonable. However, before we do that, we at least need to >figure out how to indicate in the reports that the MSVC 6.0 results >are in fact produced by compiling against something else than the >main trunk. This kind of mark-up is not currently supported and would >require a bit of coding that I'm afraid we don't have resources for at >the moment. This is explained in the serialization documentation. I wouldn't think this is interesting for the notes markup. I don't see that the above issue has any relationship at all with the question of notes markup. Regarding markup. As far as I can tell, there is no simple way to specify a note that a applies to all tests for a given toolset. E.G. All serialization tests that depend upon wide character i/o under gcc/cygwin as wide char i/o isn't supported there. E.G. All tests which depend up export on borland compilers fail. E.G. All tests for msvc which use more than one archive class in the same code module fail. These issues are addressed in the library documentation. I don't see an easy way to fit them into the notes system. Robert Ramey

3 5

[test] regression with latest change to libs/test/src/test_tools.cpp
by JOAQUIN LOPEZ MU?Z 26 Jul '04

26 Jul '04

FYI, latest changes to the aforementioned file seem to break things for msvc-stlport, as shown for instance at: http://tinyurl.com/6br7t [format] http://tinyurl.com/6xt58 [minmax] http://tinyurl.com/48hd6 [multi_index] Joaquín M´López Muñoz Telefónica, Investigación y Desarrollo

3 2

Re: [boost] Re: [test] regression with latest change tolibs/test/src/test_tools.cpp
by JOAQUIN LOPEZ MU?Z 26 Jul '04

26 Jul '04

----- Mensaje original ----- De: "Victor A. Wagner Jr." <vawjr(a)rudbek.com> Fecha: Domingo, Julio 25, 2004 11:54 pm Asunto: Re: [boost] Re: [test] regression with latest change tolibs/test/src/test_tools.cpp [...] > Also, I now have the vc8.0 beta and would be happy to add those > to my > testing if I only knew how to go about adding a toolset. Any > assistance > would be greatly appreciated. > Aleksey explains the procedure at: http://www.meta-comm.com/engineering/regression_setup/instructions.html Good luck, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

run-fail on non-Wondows platforms
by Gennadiy Rozental 25 Jul '04

25 Jul '04

What up with subject? Why all Boost.Test unit tests fail? Gennadiy.

1 0

WARNING: many changed files...
by Rene Rivera 25 Jul '04

25 Jul '04

I just finished cleaning up *all* occurrences of TABS and END-OF-LINE problems. Your next update will contain many file changes (all whitespace). And *PLEASE* to not introduce more of these errors. It's somewhat of a pain to fix the TAB errors :-( -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

1 0

Iterator lib missing copyrights
by John Maddock 25 Jul '04

25 Jul '04

The following files have no copyright info, can the owners please fix? boost/iterator/detail/categories.hpp boost/iterator/new_iterator_tests.hpp libs/iterator/example/permutation_iterator_example.cpp libs/iterator/example/reverse_iterator.cpp libs/iterator/test/is_convertible_fail.cpp libs/iterator/test/iterator_adaptor_cc.cpp libs/iterator/test/lvalue_concept_fail_expected.cpp Many thanks, John Maddock.

2 1

CW9 results
by Stefan Slapeta 25 Jul '04

25 Jul '04

I think Aleksey forgot to mention: my CW column is for CW 9. I didn't have the time yet to investigate much but the results are quite common with the CW 8 results. However, the first dynamic_bitset test produces an ICE on CW9! Also the results for program_options seem to be interesting. Stefan

4 5

Re: [boost] [Important For All Boost Contributors][multi_index] BSL Status Update
by JOAQUIN LOPEZ MU?Z 25 Jul '04

25 Jul '04

----- Mensaje original ----- De: "Stephan T. Lavavej" <stl(a)nuwen.net> Fecha: Domingo, Julio 25, 2004 3:47 am Asunto: [boost] [Important For All Boost Contributors] BSL Status Update [...] > > * I know I've seen the following people post to the Boost list > recently. They should be contacted about adding themselves to > blanket-permission.txt. > > Joaquín Mª López Muñoz This is me. Wrt to the license status of Boost.MultiIndex, * All files that appear under "Files With No Recognisable Licence" do have a BSL License and a proper (c). Is the wording wrong, or is it the bot's fault? Could anyone take a look please? Thanx. * There are a couple of trivial files without (c) or license, I'll have them fixed tomorrow. * The following files boost/multi_index/detail/ord_index_node.hpp boost/multi_index/detail/ord_index_ops.hpp boost/multi_index/ordered_index.hpp have portions based on SGI STL source code, but IMHO they have underwent enough rewriting so that the SGL license does not longer apply to them. The original SGL text appears (after BSL text) as a courtesy only. Could any expert give advice on this? Do those files really retain SGL license? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Graph lib files with no copyright/licence
by John Maddock 25 Jul '04

25 Jul '04

The following graph lib files have no copyright or licence declaration, can the owners (Jeremy?) please fix? libs/graph/example/adjacency_list_io.cpp libs/graph/example/graph_property.cpp libs/graph/example/iohb.c libs/graph/example/iohb.h libs/graph/example/subgraph_properties.cpp libs/graph/src/graphviz_digraph_parser.hpp libs/graph/src/graphviz_graph_parser.hpp libs/graph/src/yystype.h libs/graph/test/bellman-test.cpp libs/graph/test/bidir_remove_edge.cpp libs/graph/test/subgraph.cpp libs/graph/test/transitive_closure_test2.cpp Many thanks, John Maddock.

1 0

"Pending" files have no copyright
by John Maddock 25 Jul '04

25 Jul '04

The following files in boost/pending have no copyright, there is a wider issue about what we should do with these files, but for now I'd just like to fix the licence issue. It looks like these are Jeremy Siek's work, is that correct? boost/pending/container_traits.hpp boost/pending/cstddef.hpp boost/pending/detail/disjoint_sets.hpp boost/pending/detail/property.hpp boost/pending/fenced_priority_queue.hpp boost/pending/fibonacci_heap.hpp boost/pending/property.hpp boost/pending/queue.hpp boost/pending/stringtok.hpp Thanks, John Maddock

1 0

typeof: type registration
by Arkadiy Vertleyb 25 Jul '04

25 Jul '04

Hi all, Based on the discussion on this subject, I am going to switch to the automatic scheme of ID genereation. As I understand, the need to specify a unique ID could introduce just enough inconvenience to make the system unattractive to use. I will put registration classes inside anonimous namespace, to avoid ODR violation when typeof os used from a CPP. When typeof is used in templates, or enywhere else inside a header (except classes also defined in anonimous namespaces), the system will not be ODR-complient. The compilers will probably not care (since there is no runtime code generated, but this will have to be tested. I will make the changes and post them sometime soon. Anybody has any problems with this approach? Arkadiy

1 0

[config] _WIN32 question
by Vladimir Prus 25 Jul '04

25 Jul '04

Hello, in my library I use _WIN32 macro to detect the case when I'm on windows (e.g. to get the right header for 'environ'). However, Boost.Config has more complex logic: #elif defined(_WIN32) || defined(__WIN32__) || defined(WIN32) // win32: .... Does it mean I have to use the same conditional? Which compilers define __WIN32__ or WIN32, but don't define _WIN32? Shouldn't there be a single BOOST_WINDOWS macros to help in this cases? FWIW, filesystem defines such macro internally: # if !defined( BOOST_WINDOWS ) && !defined( BOOST_POSIX ) # if defined(_WIN32) || defined(__WIN32__) || defined(WIN32) || defined(__CYGWIN__) # define BOOST_WINDOWS # else # define BOOST_POSIX # endif # endif - Volodya

3 6

[Boost.Thread] mutex Win32 implementation changes
by Michael Glassford 25 Jul '04

25 Jul '04

I've just checked in changes to Win32 implementations of the mutex and recursive_mutex classes. They now use a Win32 critical section instead of a mutex whenever possible for the normal and try_ variations, though not for the timed_ variations. These are changes that were started on the mutex classes quite some time back on the thread_dev branch; I've finished the changes and applied them to the recursive_mutex classes as well. In addition, the thread_dev branch has code that allows a mutex to be named, which allows it to be shared between two or more processes. This change was begun by Bill Kempf, but is only implemented for Win32. Any suggestions about the best way to add this feature to the pthreads and MPTasks implementations? Mike

4 35

Boost Software License Status Update?
by Stephan T. Lavavej 25 Jul '04

25 Jul '04

Hi, How is the move to the Boost Software License going? I managed to compile bcp for myself (after updating bjam to 3.1.10), but I have no clue how to use it in order to check the license status of the libraries. Stephan T. Lavavej

1 0

[assign] std regression for CW8
by Rene Rivera 24 Jul '04

24 Jul '04

In this test CW8 fails to do the operator lookup within the function scope. That is doing a "using namespace boost::assign" doesn't add the += operators to the resolution path for CW8. The workaround is to move the "using namespace" to the file scope: =================================================================== RCS file: /cvsroot/boost/boost/libs/assign/test/std.cpp,v retrieving revision 1.2 diff -u -r1.2 std.cpp --- std.cpp 21 Jul 2004 11:36:11 -0000 1.2 +++ std.cpp 24 Jul 2004 16:25:35 -0000 @@ -15,6 +15,7 @@ #include <string> using namespace std; +using namespace boost::assign; template< typename K, typename V > inline pair<K,V> P( K k, V v ) @@ -46,7 +47,6 @@ template< class C > void test_int_sequence() { - using namespace boost::assign; C c; BOOST_CHECK_EQUAL( c.size(), 0u ); @@ -59,7 +59,6 @@ template< class C > void test_string_sequence() { - using namespace boost::assign; C c; BOOST_CHECK_EQUAL( c.size(), 0u ); @@ -74,7 +73,6 @@ template< class C > void test_tuple_sequence() { - using namespace boost::assign; C c; BOOST_CHECK_EQUAL( c.size(), 0u ); @@ -88,7 +86,6 @@ template< class M > void test_map() { - using namespace boost::assign; M m; m += P( "january", 31 ), P( "february", 28 ), P( "march", 31 ), P( "april", 30 ), @@ -112,7 +109,6 @@ void test_tuple() { - using namespace boost::assign; vector<three> v_three; vector<four> v_four; vector<five> v_five; @@ -131,7 +127,6 @@ void check_std() { - using namespace boost::assign; test_int_sequence< deque<int> >(); test_int_sequence< list<int> >(); test_int_sequence< vector<int> >(); =================================================================== This make the test work on CW8, and still work on vc7.1 and mingw. And this fix should also apply to CW9. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

2 1

Jamfile.v2 failing for several doc directories
by Larry Evans 24 Jul '04

24 Jul '04

How do I avoid the following errors? <------------- cd /home/evansl/prog_dev/boost-cvs/boost/libs/variant/doc/ bjam --v2 /home/evansl/prog_dev/boost-cvs/boost/tools/build/v2/tools/boostbook.jam:322: in construct warning: rulename $(base-target).depends expands to empty string /home/evansl/prog_dev/boost-cvs/boost/tools/build/v2/build/targets.jam:1025: in object(boostbook-target-class)(a)1.generate /home/evansl/prog_dev/boost-cvs/boost/tools/build/v2/build/targets.jam:546: in generate-really /home/evansl/prog_dev/boost-cvs/boost/tools/build/v2/build/targets.jam:519: in object(main-target)(a)1.generate /home/evansl/prog_dev/boost-cvs/boost/tools/build/v2/build/targets.jam:203: in object(project-target)(a)11.generate /home/evansl/prog_dev/boost-cvs/boost/tools/build/v2/build-system.jam:160: in load /home/evansl/prog_dev/boost-cvs/boost/tools/build/v2/kernel/modules.jam:259: in import /home/evansl/prog_dev/boost-cvs/boost/tools/build/v2/kernel/bootstrap.jam:120: in boost-build /home/evansl/prog_dev/boost-cvs/boost/boost-build.jam:12: in module scope /home/evansl/prog_dev/boost-cvs/boost/tools/build/v2/tools/boostbook.jam:326: in construct warning: rulename $(target).set-path expands to empty string >---------------- TIA. Larry

1 2

[assign] list_inserter regression for CW8
by Rene Rivera 24 Jul '04

24 Jul '04

The failure on this test is caused by CW8's inability to do a function_template -> function_pointer -> template_type translation automatically. The workaround is to help it along by introducing a cast for the function_template -> function_pointer translation: =================================================================== RCS file: /cvsroot/boost/boost/libs/assign/test/list_inserter.cpp,v retrieving revision 1.2 diff -u -r1.2 list_inserter.cpp --- list_inserter.cpp 21 Jul 2004 11:36:10 -0000 1.2 +++ list_inserter.cpp 24 Jul 2004 15:44:55 -0000 @@ -53,7 +53,7 @@ using namespace boost::assign; vector<int> v; - make_list_inserter( &function_ptr<int> )( 5 ),3; + make_list_inserter( (void (*)(int))&function_ptr<int> )( 5 ),3; make_list_inserter( functor() )( 4 ),2; make_list_inserter( bind( &vector<int>::push_back, &v, _1 ) )( 6 ),4; BOOST_CHECK_EQUAL( v.size(), 2u ); =================================================================== That makes this test pass for CW8, and vc7.1, and mingw. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

1 0

RE: [boost] Re: counting_iterator_test.hpp fails on aC++
by DY, JERRY U (SBCSI) 24 Jul '04

24 Jul '04

Dave, The only workaround I have is to surround the static assertion with guards: #if !defined (__HP_aCC) BOOST_ITERATOR_ADAPTOR_ASSERT_TRAVERSAL(random_access_traversal_tag) #endif The assumption is that if "advance" is called, the compiler errors eventually anyway so this change should be harmless (and lets aC++ compile the code). I had to do the same for "decrement" and "distance_to" member functions. Is this workaround okay? I probably should check this in only after 1.32 release in any case. -Jerry -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams Sent: Thursday, July 22, 2004 10:36 AM To: boost(a)lists.boost.org Subject: [boost] Re: counting_iterator_test.hpp fails on aC++ "DY, JERRY U $SBCSI$" <jd2419(a)sbc.com> writes: > The problem is that since my_int2 is not a random access iterator, class > iterator_adaptor's member function "advance" would not compile because > of the static assertion below trying to convert > random_access_traversal_tag to bidirectional_traversal_tag > (my_traversal). It should never be instantiated, because it should never be called. This is a compiler bug. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

boost/test/detail/algorithm.hpp: request for promotion and/or fast review
by Gennadiy Rozental 24 Jul '04

24 Jul '04

Hi, I added several algorithms that extent STL algorithms set. I use them in my Boost.Test development. But since they seems to be generic and IMO should be present in STL I propose to push them in boost/algorithm.hpp (or under boost/algorithm). I remember there was a discussion already about these algorithms. Here is the list (I hope name and spec is self -explanatory): template <class InputIter1, class InputIter2> inline std::pair<InputIter1, InputIter2> mismatch( InputIter1 first1, InputIter1 last1, InputIter2 first2, InputIter2 last2 ); template <class InputIter1, class InputIter2, class Predicate> inline std::pair<InputIter1, InputIter2> mismatch( InputIter1 first1, InputIter1 last1, InputIter2 first2, InputIter2 last2, Predicate pred ); template<class ForwardIterator1, class ForwardIterator2> inline ForwardIterator1 find_first_not_of( ForwardIterator1 first1, ForwardIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2 ); template<class ForwardIterator1, class ForwardIterator2, class Predicate> inline ForwardIterator1 find_first_not_of( ForwardIterator1 first1, ForwardIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2, Predicate pred ); template<class BidirectionalIterator1, class ForwardIterator2> inline BidirectionalIterator1 find_last_of( BidirectionalIterator1 first1, BidirectionalIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2 ) template<class BidirectionalIterator1, class ForwardIterator2, class Predicate> inline BidirectionalIterator1 find_last_of( BidirectionalIterator1 first1, BidirectionalIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2, Predicate pred ); template<class BidirectionalIterator1, class ForwardIterator2> inline BidirectionalIterator1 find_last_not_of( BidirectionalIterator1 first1, BidirectionalIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2 ); template<class BidirectionalIterator1, class ForwardIterator2, class Predicate> inline BidirectionalIterator1 find_last_not_of( BidirectionalIterator1 first1, BidirectionalIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2, Predicate pred ); Implementation together with doxigen docs is here: http://tinyurl.com/35pfj Test is here: http://tinyurl.com/yvlgu If we don't find this header eligible for review I would like to ask then for permision to at least put this algorithm in boost namespace (currently boost::unit_test), for it inconvenience for me to keep it in deep namespace. Gennadiy.

7 13

help with iterator_value and BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION
by Thorsten Ottosen 24 Jul '04

24 Jul '04

Hi, The boost.iterator docs says On compilers that don't support partial specialization, such as Microsoft Visual C++ 6.0 or 7.0, you may need to manually invoke BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION on the value_type of pointers that are passed to these metafunctions. Can anyone show how this must be used. I have no idea on how to apply this workaround. Thanks Thorsten

3 4

Re: typeof: lvalue preserving
by Arkadiy Vertleyb 24 Jul '04

24 Jul '04

Giovanni Bajo wrote: >Arkadiy Vertleyb wrote: > > > One more addition to the typeof library is a macro, that, unlike > > BOOST_TYPEOF(), which removes top-level consts and references, > > attempts to be closer to the decltype, by preserving lvalue-ness of > > its argument: > > > > BOOST_TYPEOF_PRESERVE_LVALUE(expr) > > > > I do admit that the name is quite clumzy :( > > BOOST_DECLTYPE? Well, unfortunately, it's not exactly decltype :( In particular: int i; const int ci = 0; decltype BOOST_TYPEOF_PRESERVE_LVALUE -------- ---------------------------- i int int& ci const int const int& etc. It is calculated by binding a T& to the expression. If it can't be bound the type is the same as one returned by BOOST_TYPEOF. If it can, it's either reference or const reference, depending on the constness of T. Any suggestions how to make it closer to the real decltype? Arkadiy

4 11

[Boost.Test] bug
by David Abrahams 24 Jul '04

24 Jul '04

This is with mingw-2.0 c:\boost\libs\test\build\../src/test_tools.cpp:37: `wcscmp' is already declared in this scope #if defined( __GNUC__ ) && defined( BOOST_NO_CWCHAR ) namespace std { using ::wcscmp; } <===================== here #endif -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

5 13

What is it with boost and tinyurl?
by Miro Jurisic 24 Jul '04

24 Jul '04

It seems to me that boost developers are particularly enamored with tinyurl. While I agree that there are cases when tinyurl is a good thing, I can't but think that in many cases where it's used on boost lists it does more harm than good. Tinyurl (and similar services) discard valuable information from the URL. I often use information in the URL itself to judge whether the topic being discussed is of interest to me. Example: Useless: <http://tinyurl.com/4ghk7> Useful: <http://boost.sourceforge.net/regression-logs/cs-win32_metacomm/developer/pr… _options.html> ("Don't need to click if you are not interested in win32 regression of program options.") Useless: <http://tinyurl.com/yrotd> Useful: <http://lists.boost.org/MailArchives/boost/msg61026.php> ("Herein I refer to a previous thread on this mailing list.") Both of those examples were recently posted to the mailing list, and in both cases there was not enough context in the surrounding text for me to determine what the URL was about (without having to read several messages in the thread). I could name at least two other reasons for why tinyurl is not a great idea: first, it means that tinyurl.com can track my web access; second, if tinyurl is down, I am screwed. Neither of those two is as important to me as the reason I outlined above, though. Finally, URL line wrapping is a well-understood problem, with a recommended practice (namely, enclosing URLs in text inside <>, as I did above) codified in the current URL RFC. Every email and usenet client I am aware of does the right thing with line-wrapped URLs in angle brackets. If someone wants to convince me that tinyurl provides a valuable service to the community, I am listening. If not, I kindly request that those people who are in the habit of using tinyurl reconsider it. Thanks, meeroh -- If this message helped you, consider buying an item from my wish list: <http://web.meeroh.org/wishlist>

16 24

Re:[boost] Re: Re: typeof: lvalue preserving
by Robert Ramey 23 Jul '04

23 Jul '04

Arkadiy Vertleyb wrote: >"Andy Little" <andy(a)servocomm.freeserve.co.uk> wrote >> ...I think spirit and lambda already have their own type deduction >> schemes, making it easy to implement there. >I am unaware of such schemes. You might check serialization as well. See extended_type_info.hpp and export.hpp Robert Ramey

2 1

RE: [boost] Re: BOOST_FOREACH and break
by Rozental, Gennadiy 23 Jul '04

23 Jul '04

> There is a hidden variable in BOOST_FOREACH that tracks this > information, but it is scoped, so you can't get at it. (And > rightly so; > the scoping of hidden control variables is what makes BOOST_FOREACH > well-behaved.) BTW, while we are on topic. Your implementation uses code like this struct any_t {...}; template<typename T> struct static_any_t : any_t {...} template<typename T> static_any_t<T> foo(...); If( any_t const& ref = foo() ) { // here you are using ref } Is it indeed allowed in standard and ref is valid reference to temp? Gennadiy.

2 1

Re:Re: [boost] Re: Re:Re: Re:Re: additional boost libraries?
by Robert Ramey 23 Jul '04

23 Jul '04

Rene Rivera wrote: Robert Ramey wrote: > >> a) If the compiler is an older compiler >> b) && SPIRIT_ROOT is defined to something not null >> c) || the compiler is a newer compiler. >> >> I think the build jamfile could altered to do this. I spent a little >> time at it but didn't immediately see how to do it. But I think it >> should be possible. Its probably trivial for a BJAM guru - so feel >> free anyone. Also it would be nice if it echoed a comment indicating >> that its skipping the XML components for lack of SPIRIT_ROOT. >Although it's now possible to do this, I would *not* recommend this as a >solution. The basic problem with changing the Jamfile to skip the building >is that it will only work if people use the Jamfile. That's fine for >testing, but not for release. Many people out there don't use BB for >building Boost. Well, if boost build isn't being used then there is no issue. Such users would just exclude libs/serialization/src/*xml*.cpp files from the library build. This is what I would like to see the boost build system do. Seems by far the simplest to me. Robert Ramey

2 1

[multi_index] regression with GCC 4.1
by Joaquín Mª López Muñoz 23 Jul '04

23 Jul '04

The test at http://boost.sourceforge.net/regression-logs/cs-Linux-links.html#multi_inde… shows this message: Date: 2004-07-23 09:44 ../libs/multi_index/test/test_mpl_ops_main.cpp:20: internal compiler error: in size_of_die, at dwarf2out.c:6220 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. Strangely enough, this test used to work for GCC 3.4.1, and I'm not aware of any significant change in the code of the library or any of its dependencies. Ideas, please? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 2

BOOST_FOREACH and break
by Rozental, Gennadiy 23 Jul '04

23 Jul '04

Hi, I am trying to use construct similar to BOOST_FOREACH macro. In many cases I need to be able to detect whether loop was aborted with break or not. BOOST_FOREACH( ... ) { } // here if( aborted ) { .... } else { } Is there way to do so? Gennadiy.

2 1

Regression reports at regression-logs/developer in-accessible.
by Rene Rivera 23 Jul '04

23 Jul '04

I get permission denied errors when trying to look at the regression outputs in .../developer/output. Seems someone forgot to make that directory+files world readable. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

4 4

Re:[boost] Re: Re:Re: Re:Re: additional boost libraries?
by Robert Ramey 23 Jul '04

23 Jul '04

Edward Diener wrote: >> If you don't >> want to take the 15 minutes to do this, you can build with an older >> compiler and without spirit at all, you could easily modify the >> jamfile. Spirit is only used in the building of the library. >How can the jamfile be modified so that those who have an older compiler, >and don't need Spirit 1.6 for XML serialization, can build the >serialization library without Spirit 1.6 ? That was my point essentially. In order to compile with older compilers the variable SPIRIT_ROOT has to be defined and point to the root where spirit is installed. So the build jamfile would have to be modified so that that the modules for XML are build if and only if: a) If the compiler is an older compiler b) && SPIRIT_ROOT is defined to something not null c) || the compiler is a newer compiler. I think the build jamfile could altered to do this. I spent a little time at it but didn't immediately see how to do it. But I think it should be possible. Its probably trivial for a BJAM guru - so feel free anyone. Also it would be nice if it echoed a comment indicating that its skipping the XML components for lack of SPIRIT_ROOT. >BTW, your library is great and you should never feel that because you don't >hear from others about it that this indicates a lack of interest in users. >What it often indicates is that the library is working so flawlessly for >99.99% of its needs that users are content and do not need to send you any >reports about problems or errors. >From my vantage point it has become so large and intricate after accommodating all the "requirements" including features and portability that it's really hard for me to believe that it actually works all that well. Oh well. Robert Ramey

2 1

typeof: type registration
by Arkadiy Vertleyb 23 Jul '04

23 Jul '04

Hello everybody, Recently there was a discussion about a typeof emulation library. The library determines the type of an expression by passing it to a function template, encoding the type as a list of integers, "returning" them one-by-one via sizeof(), and decoding the type. One of the main problems of any such emulation is the need to associate types and templates with unique compile-time integral identifiers. This becomes even bigger problem, when expressions can contain types/templates from different libraries. It's not quite clear how to ensure uniqueness of identifiers in this case (GUID would be an option, but it's far too big to fit into an integer). An attempt was made to generate the identifiers automatically. However, since mechanisms to achieve this always work inside only one compilation unit, there is no way to preserve the same identifiers for the same entities throughout different compilation units. Hence, inevitably, we run into the ODR violation. An attempt to work this around by defining stuff in anonimous namespace, forces everything that uses this facility to also be defined in the anonimous namespace or, again, the ODR is violated. Although compilers don't seem to care much about ODR in this particular case (meta-functions only, no runtime constructs), somehow I feel uneasy to proceed with the solution that does not quite comply to the standard. And so, once again, I tried to come-up with a registration scheme that, on the one hand, would not violate the ODR, and on the other hand, would not put a significant burden on the end user -- the crutial condition for this library to be of any use at all. Here is this scheme: The typeof library registers primitive types, as well as some other standard stuff, like functions, pointers, references, arrays, consts, etc. If the user only wants any combination of those, no additional actions is required, such as the following type: int& (*)(char[20], double&) would be handled. If, in addition to this, the user wants to handle types from other libraries, such as Spirit, Lambda, etc., it works as following: - The typeof library #defines a preprocessor constant, currently called BOOST_TYPEOF_USER_GROUP, which is the next identifier after the last one it actually used. - The Spirit library registers its types against some symbolic identifiers. Only one per file is required (inside the same file __LINE__ does the job). Something looking similarly to the include guard seems like a decent choice. In addition, Spirit defines a separate header where it enumerates all these symbolic identifiers. This header looks something like this: <boost/spirit/groups.hpp> #ifndef SPIRIT_GROUPS_HPP_INCLUDED #define SPIRIT_GROUPS_HPP_INCLUDED #include <boost/spirit/typeof/typeof.hpp> enum { SPIRIT_REGISTER_HPP = BOOST_TYPEOF_USER_GROUP, SPIRIT_LAST }; #undef BOOST_TYPEOF_USER_GROUP #define BOOST_TYPEOF_USER_GROUP SPIRIT_LAST #endif//SPIRIT_GROUPS_HPP_INCLUDED IOW, the Spirit identifiers start where the typeof library identifiers ended, and BOOST_TYPEOF_USER_GROUP is, again, the next available. - The Lambda library does the same, etc. - The user combines all the groups in a single include, effectively chaining the enums: #ifndef GROUPS_HPP_INCLUDED #define GROUPS_HPP_INCLUDED #include <boost/spirit/groups.hpp> #include <boost/lambda/groups.hpp> #endif//GROUPS_HPP_INCLUDED - The user includes this file before any registration file provided by these libraries. Since the file contains only enums, the compile-time penalty is minimal. This insures that identifiers remain fixed across compilation units. - Whenever the user needs to register her own classes, she provides identifiers by any means she prefers, such as enum, etc., starting from BOOST_TYPEOF_USER_GROUP. See http://groups.yahoo.com/group/boost/files/typeof.zip (or Spirit repository, TYPEOF_DEV branch) for how it all works together. I appologize for such a long post (if you are still here :) ) Any comments? Regards, Arkadiy

5 15

[thread] scoped_unlock
by Russell Hind 23 Jul '04

23 Jul '04

I think it was discussed ages ago on these lists (but can't find the messages now, probably when Bill was still around) about adding scoped_unlock classes to complement scoped_lock classes? Are there still plans to add these? My current use is nothing more than unlock in the constructor, and lock again in the destructor. Thanks Russell

1 0

I build regex with stlport , but have some problem
by 猛许 23 Jul '04

23 Jul '04

I build the regex libs with vc7.1-stlport. Then I test it: #include <boost/regex.hpp> int _tmain(int argc, _TCHAR* argv[]) { boost::regex ex; return 0; } but link error: test1.obj : error LNK2019: unresolved external symbol "public: __thiscall boost::reg_expression<char,class boost::regex_traits<char>,class _STL::allocator<char> >::reg_expression<char,class boost::regex_traits<char>,class _STL::allocator<char> >(class _STL::allocator<char> const &)" (??0?$reg_expression@DV?$regex_traits@D@boost@@V?$allocator@D@_STL@@@boost@@ QAE@ABV?$allocator@D@_STL@@@Z) referenced in function "public: __thiscall boost::basic_regex<char,class boost::regex_traits<char>,class _STL::allocator<char> >::basic_regex<char,class boost::regex_traits<char>,class _STL::allocator<char> >(class _STL::allocator<char> const &)" (??0?$basic_regex@DV?$regex_traits@D@boost@@V?$allocator@D@_STL@@@boost@@QAE @ABV?$allocator@D@_STL@@@Z) test1.obj : error LNK2019: unresolved external symbol "public: __thiscall boost::reg_expression<char,class boost::regex_traits<char>,class _STL::allocator<char> >::~reg_expression<char,class boost::regex_traits<char>,class _STL::allocator<char> >(void)" (??1?$reg_expression@DV?$regex_traits@D@boost@@V?$allocator@D@_STL@@@boost@@ QAE@XZ) referenced in function "public: __thiscall boost::basic_regex<char,class boost::regex_traits<char>,class _STL::allocator<char> >::~basic_regex<char,class boost::regex_traits<char>,class _STL::allocator<char> >(void)" (??1?$basic_regex@DV?$regex_traits@D@boost@@V?$allocator@D@_STL@@@boost@@QAE @XZ) how to solve it? thanks. _________________________________________________________________ 与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn

2 1

A nitpick about newly generated Linux tests
by Joaquín Mª López Muñoz 23 Jul '04

23 Jul '04

Linux tests, as generated Friday 23 July 2004 09:28:26 UTC http://boost.sourceforge.net/regression-logs/cs-Linux.html show a huge amount of warnings everywhere for GCC tests (for every successful pass, actually.) I guess the problem is that the compiler emits the date of compilation and this is is interpreted by the test engine as a warning. Probably this new behavior is due to some GCC configuration parameter? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

MinGW 3.2.3 regression test
by Rob Lievaart 23 Jul '04

23 Jul '04

Hi All, In a couple of hours I am going on holiday for week, and i have not had the time to fully automate the test setup, so I am afraid that next week, there will be no fresh reports. I am going to try to get my colleagues to run the script a few times, but I don't know if it will work. :-( While on the subject of automating, two of the tests near the end generate a popup dialog about a division by zero error, that requires interaction. I haven't had the time to look into it yet, but is this something with win32, or with mingw, or my local setup? Kind regards, Rob Lievaart.

2 1

boost::thread TLS atexitthread DLL et.al.
by Roland 23 Jul '04

23 Jul '04

After having been off the list for a while now, because of other things to do, I'd like to share some thought about the still not solved question of TLS on Windows. As far as I remember the original author of the thread library (Bill Kempf) intended the thread local storage to be usable in an orthogonal way to boost::threads, i.e. TLS should be cleaned up even when used in the context of native threads. He came up with a solution of using a DLL to catch the very last breath of the thread. (I proposed a "piggy pack" DLL that can be embedded in the main executable, to get rid of the need to separately distribute a DLL file.) Now while rethinking the thing I have serious reservations about the DLL solution: The exit and cleanup is getting called AFTER the C-runtime library has been de-initialized for the thread. Is it save then to call any of the library functions in the yet "zombied" thread? May I even call free or delete on objects that have been created in context of the thread? Extending this question to threads that have been created by other means (including boost::thread) this means the exit handler must not access any features that have been in control of the thread mechanism. For me this means either to drop the (desirable) requirement of orthogonality and require the thread beeing created and managed by boost when using TLS, or force the user to obey strict rules about what she is allowed to do in an exit handler (destructor in turn of an object). To me the latter seems less appealing than the first. Yet another idea would be to require at least the availability of the C-library at destruction time, but require that the destructor must not access any thread specific (i.e. boost thread) data. Someone in this list has pointed out the existence of a TLS destructor list in the PE header of executables. I have digged into this a little. While current compilers do not yet make use of this field it still would not answer all questions. (Perhaps that is the reason why they are not currently supporting it?) However this destructor list would need to be called by whichever library has created global objects. (Normally this is the C/C++ runtime stub.) It definitely cannot be the resonsibility of the operating system to call this list (at least in my opinion). Wrapping it up: Having the C/C++ runtime available at thread exit seems desirable to me. Calling the exithandler from the DLL (THREAD_DETACH) is too late. Calling the exit handler from within _endthread seems desirable (and can be reasonably expected to be supported by compilers one time.) Fortunately there is a chance to trick the _endthread to call arbitrary exit functions by making use of the fp-init/deinit hook. I will try to provide example code, but also post this at the same time to get your thoughts about this. Roland

1 0

performance: pool cleanup takes too long
by AviadR 23 Jul '04

23 Jul '04

hi, In my project I use boost::pool because I have to instantiate millions of object at the beginning of the application, and only get rid of the at termination time. I noticed that when processing large data (which may require 1Gb memory for the application while it is running) the application may finish its processing approx after 10 seconds. the cleanup part (which consists only of calling the pool release methods on allocated objects) on the other hand, takes many minutes (I usually give up after 5 minutes) debugging the code i noticed that the while loop in the nextof function (of SIMPLE SEGREGATED STORAGE.HPP) takes many iterations. this leads me to the belief that the reason the cleanup takes too long is because trying to cleanup 1GB memory of million of objects at once causes pool to retain all its chunks in the hope of more allocations in the future which in turns causes it to waste all computation on running to the end of (endless) lists in the nextof function I will appreciate a suggestion on how to fix this until a more permanent solution is applied to the pool library thanks aviad aviadr(a)pob.huji.ac.il

2 1

Re:Re: [boost] [Boost.Test] bug
by Robert Ramey 23 Jul '04

23 Jul '04

>>>There's boost/compatibility/cpp_c_headers/cwctype and >>>boost/compatibility/cpp_c_headers/cctype. Can we use those >>>instead and be assured of portability? Everyone seems to be >>>reinventing workarounds for these nasty little beasts. > >> I was under impression that we should only use these headers where there >are >> no native headers with appropriate name. Isn't it true? >Not sure. It says in the documentation: ><http://www.boost.org/libs/compatibility/index.html> Joel de Guzman wrote: >I think it is the right place for a common workaround to such problems. >We too had the same problem as you had and had to write some similar >compatibility workarounds. Other libraries also provide some sort of >workaround (e.g. <http://www.boost.org/boost/regex/config/cwchar.hpp>). >I think it would be best to have a single place to put them. I had used these headers for this purpose. Then I came to a point where one of them wasn't appropriate so I wanted it changed. Then I was told it couldn't be done be cause they were automatically generated. I was told they weren't designed to be used for this purpose. So I had to use the current method. I asked a couple of times what good they were for and it was explained to me a couple of times but I never did understand the explanation so I just moved on. Robert Ramey

1 0

Re:[boost] Re: Re:Re: Re:Re: additional boost libraries?
by Robert Ramey 23 Jul '04

23 Jul '04

Jonathan Turkanis wrote: >"Edward Diener" <eddielee(a)tropicsoft.com> wrote in message >news:cdq036$1m7$1@sea.gmane.org... >> BTW, your library is great and you should never feel that because >>you don't >> hear from others about it that this indicates a lack of interest in >users. >Lack of interest??? Soemtimes it seems that the boost developers list >is really the boost serialization list. ;-) Hmmm I was just thinking the same thing re mutex/threading. I guess it's a question of vantage point. Now 18 months ago - that's when the topic was hot. I probably consumed a couple of trees worth of energy just to power the related email. Robert Ramey

1 0

typeof: type registration
by Vertleyb 23 Jul '04

23 Jul '04

Hello everybody, Recently there was a discussion about a typeof emulation library. The library determines the type of an expression by passing it to a function template, encoding the type as a list of integers, "returning" them one-by-one via sizeof(), and decoding the type. One of the main problems of any such emulation is the need to associate types and templates with unique compile-time integral identifiers. This becomes even bigger problem, when expressions can contain types/templates from different libraries. It's not quite clear how to ensure uniqueness of identifiers in this case (GUID would be an option, but it's far too big to fit into an integer). An attempt was made to generate the identifiers automatically. However, since mechanisms to achieve this always work inside only one compilation unit, there is no way to preserve the same identifiers for the same entities throughout different compilation units. Hence, inevitably, we run into the ODR violation. An attempt to work this around by defining stuff in anonimous namespace, forces everything that uses this facility to also be defined in the anonimous namespace or, again, the ODR is violated. Although compilers don't seem to care much about ODR in this particular case (meta-functions only, no runtime constructs), somehow I feel uneasy to proceed with the solution that does not quite comply to the standard. And so, once again, I tried to come-up with a registration scheme that, on the one hand, would not violate the ODR, and on the other hand, would not put a significant burden on the end user -- the crutial condition for this library to be of any use at all. Here is this scheme: The typeof library registers primitive types, as well as some other standard stuff, like functions, pointers, references, arrays, consts, etc. If the user only wants any combination of those, no additional actions is required, such as the following type: int& (*)(char[20], double&) would be handled. If, in addition to this, the user wants to handle types from other libraries, such as Spirit, Lambda, etc., it works as following: - The typeof library #defines a preprocessor constant, currently called BOOST_TYPEOF_USER_GROUP, which is the next identifier after the last one it actually used. - The Spirit library registers its types against some symbolic identifiers. Only one per file is required (inside the same file __LINE__ does the job). Something looking similarly to the include guard seems like a decent choice. In addition, Spirit defines a separate header where it enumerates all these symbolic identifiers. This header looks something like this: <boost/spirit/groups.hpp> #ifndef SPIRIT_GROUPS_HPP_INCLUDED #define SPIRIT_GROUPS_HPP_INCLUDED #include <boost/spirit/typeof/typeof.hpp> enum { SPIRIT_REGISTER_HPP = BOOST_TYPEOF_USER_GROUP, SPIRIT_LAST }; #undef BOOST_TYPEOF_USER_GROUP #define BOOST_TYPEOF_USER_GROUP SPIRIT_LAST #endif//SPIRIT_GROUPS_HPP_INCLUDED IOW, the Spirit identifiers start where the typeof library identifiers ended, and BOOST_TYPEOF_USER_GROUP is, again, the next available. - The Lambda library does the same, etc. - The user combines all the groups in a single include, effectively chaining the enums: #ifndef GROUPS_HPP_INCLUDED #define GROUPS_HPP_INCLUDED #include <boost/spirit/groups.hpp> #include <boost/lambda/groups.hpp> #endif//GROUPS_HPP_INCLUDED - The user includes this file before any registration file provided by these libraries. Since the file contains only enums, the compile-time penalty is minimal. This insures that identifiers remain fixed across compilation units. - Whenever the user needs to register her own classes, she provides identifiers by any means she prefers, such as enum, etc., starting from BOOST_TYPEOF_USER_GROUP. See http://groups.yahoo.com/group/boost/files/typeof.zip (or Spirit repository, TYPEOF_DEV branch) for how it all works together. I appologize for such a long post (if you are still here :) ) Any comments? Regards, Arkadiy

2 1

[Boost-bugs] [ boost-Support Requests-996331 ] with constructor not allowed in union
by SourceForge.net 23 Jul '04

23 Jul '04

Support Requests item #996331, was opened at 2004-07-22 21:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=996331&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: with constructor not allowed in union Initial Comment: I get error - with '..' constructor not allowed in union, when I compile the following code in gcc. Any method for overcoming this kind of problem. The code is like this. Struct X { union ut1 { struct st1 { int i1; long l1; } s1; struct st2 { char c1; double d1; } s2; X() {} // g++ gives error if constructor is present. }; Struct Y { int i; union ut3 { X x; // member 'X Y::ut3::x' with constructor // not allowed in union. int i1; } u3; Y () { i = 0; } }; int main() { Y y; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=996331&group_i… ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

RE: [boost] [Boost.Test] bug
by Rozental, Gennadiy 23 Jul '04

23 Jul '04

> There's boost/compatibility/cpp_c_headers/cwctype and > boost/compatibility/cpp_c_headers/cctype. Can we use those > instead and be assured of portability? Everyone seems to be > reinventing workarounds for these nasty little beasts. I was under impression that we should only use these headers where there are no native headers with appropriate name. Isn't it true? Gennadiy.

2 1

Re:[boost] Re: Re:Re: additional boost libraries?
by Robert Ramey 23 Jul '04

23 Jul '04

Edward Diener wrote: >> Note that the serialization library relies upon Spirit 100 % for XML >> parsing. >Regarding your problems using an older version of Spirit with lesser >compilers, would it make sense to split the serialization library so that >those who never use XML parsing wouldn't need to have a correct version of >Spirit for their compiler ? As it is now the "correct" version of spirit is already part of the boost distribution if you're using a newer compiler. If you want to use an older compiler you'll have to get and "older" version of spirit. If you don't want to take the 15 minutes to do this, you can build with an older compiler and without spirit at all, you could easily modify the jamfile. Spirit is only used in the building of the library. It is not imported at all into programs that just use the serialization library. If one want's to build a library without spirit - all tests will compile - the xml ones would fail to link. I believe that the current setup and the method for addressing less frequently occurring situations is very convenient and practical. Robert Ramey

3 2

Identifying a compiler's version in a Jamfile
by Bart Garst 23 Jul '04

23 Jul '04

Is it possible to differentiate between compiler versions in a Jamfile? What I want to do is run our serialization tests (date_time) with gcc but only version 3 and up. Anyone know how to do this? Thanks, Bart Garst

4 5

RE: [boost] Re: Lock unification [move]
by Batov, Vladimir 23 Jul '04

23 Jul '04

> Batov, Vladimir wrote: > > > How 'bout > > > > scoped_lock lk1(m, defer); > > scoped_lock lk2(m, try); > > > > "try" is a keyword, last I checked. ;-) [Batov, Vladimir] Oh, my goodness. Of course, it is. LOL. Looks like I have not woken up yet. Then, I guess, I am leaning towards Howard's original scoped_lock lk1(m, defer_lock); scoped_lock lk2(m, try_lock); Minor repetition issue aside, it looks like the clearest, simplest and most consistent choice.

1 0

RE: [boost] Re: Lock unification [move]
by Glen Knowles 22 Jul '04

22 Jul '04

> From: Howard Hinnant [mailto:hinnant@twcny.rr.com] > > I mostly agree with Bronek Kozicki. Given a movable lock, Eric > > Niebler's > > proposal: > > > > scoped_lock try_lock( Mutex & m ); > > scoped_lock timed_lock( Mutex & m ); > > > > is a better try/timed interface. Heisenberg constructors must die. > > Sorry, I don't know what a Heisenberg constructor is. It's a reference to the Heisenberg uncertainty principle. Constructors that sometimes act one way and sometimes another must die. ;) > From: David Abrahams [mailto:dave@boost-consulting.com] > Howard Hinnant <hinnant(a)twcny.rr.com> writes: > > > scoped_lock lk1(m, defer_lock); // not locked > ^^^^ ^^^^ > Redundant. "deferred" is better. If you named it not_locked you wouldn't need the comment. ;) Of these three choices: 1. try, deferred 2. try_lock, deferred 3. try_lock, defer_lock I tend to like #3 the best. Glen

3 2

status/explicit-failures-markup.xml broken
by Martin Wille 22 Jul '04

22 Jul '04

Hi, someone broke status/explicit-failures-markup.xml, apparently. I'm getting these error messages from xsltproc: /boost/head-regression/boost/status/explicit-failures-markup.xml:594: parser error : Opening and ending tag mismatch: ostream line 594 and note <note>Interval IO require <ostream> header.</note> ^ /boost/head-regression/boost/status/explicit-failures-markup.xml:595: parser error : Opening and ending tag mismatch: note line 594 and mark-failure </mark-failure> ^ /boost/head-regression/boost/status/explicit-failures-markup.xml:596: parser error : Opening and ending tag mismatch: mark-failure line 591 and test </test> ^ /boost/head-regression/boost/status/explicit-failures-markup.xml:597: parser error : Opening and ending tag mismatch: test line 584 and library </library> ^ /boost/head-regression/boost/status/explicit-failures-markup.xml:1159: parser error : Opening and ending tag mismatch: library line 570 and explicit-failures-markup </explicit-failures-markup> ^ /boost/head-regression/boost/status/explicit-failures-markup.xml:1161: parser error : Premature end of data in tag explicit-failures-markup line 1 Please, make sure to quote '<' and '>' correctly in XML files. Regards, m

2 1

Re: [boost] [minmax] failure in GCC 3.4.1
by JOAQUIN LOPEZ MU?Z 22 Jul '04

22 Jul '04

----- Mensaje original ----- De: Hervé Brönnimann <hbr(a)poly.edu> Fecha: Jueves, Julio 22, 2004 8:43 pm Asunto: Re: [boost] [minmax] failure in GCC 3.4.1 > > On Jul 22, 2004, at 2:56 AM, Joaquín Mª López Muñoz wrote: > > 107c107 > > < RCIterator rfirst(last), rlast(first), rmin(min), rmax(max); > > --- > >> RCIterator rfirst(last), rlast(first), rmin, rmax; > > Joaquin: I thought I committed that patch yesterday. If not, my > mistake, you can go ahead. I always "cvs update" before committing > so I > will see it. You did commit that patch. The other three patches we were taking about some hours ago are also commited, so in principle minmax could now work for every compiler in Linux and Win32 tests. The current Linux cycle is broken, so we will have to wait until tomorrow to know. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[minmax] failure in GCC 3.4.1
by Joaquín Mª López Muñoz 22 Jul '04

22 Jul '04

GCC 3.4.1 complains with this absolutely clear run-time message (http://tinyurl.com/42bey) error: attempt to copy-construct an iterator from a singular iterator I've inspected the code of minmax_element_test.cpp and think the problem lies in lines 106-107: CIterator min, max; RCIterator rfirst(last), rlast(first), rmin(min), rmax(max); where rmin and rmax are copy-constructed from min,max, which are singular. Anyone sees a problem in fixing this? (Please find diff below.) I don't have GCC 3.4.1 available, so I can only guess this will clear the problem away. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 107c107 < RCIterator rfirst(last), rlast(first), rmin(min), rmax(max); --- > RCIterator rfirst(last), rlast(first), rmin, rmax;

2 1

RE: [boost] Re: counting_iterator_test.hpp fails on aC++
by DY, JERRY U (SBCSI) 22 Jul '04

22 Jul '04

The problem is that since my_int2 is not a random access iterator, class iterator_adaptor's member function "advance" would not compile because of the static assertion below trying to convert random_access_traversal_tag to bidirectional_traversal_tag (my_traversal). FILE: boost/iterator/iterator_adaptor.hpp:310 void advance(typename super_t::difference_type n) { // precompiled to: // typedef int assertion[sizeof(detail::static_assert_convertible_to<random_access_trav ersal_tag>(my_traversal()))]; BOOST_ITERATOR_ADAPTOR_ASSERT_TRAVERSAL(random_access_traversal_tag) m_iterator += n; } -Jerry -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams Sent: Thursday, July 22, 2004 7:20 AM To: boost(a)lists.boost.org Subject: [boost] Re: counting_iterator_test.hpp fails on aC++ "DY, JERRY U $SBCSI$" <jd2419(a)sbc.com> writes: > Sorry... sent the original e-mail too quickly. Here's why I say that > std::numeric_limits has to be specialized and the is_specialized member > must be set to true if you want a particular type to pass the is_numeric > test. But we don't want my_int2 to pass the is_numeric test. What's the problem? If counting_iterator_test.cpp fails there must be another reason.

2 1

Re:[boost] Re: Re:typeof: type registration
by Robert Ramey 22 Jul '04

22 Jul '04

Arkadiy Vertleyb wrote: >"Robert Ramey" <ramey(a)rrsd.com> wrote >> I'm just taken a cursory look at this scheme. But it likes it might be >> similar or even identical to that implemented by the serialization library >> to recover types for serialized pointers. See extended_type_info. >Most importantly, does this scheme really work in practice? Is it easy >enough for end users, and does it allow users and libraries to avoid >collisions with each other? Oh it works - its being subject to the boost torture test process as we speak. The issue of unique type identification was addressed at length during the first serialization review. If the typeid is only used within a program runtime type_info can be used. The system doesn't require type_info to be used but that's usually the most convenient - unless your compiler doesn't support runtime typing. If its to be passed from one executable to another - persistence and/or marshalling - you have to export it with some sort of key. I usually use the class name. Its all in there and even explained in the context of its usage within the serialization package. There is also a facility referred to a void_cast which is used to correctly cast from one type to another at runtime. That's the short version - you might want to check out the manual and the code. It could easily be excised from the serialization library. I only did it because I had to have it and I couldn't find anything else out there. Honestly, I'm not even sure it addresses the same issue that you do. Feel free to check it out. Robert Ramey

1 0

Re:Re: [boost] question re linux serialization test results
by Robert Ramey 22 Jul '04

22 Jul '04

Jonathan Wakely wrote: On Wed, Jul 21, 2004 at 04:29:23PM -0700, Robert Ramey wrote: >> http://boost.sourceforge.net/regression-logs/cs-Linux.html shows >> errors in build of the serialization libraries related to pthreads, >etc.... >This is a known (*) issue with GCC 3.4, you must explicitly define >BOOST_DISABLE_THREADS if you are not going to link with -pthread. Hmm - isn't this something that could/should be automatically handled by the bjam - gcc toolset file? I'm not really sure what I should do here. Things worked before but I suspect that this was because I had static-linking specified as the default - but I removed this to address some other confusion and relied on the default set "somewhere else" I'm not at all sure what I should do here. I think it is also affecting builds with Itel 7.1 on linux. Robert Ramey

2 1

question re linux serialization test results
by Robert Ramey 22 Jul '04

22 Jul '04

http://boost.sourceforge.net/regression-logs/cs-Linux.html shows errors in build of the serialization libraries related to pthreads, etc.... I suspect this is a build issue of some sort. When this first occurred I tweaked the jamfile. I suspect there might be some stale *.o files. Thanks for looking into this whoever you are. Robert Ramey

5 8

RE: [boost] Re: What is it with boost and tinyurl?
by Max Khesin 22 Jul '04

22 Jul '04

> -----Original Message----- > From: Rob Stewart [mailto:stewart@sig.com] > If you were aware that foo.com/~mark became mark.com, you could > make the translation having the other information in the original > URL. And how often are you aware of foo.com/~mark becoming mark.com? m This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

2 1

Re:[boost] typeof: type registration
by Robert Ramey 22 Jul '04

22 Jul '04

Arkadiy Vertleyb wrote: <big snip> >Any comments? I'm just taken a cursory look at this scheme. But it likes it might be similar or even identical to that implemented by the serialization library to recover types for serialized pointers. See extended_type_info. Robert Ramey

2 1

Latest Boost.Threads regression results on intel-8.0-linux
by Michael Glassford 22 Jul '04

22 Jul '04

All of the Boost.Threads tests for intel-8.0-linux at http://boost.sourceforge.net/regression-logs/cs-Linux/developer/thread.html are failing, and the entire error report looks like: <quote> Compiler output: Linker output: Chmod1 ../bin/boost/libs/thread/test/test_barrier.test/intel-8.0-linux/debug/threading-multi/test_barrier Run output: EXIT STATUS: 139 </quote> Every test failing with the same error indicates a fundamental problem, but since I don't have access to the compiler or OS, I have no way of troubleshooting the problem. Any help would be appreciated. Mike

4 9

RE: counting_iterator_test.hpp fails on aC++
by DY, JERRY U (SBCSI) 22 Jul '04

22 Jul '04

Sorry... sent the original e-mail too quickly. Here's why I say that std::numeric_limits has to be specialized and the is_specialized member must be set to true if you want a particular type to pass the is_numeric test. template <class T> struct is_numeric_impl { typedef ::boost::static_assert_test< sizeof(::boost::STATIC_ASSERTION_FAILURE< (bool)( ::boost::is_integral<char>::value ) >) > boost_static_assert_typedef_33 ; static const bool value = std::numeric_limits<T>::is_specialized ; }; template <> class std::numeric_limits<my_int2> { public: static bool const is_specialized = true; }; -Jerry -----Original Message----- From: DY, JERRY U (SBCSI) Sent: Wednesday, July 21, 2004 4:08 PM To: boost(a)lists.boost.org Subject: counting_iterator_test.hpp fails on aC++ I'm troubleshooting counting_iterator_test.hpp. In particular: FILE: counting_iterator_test.cpp class my_int2 { public: ... typedef std::bidirectional_iterator_tag iterator_category; }; FILE: counting_iterator.hpp template <class Incrementable, class CategoryOrTraversal, class Difference> struct counting_iterator_base { typedef typename detail::ia_dflt_help< CategoryOrTraversal , mpl::apply_if< is_numeric<Incrementable> , mpl::identity<random_access_traversal_tag> , iterator_traversal<Incrementable> > >::type traversal; ... } The class my_int2 is passed as parameter "Incrementable" to counting_iterator_base, but is failing the is_numeric test so my_int2 is just a bidirectional iterator (see mpl::apply_if above). If it passes the is_numeric test, then it's a random access traversal tag. The way it passes the is_numeric test is to specialize std::numeric_limits like so: template <> class std::numeric_limits<my_int2> { public: static bool const is_specialized = false; }; But I don't find that in the source. It appears that aC++ doing the right thing, but I know I'm wrong. Could somebody please help?? Thanks! -Jerry

2 1

Boost.Threads metacomm regression tests not working
by Michael Glassford 22 Jul '04

22 Jul '04

I've been mentioning this problem on the "Boost.Test problem" / "Boost.Threads problem" / "Boost.Threads status?" thread, but have been getting no help, so I thought I'd try a new thread. All of the Boost.Threads regression tests are failing due to an error like this: <quote> Cannot open include file: 'boost/thread/detail/config.hpp': No such file or directory </quote> The "missing" file is in cvs, and has been for a long time. Looking at the compiler command line, I see that the it contains -I"C:\Users\Administrator\boost\main\results\bin\boost\libs\thread\build" and no other directory; looking at the command line for other Boost libraries, I see that they also contain -I"C:\Users\Administrator\boost\main\boost". What do I need to do to get Boost.Threads to build with -I"C:\Users\Administrator\boost\main\boost"? Is it a problem with the Boost.Threads bjam file? A configuration problem with the regression tests? Something else? Mike

6 13

rwlocks in boost::thread
by Aleksander Demko 22 Jul '04

22 Jul '04

Does boost::thread provide a rwlock primitive? I can't seem to find it. If not, is it because it's not a true primitive? or because not all OSes have this concept in their native APIs? -- // scopira.org | ninjacoder.com //

2 2

[minmax] fixes to support MSVC
by Joaquín Mª López Muñoz 22 Jul '04

22 Jul '04

The following patches make the two tests of Boost.Minmax pass for MSVC 6.5: 1. minmax.hpp: 28a29 > #include <boost/ref.hpp> There were some usages of boost::ref without including its header. I think this patch is necessary for every copmiler, not only MSVC. 2. minmax_test.hpp: 52,53c52,53 < BOOST_CHECK_EQUAL( result1.get<0>(), zero ); < BOOST_CHECK_EQUAL( result1.get<1>(), one ); --- > BOOST_CHECK_EQUAL( get<0>(result1), zero ); > BOOST_CHECK_EQUAL( get<1>(result1), one ); 56,57c56,57 < BOOST_CHECK_EQUAL( result2.get<0>(), zero ); < BOOST_CHECK_EQUAL( result2.get<1>(), one ); --- > BOOST_CHECK_EQUAL( get<0>(result2), zero ); > BOOST_CHECK_EQUAL( get<1>(result2), one ); 62,63c62,63 < BOOST_CHECK_EQUAL( result3.get<0>(), zero ); < BOOST_CHECK_EQUAL( result3.get<1>(), one ); --- > BOOST_CHECK_EQUAL( get<0>(result3), zero ); > BOOST_CHECK_EQUAL( get<1>(result3), one ); 68,69c68,69 < BOOST_CHECK_EQUAL( result4.get<0>(), zero ); < BOOST_CHECK_EQUAL( result4.get<1>(), one ); --- > BOOST_CHECK_EQUAL( get<0>(result4), zero ); > BOOST_CHECK_EQUAL( get<1>(result4), one ); In MSVC 6.0 and later Boost.Tuple does not provide the get<>() member function, so we have to resort to the global get function. I don't think this does any harm to any other compiler. 3. minmax_element_test.hpp 0a1 > #include <boost/config.hpp> /* prevents some nasty warns in MSVC */ 35a37,38 > > BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION(custom) The first include activates pragmas in MSVC that help avoid some nasty and harmless warnings. As for the second change, the error messages clearly indicate that this macro be used. This is what I've done, and the now test compiles and runs like breeze. With these three changes, all failures for MSVC 6.5 are solved. OK to commit? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 28a29 > #include <boost/ref.hpp> 52,53c52,53 < BOOST_CHECK_EQUAL( result1.get<0>(), zero ); < BOOST_CHECK_EQUAL( result1.get<1>(), one ); --- > BOOST_CHECK_EQUAL( get<0>(result1), zero ); > BOOST_CHECK_EQUAL( get<1>(result1), one ); 56,57c56,57 < BOOST_CHECK_EQUAL( result2.get<0>(), zero ); < BOOST_CHECK_EQUAL( result2.get<1>(), one ); --- > BOOST_CHECK_EQUAL( get<0>(result2), zero ); > BOOST_CHECK_EQUAL( get<1>(result2), one ); 62,63c62,63 < BOOST_CHECK_EQUAL( result3.get<0>(), zero ); < BOOST_CHECK_EQUAL( result3.get<1>(), one ); --- > BOOST_CHECK_EQUAL( get<0>(result3), zero ); > BOOST_CHECK_EQUAL( get<1>(result3), one ); 68,69c68,69 < BOOST_CHECK_EQUAL( result4.get<0>(), zero ); < BOOST_CHECK_EQUAL( result4.get<1>(), one ); --- > BOOST_CHECK_EQUAL( get<0>(result4), zero ); > BOOST_CHECK_EQUAL( get<1>(result4), one ); 0a1 > #include <boost/config.hpp> /* prevents some nasty warns in MSVC */ 35a37,38 > > BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION(custom)

2 1

RE: [boost] Re: Lock unification [move]
by Batov, Vladimir 22 Jul '04

22 Jul '04

Does it have to be in 'std'? Cannot that be under 'scoped_lock'? Do not have the docs handy. Won't lookup mechanism pick it up? > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Howard Hinnant > Sent: Thursday, 22 July 2004 10:31 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: Lock unification [move] > > On Jul 21, 2004, at 7:16 PM, David Abrahams wrote: > > > Howard Hinnant <hinnant(a)twcny.rr.com> writes: > > > >> <nod> How's: > >> > >> scoped_lock lk1(m, defer_lock); // not locked > > ^^^^ ^^^^ > > > > Redundant. "deferred" is better. > > I seriously thought about deferred. The word, whatever it is, if > standardized, would be at namespace scope in namespace std. I was > worried about it conflicting, or with its use not being easily > associated with locks if it was just "deferred". Otoh, it is only a > tag. Maybe it is a feature, not a bug for "deferred" to be able to > influence (conflict with) things other than locks! Thanks for the > second thought. > > -Howard > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

RE: [boost] Re: Lock unification [move]
by Batov, Vladimir 22 Jul '04

22 Jul '04

Howard, Thank you for taking on the task of shaping up the interface. That activity is of great importance. A few comments. explicit scoped_lock(mutex_type& m); scoped_lock(mutex_type& m, detail::defer_lock_type); scoped_lock(mutex_type& m, detail::try_lock_type); scoped_lock(mutex_type& m, const elapsed_time& elps_time); The problem (as I can see it) with the set above is that "deferred", "tried" and "timed" appear to be alternatives or mutually exclusive. However, "deferred" and, say, "try" functionalities are orthogonal. That is, as one might need to defer a blocking lock scoped_lock l(m, deferred); one might need a deferred try_lock as well. Therefore, as we are trying to provide one universal lock, it appears we have to have something complex like basic_lock(mutex_type&, const elapsed_time&, defer_type); that would address all the lock variability/configurability. Such a basic lock would not be for general consumption but rather the basis for something like: try_lock : private (?) basic_lock { ... try_lock(mutex_type& m, deferred d) : basic_lock(m, 0, d) {} } Best, V.

3 2

RE: [boost] Re: Boost.Test and mingw (Was: [1.32 release] Intel 8 .0/Mingw regression results)
by Rob Lievaart 22 Jul '04

22 Jul '04

Hi, > Fix is in cvs. Lets see what next regression test show. Thanks, Test is running again now with the fix, and so far no lines in bjam.log complaining about wcscmp. Rob.

1 0