- Boost - lists.boost.org

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