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

boost.crc
by renjh 15 Sep '06

15 Sep '06

My truncated polynominal has 83 bits, does boost.crc support it? I hope to get an example for that.

1 0

Boost::signals MT question
by Mark Wilson 14 Sep '06

14 Sep '06

Does the fact that bjam builds a "*-mt*" version of signals indicate that signals is now thread-safe? If it isn't, why is the "*-mt*" version built? Thanks, Mark

2 1

best of both worlds: ptr_vector and multi_array
by Levent Yilmaz 14 Sep '06

14 Sep '06

This question is perhaps, rather a feature request from multi_array: ptr_vector (of pointer container library) is nice but it is not multi dimensional, multi_array is nice but it is not, well, ptr_multi_array. For any single dimensional random access array there is multi_array_ref: /**/ boost::array<size_t,2> shape = {4,4}; std::vector<int> v(16); boost::multi_array_ref<int,2> mav(&v[0],shape); /**/ But, this (&v[0]) wouldn't work with ptr_vector, due to the indirected interface of pointer containers. I was thinking, one way of achieving this is to have multi_array_ref work with any random access container, rather than just plain C array. The above example would be: /**/ boost::array<size_t,2> shape = {4,4}; std::vector<int> v(16); boost::multi_array_ref< std::vector<int>, 2 > mav(v,shape); /**/ Note the change of the first template parameter of multi_array_ref from the element type to, container type. This way, it would similarly be possible to use it with ptr_vector, or any other random access container for that matter: /**/ class foo; boost::array<size_t,2> shape = {4,4}; boost::ptr_vector<foo> v(16); boost::multi_array_ref< boost::ptr_vector<foo>, 2 > mav(v,shape); /**/ The thing is, I am not sure if this can be done with the multi_array library. Or, what other ways are there to get a multi dimenstional pointer container? thanks - Levent.

1 0

Re: [Boost-users] [program_options] Linker error with MSVS 7.1
by Scott 14 Sep '06

14 Sep '06

