- Boost - lists.boost.org

tiny review iostreams library
by Jan Christiaan van Winkel 12 Sep '04

12 Sep '04

Hello, I have been asked by Jonathan D. Turkanis to take a look at his iostreams library that is currently in review for inclusion in Boost. He asked me because I presented a paper at ACCU in 2003 about adding a filtering capability to iostreams aloing with a very convenient notation to sting filters together using the vertical bar (|) as is done in UNIX. I had very little time to do a decent review (busy working on the Netherlands Unix Users Group's conference about system administration and network engineering - see www.sane.nl it will be great!), but I think I have a good impression of the structure. 1) The library fills in some (for me) much needed gaps in the standard iostreams library. Especially being able to use a (pre-opened) filedescriptor is important to me (since attach() was not included in the standard). 2) The filtering idea I have great feelings about - I wouldn't have written an article about that kind of thing if I didn't like the idea ;-) I would like the vertical vbar (akin to UNIX'pipe notiation) were also available, but I heard that Jonathan has already worked on that. In general, I think his approach is far, far better, more evolved and complete that my own try, that was only meant as a proof of concept. What I would like: a good user-level manual. The documentation is filled with quite some standardeze (and rightly so - it should be exact!). But users may not see the full strength of the library if they are not introduced to the library using some user-oriented documentation. So, my conclusion: I hope the submission of the library to boost is succesfull - the library would be most helpfull. JC -- ___ __ ____________________________________________________________________ |/ \ Jan Christiaan van Winkel Tel: +31 24 3527252 jc(a)ATComputing.nl | AT Computing P.O. Box 1428 6501 BK Nijmegen The Netherlands __/ \__/ __________ http://www.ATComputing.nl/image/midfotos/jc.jpg _________

1 0

RE: [boost] Re: Formal review of "Output Formatters" library beginstoday
by Reece Dunn 12 Sep '04

12 Sep '04

