- Boost-users - lists.boost.org

Regex compilation failure with MSVC .NET 2002 and bjam
by Ovanes Markarian 02 Sep '05

02 Sep '05

Dear all, I am trying to build the regex library from boost 1.33 release with Visual C++ .NET 2002 and bjam. I constantly get this error (while trying to build it with ICU and without). my command line is: bjam "--with-regex" "-sTOOLS=vc7" "--prefix=E:\projects\Automation\thirdparty\boost" "--builddir=E:\projects\Automation\thirdparty\boost\build" "-sHAVE_ICU=0" "-sICU_PATH=E:\projects\Automation\thirdparty\icu\source" install I was trying to switch -sHAVE_ICU option between 0 and 1 and always got this output for regex cpp files. The error(s) is in German (I don't know why MS decided to translate C++ compiler to German, but I have no other alternative at the moment and suffer very much with it as well...). The error means: cannot form a qualified name (=Ein qualifizierter Name kann nicht gebildet werden) see reference to class template instantiation boost::re_detail::regex_iterator_traits<T>' being compiled (=Siehe Verweis auf Instantiierung der kompilierten Klassenvorlage) Full output is: vc-C++ E:\projects\Automation\thirdparty\boost\build\bin\boost\libs\regex\build\ libboost_regex.lib\vc7\release\threading-multi\icu.obj cl : Befehlszeile warning D4029 : Die Optimierung ist im Standardcompiler nicht verf?gbar. icu.cpp E:\projects\Automation\thirdparty\boost_1_33_0\boost\regex\v4\iterator_traits.hp p(34) : error C2825: 'T::iterator_category': Ein qualifizierter Name kann nicht gebildet werden E:\projects\Automation\thirdparty\boost_1_33_0\boost\regex\v4\sub_match. hpp(31) : Siehe Verweis auf Instantiierung der kompilierten Klassenvorlage 'boos t::re_detail::regex_iterator_traits<T>' with [ T=const int * ] C:\Program Files\Microsoft Visual Studio .NET\Vc7\include\vector(259) : Siehe Verweis auf Instantiierung der kompilierten Klassenvorlage 'boost::sub_mat ch<BidiIterator>' with [ BidiIterator=const int * ] E:\projects\Automation\thirdparty\boost_1_33_0\boost\regex\v4\regex_form at.hpp(34) : Siehe Verweis auf Instantiierung der kompilierten Klassenvorlage 's td::vector<_Ty,_Ax>' with [ _Ty=boost::sub_match<const int *>, _Ax=std::allocator<boost::sub_match<const int *>> ] Does someone know what is the problem and how I can fix it? With Kind Regards, Ovanes Markarian

2 2

[Test] Template specialization problems with BOOST_CHECK_EQUAL_COLLECTIONS
by Will Bryant 02 Sep '05

02 Sep '05

Hi all, I've been using Boost.Test lately and in general it's working well (thanks Gennadiy!). However, I'm having trouble with BOOST_CHECK_EQUAL_COLLECTIONS when my collections are of non-primitive types. For example, if I try: vector<wstring> test1, test2; BOOST_CHECK_EQUAL_COLLECTIONS(test1.begin(), test1.end(), test2.begin(), test2.end()); I get a compiler error along the lines of "h:\libraries\boost\boost\test\utils\wrap_stringstream.hpp(66) : 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 being wchar_t in this case, and _Traits and _Ax having the usual defaults). Looking at the source I see that BOOST_CHECK_EQUAL_COLLECTIONS is using equal_coll_impl, which is creating a predicate_result and using the stream insertion operator on the wrap_stripstream returned by its message() method. wrap_stringstream has an unspecialized template which delegates to the << operator of the backing ostringstream/ostrstream: template <typename CharT, typename T> inline basic_wrap_stringstream<CharT>& operator<<( basic_wrap_stringstream<CharT>& targ, T const& t ) { targ.stream() << t; return targ; } Since that backing ostringstream descends from ostream, I would have thought that all I needed to do was to ensure that there is a operator << (ostream&, wstring const&) defined, like this: ostream& operator << (ostream& ostr, wstring const& str) { ostr << "I'd put a wstring-to-string function here instead of this constant"; return ostr; } Hower this doesn't work - although I can now compile: ostringstream oss; oss << wstring(L"test"); successfully, if I try: boost::wrap_stringstream wss; wss << wstring(L"test"); or: boost::test_tools::predicate_result res(true); res.message() << wstring(L"test"); I get the same error as above. Interestingly, if I change that << operator implementation so that it takes and returns a wrap_stringstream, instead of an ostream: boost::wrap_stringstream& operator << (boost::wrap_stringstream& ostr, const wstring& str) { ostr << "I'd put a wstring-to-string function here instead of this constant"; return ostr; } then I can compile 'wss << wstring(L"test")' and ' res.message() << wstring(L"test")' OK. This is weird because it suggests to me that that unspecialized wrap_stringstream template that delegates to the ostringstream's << isn't working properly. But weirder is that even having done that, using BOOST_CHECK_EQUAL_COLLECTIONS still produces the same compilation error, even though it's making the same operator call - I can't see why. Am I missing something here? I also tried specializing print_log_value: namespace boost { namespace test_tools { namespace tt_detail { template<> struct print_log_value<std::wstring> { void operator()(std::ostream& ostr, const std::wstring& str) { ostr << "I'd put a wstring-to-string function here instead of this constant"; } }; }}} But that didn't help either - same error. I'm primarily using Visual Studio 2005, but I have exactly the same problems under gcc 3.3.5 too. Any suggestions? Cheers, Will -- Will Bryant http://carcino.gen.nz/ will(a)core-dev.co.nz +64 21 655 443

2 2

[serialization] bug with new_cid != cid
by Sergey Skorniakov 01 Sep '05

01 Sep '05

Following code produced assert at line 444 in libs/serializatin/src/basic_iarchive with version 1.32.0, 1.33.0 and with every archive that's headers are included: #define BOOST_SERIALIZATION_DYN_LINK #include <boost/archive/polymorphic_iarchive.hpp> #include <boost/archive/polymorphic_oarchive.hpp> #include <boost/archive/polymorphic_text_iarchive.hpp> #include <boost/archive/polymorphic_text_oarchive.hpp> #include <boost/archive/polymorphic_xml_iarchive.hpp> #include <boost/archive/polymorphic_xml_oarchive.hpp> #include <boost/archive/polymorphic_binary_iarchive.hpp> #include <boost/archive/polymorphic_binary_oarchive.hpp> #include <boost/archive/xml_iarchive.hpp> #include <boost/archive/xml_oarchive.hpp> #include <boost/archive/binary_iarchive.hpp> #include <boost/archive/binary_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> #include <boost/archive/text_oarchive.hpp> #include <iostream> #include <sstream> #include <boost/serialization/map.hpp> int main(int argc, char* argv[]) { std::pair<int, int> a(11, 22); std::map<int, int> b; b[0] = 0; b[-1] = -1; b[1] = 1; std::stringstream ss; { std::pair<int, int> *pa = &a; std::map<int, int> *pb = &b; boost::archive::binary_oarchive oa(ss); oa << boost::serialization::make_nvp("B1", pb); oa << boost::serialization::make_nvp("A1", pa); } std::cout << ss.str(); { std::pair<int, int> *pa = 0; std::map<int, int> *pb = 0; boost::archive::binary_iarchive ia(ss); ia >> boost::serialization::make_nvp("B1", pb); ia >> boost::serialization::make_nvp("A1", pa); delete pa; delete pb; } return 0; } Similar program without nvp's has the same problem: int main(int argc, char* argv[]) { std::pair<int, int> a(11, 22); std::map<int, int> b; b[0] = 0; b[-1] = -1; b[1] = 1; std::stringstream ss; { std::pair<int, int> * const pa = &a; std::map<int, int> * const pb = &b; boost::archive::text_oarchive oa(ss); oa << pb; oa << pa; } std::cout << ss.str(); { std::pair<int, int> *pa = 0; std::map<int, int> *pb = 0; boost::archive::text_iarchive ia(ss); ia >> pb; ia >> pa; delete pa; delete pb; } return 0; }

2 1

[boost.lambda] Problem with combining if_then_else_return and bind?
by Stuart Dootson 01 Sep '05

01 Sep '05

Hi - I've been trying to use the if_then_else_return feature of Boost.Lambda, and have run into a problem using Lambda's bind with this feature. My minimal example (at the end of the message) fails when compiled with the VC7.1 command line "cl -c -EHsc -DBAD" (the -DBAD is to compile the non-compiling code). The error message (attached as err.txt) indicates that return type deduction has failed at some point, I guess. The compiling version of the code differs from the non-compiling version by assigning the bind result to a variable. This seems to enable correct return type deduction. No other forms using lambda and bind that I've tried have exhibited this problem. So, the question is - is this a bug in Lambda or am I doing something wrong? Oh, I've also tried this with gcc 3.4.2 (Mingw version) and it behaved the same as VC7.1. Stuart Dootson #include <boost/lambda/lambda.hpp> #include <boost/lambda/bind.hpp> #include <boost/lambda/if.hpp> #include <boost/function.hpp> using namespace boost::lambda; bool Test1(char); void Fn(char c, bool b) { bool flag; #if defined(BAD) boost::function<bool(char)> fn = if_then_else_return(var(b), bind<bool>(&Test1, _1), constant(false) ) ; #else bool blah; boost::function<bool(char)> fn = if_then_else_return(var(b), var(blah)=bind(&Test1, _1), constant(false) ) ; #endif }

2 2

Thread cancellation
by Sliwa, Przemyslaw (London) 01 Sep '05

01 Sep '05

Hi, Can anyone tell me if it is possible to cancel a thread using boost.thread library? Thanks Pshemek -------------------------------------------------------- If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ --------------------------------------------------------

6 5

program_options library, options_description object copying
by Leon Mergen 01 Sep '05

01 Sep '05

Hello, Today I upgraded to boost 1.33, which broke the 'program options' part of my application. Copying of a boost::program_options::options_description is not allowed anymore, because of a const unsigned int m_line_length, defined at line 211 of <boost/program_options/options_descriptions.hpp> : ===================================================================== Compiling: Configurator.o Configurator.cpp: In member function ` boost::program_options::options_description& boost::program_options::options_description::operator=(const boost::program_options::options_description&)': Configurator.cpp:13: error: non-static const member `const unsigned int boost::program_options::options_description::m_line_length', can't use default assignment operator make: *** [Configurator.o] Error 1 ===================================================================== I wonder, why is this not allowed anymore (except the obvious answer that a const variable cannot be assigned a new value) ? What is the "new", preferred way to copy these objects ? Right now, I've fixed it by removing the const qualifier of that variable, but I can see that's not the preferred way... :) Regards, Leon Mergen

