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

Re: [Boost-users] Version Mgmt classes/algorithms
by Rich Johnson 27 Jan '06

27 Jan '06

> > For what it's worth, we use namespaces to do version management and > this works quite well for us. This technique may not work for you > but a brief description of it is in Stroustrup's D&E in section > 17.4.4 (Using Namespaces to Manage Releases). We've done a lot of > work in this area, just not sure if it's what you're interested in. Hmm...I'll have to take a look. Do you do use it with dynamically loaded modules--dlopen(), dlsym(), etc.?

2 1

boost::serialisation - portable_binary_oarchive not part of library
by Oliver.Kowalke＠infineon.com 27 Jan '06

27 Jan '06

Hallo, why is portable_binary_oarchive and portable_binary_iarchive only contained in the examples not part of the library interface? Regards, Oliver

2 1

Boost threads- how do I simultaneously check the lock on two or more mutexes?
by Terence Wilson 26 Jan '06

26 Jan '06

boost::try_mutex M1, M2; boost::try_mutex::scoped_try_lock lockx(M1, false); boost::try_mutex::scoped_try_lock locky(M2, false); I would like to be able to atomically check that at least one lock can be made: assert(lockx.try_lock() || locky.try_lock()); In Win32 I would use WaitForMultipleObjects. Thanks in advance.

1 0

Comments on the usability of program_options
by Steve Byan 26 Jan '06

26 Jan '06

First let me mention that I greatly appreciate all the work done by the contributors to Boost. The library has been extremely helpful to me both as a class and template library and as a learning tool for template meta-programming. In the spirit of constructive criticism, I'd like to offer a few usability observations arising from my first attempt to use program_options. I appreciate the flexibility, extensive feature set, and the extensibility of the library. I particularly like the unification of command-line options with configuration files; this is a very handy feature. However, I think the unification of program arguments with program options is less successful. I think the library would be better if arguments were a separate concept. Unifying program arguments with program options has these consequences: 1) The error message produced by an excessive number of arguments is opaque to most users. The error message produced is "Error: unknown option foo", which I think would be better phrased as something along the lines of "Error: too many arguments". Since program_options doesn't distinguish options from arguments, it can't easily produce a better diagnostic message. 2) The usage description by default describes command-line arguments as options. E.g. the usage message is something like this: Supported options: -h [ --help ] produce this help message --device-file arg scsi pass-thru device special file To hide the "argument options" in the help message, program_options supports multiple options_descriptions, but puts the responsibility for hiding the "argument options" on the user of the library, and, unlike normal options, does not automatically provide a description of the argument in the help message. If arguments were instead treated as first-class concept instead of a mutant form of an option, the library could automatically handle these issues. 3) Somewhat related to issue #2, program_options doesn't generate a concise usage description help-message from the grammar. For example, it would be nice if options_desciption could provide a string like this: Usage: scsi_tool [-h | --help] [-v | --verbose] <device-file> [<output-file>] Additionally, it would be nice if program_options handled more of the validation and error reporting. Currently the user is responsible for checking for required arguments and generating an error if they are not supplied, and for coding the generation of a usage message when the options and arguments don't conform to the specified grammar. An example of an alternative design which addresses these concerns (but which lacks many of the more sophisticated features of program_options) is Ole Laursen's commandoptions <http:// www.cs.aau.dk/~olau/commandoptions/> Regards, -Steve -------- Steve Byan <smb(a)egenera.com> Software Architect Egenera, Inc. 165 Forest Street Marlboro, MA 01752 (508) 858-3125

3 2

Re: [Boost-users] program_options requires non-const argv
by Merrill Cornish 26 Jan '06

26 Jan '06

Steve, I ran into the same problem. Once I thought about it, I realized I had _never_ seen a C or C++ main() function prototype defined with a const second argument. I think I remember that one of the traditional C getopt() function variants actually munges the argument list by removing that arguments it recognizes, leaving anything else for direct processing by the program. I'm guessing program_options is therefore tacitly assuming the second argument is non-const also. Merrill

4 3

spirit::, token_node_d, xml-tree
by elviin 26 Jan '06

26 Jan '06

