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

lexical_cast<string> of type char
by DY, JERRY U (SBCSI) 01 May '04

01 May '04

I'm converting our code to use lexical_cast for converting between our numeric types to string. It worked mostly but was surprised to see what looked like graphic characters on my screen. It turns out that when we wanted to display the ascii value of a character, lexical_cast<string> doesn't work -- it doesn't treat the char as a numeric, which when we really think about it, makes a lot of sense. Casting the char to int solves the problem. But I was just wondering how the experts would handle this. char c = 65; string s1 = lexical_cast<string>(c) // s1 = "A" string s2 = lexical_cast<string>((int)c) // s2 = "65" Thanks! -Jerry

3 3

A BUG WITH THE BGL
by Hugues Joly 01 May '04

01 May '04

Hi, I have found a bug with the adjacency_list. It seems that there's a bug with the deletion of a vertex. See the attachment for a small program that triggers the problem. Thanks in advance. __________________________________________________________ Lèche-vitrine ou lèche-écran ? magasinage.yahoo.ca // test.cpp : Defines the entry point for the console application. // #include "stdafx.h" #include <boost/config.hpp> #include <iostream> #include <boost/graph/subgraph.hpp> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/graph_utility.hpp> int _tmain(int argc, _TCHAR* argv[]) { using namespace boost; //typedef adjacency_list_traits<vecS, vecS, directedS> Traits;// Does nothing? typedef boost::property<boost::vertex_color_t, int, boost::property< boost::vertex_name_t, std::string > > VertexProperty; typedef adjacency_list<vecS, vecS, directedS, VertexProperty, property<edge_index_t, int> > Graph; Graph G0; Graph::vertex_descriptor v_descr[4]; Graph::edge_descriptor e_descr[4]; for (int i = 0; i < 4; i++) { v_descr[i] = boost::add_vertex(G0); } for (int i = 0; i < 4; i++) { boost::remove_vertex(v_descr[i], G0); } return 0; }

2 1

string/wstring conversion using lexical_cast
by Tony Djordjevski 30 Apr '04

30 Apr '04

Hi, I'm using Boost 1.31.0 with VC++ 7.1 and I'm having some problems converting std::string to std::wstring and back. Here's the code that I'm trying to get to compile: std::wstring x = boost::lexical_cast<std::wstring>( std::string("this doesn't work")); std::string y = boost::lexical_cast<std::string>( std::wstring(L"neither does this")); The error I get for string to wstring: lexical_cast.hpp(150): error C2679: binary '>>' : no operator found which takes a right-hand operand of type 'std::wstring' (or there is no acceptable conversion) And the errors I get for wstring to string: lexical_cast.hpp(144): error C2679: binary '<<' : no operator found which takes a right-hand operand of type 'const std::basic_string<_Elem,_Traits,_Ax>' (or there is no acceptable conversion) with [ _Elem=wchar_t, _Traits=std::char_traits<wchar_t>, _Ax=std::allocator<wchar_t> ] lexical_cast.hpp(144): error C2228: left of '.fail' must have class/struct/union type Any ideas of what I'm doing wrong? Best Regards, Tony Djordjevski

2 1

RE: [Boost-users] Regex simple code can't compile on linux, but it can be built on windows VC6.
by Ben Hutchings 30 Apr '04

30 Apr '04

John Maddock <john(a)johnmaddock.co.uk> wrote: <snip> > The g++ linker is pretty brain-dead - the libraries have to appear > on the command line *after* the source files that use them. This is not brain-dead. It is useful to be able to control the order in which symbols are looked for since they may be defined in more than one library. It is a bit weird that -l is not placed before the file names as is the Unix convention for options, but it *isn't* an option - it is a shortcut for specifying a file in the library search path that follows the usual library name convention (lib<name>.a) and is exactly equivalent to specifying the full file name (AFAIK). Secondly, there is no g++ linker. g++ can use various Unix linkers though it is most commonly used together with the linker from GNU binutils. However, all Unix linkers should behave this way. Ben.

1 0

Config question: BOOST_NO_INTRINSIC_WCHAR_T (Intel 7.1)
by Christopher D. Russell 30 Apr '04

30 Apr '04