2 2

Re: [Boost-users] Problem compiling boost::iostreams - bzlib.h file not found
by Tim Taylor 01 Sep '05

01 Sep '05

Thanks for your help Jonathan. Regarding my comment on the #includes, it's just a minor stylistic point which you can take or leave. My point was just that, in my experience, common practice is to use #include <..> for files from different libraries, and #include "..." only for files from your own project. Of course the only difference is that the <> version looks for files in the include path, and the "" version first looks in the current directory and then in the include path. Using <> to include headers from other libraries is therefore *slightly* safer I guess, if only in the unlikely situation where you have a header file with the same name in the current directory; with <> you know you're using the library's own version of the header file and not your own (which would generally be the desired action unless you specifically wanted to override the library's own version). Additionally, from a readability point of view, <> makes it clear that the header is from another library. As I say, this is a minor point, and feel free to ignore it! Tim > >Message: 2 >Date: Wed, 31 Aug 2005 12:34:46 -0600 >From: "Jonathan Turkanis" <technews(a)kangaroologic.com> >Subject: Re: [Boost-users] Problem compiling boost::iostreams - > bzlib.h file notfound >To: boost-users(a)lists.boost.org >Message-ID: <df4t2b$ive$1(a)sea.gmane.org> > >Tim Taylor wrote: > > >>I have just downloaded boost 1.33.0 and am doing a bulk-standard >>install on my linux PC as per the instructions, with the command: >> >>bjam "-sTOOLS=gcc" install >> >>Nearly everything worked fine, but the iostreams library failed to >>compile, with the error in boost_1_33_0/libs/iostreams/src/bzip2.cpp: >>could not find include file "bzlib.h" >> >> > >Try defining the variable NO_BZIP2. See http://tinyurl.com/bcjuz and >http://tinyurl.com/dn6gx. > > > >>On further investigation, this file comes from the package >>libbzip2_1-devel, which also needs to be installed. >> >>An extra thought: bzip2.cpp includes this file as >>#include "bzlib.h" >>but it should really be >>#include <bzlib.h> >>as this is from a different library. >> >> > >Could you elaborate? > > > >>Tim >> >> > >Jonathan > > >