Hello there. I'd like to use non-ast tree. I'm also using the tree_to_xml function to generate xml code. Plus my own grammar. The problem is with the token_node_d directive. I assumed that this directive merge the parsed code to an one node. At this time my parser works for me very fine except the tree because there are missing value objects in xml structure. So it seems that the whole tree is empty:/ I can reproduce that state with the example file parse_tree_calc1.cpp: The correct output from the tree_to_xml function is following when parsing "1": <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE parsetree SYSTEM "parsetree.dtd">  <parsetree version="1.0"> <parsenode rule="expression"> <parsenode rule="term"> <parsenode rule="factor"> <parsenode rule="integer"> <parsenode rule="integer"> <value>1</value> <<<<======== it's OK here </parsenode> </parsenode> </parsenode> </parsenode> </parsenode> </parsetree> parsing succeeded ... and the corresponfing code/rules: integer = lexeme_d[ token_node_d[ (!ch_p('-') >> +digit_p) ] ]; factor = integer | '(' >> expression >> ')' | ('-' >> factor); term = factor >> *( ('*' >> factor) | ('/' >> factor) ); expression = term >> *( ('+' >> term) | ('-' >> term) ); But if I move the token_node_d directive to another position, so that is similar to the problem with my grammar: integer = lexeme_d[ (!ch_p('-') >> +digit_p) ]; factor = token_node_d[integer] | '(' >> expression >> ')' | ('-' >> factor); term = factor >> *( ('*' >> factor) | ('/' >> factor) ); expression = term >> *( ('+' >> term) | ('-' >> term) ); ... then the XML structure looks like this. The "value" object are missing: <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE parsetree SYSTEM "parsetree.dtd">  <parsetree version="1.0"> <parsenode rule="expression"> <parsenode rule="term"> <parsenode rule="factor"> <parsenode rule="integer"> <<<<======== it is not OK here </parsenode> </parsenode> </parsenode> </parsenode> </parsetree> parsing succeeded Can anyone explain me why it is not possible to use the directive token_node_d like this token_node_d[integer]? I just want to group all the parsed text (integer) in one node. May I have to change the policy or to create proper typedefs. The problem is with hierarchy, that I want to group the parsed text only in the higher levels of parsing process. Thank you. Elviin

2 2

Weird regex compiler warnings with VC 7.1
by Alan Davies 26 Jan '06

26 Jan '06