Thorsten Ottosen wrote: >Here are some general comments: >---------------------------------- > >0. I think the library should be put in the directory >"boost/output_format" >I hate cryptic names. Or "boost/ioformat" since it also has input capabilities :). There was talk when I was developing the library about moving it into the "boost/io" directory, but that seems to be getting a little crowded ;) >1. In this example > > std::cout << boost::io::formatob( vec ); > // output: [ 1, 2, 3 ] > std::cout << boost::io::formatob( vec ).format( "{ ", " }" ); > // output: { 1 : 2 : 3 } > >why does the change of braces change "," to ":" ? It doesn't! This was a typeo. (Fixed in my documents, will commit post-review). >2. In this example > > int a[] = { 5, 4, 3, 2, 1 }; > std::cout << boost::io::formatob( boost::io::range( a, a + 5 )); > std::cin >> boost::io::formatob( boost::io::range( a, a + 5 )); > // output: [ 5, 4, 3, 2, 1 ] > >it might be good to support a range version with the posibility to > >1. throw if there is too few elements >2. default initialize if there is too few elements You mean when reading in the input? The default behaviour is to set the input stream fail bit, so you can check that. >3. cryptic name: formatob.hpp && formatobex; should be format_object and >whatever the latter really means I was going for ease of typing :). maybe boost::io::format/boost::io::formatex. The latter allows you to control the delimeter type being used, so you can do: std::wout << boost::io::formatobex< const wchar_t * >( v ).format( " : " ); >4. given std::cout << boost::io::formatobex< std::string >( v ); > > maybe std::string should be a default argument? I was thinking here about performance. The default type is const char * which should be fairly flexible without providing compy penalties. >5. A lot of boost::io::range() can be replaced with one Taking a Single >Pass >Range You mean from your Boost.Range library? This is something that I am considering, but don't know enough of the library to do this yet. >6. STL IO: It is not obvious how insertion is done? With push_back or by >overwriting elements? The container is cleared and insert is used to insert the elements into the container. >7. why is it necessary with > boost::io::formatob( boost::io::range( a, a + 5 )); > could we not just say > boost::io::range( a, a + 5 ); Because the boost::io::range_t class (created by boost::io::range) does not provide input/output functionality. It is a holder for a range [first, second) so that boost::io::formatob can process it. This is if you either specify a std::pair (boost::io::formatob treats this as a 2-ary type and not a range holder) or a (first, last) pair of values (since boost::io::formatob accepts a single object). It could be possible to make boost::io::range return a boost::io::formatob_t type (and thus allow the above), but when I previously used seperate constructs, it interfered with the type/format deduction mechanism. >8. It should be possible to say > > vector<int> v = ...; > cout << v; > >without the format_ob() if I include stl.hpp, ie, overloads for all >standard >types. Yup. This will provide the default formatting ("[ a, b, c ]" in this case). If you need alternate formatting, you need to use boost::io::formatob. >9. I would prefer basicfmt_t to be basic_format_type or perhaps >basic_fmt_type >if the "fmt" shorthand is used consistently etc. That is, all the cryptic > concatenation should be removed. That would make things fairly long-winded. For example: std::pair < std::pair< int, std::vector< char > >, std::list< std::complex< float > > > mct; std::cout << boost::io::format_object( mct, boost::io::pair_format ( boost::io::pair_format ( boost::io::basic_format(), boost::io::container_format() ), boost::io::container_format( boost::io::nary_format()) ) ); compared to: std::cout << boost::io::formatob( mct, boost::io::pairfmt ( boost::io::pairfmt( boost::io::basicfmt(), boost::io::containerfmt()), boost::io::containerfmt( boost::io::naryfmt()) ) ); >And now my review comments. > >| When doing the formal review, please answer the following questions: >| >| 1. What is your evaluation of the design? > >seems ok. I'm a little irritated about too cryptic names, concatenation and >_t >types. Basically, the "_t" types indicate the implementation type of a given construct. For example, the boost::io::formatob function creates an instance of the boost::io::formatob_t class. With regards to names, I am intending on changing FormatTraits to DelimeterTraits and possibly a few others. I am not sure what you mean by concatenation. >| 2. What is your evaluation of the implementation? > >haven't looked. > >| 3. What is your evaluation of the documentation? > >good, although I miss return-types and template paramaters and some >synopsises >with better overview. >For example, what does boost::io::formatobex< DelimeterType >( const T & ob >); >return? Maybe it doesn't matter, but >then it should say <i>Implementation-defined</i>boost::io::formatobex< >DelimeterType >( const T & ob ); etc. Okay, I will bear that in mind. FYI, the above function returns: formatob_t< T, DelimeterType, typename deducer< T, DelimeterType >::type::outputter > ! My rationale for not supplying the return types was to not consume more space and not confuse readers. Marking them *implementation defined* would be a good idea. >| 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. > >yes. I think all issues can be dealt with quite easy for a post-review. Great. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

3 2

Re: [boost] [Config] Re: serializing a hash_map (tweaks for gcc-3.3.4/libstdc++-v3)
by Robert Ramey 12 Sep '04

12 Sep '04