2 1

Re: [Boost-users] [statechart] Can events carry data?
by BRIDGES Dick 01 Sep '05

01 Sep '05

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Peter Petrov > Sent: Tuesday, August 30, 2005 1:13 PM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] [statechart] Can events carry data? > > > BRIDGES Dick wrote: > > Is there any provision for "event-local" storage? I'd like > to create > > events that carry data (e.g., timestamp, source, etc.) to be used by > > reactions and transitions to update state-local storage. > > > > I didn't see anything like this in the documentation. Bad > idea? Major > > drawbacks? If it wouldn't be a problem, how might I go > about doing it? > > > struct MyEvent : public boost::statechart::event<MyEvent> > { > int myData; > double myOtherData; > MyClass myOtherOtherData; > }; > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users > Thank you for the example. I'm still not clear on the requirements surrounding such an instance. For example, the reference requires that <code>new E(*pCE)</code> be well-formed and make "a copy of pE". Does the current implementation work ok with boost::shared_ptr? How about auto_ptr? If a data member would normally require a deep copy, would I be better off managing it external to the event object - or avoiding that type of data altogether? How many copies are we talking about here? Any cautions and/or advise regarding the use of data members in events would be appreciated. Thanks again for the response. Regards, Dick Bridges

2 2

Thread cancellation
by Chris Coleman 01 Sep '05