Hello folks, I'm just getting around to upgrade to Boost 1_31_0 from Boost 1_30_0. I'm attempting to use 1_31_0 out-of-the-box (w/no bjam) but am confused about how to resolve problems related to native wchar_t support (or lack thereof). Some details: I'm using MSV6 with the Intel 7.1 compiler. Specifically I'm using: Intel(R) C++ Compiler for 32-bit applications, Version 7.1 Build 20030609Z I added a few #pragma messages to the config headers and have verified that config indeed seems to making the right decisions - at least at a high level: [Boost Configure: Selected Intel Compiler] [Boost Configure: Selected STLport Standard Library] [Boost Configure: Selected Win32 Platform] The specific error I encounter: d:\ENCAPSULE-EXTLIB\boost\boost_1_31_0\boost_1_31_0\boost/type_traits/is_inte gral.hpp(38): error: class "boost::is_integral<unsigned short>" has already been defined BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,wchar_t,true) ^ d:\ENCAPSULE-EXTLIB\boost\boost_1_31_0\boost_1_31_0\boost/type_traits/is_inte gral.hpp(38): error: class "boost::is_integral<const unsigned short>" has already been defined BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,wchar_t,true) ^ d:\ENCAPSULE-EXTLIB\boost\boost_1_31_0\boost_1_31_0\boost/type_traits/is_inte gral.hpp(38): error: class "boost::is_integral<volatile unsigned short>" has already been defined BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,wchar_t,true) ^ d:\ENCAPSULE-EXTLIB\boost\boost_1_31_0\boost_1_31_0\boost/type_traits/is_inte gral.hpp(38): error: class "boost::is_integral<const volatile unsigned short>" has already been defined BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,wchar_t,true) ^ ... tracked back into .../1_31_0/boost/type_traits/is_integral.hpp #ifndef BOOST_NO_INTRINSIC_WCHAR_T BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,wchar_t,true) #endif ... where BOOST_NO_INTRINSIC_WCHAR_T is defined in ../1_31_0/boost/config/compiler/intel.hpp // See http://aspn.activestate.com/ASPN/Mail/Message/boost/1614864 #if BOOST_INTEL_CXX_VERSION < 700 # define BOOST_NO_INTRINSIC_WCHAR_T #else // _WCHAR_T_DEFINED is the Win32 spelling // _WCHAR_T is the Linux spelling # if !defined(_WCHAR_T_DEFINED) && !defined(_WCHAR_T) # define BOOST_NO_INTRINSIC_WCHAR_T # endif #endif I read the post on ActiveState but I'm still confused. With the frequency of Intel compiler updates is it possible this particular release is not setting the expected macros correctly? If someone could give me a kick in the right direction I would appreciate it. I really want to try some of these nifty Spirit v1.8 facilities (wow Joel). - Thanks Chris

2 4

Regex simple code can't compile on linux, but it can be built on windows VC6.
by Guan Bin 30 Apr '04

30 Apr '04