As a follow up to my previous email regarding UNICODE problems, I tried the following on a whim: int _tmain(int argc, _TCHAR* argv[]) { try { static char* argvv[] = { "help" }; po::options_description desc("Allowed options"); desc.add_options() ("help", "produce help message") ("set,s", po::value< std::vector<std::string> >(), "Set one or more node values, overriding stored value in config file") ; po::variables_map vm; po::store(po::parse_command_line(argc, argvv, desc), vm); The program above compiles. If I switch from argvv (ANSI) to argv (UNICODE) in parse_command_line(), I get all those linker errors. The docs seem to indicate that UNICODE parsing is supported, so what am I missing? Thanks, Scott

1 0

[program_options] Linker error with MSVS 7.1
by Scott 14 Sep '06

14 Sep '06

I'm trying to link a win32 console app using program options. I have previously build boost with bjam using MSVS 7.1. My program, which is pretty basic and taken from first.cpp looks something like this: int _tmain(int argc, _TCHAR* argv[]) { try { po::options_description desc("Allowed options"); desc.add_options() ("help", "produce help message") ("set,s", po::value< std::vector<std::string> >(), "Set one or more node values, overriding stored value in config file") ; po::variables_map vm; po::store(po::parse_command_line(argc, argv, desc), vm); po::notify(vm); if (vm.count("help")) { std::cout << desc << "\n"; } [snip] The program is compiled as _UNICODE. It seems to compile ok, though I get the following warnings: ..\API\inc\boost\program_options\errors.hpp(21) : warning C4275: non dll-interface class 'std::logic_error' used as base for dll-interface class 'boost::program_options::error' C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\stdexcept(14) : see declaration of 'std::logic_error' ..\API\inc\boost\program_options\errors.hpp(21) : see declaration of 'boost::program_options::error' ..\API\inc\boost\program_options\variables_map.hpp(130) : warning C4273: 'boost::program_options::store' : inconsistent dll linkage ..\API\inc\boost\program_options\variables_map.hpp(138) : warning C4273: 'boost::program_options::store' : inconsistent dll linkage But then I get linker errors, like this: NwEngine.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall boost::program_options::basic_parsed_options<unsigned short>::~basic_parsed_options<unsigned short>(void)" (__imp_??1?$basic_parsed_options@G@program_options@boost@@QAE@XZ) referenced in function _wmain I have the following lib files in my lib path: boost_program_options-vc71-mt-1_33_1.lib boost_program_options-vc71-mt-gd-1_33_1.lib libboost_program_options-vc71-mt-1_33_1.lib libboost_program_options-vc71-mt-gd-1_33_1.lib libboost_program_options-vc71-mt-s-1_33_1.lib libboost_program_options-vc71-mt-sgd-1_33_1.lib Am I supposed to do something special to link to them? I was under the impression that it worked similar to boost regex and auto-linked. Thanks, Scott

1 0

program_options application crashes when printing options descriptions
by Matt Schuckmann 14 Sep '06

14 Sep '06

At some point many of my applications that use the boost.program_options libraries started crashing when they attempt to print the options descriptions i.e. cout << opt_desc; I believe the problem started when we upgraded to boost 1.33.1 from 1.32.0 and were using MSVC 7.1. I'm not trying to figure out the problem using boost 1.33.1 using MSVC 8.0. Here is the deal if I run the debug version of one of my apps with the standard --help option it runs fine. If I run the release version part of the help message is displayed but then the application crashes If I attempt to debug the problem by launching the debug version of application from the MS debugger I get a debug assertion failed in xstring in a _SCL_SECURE_VALIDATE_RANGE check on operator += (basically the new secure checked iterators MS had introduced are complaining about an out of range iterator). Looking at the call stack the problem stemmed from line 361 of options_description.cpp (the format_paragraph function). Basically it looks like the program_options library is running afoul of the new checked iterators in MSVC 8.0 but since I do know we experienced a problem in using MSVC7.1 I think the problem is more insidious than a boundary condition check is overstepping an iterator range. Has anybody else experienced this type of problem or have any idea's on how to fix it? Thanks Matt S. FYI here is the start of my main including my add_options, store, and notify calls and the call to display the help message. o::options_description options_desc("Options"); po::variables_map vm; int _tmain(int argc, TCHAR* argv[]) { int nRetCode = 0; // initialize MFC and print and error on failure if (!AfxWinInit(::GetModuleHandle(NULL), NULL, ::GetCommandLine(), 0)) { // TODO: change error code to suit your needs _tprintf(_T("Fatal Error: MFC initialization failed\n")); nRetCode = 1; } else { //Setup our program options. options_desc.add_options() ("help,h", "Produce help message") ("cal_file,c", po::value< std::string >(), "Add use this characterization file, overrides any other options(-I)" ) ("output_file,o", po::value< std::string >(), "File to write to." ) ("input_file,i", po::value< std::string >(), "Tab delimited file to read from that characterizes frames to generate." ) ("ideal_perspective,I", "Use the default ideal perspective cubic characterization." ) ("ideal_fisheye,F", "Use the default ideal fisheye cubic characterization." ) ("num_video_streams,s", po::value<unsigned int>(), "Number of video streams to create in the iPAN file." ) ("no_gps_stream", "Don't generate a GPS stream, but do put GPS data in JPEG headers if input indicates it.") ("no_att_stream", "Don't generate a attitude stream, but do put attitude data in JPEG headers if input indicates it." ) // ("blocks,b", "Produce synchronization blocks") ; po::store( parse_command_line(argc, argv, options_desc), vm ); po::notify(vm); if( vm.count("help") ) { cout << options_desc << "\n"; return 1; }

2 3

Re: [Boost-users] Library Interface Design
by Sohail Somani 14 Sep '06

14 Sep '06

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of > David Abrahams > Sent: Thursday, September 14, 2006 4:07 AM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] Library Interface Design > > Scott Meyers <usenet(a)aristeia.com> writes: > > > - It has to be easy to find and fix mistakes resulting from > incorrect > > usage of an API. For example, APIs should throw exceptions clearly > > describing what needs to be done to fix the problems. > > It's always better to detect the problems at compile-time, at least in > the world of statically-checked languages. I would echo that this statement is also true for dynamically-checked languages in the obvious way. I think my python code is much easier to read if there is only one way to get a good object.

1 0

Newbie Jamfile author question
by Drumheller, Michael 14 Sep '06

14 Sep '06

(Thank you to Rene and David.) Rene, Are you referring to the parsing phase? Such behavior would not seem so harmful there (to me anyway). But if I add some actions, they get done twice, which does seem very harmful. I mean, it's like the updating phase gets done twice, not just the parsing. Here is another example Jamfile: ------------------------ begin Jamfile-------------------------- rule MyRule { Echo $(1) ; MyAction $(1) ; Depends all : $(1) ; } actions MyAction { touch $(1) ; echo $(1) andAgain ; } MyRule HelloAgain ; ------------------------ end Jamfile-------------------------- Here is the output: ------------------------ begin output-------------------------- c:/deleteme=> bjam HelloAgain HelloAgain ...found 9 targets... ...updating 1 target... MyAction HelloAgain HelloAgain andAgain ; MyAction HelloAgain HelloAgain andAgain ; ...updated 1 target... ------------------------ end Jamfile-------------------------- If the (lowercase) echo in MyAction had been a compilation, then I would have compiled all my files twice. (In fact, that is just the situation that led me construct this simple example.) Does bjam's behavior still seem OK to you? (I realize that bjam is used all the time by a zillion people--there must be somethng I'm doing wrong, or something I'm just not understanding--I'm sorry to be taking everyone's time with this.) Thanks again, Mike D. >>> -----Original Message----- >>> From: boost-users-request(a)lists.boost.org >>> [mailto:boost-users-request@lists.boost.org] >>> Sent: Wednesday, September 13, 2006 3:37 PM >>> To: boost-users(a)lists.boost.org >>> Subject: Boost-users Digest, Vol 1026, Issue 7 >>> >>> Send Boost-users mailing list submissions to >>> boost-users(a)lists.boost.org >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> http://lists.boost.org/mailman/listinfo.cgi/boost-users >>> or, via email, send a message with subject or body 'help' to >>> boost-users-request(a)lists.boost.org >>> >>> You can reach the person managing the list at >>> boost-users-owner(a)lists.boost.org >>> >>> When replying, please edit your Subject line so it is more >>> specific than "Re: Contents of Boost-users digest..." >>> >>> >>> Today's Topics: >>> >>> 1. Re: bind, and member function with a parameter >>> (Arkadiy Vertleyb) >>> 2. multi_index library, dynamic number of indices ( Ad?n >>> Cosgaya ) >>> 3. Re: Newbie Jamfile author question (David Klein) >>> 4. Re: bind, and member function with a parameter >>> (Alexander Shyrokov) >>> 5. Re: Newbie Jamfile author question (Rene Rivera) >>> 6. mingw, bjam and Boost.Python tutorial problem >>> (Import Error) >>> (Sune Mai) >>> 7. Re: multi_index library, dynamic number of indices >>> (JOAQUIN LOPEZ MU?Z) >>> 8. Re: Library Interface Design (Jens Theisen) >>> >>> >>> ------------------------------------------------------------ >>> ---------- >>> >>> Message: 1 >>> Date: Wed, 13 Sep 2006 15:55:46 -0400 >>> From: "Arkadiy Vertleyb" <vertleyb(a)hotmail.com> >>> Subject: Re: [Boost-users] bind, and member function with a >>> parameter >>> To: boost-users(a)lists.boost.org >>> Message-ID: <ee9nob$v44$1(a)sea.gmane.org> >>> >>> "Peter Dimov" <pdimov(a)mmltd.net> wrote >>> >>> >> Just an idea -- is it possible to have one universal set of >>> >> placeholders in boost? Bind, Lambda, MPL, and possibly other >>> >> libraries could then use some sort of redirection to their >>> >> specialized placeholders... Might help to avoid some confusion. >>> > >>> > This isn't possible in general >>> >>> Not sure I understand why... >>> >>> AFAIU, placeholders are either types (MPL), in which case >>> some sort of traits can be used to redirect from, say, >>> boost::_1 to mpl::_1, or const objects (Bind, Lambda), in >>> which case some extra indirection through overload could >>> possibly do the trick something like: >>> >>> template<class T> T redirect(const T&); >>> template<int n> bind::arg<n> redirect(const boost::arg<n>&); >>> >>> Regards, >>> Arkadiy >>> >>> >>> >>> >>> >>> >>> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Wed, 13 Sep 2006 17:37:44 -0300 >>> From: " Ad?n Cosgaya " <acosgaya(a)gmail.com> >>> Subject: [Boost-users] multi_index library, dynamic number >>> of indices >>> To: boost-users(a)lists.boost.org >>> Message-ID: >>> <df7e9fd90609131337u7844f495i1e857c265cb673b1(a)mail.gmail.com> >>> Content-Type: text/plain; charset="iso-8859-1" >>> >>> Hi, I am using multi_index to keep a set of d-dimensional >>> points, where each point is a vector inside the multi_index >>> container. >>> e.g (3,5,8,9,5) is a 5-dimensional point (but this can vary >>> and be 3-d, 7-d, etc..). I need to have the set sorted by >>> each of the dimensions. >>> >>> I can do it statically if I know in advance how many >>> dimensions I have, but I don't know how to make dynamic to >>> any number of dimensions. >>> >>> I currently have: >>> >>> template<int N> >>> struct nth_coordinate >>> { >>> typedef int result_type; >>> >>> int operator()(const vector<int>& x)const >>> { >>> return x[N]; >>> } >>> }; >>> >>> typedef multi_index_container< >>> vector<int>, >>> indexed_by< >>> sequenced<>, >>> ordered_non_unique<nth_coordinate<0> >, >>> ordered_non_unique<nth_coordinate<1> >, >>> ordered_non_unique<nth_coordinate<2> >, >>> ordered_non_unique<nth_coordinate<3> >, >>> ordered_non_unique<nth_coordinate<4> > >>> > >>> > multi_index_Points; >>> >>> is it possible do it without explicitly saying how many >>> indices do I need? >>> >>> Also, I am trying to create a function which receives as a >>> parameter the dimension I want to work with, but it seems >>> that I need to explicitly say the number of the index in >>> nth_index (it obviously needs a constant). For >>> example: >>> >>> int median (int d){ >>> ... >>> typedef multi_index_Points::nth_index< d >::type >>> multi_index_Points_it; ===> I would like to pass "d" as >>> a parameter >>> ... >>> } >>> >>> is there any workaround for this issues? >>> >>> would you mind pointing me in the right direction with an >>> example of how to do it with thelibrary? >>> >>> thanks in advance... >>> >>> Adan >>>

3 2

[test] Generate xml from unit tests
by Chris Weed 14 Sep '06

14 Sep '06

Hi, I would like to generate xml output from my test. The boost libraries seem to have an executable that converts the test output to xml. Is there a way to do it directly from the testing library? Chris

2 4

build regex with visual studio 2005
by Lars Schouw 14 Sep '06

14 Sep '06

I have a problem. When I build boost with visual studio 2005 regex does not get build. Anyidea how I enable this? I tried with --with-regex but this did not change I used bjam "-sTOOLS=vc-8_0" Regards Lars Schouw --------------------------------- Get your email and more, right on the new Yahoo.com

2 1