troy d.straszheim wrote: >>> I have a patched stdlibcpp3.hpp and serialization/hash_map.hpp if >>> somebody wants 'em... >> >> Yes, please post them as attachments, and put [Config] in your >> subject line. >Here they are. I figure there is a "best practice" I'm missing (that >#ifdef __GLIBCPP__ looks out of place to me in hash_map) if so clue me >in for future reference. Also that <ext/hash_map> might very well >apply for __GLIBCXX__ as well, dunno, I made the minimum change to fix >my platform... Shouldn't there be similar set of changes for hash_set as well? Robert Ramey

1 0

RE: [boost] Re: Re: Formal review of "Output Formatters"librarybeginstoday
by Reece Dunn 12 Sep '04

12 Sep '04

Thorsten Ottosen wrote: >"Reece Dunn" <msclrhd(a)hotmail.com> wrote >| Thorsten Ottosen wrote: >|The default behaviour is to set the >| input stream fail bit, so you can check that. > >Ok, I guess that goes in hand with the bahavior of the standard library >(although I prefer throw by default). > >could syntax like > >std::cin >> io::throw_on_error() >> io::formatob( ... ) >std::cin >> io::default_init_rest() >> io::formatob( ... ) > >be supported too.? Possibly. I'd need to look into this. >| >3. cryptic name: formatob.hpp && formatobex; should be format_object and >| >whatever the latter really means >| >| I was going for ease of typing :). maybe >| boost::io::format/boost::io::formatex. The latter allows you to control >the >| delimeter type being used, so you can do: > >yeah, what does "ex" mean? "extended". A better name is probably needed and should be consistent throughout (i.e. for boost::io::wrappedfmtex, etc.) The problem is how to keep close to the original so that you know what it does and also tells you that this variant controls the delimeter type, since you can't reuse the original name due to overload resolution issues. >| I was thinking here about performance. The default type is const char * >| which should be fairly flexible without providing compy penalties. > >seems reasonable...just mention this stuff in the docs. It is (in a round-about way). I have fixed in my local docs to say: "This uses const char * as its delimeter storage type." >| >5. A lot of boost::io::range() can be replaced with one Taking a Single >| >Pass >| >Range >| >| You mean from your Boost.Range library? This is something that I am >| considering, but don't know enough of the library to do this yet. > >Ok, basically you can replace > >foo( std::pair<iterator,iterator> ); >foo( T (&array)[sz] ); >foo( const standard_container& ) >foo( builtin-strings ); > >with one function taking a Range > >foo( const Range& ); Great! I will replace boost::io::range and boost::io::range_t with this post-review. >| >6. STL IO: It is not obvious how insertion is done? With push_back or by >| >overwriting elements? >| >| The container is cleared and insert is used to insert the elements into >the >| container. > >ok, a small comment about it would be good. Done in local docs. >| >7. why is it necessary with >| > boost::io::formatob( boost::io::range( a, a + 5 )); >| > could we not just say >| > boost::io::range( a, a + 5 ); >| >| Because the boost::io::range_t class (created by boost::io::range) does >not >| provide input/output functionality. It is a holder for a range [first, >| second) so that boost::io::formatob can process it. This is if you either >| specify a std::pair (boost::io::formatob treats this as a 2-ary type and >not >| a range holder) or a (first, last) pair of values (since >boost::io::formatob >| accepts a single object). > >hm...it seems to me that boost.range has all you need: > >class iterator_range or class sub_range + >function make_iterator_range( a, a + 5 ); > >I could probably benefit you code to use this instead (unless I'm >overlooking >something). Nope. I'll update post-review. >| >9. I would prefer basicfmt_t to be basic_format_type or perhaps >| >basic_fmt_type >| >if the "fmt" shorthand is used consistently etc. That is, all the >cryptic >| > concatenation should be removed. >| >| That would make things fairly long-winded. For example: >| [snip] > >yeah, I know, but at least say pair_fmt instead of pairfmt etc. Yes. This is better. >| I am not sure what you mean by concatenation. > >the contraction of X_fmt to Xfmt. Okay. I'll look at revising the affected names. >| Okay, I will bear that in mind. FYI, the above function returns: >| formatob_t< T, DelimeterType, typename deducer< T, DelimeterType >| >::type::outputter > >| ! My rationale for not supplying the return types was to not consume more >| space and not confuse readers. Marking them *implementation defined* >would >| be a good idea. > >yeah, that would be sufficient. Great. Regards, Reece _________________________________________________________________ Check out Election 2004 for up-to-date election news, plus voter tools and more! http://special.msn.com/msn/election2004.armx

1 0

RE: [boost] Re: Formal review of "Output Formatters" library beginstoday
by Reece Dunn 12 Sep '04

12 Sep '04

