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

[Random] Documentation enhancement
by Richard Jennings 04 Mar '05

04 Mar '05

I would like to suggest an enhancement to the documentation for the random library. The documentation for the number generators advises not to construct generators frequently for various reasons. On some platforms there could also be an issue with memory use where the generators are created on the stack. I have used the suggested mt19937 generator that is about 5000 bytes in size on my system. If I create two of these on the stack then I get a crash. I followed the "very quick start" example that creates the generator on the stack and has a variate_generator like this: boost::mt19937 rng; boost::uniform_int<> six(1,6) boost::variate_generator<boost::mt19937, boost::uniform_int<> > die(rng, six); Thus, each instance of variate_generator has a copy of the generator too. The random_demo.cpp works just fine because it uses an alias for the generator: boost::variate_generator<base_generator_type&, boost::uniform_real<> > thus multiple copies of the variate_generator on the stack are fine. I guess what this comes down to is a warning about creating multiple instances on the stack of generators and/or variate_generators where the engine template parameter to variate_generator is a engine rather than a pointer or reference to an engine. Richard

1 0

Program options: terminating parsing.
by The Grumpiest Man You Know 04 Mar '05

04 Mar '05

As context I would like to say that read "The C++ Programming Language" first edition and thought, "That sounds interesting." and then didn't think of it again 'til about a a couple of months ago, when I read Accelerated C++ on the recommendation of a friend and then updated my original copy to the third edition. So I have NO useful C++ experience, please point out even the most obvious things, I really could be that dumb. I have started a non trivial project that I hope will cement some of the things I've read. And that's where boost comes in. I had some success with using boost_filesystem, so I think I am able to extract basic usage out of the documentation but I've failed to find what I'm looking for in program_options. I would really like to parse a line that has the the form: word [options]... nother option-like-non-option-word... so for instance -F after "word" indicates a legitimate value but -F after "nother" shouldn't set or change the value and indeed might not even have a "value" I've been considering producing a class defining operator() to be used as an additional parser that would recognize the second bare word and make all options thereafter into some list for a dummy option, like the file names in the example. However there is mention of allowing multi word options being "not enabled by default" and I thought that the style argument might be the key, but what I've managed to work out from reading a tarball I downloaded of 1_32_0 seems to use style for changing how single words are interpreted. So before I go crazy trying to implement something that sounds easy to say but beyond my ken, is there a method I'm overlooking for terminating the parsing of the command line before the words are all consumed? Thanks for your time, I'll try to be more brief in future. :) -- Blue Skies

3 6

Problems using boost::filesystem
by steve ahlgren 03 Mar '05

03 Mar '05

Hello : I have a question about boost::filesystem::path. My frustration level is growing quickly because I'm getting exceptions when constructing paths such as these : boostfs::path searchPath( "d:/temp", boostfs::native ); boostfs::path searchPath( "d:/temp" ); boostfs::path searchPath( "d:\\temp", boostfs::native ); boostfs::path searchPath( "d:\\temp" ); Looking at the boost test files [at least some of] these appear to be valid. The key seems to be in the method windows_name(...) in path_posix_windows.cpp. This method searches through the array invalid_chars[] which contains "<>:\"/\\|" ... hence the reason why "d:" causes a failure? I've rebuilt the source from the bjam files, tried compiling them into my own code, compiled as a dll etc. to no avail ... Could someone shed some light on this problem before I go even crazier? Thank you kindly in advance; Steve a.

2 1

Lambda question (deferring evaluation)
by Johan Nilsson 03 Mar '05

03 Mar '05

Hi, would it be possible to implement something the following lines using lambda, without having all values referring to the same shared object: ... #include <boost/shared_ptr.hpp> #include <boost/lambda/lambda.hpp> #include <algorithm> #include "Foo.h" ... using namespace boost; using namespace boost::lambda; std::vector<shared_ptr<Foo> > foos(10); std::for_each(foos.begin(), foos.end(), _1 = shared_ptr<Foo>(new Foo)); Thanks // Johan

