September 2004 - Boost - lists.preview.boost.org

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

Two issues with the IBM xlC compiler
by Matthias Troyer 11 Sep '04

11 Sep '04

Dear Boosters, I've got a patch to report for the IBM Viisual Age C++ compiler xlC, and one other problem to discuss. The patch we found necessary for version 6.0 of the compiler is: diff -u -r1.26 filtered_graph.hpp --- boost/graph/filtered_graph.hpp 22 Nov 2003 01:18:37 -0000 1.26 +++ boost/graph/filtered_graph.hpp 1 Jul 2004 14:11:27 -0000 @@ -208,8 +208,8 @@ > edge_iterator; typedef typename Traits::edges_size_type edges_size_type; - typedef typename edge_property_type<Graph>::type edge_property_type; - typedef typename vertex_property_type<Graph>::type vertex_property_type; + typedef typename ::boost::edge_property_type<Graph>::type edge_property_type; + typedef typename ::boost::vertex_property_type<Graph>::type vertex_property_type; typedef filtered_graph_tag graph_tag; //private: The original version just gives compiler errors, probably incorrectly but it does. The second problem is in the configure files. Who is responsible for maintaining them? The issue is the following patch I found necessary: --- boost/config/compiler/vacpp.hpp 22 Jun 2004 12:33:06 -0000 1.16 +++ boost/config/compiler/vacpp.hpp 1 Jul 2004 14:11:23 -0000 @@ -26,7 +26,7 @@ #endif #if (__IBMCPP__ <= 600) || !defined(BOOST_STRICT_CONFIG) -# define BOOST_NO_INCLASS_MEMBER_INITIALIZATION +//# define BOOST_NO_INCLASS_MEMBER_INITIALIZATION # define BOOST_NO_POINTER_TO_MEMBER_TEMPLATE_PARAMETERS #endif in-class member initializtions seem to work flawlessly on this compiler, so I wonder why BOOST_NO_INCLASS_MEMBER_INITIALIZATION is defined. Having it defined causes problems with the Boost random library, which then tries to initializes values of an enum tto a 64-bit integer, which fails. Is there a reason why BOOST_NO_INCLASS_MEMBER_INITIALIZATION is defined for this compiler or is this a bug? Best regards, Matthias

3 7

Re: Empty member optimization
by Joao Abecasis 11 Sep '04

11 Sep '04

David Abrahams wrote: > I think the question is whether it's ever desirable to break the > current C++ invariant that no two objects of the same type will ever > share an address **in generic code** -- that is, when you don't know > anything about the assumptions that may be made by that type. An alternative implementation is to privately inherit from the specified type for empty classes as compressed_pair does. This maintains the invariant but has the drawback that inheritance is visible in user code. For a generic compressed_tuple the private inheritance should not be a problem. João

3 5

[Config] proposal of new macro, BOOST_DECL
by Pavel Vozenilek 11 Sep '04

11 Sep '04

In order to export class from dynamic library one needs to add something as: __declspec(dllexport) wrapped in a macro. (Win32 example.) Right now libraries define their own macros, e.g Iostreams has BOOST_IO_DECL and Regex uses BOOST_REGEX_DECL. There could be more. I suggest common macro, BOOST_DECL to be used Boost-wide. Its value may be by default empty or deduced from BOOST_ALL_DYN_LINK as it is done in Regex. /Pavel

5 7