01 Sep '05

Hi, I know at present that the Boost Threads implementation does not provide a terminate() / cancel() function, but the documentation suggests that work is in progress to implement this feature once a safe and portable way is found. I was just wondering whether this will appear soon in future releases, or if it is likely to be some time? At present I can kill a thread internally by simply throwing an exception and not catching it. But externally I cannot. I have a thread pool server I built some time ago using the pthread API and I'm porting it to use Boost Threads. The server has add() and remove() thread methods. Within the remove function under the pthread implementation I could call pthread_cancel(thrID) and that would be that, Obviously I cant call thread.cancel() as I'd like here and was wondering if there were any simple ways to signify that a particular thread should terminate? Cheers Chris This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

9 16

Boost.Random: Some proposed fixes
by Daniel Krügler 01 Sep '05

01 Sep '05

I observed some further missing definitions of constant static members of integral type, which have been initialized in-class: 1) additive_combine.hpp Proposal: Add the following #ifndef BOOST_NO_INCLASS_MEMBER_INITIALIZATION // A definition is required even for integral static constants template<class MLCG1, class MLCG2, #ifndef BOOST_NO_DEPENDENT_TYPES_IN_TEMPLATE_VALUE_PARAMETERS typename MLCG1::result_type #else int32_t #endif val> const bool additive_combine<MLCG1, MLCG2, val>::has_fixed_range; template<class MLCG1, class MLCG2, #ifndef BOOST_NO_DEPENDENT_TYPES_IN_TEMPLATE_VALUE_PARAMETERS typename MLCG1::result_type #else int32_t #endif val> const typename additive_combine<MLCG1, MLCG2, val>::result_type additive_combine<MLCG1, MLCG2, val>::min_value; template<class MLCG1, class MLCG2, #ifndef BOOST_NO_DEPENDENT_TYPES_IN_TEMPLATE_VALUE_PARAMETERS typename MLCG1::result_type #else int32_t #endif val> const typename additive_combine<MLCG1, MLCG2, val>::result_type additive_combine<MLCG1, MLCG2, val>::max_value; #endif 2) What is actually the reason for the trailing whitespace on streaming of the class template discard_block? It seems inconsistent compared to the other outputs. 3) linear_congruential.hpp: Add missing static member definitions for linear_congruential: #ifndef BOOST_NO_INCLASS_MEMBER_INITIALIZATION ... // Other already defined constants template<class IntType, IntType a, IntType c, IntType m, IntType val> const IntType linear_congruential<IntType,a,c,m,val>::multiplier; #endif .. and for class rand48 (in its corresponding cpp, not the header): #ifndef BOOST_NO_INCLASS_MEMBER_INITIALIZATION ... // Other already defined constants const bool rand48::has_fixed_range; const int32_t rand48::min_value; const int32_t rand48::max_value #endif Greetings from Bremen, Daniel Krügler

1 0