troy d.straszheim wrote: >Anybody have a hint on how to build the docs for this (or be willing to >just build them and put them up somewhere)? HTML versions of the docs are provided here: >>As a convenience (only for the period of the review), you can also get it >>from >>http://www.torjo.com/code/outfmt.zip (153Kb) Open the file: libs/outfmt/docs/html/frame.html. Alternatively, to build from the sources, open up a command line at libs/outfmt/docs and run bjam using: bjam This should build the docs as long as you have BBv2 (not sure about BBv1) set up and BoostBook properly configured. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

2 1

mipspro tests?
by Joaquín Mª López Muñoz 12 Sep '04

12 Sep '04

Hello, MIPSpro tests haven't been updated since Aug 18, yet I see some recent fixes being done in the CVS for this compiler. Is there anywhere else where tests for this platform can be consulted? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 6

boost.cvs range.hpp broken?
by Neal Becker 12 Sep '04

12 Sep '04

Just ran cvs update. Something is wrong with range.hpp: g++34 -x c++ /usr/local/src/boost.cvs/boost/range.hpp -I /usr/local/src/boost.cvs -fsyntax-only In file included from /usr/local/src/boost.cvs/boost/range/begin.hpp:18, from /usr/local/src/boost.cvs/boost/range/functions.hpp:18, from /usr/local/src/boost.cvs/boost/range.hpp:18: /usr/local/src/boost.cvs/boost/range/config.hpp:24:21: missing binary operator before token "("

3 5

OOPSLA 2004 Boost workshop proposal
by PORKOLAB Zoltan 12 Sep '04

12 Sep '04

Dear Sir, Here is the abstract of our proposal for the OOPSLA2004 Boost Workshop. The proposal and the corresponding source is downloadable from http://gsd.web.elte.hu/Publications/GPCE_04/concept.pdf http://gsd.web.elte.hu/Publications/GPCE_04/concept.h Please forgive us the possible errors. Istvan Zolyomi scamel(a)elte.hu Zoltan Porkolab gsd(a)elte.hu ================================================================== Improving concept checking in Boost ABSTRACT To ensure the correctness of template based constructions in C++, constraints on template parameters are especially useful. Though C++ does not directly support checking requirements on template parameters, several solutions address this problem. Boost provides a comprehensive concept checking library that could be further advanced in many areas. In this paper we propose a different structure and an extended feature set to improve the Boost concept checking library into a general template introspection library. Our recommended solution takes the advantages of previous solutions, such as REQUIRE-like macros and static interfaces. On the lowest level, we suggest an orthogonal construction of elementary concepts instead of a predefined set of complex constraints. These basic concepts should return a boolean results instead of aborting compilation immediately, thus any metaprogramming tool could use the result of the check. Based on these building blocks, it is possible to express highly complex constraints using arbitrary logical expressions instead of the implicit conjunction used in all current concept checking libraries. Our solution is non-intrusive, relies only on standard C++ language features and implies no runtime overhead. Note that this is a shortened version of our paper 'Towards a general template introspection library' for GPCE'04 which can be downloaded from http://gsd.web.elte.hu/Publications/GPCE_04/introspection.pdf. In that article we also introduce a possible implementation detailed to the source-level. The sample source code can be downloaded from http://gsd.web.elte.hu/Publications/GPCE_04/concept.h. ==================================================================

3 2

IOStreams Review -- Last Day
by Jonathan Turkanis 12 Sep '04

12 Sep '04

Hi all, This is the last day of the iostream library review. There have been a lot of messages to read; I've tried to respond to all of them, but I may have missed some. If you feel you have raised an issue which I have not adequtely addressed, please try again. Also, if you have been considering posting a review, but have run out of time, please post whatever comments you have even if they are not as detailed as you may have liked. Best Regards, Jonathan

2 2

Re: IOStreams formal review start
by Robert Ramey 11 Sep '04

11 Sep '04

