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

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

[BGL] Bipartite matching
by Swidan, Firas, Ph.D. 14 Sep '06

14 Sep '06

Hi, I was wondering if BGL contains algorithms for (weighted and unweighted) bipartite matching; the documentation site ( http://www.boost.org/libs/graph/doc/table_of_contents.html) shows no trace of such algorithms, neither does googling the users mailing list. Thanks for the help, Firas.

2 1

[Boost.Signal]
by Wu Yinghui, Freddie 14 Sep '06

14 Sep '06

Hi all, I'm a happy user of Boost.Signal, as it brings great power to our software design in terms of loosening all the coupling between components. However, I recently come across a case where a single-shot slot is desired (i.e., a signal-slot connection that is automatically disconnected once the signal is invoked for once). In our current implementation, we have to keep boost::signals::connection object around with the slot implementation, so that it can disconnect it after the first invocation. However, we have this problem of boost::signals::connection management, since one signal may be connected to different signals and we have problem identifying the correct connection to be disconnected. So my question is: Is there any easier way (i.e., ways that doesn't involve the implementation of the slot function itself) that I can add a single-shot signal-slot connection? Any suggestion is appreciated. Cheers, Freddie -- Wu Yinghui, Freddie Research & Development Senior Software Engineer Volume Interactions Pte Ltd 1 Kim Seng Promenade, #12-01 Great World City East Tower Singapore 237994 Tel: +65 62226962 (Ext 216) Fax: +65 62226215 Email: yhwu(a)volumeinteractions.com URL: http://www.volumeinteractions.com Important: This message is intended for the recipient(s) addressed above. It contains privileged and confidential information. If you are not the intended recipient, please notify the sender immediately by replying to this message and then delete it from your system. You must not read, copy, use, or disseminate this communication in any form. Thank you.

1 0

GraphViz sample help?
by Ramy Sadek 14 Sep '06

14 Sep '06

Hi All, I'm trying to create a simple C++ program that loads graphviz files (with arbitrary properties) into a mutable BGL graph by using a dynamic property map. This seemingly simple task has become a much larger task than I expected. So much so that I believe I'm barking up the wrong tree. I have been studying basic_graph<> in the python examples, trying to model my code after it, but several details elude me. So, I'm writing to ask if anyone has an example code that does this and would be kind enough to share it. It would be most helpful to me to see the concrete class definitions alongside the generic ones, to understand how to use them in my code. Thanks in advance! -Ramy

1 0

mingw, bjam and Boost.Python tutorial problem (Import Error)
by Sune Mai 14 Sep '06

14 Sep '06

Hi, I have a problem exactly similar to what is described in great detail in an earlier post to this list (with the same title): http://lists.boost.org/boost-users/2006/02/17367.php Unfortunatly, the thread ends without a solution... Just as in the above post, the dll "hello.pyd" built with bjam (following the Boost.Python tutorial) doesn't export inithello. A manual build does, and the resulting "hello.pyd" works fine when imported into python. One observation that might help pinpoint the problem is that the sizes of "hello.obj" and "hello.pyd", generated by the bjam build, are very different: hello.obj: 766 kB hello.pyd: 13 kB In the manual build they are both large (~800 kB). If any further info is needed please tell me, and I'll see what I can do - but please be very specific, since I'm an absolute newbie in the world of boost, and not a very experienced programmer in general either. Regards \Sune Mai

2 1

Re: [Boost-users] multi_index library, dynamic number of indices
by JOAQUIN LOPEZ MU?Z 13 Sep '06

13 Sep '06

Adán Cosgaya ha escrito: > 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? Well, the short answer is no, you can't: multi_index_container is a compile-time construct, you cannot delay the specification to run time. That said, you can sort of have a kind of rudimentary dynamicity if you know the maximum number of coordinates and don't mind wasting memory and cpu cycles for those cases where the number of coordinates is less: rewrite nth_coordinate so as to not incur out of bounds accesses: template<int N> struct nth_coordinate { typedef int result_type; int operator()(const vector<int>& x)const { if(x.size()>N)return x[N]; else return 0; } }; and add as many indices to multi_index_Points as the maximum number of coordinates you know you're going to handle. > 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? Well, you're experiencing a typical clash between compile-time (or static) and run-time (or dynamic) polymorphisn. In the particular case of your median function, what you propose cannot work as is because multi_index_Points_it would be of a *different* type for each d! There are some techniques to bridge the static and dynamic worlds, all of them involving some sort of "type erasure", i.e. absorbing several different types into one polymorphic proxy type. The following is a possible realization of a dynamic median facility: class compile_time_median_table { private: template<int D> static int compile_time_median() { typedef typename multi_index_Points:: nth_index<D>::type multi_index_Points_it; ... } std::map<int,int (*)()> m; public: compile_time_median_table() { m[0]=compile_time_median<0>; ... m[6]=compile_time_median<6>; } int operator()(int d) { return m[d](); } }; int median(int d) { static compile_time_median_table t; return t(d); } Here, we perform the type erasure by storing a pointer to every different instantiation of compile_time_median<D> and using those within a proxy function int median(int) which provides the illusion of runtime polymorphism. Maybe this sort of approach does suit your needs. Best regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0