Hi, the simple code is below: ____________________________________________________________________ #include <iostream> #include <string> #include "boost/regex.hpp" using namespace boost; regex expression("this is ([[:digit:]]*)"); int main(int argc, char* argv[]) { while (true) { char buf[1000]; memset(buf, 0, 1000); std::cin.getline(buf, 1000); std::string str(buf); cmatch match; if (!regex_match(str, match, expression)) { std::cout<<"Don't match"<<std::endl; continue; } for (int i = 0; i < match.size(); i++) { std::string msg; msg.assign(match[i].first, match[i].second); std::cout<<msg<<std::endl; } } return 0; } ____________________________________________________________________________________ the makefile is below ------------------------------------------------------ INCLUDE_DIR = /unzipped/boost_1_31_0/ -I/usr/local/include/stlport/ #INCLUDE_DIR = /unzipped/boost_1_31_0/ LIB_DIR = /unzipped/boost_1_31_0/libs/regex/build/gcc/ -L/usr/local/lib/ #LIB_DIR = /unzipped/boost_1_31_0/libs/regex/build/gcc/ LINK = boost_regex-gcc-1_31 -lstlport_gcc #LINK = boost_regex-gcc-1_31 FLG = -Wall all : regex_sample.o g++ regex_sample.o -L$(LIB_DIR) $(FLG) -l$(LINK) -o sample %.o : %.cpp g++ -I$(INCLUDE_DIR) -L$(LIB_DIR) $(FLG) -l$(LINK) -c $< -------------------------------------------------------------- and the error information is : ------------------------------------------------------------ [root@guanbin regex]# make g++ -I/unzipped/boost_1_31_0/ -I/usr/local/include/stlport/ -L/unzipped/boost_1_31_0/libs/regex/build/gcc/ -L/usr/local/lib/ -Wall -lboost_regex-gcc-1_31 -lstlport_gcc -c regex_sample.cpp regex_sample.cpp: In function `int main(int, char**)': regex_sample.cpp:37: warning: comparison between signed and unsigned integer expressions g++: -lboost_regex-gcc-1_31: linker input file unused because linking not done g++: -lstlport_gcc: linker input file unused because linking not done g++ regex_sample.o -L/unzipped/boost_1_31_0/libs/regex/build/gcc/ -L/usr/local/lib/ -Wall -lboost_regex-gcc-1_31 -lstlport_gcc -o sample regex_sample.o(.gnu.linkonce.t._ZN5boost9re_detail12perl_matcherIPKcN4_STL9allocatorINS_9sub_matchIS3_EEEENS_12regex_traitsIcEENS5_IcEEEC1ES3_S3_RNS_13match_resultsIS3_S8_EERKNS_14reg_expressionIcSA_SB_EENS_15regex_constants12_match_flagsE+0x51): In function `boost::re_detail::perl_matcher<char const*, _STL::allocator<boost::sub_match<char const*> >, boost::regex_traits<char>, _STL::allocator<char> >::perl_matcher[in-charge](char const*, char const*, boost::match_results<char const*, _STL::allocator<boost::sub_match<char const*> > >&, boost::reg_expression<char, boost::regex_traits<char>, _STL::allocator<char> > const&, boost::regex_constants::_match_flags)': : undefined reference to `boost::reg_expression<char, boost::regex_traits<char>, _STL::allocator<char> >::get_traits() const' regex_sample.o(.gnu.linkonce.t._ZN5boost9re_detail12perl_matcherIPKcN4_STL9allocatorINS_9sub_matchIS3_EEEENS_12regex_traitsIcEENS5_IcEEEC1ES3_S3_RNS_13match_resultsIS3_S8_EERKNS_14reg_expressionIcSA_SB_EENS_15regex_constants12_match_flagsE+0x8a): In function `boost::re_detail::perl_matcher<char const*, _STL::allocator<boost::sub_match<char const*> >, boost::regex_traits<char>, _STL::allocator<char> >::perl_matcher[in-charge](char const*, char const*, boost::match_results<char const*, _STL::allocator<boost::sub_match<char const*> > >&, boost::reg_expression<char, boost::regex_traits<char>, _STL::allocator<char> > const&, boost::regex_constants::_match_flags)': : undefined reference to `boost::reg_expression<char, boost::regex_traits<char>, _STL::allocator<char> >::empty() const' regex_sample.o(.gnu.linkonce.t._ZN5boost9re_detail12perl_matcherIPKcN4_STL9allocatorINS_9sub_matchIS3_EEEENS_12regex_traitsIcEENS5_IcEEE24estimate_max_state_countEPNS4_26random_access_iterator_tagE+0x2c): In function `boost::re_detail::perl_matcher<char const*, _STL::allocator<boost::sub_match<char const*> >, boost::regex_traits<char>, _STL::allocator<char> >::estimate_max_state_count(_STL::random_access_iterator_tag*)': : undefined reference to `boost::reg_expression<char, boost::regex_traits<char>, _STL::allocator<char> >::size() const' regex_sample.o(.gnu.linkonce.t._ZN5boost9re_detail12perl_matcherIPKcN4_STL9allocatorINS_9sub_matchIS3_EEEENS_12regex_traitsIcEENS5_IcEEE9match_impEv+0x94): In function `boost::re_detail::perl_matcher<char const*, _STL::allocator<boost::sub_match<char const*> >, boost::regex_traits<char>, _STL::allocator<char> >::match_imp()': : undefined reference to `boost::reg_expression<char, boost::regex_traits<char>, _STL::allocator<char> >::mark_count() const' regex_sample.o(.gnu.linkonce.t._ZN5boost9re_detail8access_tIcNS_12regex_traitsIcEEN4_STL9allocatorIcEEE5firstERKNS_14reg_expressionIcS3_S6_EE+0xd): In function `boost::re_detail::access_t<char, boost::regex_traits<char>, _STL::allocator<char> >::first(boost::reg_expression<char, boost::regex_traits<char>, _STL::allocator<char> > const&)': : undefined reference to `boost::reg_expression<char, boost::regex_traits<char>, _STL::allocator<char> >::first(boost::reg_expression<char, boost::regex_traits<char>, _STL::allocator<char> > const&)' regex_sample.o(.gnu.linkonce.t._ZN5boost9re_detail11raise_errorINS_12regex_traitsIcEEEEvRKT_j+0x21): In function `void boost::re_detail::raise_error<boost::regex_traits<char> >(boost::regex_traits<char> const&, unsigned)': : undefined reference to `boost::re_detail::raise_regex_exception(_STL::basic_string<char, _STL::char_traits<char>, _STL::allocator<char> > const&)' regex_sample.o(.gnu.linkonce.t._ZN5boost9re_detail8access_tIcNS_12regex_traitsIcEEN4_STL9allocatorIcEEE9can_startEcPKhh+0x24): In function `boost::re_detail::access_t<char, boost::regex_traits<char>, _STL::allocator<char> >::can_start(char, unsigned char const*, unsigned char)': : undefined reference to `boost::reg_expression<char, boost::regex_traits<char>, _STL::allocator<char> >::can_start(char, unsigned char const*, unsigned char, boost::re_detail::_narrow_type const&)' regex_sample.o(.gnu.linkonce.t._ZN5boost9re_detail16re_is_set_memberIPKccNS_12regex_traitsIcEEN4_STL9allocatorIcEEEET_S9_S9_PKNS0_11re_set_longERKNS_14reg_expressionIT0_T1_T2_EE+0x41): In function `char const* boost::re_detail::re_is_set_member<char const*, char, boost::regex_traits<char>, _STL::allocator<char> >(char const*, char const*, boost::re_detail::re_set_long const*, boost::reg_expression<char, boost::regex_traits<char>, _STL::allocator<char> > const&)': : undefined reference to `boost::reg_expression<char, boost::regex_traits<char>, _STL::allocator<char> >::get_traits() const' regex_sample.o(.gnu.linkonce.t._ZN5boost9re_detail16re_is_set_memberIPKccNS_12regex_traitsIcEEN4_STL9allocatorIcEEEET_S9_S9_PKNS0_11re_set_longERKNS_14reg_expressionIT0_T1_T2_EE+0x258): In function `char const* boost::re_detail::re_is_set_member<char const*, char, boost::regex_traits<char>, _STL::allocator<char> >(char const*, char const*, boost::re_detail::re_set_long const*, boost::reg_expression<char, boost::regex_traits<char>, _STL::allocator<char> > const&)': : undefined reference to `boost::c_regex_traits<char>::transform(_STL::basic_string<char, _STL::char_traits<char>, _STL::allocator<char> >&, _STL::basic_string<char, _STL::char_traits<char>, _STL::allocator<char> > const&)' regex_sample.o(.gnu.linkonce.t._ZN5boost9re_detail16re_is_set_memberIPKccNS_12regex_traitsIcEEN4_STL9allocatorIcEEEET_S9_S9_PKNS0_11re_set_longERKNS_14reg_expressionIT0_T1_T2_EE+0x34b): In function `char const* boost::re_detail::re_is_set_member<char const*, char, boost::regex_traits<char>, _STL::allocator<char> >(char const*, char const*, boost::re_detail::re_set_long const*, boost::reg_expression<char, boost::regex_traits<char>, _STL::allocator<char> > const&)': : undefined reference to `boost::c_regex_traits<char>::transform_primary(_STL::basic_string<char, _STL::char_traits<char>, _STL::allocator<char> >&, _STL::basic_string<char, _STL::char_traits<char>, _STL::allocator<char> > const&)' regex_sample.o(.gnu.linkonce.t._ZN5boost11basic_regexIcNS_12regex_traitsIcEEN4_STL9allocatorIcEEEC1EPKcjRKS5_+0x13): In function `boost::basic_regex<char, boost::regex_traits<char>, _STL::allocator<char> >::basic_regex[in-charge](char const*, unsigned, _STL::allocator<char> const&)': : undefined reference to `boost::reg_expression<char, boost::regex_traits<char>, _STL::allocator<char> >::reg_expression[not-in-charge](char const*, unsigned, _STL::allocator<char> const&)' regex_sample.o(.gnu.linkonce.t._ZN5boost11basic_regexIcNS_12regex_traitsIcEEN4_STL9allocatorIcEEED1Ev+0xd): In function `boost::basic_regex<char, boost::regex_traits<char>, _STL::allocator<char> >::~basic_regex [in-charge]()': : undefined reference to `boost::reg_expression<char, boost::regex_traits<char>, _STL::allocator<char> >::~reg_expression [not-in-charge]()' collect2: ld returned 1 exit status make: *** [all] Error 1 ------------------------------------------------------------------------------------- the environment is : linux redhat 9.0 gcc 3.2.2 boost_1_31_0 stlport_4_6_2 Who can help me? thanks Guan Bin gb0519(a)hotmail.com