What is your evaluation of the documentation? I've been reading through the documentation and I have a couple of questions and observations. I'm not sure I understand all the details so feel free to correct me if I've miss understood something. 1) Generally the quality of the documentation is very good. 2) I have a problem with the name of the library - I find it very misleading. I would character the library by its main functionality a) simplify the creation of new stream buffers. b) permit stream buffers to be "chained" together to sequentially process input and output. So I think a better name would be "Stream Buffer Library" Additionally it includes some very "thin" classes to make streams with with the indicated buffers. As I understand it this this basically replaces the rdbuf member of the stream in the normal way. In my view the tutorials don't make a clear distinction between stream buffers and streams. For example, I would prefer that the first one be: Defining a Stream Buffer for a New Data Source. Which would create a new stream buffer and then use in a stream created the old fashion way. Basically I think the tutorial is easier to understand if one can add one concept at a time - especially when (in my view) they are orthogonal concepts. Same for the other tutorials. The stream constructor can be in separate section. This would also make it much easier to see where the overlap is with Daryl's library. Adaptors and Object Generators Hmmm - I'm not sure "Adaptors" should be in here. How about "Streambuffer Generator" as it seems just to be shorthand for the above. Filtering Input/Output At first I was going to complain about this, but upon forming my complaint it became clear how its supposed to be used. Again I was thrown by the mixing of streambuffer and stream. I would prefer to see this divided into two pieces - making a chain of streambuffers and a final layer to used the buffer in a standard stream. It would characterize the source/sink concepts as "helpers" to building streambufs but providing the end points of a chain of filters. But that leaves me with the question "What about a filter to a standard filebuf? What do we use for sink? I'm sure its in there, I just didn't see it where I expected to find it. I presume its hidden in the filtered_?stream .. which makes harder to see. Of course this is the way its was designed so I guess I'm complaining about this design decision. 3) Reference ========= Another very professional job. A few observations: a) I'm sort of intrigued with the sequence that things are explained. For example, it's hard to understand the concept of "chains" until the Filter Stream is described. These are relatively small points. b) I'm intrigued with the section "Code Converters". How does this contrast with using a codecvt facet? What are we doing here that is not better than adding a codecvt facet? Might be better make a method of composition ("chaining") codecvt facets? I don't know the answer. As I went through that part of the documentation this question occurred to me - it sort of begs and answer. 4) Rationale a) The section Generic Design left me stumped. The selection of conditional verb tenses suggests that neither alternative was used. b) Interesting to me was that fact that the issue of streambuf vs stream is dealt with explicitly. 5) What is your evaluation of the design? a) I've already stated my reservations about the mixing of streams and stream buffers. b) the concept of "chaining" is quite different than what I would have envisioned. As I understand it, if 10 filters are chained together, this system is going to require ten levels of function calls to get a character in/out. Someone is bound to object to this. On the other hand, this system permits filter to be composed "chained" at runtime which may be useful in some instances. I would have expected something like the filters be composed at construction time with templated constructors. This would permit the inlined member functions to be collapsed by the compiler to minimize copying. The Dataflow iterators in the serialization library manifest this expection. I'm not saying that the method chosen by Jonathon isn't as good ( though I might believe that) its just not what I expected. c) I'm a little concerned as to where codecvt, wide character i/o etc fit into this. d) I would be curious as to whether this is suitable for something other than filebuf - e.g. stream adaptor for sockets i/o. ? 6) What is your evaluation of the implementation? I didn't build the library or use in any tests so I recall can't contribute to that assessment. 7) What is your evaluation of the potential usefulness of the library? This is very useful and necessary. Something like this is what I've hoped for to complement the serialization library. I envision something like this combined with the serialization libray, combined with the mult-index set as making one great in memory database. Did you try to use the library? With what compiler? Did you have any problems? no How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A couple hours with the documentation Are you knowledgeable about the problem domain? Fairly knowledgable. 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. I have reservations as stated above. It very useful and necessary, and seems (from the quality of the documentation) a high quality implementation. If my choices were t accept or reject it as is I would accept it. Of course, if others who've studied it in more depth confirm my reservations above, I would like to see them addressed first. Robert Ramey

4 16