- Boost - lists.boost.org

program_options bool_switch usage string ... how to prettify?
by Jonathan Graehl 16 Sep '04

16 Sep '04

I used to do this: >>bool help_flag; >>options.add_options() >> ("help,h","produce help message"); >>help_flag=vm.count("help") >> >>But it's possible to make a typo and everything isn't in one place (I >>prefer not to create a preprocessor macro to make "help" only occur once). >> >> > > > Now this is better: >bool help_flag; >options.add_options() > ("help,h", bool_switch(&help_flag),"produce help message"); > > > I tried it, and it works, but the usage string is a little odd: -h [ --help ] arg (=0) : produce help message -v [ --version ] arg (=0) : print the version number I would have hoped that the "arg (=0)" part would not be displayed at all for bool_switches. What would be the easiest way to suppress this? Similarly, is there some easy to use hook for customizing the "arg" to indicate the type of the data (similar to how the textual representation of the default argument can be changed, e.g. value<Infile>(&forests_file)->default_value(default_in,"STDIN"), so that I could get something like: "-f filename (=STDIN) :" instead of "-f arg (=STDIN) :"? -Jon p.s. should I post this sort of question in boost-users? I'd have to subscribe to it in order to post, so I didn't this time ...

3 6

program_options options description output
by Leo Goodstadt 16 Sep '04

16 Sep '04

Dear Volodya, Have you also given any consideration to how the descriptions wrap around if they are too long? For long descriptions, they can be quite ugly if left as is. At the moment, I output the description to a stringstream and wrap and indent everything post factum using the ": " in the output (I supply an optional line length for wrapping). This is fine and produces really nice output including embedded \n in the description text, but I wouldn't mind a more general solution. A minor nit pick, with option groups (chained options_description), the colons for the same group align but not across groups. Perhaps it might be possible to also dump the various fields of the output to some vector or even a templated callback object for greater flexibility of output. Llew Leo Goodstadt MRC Functional Genetics Unit Department of Human Anatomy and Genetics South Parks Road Oxford OX1 3QX United Kingdom leo.goodstadt(a)anatomy.oxford.ac.uk

2 1

FORMAL Review of "Output Formatter" library - 7 days left
by John Torjo 16 Sep '04

16 Sep '04

Dear boosters, For the FORMAL Review of "Output Formatter" - there are 7 days left. <side-note> There are quite a few hot topics at boost. So people might forget that there's a review going on ;) I would like to send a notification like this every 3 days. Boosters, please let me know if you find this ok or not. As I know, it hasn't been done before (announcing a format review multiple times) </side-note> Author: Reece Dunn Description: The outfmt library provides means to write and read containers/ arrays/ ranges (pairs of iterators) to/from STL streams. It also provides means to customize formatting as your write to/read from a stream: std::list<int> l; // { 1, 4, 10 } std::cout << formatob(l); // output: [ 1, 4, 10 ] std::cout << formatob(l).format("<",">"); // output: <1, 4, 10> Download: You can get it from the boost sandbox: http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/libs/outf… http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/out… As a convenience (only for the period of the review), you can also get it from http://www.torjo.com/code/outfmt.zip (153Kb) Review process: Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. When doing the formal review, please answer the following questions: 1. What is your evaluation of the design? 2. What is your evaluation of the implementation? 3. What is your evaluation of the documentation? 4. What is your evaluation of the potential usefulness of the library? 5. Did you try to use the library? With what compiler? Did you have any problems? 6. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 7. Are you knowledgeable about the problem domain? And most important, 8. Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. More on the formal review process: http://www.boost.org/more/formal_review_process.htm The Review Manager is: John Torjo john.lists(a)torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/

3 3

Still problems with current cvs (libs/python/src/converter/type_id.cpp)
by Neal Becker 16 Sep '04

16 Sep '04

gcc-3.3.3 (linux): In file included from /usr/local/src/boost.cvs/libs/python/src/converter/type_id.cpp:7: /usr/local/src/boost.cvs/boost/python/detail/decorated_type_id.hpp: In function `boost::python::detail::decorated_type_info boost::python::detail::decorated_type_id(boost::type<T>*)': /usr/local/src/boost.cvs/boost/python/detail/decorated_type_id.hpp:40: error: syntax error before `>' token /usr/local/src/boost.cvs/boost/python/detail/decorated_type_id.hpp:42: error: syntax error before `>' token

2 1

IOStreams endianness filter
by Tony Juricic 15 Sep '04

15 Sep '04

Just a thought. My tests so far were too limited to write a review (maybe reviews could last a little longer?), but in the process I stumbled on one image file in big-endian format and thought it may deserve to be mentioned here. Tony

2 4

Aaron's Informal Proposal for a Universal Demultiplexor for Boost
by Aaron W. LaFramboise 15 Sep '04

15 Sep '04

Well here it is. This is a very sketchy "brain dump" of the general form of demultiplexor I have been referring to. I think that it might be a basis for something eventually acceptable as a general demultiplexor for Boost. The general concept comes from a demultiplexor library that I have implemented privately (perhaps it could now be considered a prototype). I've tried to introduce the library design from a standpoint of rationale. This description is quite vague, but hopefully it will be a sufficient starting point. As always, comments of all kinds are appreciated. Aaron's Informal Proposal for a Universal Demultiplexor for Boost <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Multiplexing…> Aaron W. LaFramboise

6 18

behond IOStreams
by Carlo Wood 15 Sep '04

15 Sep '04

Hiya all. I already briefly discussed this with Jonathan Turkan and I understood he is interested to continue on a new project when IOStreams is accepted. I'd like to work together with him in this new project. In the past week I've done some "research" (between quotes because I still very new to this, can't call myself knowledgable yet). I'd start an early kick-off with this post ;). IOStreams can be seen as a library that allows one to define the following: Source --> filter --> filter --> Sink The relationship between the types involved can be delayed till runtime, but each individual type above has to be coded before that. It makes most sense to look at the above as instances instead of classes therefore (cause I did draw in the relationships between the different types already): Source_instance --> filter_instance --> filter_instance --> Sink_instance But for brevity I will not type the '_instance' part anymore. Obviously, we can have multiple Sources and Sinks at the same time: Source --> Sink Source --> filter --> filter --> Sink Source --> filter --> filter --> filter --> Sink Source --> filter --> Sink ... Each of these Sources will need to be handled by the Operating System; for example if they are sockets. In order to make an application work one will need "event demultiplexing" like forinstance is provided by select() or poll(). In order to write a framework that can "connect" the Sources and Sinks to this event demultiplexor in a flexible, portable and efficient way - a lot of design decisions need to be taken. Below I have made a list of a few topics that we can discuss, one by one - in order to make progress with these decisions. I am aware that there has been made a beginning with a design for such a framework already with boost in mind (see http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket) This design mainly considers sockets, but I think that a much wider approach is necessary (as we can discuss by following the points below). But of course we will use anything of this project that is useful. Another important source of experience is libACE. Although libACE provides everything we might need, it doesn't 'connect' well to boost; it has a lot of interfaces that are already done in boost but in another way. Also, I think that libACE is doing more than we need and not everything that we might want. If it were possible to write a more 'native' event demultiplexing library for boost then that will definitely add useful and additional functionality for the open source community. Apart from that, there is the license issue. I believe that the boost libraries are more 'free' then ACE, so in some cases ACE might not even be an option. ========================================================== Follows: Topics that can be discussed. I'd like to urge to stick to one Topic per thread. 1. Is there a need for this library? Should be a new effort like proposed or do we have to revive 'boost Sockets' and only build upon that without throwing things away? If "yes - there is a need for it and we might as well start with a clean plate": For the below I have chosen to phrase the topics as statements that I believe I can give sufficient argumentation for (if needed). 2. It is unavoidable that this library uses threads. 3. User programs compiled for platform A, and linking with a shared versions of this library - do not need to be able to run on platform B (with same architecture) without recompilation. 4. It is unacceptable that we would depend on other libraries (libevent, libACE) for this, except standard libraries (libc, libstdc++, socket, ws2_32, etc). 5. We should heavily lean on the expertise that is condensed in libACE for things like the following: There must be a concept "Event Handler" (the 'call back'). There must be a concept "Acceptor", "Connector" and "Handle" types. 6. The ideas about I/O filtering as discussed for Apache (see http://www.serverwatch.com/tutorials/article.php/1129721) need to be analyzed and probably implemented in IOStreams before we can really design the demultiplexor library. I will start a thread for each of these topics. Please reply to the first subject that you do not agree with (yet) only: it makes no sense to participate in discussions with a higher number if you disagree with the statement of one with a lower number :) Regards, -- Carlo Wood <carlo(a)alinoe.com>

10 54

Re:Re: [boost] serialization tests with intel 8.0 on linux
by Robert Ramey 15 Sep '04

15 Sep '04

Matthias Troyer wrote: >Shall I get you an account on a machine with that compiler? Latest test results seem to show this to be resolved. Thanks to whomever addressed. I'm sure it wasn't me. Robert Ramey

1 0

Re: Re: Re: IOStreams formal review -- extended
by Jonathan Turkanis 15 Sep '04

15 Sep '04

"Jonathan Turkanis" <technews(a)kangaroologic.com> wrote in message news:... > (i) buffering will be omitted, since it's hard to do correctly. > (ii) buffering will be provided, but mistakes in pointer arithmetic will cause > subtle errors > (iii) sub-optimal algorithms will be used. > > Note that two of Daryle's stream buffers suffer from defect (i). I didn't mean to imply that Daryle omitted buffering because it was hard -- I assume he had some other reason. Jonathan

1 0

Current cvs build broken (/boost/python/detail/signature.hpp)
by Neal D. Becker 15 Sep '04

15 Sep '04

/usr/local/src/boost.cvs/boost/python/detail/signature.hpp: In static member function `static const boost::python::detail::signature_element* boost::python::detail::signature_arity<11>::impl<Sig>::elements()': /usr/local/src/boost.cvs/boost/python/detail/signature.hpp:34: error: syntax error before `;' token...interrupted .

2 1