Hello. I've come across a weird compiler warning when using the regex library on VC 7.1 (I think the problem also occurs in VC 7.0). I'm using Boost 1.33.1 The code below throws up warnings. Removing the min() call from main, or changing a, b and c's type to anything else (e.g. short) gets rid of the warnings. The offending line is in regex_format.hpp (it appears twice in that file): std::ptrdiff_t len = (std::min)(static_cast<std::ptrdiff_t>(2), ::boost::re_detail::distance(m_position, m_end)); Putting a static cast around the distance() call makes no difference, but splitting it into two lines as follows gets rid of the warning: std::ptrdiff_t distance = ::boost::re_detail::distance(m_position, m_end); std::ptrdiff_t len = (std::min)(static_cast<std::ptrdiff_t>(2), distance); This makes absolutely no sense to me! My code and the warnings are below. #include "boost/regex.hpp" #include <iostream> #include <string> int main(int argc, char *argv[]) { std::string hello = "hello world!"; boost::regex multipleSpacesRegex("([[:space:]]){2,}"); int a=1, b=2; // Remove the next line to get rid of the warnings int c=(std::min)(a,b); hello = boost::regex_replace(hello, multipleSpacesRegex, "$1"); std::cout << hello << std::endl; return 0; } ------ Build started: Project: regex_test, Configuration: Debug Win32 ------ Compiling... main.cpp f:\dev\include\boost\regex\v4\regex_format.hpp(246) : warning C4244: 'argument' : conversion from 'std::iterator_traits<_Iter>::difference_type' to 'const int', possible loss of data with [ _Iter=const char * ] f:\dev\include\boost\regex\v4\sub_match.hpp(130) : while compiling class-template member function 'void boost::re_detail::basic_regex_formatter<OutputIterator,Results,traits>::format_perl(void)' with [ OutputIterator=boost::re_detail::string_out_iterator<std::basic_string<char,std::char_traits<char>,std::allocator<char>>>, Results=boost::match_results<std::basic_string<char,std::char_traits<char>,std::allocator<char>>::const_iterator>, traits=boost::regex_traits_wrapper<boost::regex_traits<char>> ] c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\vector(152) : while compiling class-template member function 'void boost::re_detail::basic_regex_formatter<OutputIterator,Results,traits>::format_all(void)' with [ OutputIterator=boost::re_detail::string_out_iterator<std::basic_string<char,std::char_traits<char>,std::allocator<char>>>, Results=boost::match_results<std::basic_string<char,std::char_traits<char>,std::allocator<char>>::const_iterator>, traits=boost::regex_traits_wrapper<boost::regex_traits<char>> ] c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xstring(542) : while compiling class-template member function 'boost::re_detail::string_out_iterator<S> boost::re_detail::basic_regex_formatter<OutputIterator,Results,traits>::format(const boost::re_detail::basic_regex_formatter<OutputIterator,Results,traits>::char_type *,const boost::re_detail::basic_regex_formatter<OutputIterator,Results,traits>::char_type *,boost::regex_constants::match_flag_type)' with [ S=std::basic_string<char,std::char_traits<char>,std::allocator<char>>, OutputIterator=boost::re_detail::string_out_iterator<std::basic_string<char,std::char_traits<char>,std::allocator<char>>>, Results=boost::match_results<std::basic_string<char,std::char_traits<char>,std::allocator<char>>::const_iterator>, traits=boost::regex_traits_wrapper<boost::regex_traits<char>> ] f:\dev\include\boost\regex\v4\regex_format.hpp(568) : see reference to class template instantiation 'boost::re_detail::basic_regex_formatter<OutputIterator,Results,traits>' being compiled with [ OutputIterator=boost::re_detail::string_out_iterator<std::basic_string<char,std::char_traits<char>,std::allocator<char>>>, Results=boost::match_results<std::basic_string<char,std::char_traits<char>,std::allocator<char>>::const_iterator>, traits=boost::regex_traits_wrapper<boost::regex_traits<char>> ] f:\dev\include\boost\regex\v4\match_results.hpp(170) : see reference to function template instantiation 'OutputIterator boost::re_detail::regex_format_imp<OutputIterator,std::basic_string<_Elem,_Traits,_Ax>::const_iterator,std::vector<_Ty>::allocator_type,_Elem,boost::regex_traits_wrapper<BaseT>>(OutputIterator,const boost::match_results<BidiIterator> &,const charT *,const charT *,boost::regex_constants::match_flag_type,const traits &)' being compiled with [ OutputIterator=boost::re_detail::string_out_iterator<std::basic_string<char,std::char_traits<char>,std::allocator<char>>>, _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char>, _Ty=boost::sub_match<std::basic_string<char,std::char_traits<char>,std::allocator<char>>::const_iterator>, BaseT=boost::regex_traits<char>, BidiIterator=std::basic_string<char,std::char_traits<char>,std::allocator<char>>::const_iterator, charT=char, traits=boost::regex_traits_wrapper<boost::regex_traits<char>> ] f:\dev\include\boost\regex\v4\regex_replace.hpp(53) : see reference to function template instantiation 'OutputIterator boost::match_results<BidiIterator>::format<OutputIterator,boost::basic_regex<charT,traits>>(OutputIterator,const boost::match_results<BidiIterator>::st std::ptrdiff_t distance = ::boost::re_detail::distance(m_position, m_end); std::ptrdiff_t len = (std::min)(static_cast<std::ptrdiff_t>(2), distance); ring_type &,boost::regex_constants::match_flag_type,const RegexT &) const' being compiled with [ OutputIterator=boost::re_detail::string_out_iterator<std::basic_string<char,std::char_traits<char>,std::allocator<char>>>, BidiIterator=std::basic_string<char,std::char_traits<char>,std::allocator<char>>::const_iterator, charT=char, traits=boost::regex_traits<char>, RegexT=boost::basic_regex<char,boost::regex_traits<char>> ] f:\dev\include\boost\regex\v4\regex_replace.hpp(84) : see reference to function template instantiation 'OutputIterator boost::regex_replace<boost::re_detail::string_out_iterator<S>,std::basic_string<_Elem,_Traits,_Ax>::const_iterator,boost::regex_traits<charT>,char>(OutputIterator,BidirectionalIterator,BidirectionalIterator,const boost::basic_regex<charT,traits> &,const charT *,boost::regex_constants::match_flag_type)' being compiled with [ OutputIterator=boost::re_detail::string_out_iterator<std::basic_string<char,std::char_traits<char>,std::allocator<char>>>, S=std::basic_string<char,std::char_traits<char>,std::allocator<char>>, _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char>, charT=char, BidirectionalIterator=std::basic_string<char,std::char_traits<char>,std::allocator<char>>::const_iterator, traits=boost::regex_traits<char> ] f:\dev\projects\regex_test\main.cpp(17) : see reference to function template instantiation 'std::basic_string<_Elem,_Traits,_Ax> boost::regex_replace<boost::regex_traits<charT>,char>(const std::basic_string<_Elem,_Traits,_Ax> &,const boost::basic_regex<charT,traits> &,const charT *,boost::regex_constants::match_flag_type)' being compiled with [ _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char>, charT=char, traits=boost::regex_traits<char> ] f:\dev\include\boost\regex\v4\regex_format.hpp(330) : warning C4244: 'argument' : conversion from 'std::iterator_traits<_Iter>::difference_type' to 'const int', possible loss of data with [ _Iter=const char * ] f:\dev\include\boost\regex\v4\sub_match.hpp(130) : while compiling class-template member function 'void boost::re_detail::basic_regex_formatter<OutputIterator,Results,traits>::format_escape(void)' with [ OutputIterator=boost::re_detail::string_out_iterator<std::basic_string<char,std::char_traits<char>,std::allocator<char>>>, Results=boost::match_results<std::basic_string<char,std::char_traits<char>,std::allocator<char>>::const_iterator>, traits=boost::regex_traits_wrapper<boost::regex_traits<char>> ] f:\dev\include\boost\regex\v4\regex_format.hpp(401) : warning C4244: 'argument' : conversion from 'std::iterator_traits<_Iter>::difference_type' to 'const int', possible loss of data with [ _Iter=const char * ] f:\dev\include\boost\regex\v4\regex_format.hpp(422) : warning C4244: 'argument' : conversion from 'std::iterator_traits<_Iter>::difference_type' to 'const int', possible loss of data with [ _Iter=const char * ] f:\dev\include\boost\regex\v4\sub_match.hpp(130) : while compiling class-template member function 'void boost::re_detail::basic_regex_formatter<OutputIterator,Results,traits>::format_conditional(void)' with [ OutputIterator=boost::re_detail::string_out_iterator<std::basic_string<char,std::char_traits<char>,std::allocator<char>>>, Results=boost::match_results<std::basic_string<char,std::char_traits<char>,std::allocator<char>>::const_iterator>, traits=boost::regex_traits_wrapper<boost::regex_traits<char>> ] Linking... Build log was saved at "file://f:\dev\projects\regex_test\Debug\BuildLog.htm" regex_test - 0 error(s), 4 warning(s) ---------------------- Done ---------------------- Build: 1 succeeded, 0 failed, 0 skipped ___________________________________________________________ Yahoo! Photos NEW, now offering a quality print service from just 8p a photo http://uk.photos.yahoo.com

