- Boost-users - lists.preview.boost.org

[boost-users][MPL] integral_c<long long,...>
by Cromwell Enage 19 Sep '04

19 Sep '04

The attached program fails to compile if BOOST_HAS_LONG_LONG is defined. The error is mainly about integral_rank<long long int> not having a static member named 'value'. Is integral_c not meant to be used with long long? Cromwell Enage __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail

2 2

Regex Libraries giving errors
by Corey M. Ellis 19 Sep '04

19 Sep '04

Hi, I am trying to use the regex library (regex_match in particular) I included "boost/regex.hpp". I get the following errors when compiling my code. g++ -W -Wall -Wpointer-arith -O3 -g -pipe -D_REENTRANT -DACE_HAS_AIO_CALLS -D_GNU_SOURCE -I/usr/local/ACE_wrappers -DACE_HAS_EXCEPTIONS -D__ACE_INLINE__ -I/usr/local/ACE_wrappers -I/usr/local/include -I/usr/local/include/boost-1_31 -DACE_NTRACE=1 -D__USE_REG_EXPR -c -o .obj/FTP_Task.o FTP_Task.cpp In file included from /usr/local/include/boost-1_31/boost/cregex.hpp:30, from /usr/local/include/boost-1_31/boost/regex/v4/regex.hpp:25, from /usr/local/include/boost-1_31/boost/regex.hpp:34, from FTP_Task.h:19, from FTP_Task.cpp:1: /usr/local/include/boost-1_31/boost/regex/v4/cregex.hpp:75: error: syntax error before numeric constant /usr/local/include/boost-1_31/boost/regex/v4/cregex.hpp:96: error: ISO C++ forbids declaration of `reg_comp_flags' with no type /usr/local/include/boost-1_31/boost/regex/v4/cregex.hpp:100: error: syntax error before numeric constant /usr/local/include/boost-1_31/boost/regex/v4/cregex.hpp:103: error: ISO C++ forbids declaration of `reg_exec_flags' with no type make[1]: *** [.obj/FTP_Task.o] Error 1 make[1]: Leaving directory `/home/bipuser/nBIP-9.0/src' make: *** [NBIP] Error 2 Can sme please shed some light on the problem. I am only using the regex_match function. I create an expression object, and use regex_match to match against it. Thanks in advance for any help. Corey

2 5

Re: [Boost-users] Regex Libraries giving errors
by corey.m.ellis＠comcast.net 19 Sep '04

19 Sep '04

Thanks for the quick response. Do you know of a workaround that is being used for version 1_31. All the examples say include "boost/regex.hpp". Is there some way I can include the headers so the problem will go away. What's really strange is that I compiled the entire library using the Jam method, and it I got these regex errors. I then compiled the regex libraries using the gcc make file, and use the static libraries when I compiled. It worked. But after I made some more code changes (not regex changes) to my application and recompiled, I started getting the errors again. I thought the gcc compilation fixed it, but it didn't. Anyway, if you could tell me a workaround that would be great. Is it just a matter of trying to include the regex.hpp header first before the regex.h header gets included, have other people seen this problem in the regex library? Corey -------------- Original message -------------- > > I am trying to use the regex library (regex_match in particular) > > I included "boost/regex.hpp". I get the following errors when compiling > > my code. > > > > Can sme please shed some light on the problem. I am only using the > > regex_match function. I create an expression object, and use regex_match > > to match against it. > > > > Thanks in advance for any help. > > I suspect that you are including the platforms (possibly > indirectly) before including . That currently causes > conflicts: there is a fix in the works, but it involves a complete > restructuring of Boost.Regex that won't be released until Boost-1.33 (that's > the release after next). > > John. > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

RE: [Boost-users] Boost problems
by Puverle, Tomas (IT) 18 Sep '04

18 Sep '04

> <snip> > Done, apologies for the delay, I didn't notice your message > first time around, I should have made the topic more obvious, like "Bug report: ... " or something. Would it have been better or made it easier for you if I had posted the original report to the boost developer forum? > Thanks for the bug report, > > John. Thank you very much John. Also, regarding the last issue mentioned in my original email (Boost.Build), should I cross post it to the Boost.Build forum? Thanks, Tom -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.

2 1

RE: [Boost-users] Re: Boost problems
by Puverle, Tomas (IT) 18 Sep '04

18 Sep '04

> That's been cleaned up in the latest CVS. Great! So that's 2 problems down, 2 to go. Do you think you could comment on the other 2 unresolved issues from my original email? (the defines in regex and Boost.build problem/feature request?) Thanks a lot. Tom -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.

2 1

Boost problems
by Tom Puverle 18 Sep '04

18 Sep '04