4 4

BOOST_CHECK_EQUAL and operator<<
by Patrick Mézard 03 Mar '05

03 Mar '05

Hello, I am currently upgrading from boost-1.30.2 to boost-1.32.0 with MSVC 7.1 and I am running into the following issue: BOOST_CHECK_EQUAL requires the elements to be compared to provide an operator<< taking an std::ostream& as first parameter. I always had names lookups problems with that when the operator was provided by the test and not along with the element. Until now, I had the operator defined in "boost" namespace (that's ugly I know) in the test file. It breaks with 1.32.0 because the problematic function (print_log_value) moved deeped into test tools namespaces. Then I try to revert to a normal definition but it does not work either. For instance : //******************************* #include <boost/test/unit_test.hpp> using boost::unit_test::test_suite; namespace testns { struct Test { Test(std::string const& s_) : s(s_) {} bool operator==(Test const& t) const { return s==t.s; } std::string s; }; namespace { std::ostream& operator<<(std::ostream& o, Test const& t) { return o<<t.s; } void free_test_function() { Test t1("test1"), t2("test2"); BOOST_CHECK_EQUAL(t1, t2); } } //namespace } //namespace testns test_suite* init_unit_test_suite( int, char* [] ) { test_suite* test= BOOST_TEST_SUITE( "Unit test example 1" ); test->add( BOOST_TEST_CASE( &testns::free_test_function )); return test; } //*********************** Does not compile and gives me a: C2679: binary 'operator' : no operator defined which takes a right-hand operand of type 'const testns::Test' (or there is no acceptable conversion), the failure being issued by "void boost::test_tools::tt_detail::print_log_value<T>::operator ()(std::ostream &,const T &)" However, if I define operator<< as a public member of testns::Test it compiles. Same thing if I move it outside the anonymous namespace, with or without static linkage. Note these workaround do not work or cannot be applied if the type is declared by a typedef. In this case, I have to define again the operator in namespace boost.test_tools.tt_detail. Is it to be expected ? Is is an ADL issue ? Or something related to MSVC 7.1 ? What is the proper way to do that ? Patrick Mézard

4 9

reverse_iterators for uBLAS sparse matrices
by Nikos Platis 02 Mar '05

02 Mar '05

Hi, I am relatively new to Boost and I find it an excellent C++ library. During my experiments with the library, I tried the sparse matrix classes offered by uBLAS. Unfortunately, I think that reverse_iterators of these classes do not work correctly. Below is my sample code, which demonstrates some problems; the problems are the same with all three sparse matrix classes. I tried it with gcc 3.4.1 on Linux. Any comments would be appreciated. Thanks in advance, Nikos Platis PS. I post here instead of the uBLAS Yahoo Group because I am still waiting for membership approval... ---------------------------------------------------- #include <iostream> #include <boost/numeric/ublas/matrix_sparse.hpp> #include <boost/numeric/ublas/io.hpp> namespace ublas = boost::numeric::ublas; //typedef ublas::sparse_matrix<double> spmd; //typedef ublas::compressed_matrix<double> spmd; typedef ublas::coordinate_matrix<double> spmd; int main() { // Construct a sample sparse matrix spmd M(5, 5); M(0,0) = 11; M(0,2) = 13; M(1,0) = 21; M(1,1) = 22; M(2,2) = 33; M(2,4) = 35; M(3,3) = 44; M(4,0) = 52; M(4,4) = 55; /* OK */ for (spmd::const_iterator1 it1 = M.begin1(); it1 != M.end1(); ++it1) { for (spmd::const_iterator2 it2 = it1.begin(); it2 != it1.end(); ++it2) { std::cout << it2.index1() << " " << it2.index2() << ": " << *it2 << std::endl; } } std::cout << std::endl << std::endl; /* The following does not compile, error about the const reverse iterators for (spmd::const_reverse_iterator1 it1 = M.rbegin1(); it1 != M.rend1(); ++it1) { for (spmd::const_reverse_iterator2 it2 = it1.rbegin(); it2 != it1.rend(); ++it2) { std::cout << it2.index1() << " " << it2.index2() << ": " << *it2 << std::endl; } } std::cout << std::endl << std::endl; */ /* The following compiles but throws bad_index exception */ for (spmd::reverse_iterator1 it1 = M.rbegin1(); it1 != M.rend1(); ++it1) { for (spmd::reverse_iterator2 it2 = it1.rbegin(); it2 != it1.rend(); ++it2) { std::cout << it2.index1() << " " << it2.index2() << ": " << *it2 << std::endl; } } std::cout << std::endl << std::endl; } ---------------------------------------------------- -- ----------------------------------------------------------------------- Nikos Platis e-mail: nplatis(a)di.uoa.gr Department of Informatics tel: +30 210-727-5106 University of Athens fax: +30 210-727-5114 "The empires of the future are the empires of the mind." - W. Churchill -----------------------------------------------------------------------

1 0

boost regex 1.32/VC7.1 compile problem
by frank fu 02 Mar '05

02 Mar '05

I am trying to move my code from vc6.0 to vc71. Here is the part of code using boost regex: boost::wregex ee(L"[E|e],(\\w+),(.+)$"); boost::wcmatch mr; TString value=L"some char"; if (boost::regex_match(value, mr, ee)) { ... } Those code compiled with UNICODE and was ok on vc6.0. But when I compile with VC71, it gives me error c2664: ============ d:\s\AEM\AEM6.0\source\AEMCore\AEMRulesCfgReg.cpp(176): error C2664: 'bool boost::regex_match<std::char_traits<wchar_t>,std::allocator<_Ty>,std::allocator<boost::sub_match<BidiIterator>>,wchar_t,traits,Allocator>(const std::basic_string<_Elem,_Traits,_Ax> &,boost::match_results<std::basic_string<_Elem,_Traits,_Ax>::const_iterator,std::allocator<boost::sub_match<BidiIterator>>> &,const boost::reg_expression<charT,traits,Allocator> &,boost::regex_constants::match_flag_type)' : cannot convert parameter 2 from 'boost::wcmatch' to 'boost::match_results<BidiIterator,Allocator> &' with [ _Ty=wchar_t, BidiIterator=const unsigned short *, traits=boost::regex_traits<wchar_t>, Allocator=std::allocator<wchar_t>, _Elem=wchar_t, _Traits=std::char_traits<wchar_t>, _Ax=std::allocator<wchar_t>, charT=wchar_t ] and [ BidiIterator=std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>>::const_iterator, Allocator=std::allocator<boost::sub_match<const unsigned short *>> ] ================== also, I got lots warning C4018: '<' : signed/unsigned mismatch, although that's ok for me right now. Thanks for any help. frank

3 4

Weird behaviour when changing states in boost::fsm
by Jan Eickmann 02 Mar '05

02 Mar '05

Hi, I realized a weird behaviour when using boost::fsm. Here's my state setup: I have a parent state which has two substates. One is basicly a noop as InnerInitial, the other is and OptionsDialog. Now, in a custom_reaction's react function in the parent state, I call transit<OptionsDialog> in order to go to the OptionsDialog-substate. What happens is that the parentstate itself is destroyed and reentered, then it enters the OptionsDialog state. Something similar happens when I use transit<ParentState> to go back to the ParentState (which should automatically enter the InnerInitial, no?). It exits the OptionsDialog, then exits ParentState and reenters ParentState (I haven't checked if it enters the InnerInitial). If in the OptionsDialog, I do a transit<NoOpInnerInitial> it just goes there without first destroying the parent-state (just exits OptionsDialog but not ParentState). Is this the expected behaviour, if so, could someone explain how to get the desired behaviour? Thanks, Jan Eickmann

2 1

[program_options] parsing multiple times for different sets of opts
by Liam Routt 02 Mar '05

02 Mar '05

I'm very hopeful that program_options will simplify the mess that is the options parsing in our application, especially as it should allow us to handle command-line, config-fle, and environment-variable options in one logical step. This is all good. My initial tests have run into a small hitch, and I'm wondering whether there is a way to do what I have been trying to do: We have a core engine which has the largest options requirements. For testing, mainly, we wrap that core engine and provide a user utility. I'd like the core engine to be able to handle a broad set of options from all three directions (config, command line, environment). Easy. I'd also like the wrapping utility to have its own (smaller) set of options that control what it does. Ideally this should be as logically seperate from the engine as possible. At present we do this by simply not using command-line options for the core engine, and only using command-line options for the wrapping utility, but that is the fucntionality I most want to add at the moment - the use of multiple methods of setting (most) options at both levels (wrapper and core engine). What I would most like to be able to do is process the command line (for example) twice - once in the outer wrapping context, looking for the options that are relvant there, and once in the core engine, looking for the options there. When I try a test app with this structure, though, I get exceptions thrown when any options are encountered that are not included in both the options_descriptions used, which sort of defeats what I'm trying to do - I want to have two distinct sets of options: one for the wrapper, and one for the core, with (little or) no overlap. I would be happy if I could disable the exception behaviour, allowing the processing to complete and report to me that it encountered some unknown options along the way. This would mean that I would risk ignoring some unknown options in both passes, but I could live with that, I think. I can see a possible alternative, which requires me to pass the wrapper's options_description to the core engine, get it all parsed there, and pass back the map for examination by the wrapper. This would make some additional work for me, but would probably work fine. I guess I'd just like to know whether the other way of approaching things is going to be supported, or whether there is yet another approach I should consider? Take care, Liam -- Liam Routt Ph: (03) 8344-1315 Research Programmer caligari(a)cs.mu.oz.au Computer Science, Melbourne University (or liam(a)routt.net)

2 1

RE: [Boost-users] Weird behaviour when changing states in boost::fsm
by Darryl Green 02 Mar '05

02 Mar '05

Hi Jan, > -----Original Message----- > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Jan Eickmann > Subject: [Boost-users] Weird behaviour when changing states > in boost::fsm > > I have a parent state which has two substates. One is basicly > a noop as > InnerInitial, the other is and OptionsDialog. > Now, in a custom_reaction's react function in the parent > state, I call > transit<OptionsDialog> in order to go to the OptionsDialog-substate. > What happens is that the parentstate itself is destroyed and > reentered, > then it enters the OptionsDialog state. > Something similar happens when I use transit<ParentState> to > go back to > the ParentState (which should automatically enter the InnerInitial, > no?). It exits the OptionsDialog, then exits ParentState and reenters > ParentState (I haven't checked if it enters the InnerInitial). > If in the OptionsDialog, I do a transit<NoOpInnerInitial> it > just goes > there without first destroying the parent-state (just exits > OptionsDialog but not ParentState). > > Is this the expected behaviour, if so, could someone explain > how to get > the desired behaviour? Yes it is expected. See transit() in reference. In summary, calling transit will always exit the current state, and keep exiting back to the icos of the current state and the final state, then work in again from there to reach the destination state. Note tht exit = destruct, enter = construct. There isn't enough information to properly answer your question. For a start I don't properly understand your fsm, or whether this is just a minimal example to illustrate your problem. The obvious answer is that you should just make the inner states react to the event you currently have the parent reacting to. Using the form of custom reaction that allows a transition context and member function to be specified, you can make the transition context the parent state and a member function of the parent can perform action. Of course, if your reason for using a custom reaction is to implement some form of guard, this won't entirely solve the problem. The other way to look at this is to see if you can replace the guard with more states/events (the reaction to the original event conditionally produces the appropriate more specific event to cause the correct action and final state). hth Darryl. ########################################################################## This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. ##########################################################################

1 0