2 1

Re: [Boost-users] Version Mgmt classes/algorithms
by Rich Johnson 26 Jan '06

26 Jan '06

> I'm looking for a peer-reviewed solutions for managing versions (dll > compatibiity, data formats, etc.). If they exist, they're pretty > hard to find. ( FWIW, searches with the terms "version" or > "versioning" aren't very helpful :-() > [...snip...] > Have there been any discussions on this topic in the boost domain? > If so, how would I find it? > Any one have ideas where else I could look? Or any useful codewords to search > for. Oooh, dead air! Er, would anyone be interested in discussing this issue or reviewing a proposed base class? Feel free to contact me off-list. Thnx, ---rich

1 0

Re: [Boost-users] program_options requires non-const argv
by Sohail Somani 25 Jan '06

25 Jan '06

> I ran into the same problem. Once I thought about it, I realized > I had _never_ seen a C or C++ main() function prototype defined > with a const second argument. I do it too :)

1 0

[ptr_container] Bug in reverse iterators?
by Bill Buklis 25 Jan '06

25 Jan '06

Is this a bug or am I expecting it to do something that it shouldn't? Does anyone know a workaround for this (at least temporarily)? Compiler: VC 7.1 boost: 1.33.0 Description: The "base" function for reverse iterators in the pointer container classes do not return the underlying iterator type as expected. It appears that "base" returns a reverse iterator instead. This is not specific with ptr_vector. All the pointer containers seem to have this problem. #include <boost/ptr_container/ptr_vector.hpp> void sample() { // the type of the vector does not matter for this typedef boost::ptr_vector<DWORD> boostvector; boostvector boostvec; boostvector::reverse_iterator rboostIt = boostvec.rbegin(); // The following line does NOT compile. boostvector::iterator boostIt = rboostIt.base(); // For comparison of code that DOES compile typedef std::vector<DWORD> stdvector; stdvector stdvec; stdvector::reverse_iterator rstdIt = stdvec.rbegin(); // The following line DOES compile. stdvector::iterator stdIt = rstdIt.base(); }

2 4