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

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

Problem compiling boost::iostreams - bzlib.h file not found
by Tim Taylor 31 Aug '05

31 Aug '05

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" 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. Tim

2 1

boost::lambda::bind operator = std::vector sucess, bnu::vector and std::valarray fail
by pviallet＠yahoo.fr 31 Aug '05

31 Aug '05

I’m just starting to use boost::lambda an boost::lambda::bind, and I do not understand why this do not work whith bnuy::vector && std::valarray : class CToto{ public: CToto(double _i): a(_i) {} CToto(): a(0.0) {} double get() const {return a;} private: double a; }; std::vector<std::CToto *> aTotoPtrVect; aTotoPtrVect.push_back(new std::CToto(1.1)); aTotoPtrVect.push_back(new std::CToto(2.2)); aTotoPtrVect.push_back(new std::CToto(3.3)); aTotoPtrVect.push_back(new std::CToto(4.4)); //case 1 std::vector <double> dv(std::distance((aTotoVect.begin(), aTotoVect.end()); std::for_each(aTotoPtrVect.begin(), aTotoPtrVect.end(), bll::var(dv)[bll::var(uiIdx)++] = bll::bind(&CToto::get, bll::_1)); // work fine //case 2 double d(4) std::for_each(aTotoPtrVect.begin(), aTotoPtrVect.end(), bll::var(d)[bll::var(uiIdx)++] = bll::bind(&CToto::get, bll::_1)); // work fine //case 3 std::valaray <double> dvv(std::distance((aTotoVect.begin(), aTotoVect.end()); std::for_each(aTotoPtrVect.begin(), aTotoPtrVect.end(), bll::var(dvv)[bll::var(uiIdx)++] = bll::bind(&CToto::get, bll::_1)); // do not compile //case 4 bnu::vector<double> bvv(std::distance((aTotoVect.begin(), aTotoVect.end()); std::for_each(aTotoPtrVect.begin(), aTotoPtrVect.end(), bll::var(bvv)[bll::var(uiIdx)++] = bll::bind(&CToto::get, bll::_1)); // do not compile Is someone could explain me why it work in 1 and 2 ?

1 0

boost::date_time GMT/UTC question
by Leon Mergen 31 Aug '05

31 Aug '05

Hello, Simple/quick question: is boost::posix_time::ptime boost::posix_time::second_clock::universal_time(), which is described as UTC in the boost manual page, equal to GMT? If not, what is the difference between UTC and GMT? As I understood it, UTC is the "new" name for GMT, but I'm not sure. Regards, Leon

2 3

Re: [Boost-users] Boost-users] boost::date_time GMT/UTC question
by Christopher Hunt 31 Aug '05

31 Aug '05

Sorry about my previous post - I don't know quite what happened but it didn't include the intended response. What I meant to state was that for most applications, UTC and GMT can be regarded as the same. Here's a good explanation on UTC: http://en.wikipedia.org/wiki/Utc Cheers, -C

1 0

Re: [Boost-users] Regex boost 1.33 - (mingw/w32) linking
by Arno Mauhourat 31 Aug '05

31 Aug '05

> Well there's something wrong at your end, because it works for me: > > cd libs/regex/example/grep > g++ -I../../../.. -c -o grep.o grep.cpp > g++ -o grep.exe grep.o > 'C:\data\boost\develop\boost\bin\boost\libs\regex\build\libboost_regex.lib\mingw\debug\threading-multi\libboost_regex-mgw-mt-d-1_33.lib' > 'C:\data\boost\develop\boost\bin\boost\libs\program_options\build\libboost_program_options.lib\mingw\debug\threading-multi\libboost_program_options-mgw-mt-d-1_33.lib' > -g3 > > compiles and links cleanly with the current MinGW release. > > John. > Thanks John, for your time and quick answers. I found the issue: I compiled "grep.cpp" with -O3 and this leads to: - error at linking on debug version of the library (libboost_regex-mgw-mt-d-1_33.lib) - OK linking with non-debug version (libboost_regex-mgw-mt-1_33.lib) I am quite unfamiliar with g++ (and it is quite off topic here) but seems strange to me that an optimization level ruins a linking... Arno

2 1