Hey boosters, We have found some problems with the following files: boost_1_31_0/libs/regex/src/cpp_regex_traits.cpp boost_1_31_0/libs/test/src/test_tools.cpp They use definitions from <ios> but never actually include it - they are relying on the fact that in some STLs the headers are pulled in by other header files. Unfortunately, under our STL (RW STL 6.0) this is not the case and hence the files fail to compile. Add the following include line to both to fix the problem: #include <ios> There is another STL related problem in boost_1_31_0/boost/regex/config/cwchar.hpp which manipulates some macros such as iswalnum etc. These are originally pulled in from <wctype.h> and <wchar.h> under /usr/include. With gcc, <cwctype> and <cwchar> undefine these macros as the first thing, however, our STL's headers don't. That leads to compilation errors from the above header. To fix this, add #undef iswalnum #undef iswalpha #undef iswblank #undef iswcntrl #undef iswdigit #undef iswgraph #undef iswlower #undef iswprint #undef iswprint #undef iswpunct #undef iswspace #undef iswupper #undef iswxdigit #undef iswctype #undef towlower #undef towupper #undef towctrans #undef wctrans #undef wctype when RW STL 6.0 is being used. The final problem is more of a feature request: In our environment, we build all shared objects with all external references unresolved, so that a .so A never depends on a shared library B. The symbols get only resolved once the final executable is linked. This causes us problems with boost when building the regression tests, as the final Jam link rule adds all additional libraries *before* the final libboost_*. That way, we end up with unresolved symbols to e.g. our STL. Is there any way in which this requirement could be incorporated into Boost.Build? I guess a simple solution would be to have another variable called e.g. ADDITIONAL_LIBS_LAST which would be passed as the last thing on linker line in the link rule. HW & SW details: OS: Red Hat Enterprise Linux 2.1 & 3.0 HW: various Compiler: gcc 3.2.3-20 STL: RogueWave 6.0 Boost: 1.31.0 Thanks, Tom _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

2 1

BOOST 1.32 soon?
by Daniel L Elliott 18 Sep '04

18 Sep '04

Hello, Will there be a BOOST 1.32 tagged soon? Thank you, to everyone, for this contribution! -- dan ******************* Dan Elliott *******************

4 7

Can boost::tokenizer tokenize 2byte character string?
by Lee, Joo-Young 18 Sep '04

18 Sep '04

Hi. I try to use 'boost::tokenizer<boost::char_separator<char> >' to separate 2byte character string like Korean, Japanese, or Chinese. But, I found that it does not works correctly. Is there a solution? Thanks for the help, Lee Joo-Young

1 0

Re: Newbie help in compiling boost
by Jeff Flinn 17 Sep '04

17 Sep '04

"David Abrahams" <dave(a)boost-consulting.com> wrote in message news:uzn3p2g31.fsf__38100.3229799264$1095428766$gmane$org@boost-consulting.com... > Murali Krishnan Ganapathy <gmkrishn(a)cs.uchicago.edu> writes: > > > When boost.jam tries to make a directory it tries to access %TEMP%. > > Machine complains that there is no "C;\DOCUME~1\...." (it is not > > checking the 8.3 version I guess) > > and the mkdir1 fails. Is the ';' here a typo, or is that what TEMP and TMP are really defined as? This is the 8.3 version, so I don't understand what your saying here. > > The work around is to have a simple %TEMP% and %TMP%. > > I reset %TEMP% and %TMP% to "C:\Temp" (no spaces and less than 8 > > chars), now boost is > > building as I write this. > > > > I guess this should be considered as a minor bug in bjam? > > Maybe so. Any Win/DOS experts out there who can suggest a correct > fix? NT, 2K and XP maintain "C:\Documents and Settings\<user-name>\Local Settings\Temp" directories for each user. Changing this to C:\Temp could cause problems for users w/out admin privileges. I've no problems with vc7.1 builds, and I imagine a lot of others utilize the same platform and can build as well. So it's not a general problem. The possible sources of this problem could be: - some odd access settings on the directory ( can even occur with admin privilege) - a lot of files in the temp directory from other misbehaving app's - environment variable definitions were mucked up by manual editing - generally mucking about with these dir's by the user can cause problems Jeff F

5 4

RE: [Boost-users] Boost problems
by Puverle, Tomas (IT) 17 Sep '04

17 Sep '04

On a similar note, I also noticed the following: iterator/detail/facade_iterator_category.hpp:# include <boost/python/detail/indirect_traits.hpp> iterator/indirect_iterator.hpp:#include <boost/python/detail/indirect_traits.hpp> It doesn't seem right that iterator should be including headers from python/detail. Tom -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.

2 1