2 1

Problem with Boost 1.31.0 Regex for tru64cxx65
by Richard Hadsell 29 Apr '04

29 Apr '04

Having found out how to build Bjam, I have tried to build the libraries of Boost 1.31.0 for tru64cxx65. I'm only interested in Regex at the moment, so I won't bother you with the problems building other libraries. When the build gets to this point: tru64cxx65-C++-action bin/boost/libs/regex/build/libboost_regex.so/tru64cxx65/release/cregex.o it hangs. I have run into this situation with other large files, and my usual remedy is to decrease the optimization level. How can I do that? If I can't do it for just this file, I'm willing to reduce the optimization level for the entire library, or even for all libraries. (This is not a platform that I worry about performance; it's just there to support a few vestigial machines.) -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601

2 2

Cannot build bjam for tru64cxx
by Richard Hadsell 29 Apr '04

29 Apr '04

I am trying to upgrade from Boost 1.30.0 to 1.31.0. I am unable to build bjam from the source in tools/build/jam_src: 67% build.sh tru64cxx ### ### Using 'tru64cxx' toolset. ### rm -rf bootstrap.tru64cxx mkdir bootstrap.tru64cxx cc -o bootstrap.tru64cxx/jam0 command.c compile.c execnt.c execunix.c execvms.c expand.c filent.c fileos2.c fileunix.c filevms.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c parse.c pathunix.c pathvms.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c class.c native.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c command.c: compile.c: [snip] modules/sequence.c: ./bootstrap.tru64cxx/jam0 -f build.jam --toolset=tru64cxx --toolset-root= clean ...found 1 target... ...updating 1 target... ...updated 1 target... ./bootstrap.tru64cxx/jam0 -f build.jam --toolset=tru64cxx --toolset-root= don't know how to make ...found 1 target... ...can't find 1 target... -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601

3 5

Re: [Boost-users] Re: Config question: BOOST_NO_INTRINSIC_WCHAR_T(Intel7.1)
by Aleksey Gurtovoy 29 Apr '04

29 Apr '04

Christopher D. Russell writes: > Some additional information pertaining to BOOST_NO_INTRINSIC_WCHAR_T using > the Intel C++ 7.1 compiler in my MSVC 6 SP6 environment: > > Using Boost v1.31.0 + STLport v5.0-125 + Intel C++ v7.1 (I updated to build > 20030910Z) inside of MSVC 6 SP6 with a fairly recent MS Platform SDK, I > simply could not get boost/config/compiler/intel.hpp to send me down the road > to glory. In short, if you are running Intel in MSVC6 compatibility-mode and you are not compiling through bjam, you have to define BOOST_NO_INTRINSIC_WCHAR_T yourself -- either through command line or in the user config. If you are using bjam, the Intel toolset (http://tinyurl.com/2codz) does that for you. > > Inside of config/compiler/intel.hpp, _WCHAR_T_DEFINED is defined resulting in > BOOST_NO_INTRINSIC_WCHAR_T not being set. Subsequently, this results in the > compile-time error: > > boost/type_traits/is_integral.hpp(38): error: class > "boost::is_integral<unsigned short>" has already been defined > > Per "Compiler errors with Intel 7.1 and type_traits" > (http://lists.boost.org/MailArchives/boost/msg53033.php) specifically John > Maddock's reply (http://lists.boost.org/MailArchives/boost/msg53121.php) I > short-circuited the logic in config/compiler/intel.hpp and explicitly defined > BOOST_NO_INTRINSIC_WCHAR_T in config/user.hpp. This seems to work acceptably > for this project. But I'm not at all comfortable with this solution because I > really don't understand what the fundamental issue is with all this wchar_t > stuff. > > Forgive my ignorance but if, with my current working config, if I declare a > wchar_t type in my code I will get a 16-bit UCS-2 character. Correct? Having > now poured over all postings related to this subject in the archive, I have > an inkling that the root of all this stems from the way the compiler handles > type aliasing? Yes, more or less. > That is, with BOOST_NO_INTRINSIC_WCHAR_T a defined a wchar_t is actually an > alias for an unsigned int More likely 'unsigned short', but otherwise yes. > whereas in the case > !defined(BOOST_NO_INTRINSIC_WCHAR_T), the compiler treats wchar_t as an > intrinsic type? Yes. Or, rather, to be precisely clear, BOOST_NO_INTRINSIC_WCHAR_T _indicates_ to the Boost code that on the particular compiler/configuration 'wchar_t' is simply an alias for some other built-in integral type. It doesn't change the compiler's behavior. > And from this we get these template specialization errors? Yep. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Boost won't build
by Charles Polisher 28 Apr '04

28 Apr '04

$ pwd /BUILD_TREES/boost $ bjam "-sTOOLS=gcc" /usr/bin/locate/allyourbase.jam: Not a directory /usr/bin/locate/boost-base.jam: Not a directory /BUILD_TREES/boost/tools/build/v1/bootstrap.jam:22: in boost-build rule load-jamfiles unknown in module /BUILD_TREES/boost/boost-build.jam:16: in module scope $ gcc -v <snip> gcc version 3.3 20030226 (prerelease) (SuSE Linux) I get the same result with both the latest release (1.31.0) on sourceforge and with the CVS version. Google, the FAQ and the list archives haven't yielded up a clue. I *must* be overlooking something obvious. Help!

2 3

RE: [Boost-users] Config question: BOOST_NO_INTRINSIC_WCHAR_T (Intel7.1)
by Ben Hutchings 28 Apr '04

28 Apr '04

Christopher D. Russell <cdr(a)encapsule.com> wrote: > I'm just getting around to upgrade to Boost 1_31_0 from Boost 1_30_0. > I'm attempting to use 1_31_0 out-of-the-box (w/no bjam) but am > confused about how to resolve problems related to native wchar_t > support (or lack thereof). <snip error messages> > ... tracked back into .../1_31_0/boost/type_traits/is_integral.hpp > > #ifndef BOOST_NO_INTRINSIC_WCHAR_T > BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,wchar_t,true) > #endif > > ... where BOOST_NO_INTRINSIC_WCHAR_T is defined in > ../1_31_0/boost/config/compiler/intel.hpp > > // See http://aspn.activestate.com/ASPN/Mail/Message/boost/1614864 > #if BOOST_INTEL_CXX_VERSION < 700 > # define BOOST_NO_INTRINSIC_WCHAR_T > #else > // _WCHAR_T_DEFINED is the Win32 spelling > // _WCHAR_T is the Linux spelling > # if !defined(_WCHAR_T_DEFINED) && !defined(_WCHAR_T) > # define BOOST_NO_INTRINSIC_WCHAR_T > # endif > #endif <snip> Since Intel C++ on Windows is supposed to be compatible with Visual C++ I think this should be testing _NATIVE_WCHAR_T_DEFINED and not _WCHAR_T_DEFINED. VC++ defines the latter if wchar_t is an intrinsic type *or* a type alias but it defines the former only if wchar_t is an intrinsic type. I couldn't find any detailed documentation for Intel C++ online so I don't know if it is exactly compatible in this respect.

1 0

Any one used boost with RISCOS and GCC
by dahman madani 28 Apr '04

28 Apr '04

To the community; I was wondering if anyone has experience using the boost libraries with the RISCOS platform Thanks Dahman

1 0

Problem building archive libs for mipspro
by Richard Hadsell 28 Apr '04

28 Apr '04

I am trying to upgrade from Boost 1.30.0 to 1.31.0. My main interest is in the Regex library. I was pleased to build its libraries successfully for intel-linux, both .a and .so forms, using bjam. When trying to build the libraries for mipspro, it fails to build the .a forms, because it is trying to use ranlib. The bjam system is too unfamiliar to me to debug it, so I'm hoping somebody else can give me a remedy. (Note: I built bjam from the source in tools/build/jam_src, as described in the docs.) Here is the evidence: 69% bjam "-sTOOLS=mipspro" --stagedir=stage "-sBUILD=debug release <threading>single" stage [snip] mipspro-Archive-action bin/boost/libs/regex/build/libboost_regex.a/mipspro/debug/libboost_regex-mp-d-1_31.a --- C++ prelinker: bin/boost/libs/regex/build/libboost_regex.a/mipspro/debug/c_regex_traits.o --- [snip] Ranlib bin/boost/libs/regex/build/libboost_regex.a/mipspro/debug/libboost_regex-mp-d-1_31.a /bin/sh[2]: ranlib: not found ranlib bin/boost/libs/regex/build/libboost_regex.a/mipspro/debug/libboost_regex-mp-d-1_31.a ...failed Ranlib bin/boost/libs/regex/build/libboost_regex.a/mipspro/debug/libboost_regex-mp-d-1_31.a... ...skipped <@boost!lib>libboost_regex-mp-d-1_31.a for lack of <@boost!libs!regex!build/libboost_regex.a/mipspro/debug>libboost_regex-mp-d-1_31.a... [snip] -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601

3 4

[BGL] jweb.sty and biconnected_components.w
by Sven de Vries 25 Apr '04

25 Apr '04

Hi, tried to latex the file biconnected_components.w. But it requires a package jweb that I can not find on ctan. Where could I get that from? thanks! sven

2 1

tokenizer: exceptions not documented
by Keith MacDonald 25 Apr '04

25 Apr '04

I discovered the hard way that tokenizer (from CVS head) can throw escaped_list_error. It would help if that was documented. Keith MacDonald

1 0

Iterators
by Witz 24 Apr '04

24 Apr '04

just a quick question - which maybe should have been directed at the developers list but ... would it be possible in the iterator adaptors to have an operator== defined that takes the base iterator as the right hand side? it would certainly cut down on typing and also obviate the need to create an end iterator that is only used as an 'end of container' sentinel value if it was possible it would allow us to write, for example: copy( make_filter_iterator<is_positive_number>(numbers, numbers + N), numbers + N, ostream_iterator<int>(cout, " ")); rather than: copy( make_filter_iterator<is_positive_number>(numbers, numbers + N), make_filter_iterator<is_positive_number>(numbers + N, numbers + N), ostream_iterator<int>(cout, " ")); of course i am aware that i might be missing something obvious ... ian whittley

3 5

boost format problems
by Navneet Dalal 23 Apr '04

23 Apr '04

Hi I decided to try boost::format for more compact and typesafe formatting of text. However, I am running into some problems. Problem 1 ============== The following line throws boost:bad_format_string exception. std::cout << format("%|1| %|2$3|") % "Hello" % 3 << std::endl; However, this one works std::cout << format("%|1|") % "Hello" << std::endl; All I want to do is use notation for printing character streams i.e. %|1| instead of %1% Is this a bug or I am doing something wrong? Problem 2 ============= How can I print a float such that it appends 0 for remaining precision digits. For e.g. let us say I want to print 0.2 with 5 characters of overall length and till 3 digits of precision. Kind of output I am looking for is 0.200 One would expect that following command may work (as I am indicating left print, fill any remaining characters and till 3 digits of precision after decimal) std::cout << format("#%|1$-05.03|#") % 0.2 << std::endl; // however it prints #0.2 # This command prints something like std::cout << format("#%|1$05.03|#") % 0.2 << std::endl; // it prints #000.2# with C++ cout, I can print it like std::cout << '#' << std::left << std::setfill('0') << std::setw(5) << std::setprecision(3) << 0.2 << '#' << std::endl; so on similar lines I wrote following line. it works, but it seems ugly to use group only for this std::cout << format("#%|1$-05.3|#") % group(setfill('0'), 0.2) << std::endl; // prints #0.200# Does any one has any other suggestions? regards navneet

2 1

Compilation problem with BOOST::filesystem lib
by Peter Koerber 23 Apr '04

23 Apr '04

Hello, i try to compile the *.cpp files of boost::filesystem within the following environment: os: Windows XP compiler: Visual C++ Toolkit 2003 (this is the free version of MS Visual C++ V7.1) boost: Version 1.31.0 If BOOST_WINDOWS is defined, the file windows.h is included in the sources: * exception.cpp * operations_posix_windows.cpp. Otherwise the file errno.h is included. BOOST_WINDOWS is defined within the environment mentioned above, but the compiler does not have a windows.h include file. Hence compilation fails. OTOH, if BOOST_WINDOWS is "manually" undefined, the errno constant: ETXTBSY is not defined in the file errno.h which comes with the Visual C++ Toolkit 2003. Kind regards Peter

2 1

BGL: INTERNAL COMPILER ERROR in VC7.1
by Nicholas Burlett 22 Apr '04

22 Apr '04

I'm rather unsure about what is causing this, but I get an internal compiler error in Visual C++ 7.1 when using BGL in some specific circumstances. I have a graph defined in class Graph defined as such: typedef property<edge_feedback_t, bool> EdgeFeedback; typedef property<edge_sourcejack_t, IAudioOutputJack*, EdgeFeedback> EdgeSourceJack; typedef property<edge_destinationjack_t, IAudioInputJack*, EdgeSourceJack> EdgeDestinationJack; typedef EdgeDestinationJack EdgeProperty; typedef boost::property<boost::vertex_index_t, int> VertexIndexProp; typedef property<vertex_name_t, nsCOMPtr<IAudioModule>, VertexIndexProp> VertexProperty; typedef adjacency_list<listS, listS, bidirectionalS, VertexProperty, EdgeProperty> graphdata; typedef graph_traits < graphdata >::vertex_descriptor vertdsc; This definition works fine in the graph.cpp file that implements the class Graph. However, when I use graph.h in another cpp file, I get bizarre compiler errors: c:\Boost\include\boost -1_31\boost\mpl\aux_\preprocessed\plain\apply.hpp(50) : fatal error C1001: INTERNAL COMPILER ERROR After some trial and error, I narrowed the problem down to needing to have a != between two oedge_iterators _somewhere_ in the cpp file including graph.h. Simply putting the following function into my other files will cause them to compile just fine: void makeVChappy() { typedef graph_traits< Graph::graphdata >::out_edge_iterator oedge_iterator; oedge_iterator oiter, oend; oiter != oend; } I'm a a complete loss as to how this could be happening, but since I have a work-around for now, I'm not going to push the issue too much further at the moment --- I just thought I'd bring this to your attention, and see if anyone knows of a more elegant solution.

5 5

RE: [Boost-users] Compilation problem with BOOST::filesystem lib
by Ben Hutchings 22 Apr '04

22 Apr '04

Peter Koerber <pk(a)ExperTeam.de> wrote: > i try to compile the *.cpp files of boost::filesystem within the > following environment: > > os: Windows XP > compiler: Visual C++ Toolkit 2003 (this is the free version > of MS Visual C++ V7.1) > boost: Version 1.31.0 > > If BOOST_WINDOWS is defined, the file windows.h is included > in the sources: > * exception.cpp > * operations_posix_windows.cpp. > > Otherwise the file errno.h is included. > > BOOST_WINDOWS is defined within the environment mentioned above, > but the compiler does not have a windows.h include file. Hence > compilation fails. <snip> You need to install the Windows Platform SDK as well as the Toolkit.

1 0

problems using VC 7.1 and boost regex library
by Keith Smith 22 Apr '04

22 Apr '04

Sorry if this is a resend, but not sure if the original got sent! I tried your suggestion, and it appears that I still have the same errors. Anyone have any other ideas? (See Attached) -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Thursday, April 15, 2004 5:45 AM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] problems using VC 7.1 and boost regex library > I have been trying to compile the following code with VC 7.1 ( which > compiled fine with VC 6 ) with no luck. > > std::string m_rBuffer; > boost::regex m_rStartExp; > > string::const_iterator rRawDataBegin = m_rBuffer.begin(); > string::const_iterator rRawDataEnd = m_rBuffer.end(); > > boost::cmatch rStartMessage; > > unsigned int flags = boost::match_default; > while ( boost::regex_search(rRawDataBegin, > rRawDataEnd, > rStartMessage, > m_rStartExp, > flags) ) > > Included is the compiler error report. The match-flags area distinct type, so use: boost::match_flag_type flags = boost::match_default; John. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

2 1

Problems with installation of boost unit_test_framework
by Matthew Burgess 21 Apr '04

21 Apr '04

Hi folks, http://www.boost.org/libs/test/doc/components/unit_test_framework/compilati… states that I can include <boost/test/included/unit_test_framework.hpp> in order to avoid having to link against the unit_test_framework library. However, the files it #includes are located in the boost test library source directory which doesn't appear to be installed by the default bjam procedure (I just get '/opt/boost/lib' &'/opt/boost/include' directories after installing boost). If it helps to clarify things here's some output: --- bash-2.05b$ cat example1.cpp #include <boost/test/included/unit_test_framework.hpp> using boost::unit_test_framework::test_suite; void test_function() { BOOST_CHECK(2 == 1); // intentional failure } test_suite* init_unit_test_suite(int, char* []) { test_suite* test = BOOST_TEST_SUITE("Unit test example 1"); test->add(BOOST_TEST_CASE(&test_function)); return test; } bash-2.05b$ g++ -I /opt/boost/include/boost-1_31/ -L /opt/boost/lib/ -o test example1.cpp In file included from example1.cpp:2: /opt/boost/include/boost-1_31/boost/test/included/unit_test_framework.h pp:18:47: libs/test/src/execution_monitor.cpp: No such file or directory ... --- The only place I find the required files is in the original location I extracted the boost source tarball to. I can (and have) copied the 'libs' directory to sit inside my 'include' directory and verified this fixes things, but I doubt very much this is the correct solution. I'm particularly concerned that if someone else wants to compile my toy code, simply telling them to "install boost" might not be enough. Related to all this is the issue of best-practice. Should I make efforts not to have to link to a library, what are the trade-offs? Can I simply take a copy of the required boost headers and place them directly in my project's directory structure? If not, is anyone aware of an autoconf style macro that can be used to detect the presence of the boost headers and/or libraries? I took a quick glance at the autoconf-archive but didn't see anything immediately. Thanks for anyone who can hit me with a cluebat (or FAQ pointer). Matt Burgess

1 0

problems using VC 7.1 and boost regex library ( this time with attachment )
by Keith Smith 21 Apr '04

21 Apr '04

1 0

problems using VC 7.1 and boost regex library
by Keith Smith 21 Apr '04

21 Apr '04

I tried your suggestion, and it appears that I still have the same errors. Anyone have any other ideas? (See Attached) -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Thursday, April 15, 2004 5:45 AM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] problems using VC 7.1 and boost regex library > I have been trying to compile the following code with VC 7.1 ( which > compiled fine with VC 6 ) with no luck. > > std::string m_rBuffer; > boost::regex m_rStartExp; > > string::const_iterator rRawDataBegin = m_rBuffer.begin(); > string::const_iterator rRawDataEnd = m_rBuffer.end(); > > boost::cmatch rStartMessage; > > unsigned int flags = boost::match_default; > while ( boost::regex_search(rRawDataBegin, > rRawDataEnd, > rStartMessage, > m_rStartExp, > flags) ) > > Included is the compiler error report. The match-flags area distinct type, so use: boost::match_flag_type flags = boost::match_default; John. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

Selection scheme for boost libraries
by Uli Tuerk 19 Apr '04

19 Apr '04

Hi all! I have a very basic problem with the boost libraries: I used bjam to build all boost libraries for Linux (using "gcc" as toolset and the call 'bjam "-sTOOLS=gcc" install'). All went fine, however I wanted to do the regression tests for boost_regex using the gcc.mak Makefile in <boost_main>/libs/regex/test/regress which uses "-lboost_regex" for linking. The linker reported an error because there is no "libboost_regex.so" in my lib folder unless I created a link with this name to one of the various versions of libboost_regex. A comment for these Makefiles would be helpful for the case when having build all with bjam. When compiling the regex part alone, the library is created in build/gcc with the correct name (libboost_regex.so). I'm new to C++, so maybe I haven't got the point with the sophisticated naming scheme of the libraries, but: for the library "libboost_regex-gcc-mt-d-1_31.so" e.g. are the tool specifier ("gcc") and the version ("1_31") really necessary for a platform using version numbering of the libraries anyway in the ".so" extension? OK, there are still the categories with/without debug and with/without threading. How would you guys select the type of library? In the Makefile? Thanks in advance! Uli ************************************************************************ Uli Türk

2 1