- Boost - lists.boost.org

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

Regex
by Lucas Galfaso 11 Sep '04

11 Sep '04

What should be the behavior of a regex::smatch whenever the regex::expression you are trying to match is not a well formed regex expression? With the current implementation is crush and burn. I do not know what is boost policy on this matter, but I think this is not desirable. Lucas/

2 2

Re: Copyright (again, sorry...)
by Jürgen Hunold 11 Sep '04

11 Sep '04

Hi John ! On Friday 10 September 2004 12:08, John Maddock wrote: > Juergen, > > In case you missed this at the end of my last mail, there are still > some copyright issues to try and sort out; the copyright I'm seeing > in some of your work is: > > // Copyright (c) 2003 Institute of Transport, > // Railway Construction and Operation, > // University of Hanover, Germany > // > // Author: Jürgen Hunold > > In the files: > > libs/graph/test/property_iter.cpp This was changed to BSL in current cvs already > tools/build/v2/test/railsys/libx/include/libx/test_libx.h > tools/build/v2/test/railsys/libx/src/test_libx.cpp > tools/build/v2/test/railsys/program/include/test_a.h > tools/build/v2/test/railsys/program/liba/test_a.cpp > tools/build/v2/test/railsys/program/main/main.cpp > > I don't think having your name in blanket-permission.txt is enough > for us to move these over to the BSL is it? Well, I thought it was enough ;-) Especially because all files (should) have stated: // Permission to copy, use, modify, sell and distribute this software is // granted provided this copyright notice appears in all copies. This // software is provided "as is" without express or implied warranty, and // with no claim as to its suitability for any purpose. So I thought that changing to the equivalent BSL would not be such an issue, especially because all that matters is the fact that the copyright itself stays. But luckily I'm no lawyer. > So I guess what we really need is the permission of the "Institute of > Transport", would you be able to help us out with that? Yes I can. I'm in charge of the Boost issue here, and the author of all the files, so I can give you the permission: You may change these files to the Boost Software License. I hope this is sufficient. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Institut für Verkehrswesen, Eisenbahnbau * voice: ++49 511 762-2529 ! und -betrieb, Universität Hannover * fax : ++49 511 762-3001 ! Appelstrasse 9a, D-30167 Hannover * hunold(a)ive.uni-hannover.de ! www.ive.uni-hannover.de

2 1

serialization tests status
by Robert Ramey 10 Sep '04

10 Sep '04

NOB_AVEx - mingw >From the test output I have no idea why this fails. I also don't know which version of gcc is being used. General - mingw Tests which use wide char i/o fail because mingw standard library doesn't implement wchar_t i/o VC 8.0 Library fails to build because of an error compiling a spirit 1.8 header. This also fails in the spirit tests (chest) Comeau Wide char tests because of a bug in library implementation. Comeau has been notified and verified it's a bug. Borland, msvc 6.0, 7.0 These libraries fail to build. They depend on spirit 1.61. Spirit 1.61 in turn depends upon the existence of mpl/apply_if.hpp which has been removed. For backwards compatibility sake, there should be an apply_if even only if it's a wrapper around eval_if. intel- win32- 7.1- vc6- stlport- 4.5.3 pending library issue - under investigation gcc- 2.95.3- stlport- 4.5.3- linux I have verified that this works on Win 32 if spirit 1.61 is installed (subject to the above). Robert Ramey

1 0

[serialization] building fails on OS X...
by Ronald Garcia 10 Sep '04

10 Sep '04

Hi, I have tried a few times recently to build Boost from CVS under OS X on machine with 2 GB of memory. Unfortunately building fails at the following point: darwin-C++-action bin/boost/libs/serialization/build/libboost_wserialization.a/darwin/ release/xml_wgrammar.o virtual memory exhausted: Cannot allocate memory Has anyone else run into this problem? ron

2 1

Re: [boost] Re: [admin] Overlapping reviews -- should this be allowed?
by brangdon＠cix.compulink.co.uk 10 Sep '04

10 Sep '04

In-Reply-To: <chm2sp$bs9$1(a)sea.gmane.org> reportbase(a)yahoo.com (tom brinkman) wrote (abridged): > 2) The current backlog of libraries to review is quite large. How large? The schedule at: http://www.boost.org/more/formal_review_schedule.html is years out of date and I couldn't find an online schedule using google. > 7) The reason for not having overalpping reviews is based on the > preference for a flexible review schedule. This flexibility, > however, has a large cost in terms of not being able to provide > firm start dates for our library authors. That partly depends on whether the current necessary adjustment is a once-off or a regular thing. I suppose if a review looks like going over time, we have 4 choices: (1) Give up and reschedule the review for later - presumably 6 or more months later if it goes to the back of the queue, so as not to upset published schedules. (2) Force the review to end on time anyway, with a hurried judgement. (3) Extend the review period, and reschedule subsequent reviews. (4) Extend the review period, and don't reschedule subsequent reviews. This is the option which may lead to overlap. None of which are ideal, of course, but to me the latter two seem better then the first two. I'm inclined to think (4) should be considered on a case by case basis. It would depend mainly on whether the same people would be reviewing both of the overlapping libraries. Or rather, whether the people who aim to review both can get the first one done in time. Is it fair to say that the people who review all submissions do so relatively shallowly and quickly? And the people who review in depth, only do so for submissions they are specifically interested in and/or have expertise about and/or an immediate real-world application for? -- Dave Harris, Nottingham, UK

1 0

Re: [boost] Re: static sized strings
by Reece Dunn 10 Sep '04

10 Sep '04

Rob Stewart wrote: >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > [1] How do I pass the buffer and capacity to the implementation while > > allowing both fixed_string_base and fixed_string access to the >basic_string > > interface? I have chosen to route the data through one of the >basic_string > > constructors, requiring a const_cast. This is the best approach AFAICS. > >I haven't looked at your recent implementation, and I don't >presently have the time, so I really don't know what you're >talking about. If you can explain the dependencies to which you >refer, I'd appreciate it. I think it has bearing on the swap() >discussion. I have a class called detail::fixed_string_impl that has three data members: size, capacity and a pointer to the data buffer (len, cap and str respectively). Doing this allows the virtual functions to be removed and the implementation moved out of fixed_string. The fixed_string class can then pass its buffer and the capacity template parameter to the implementation via a constructor. The problem is that fixed_string is derived from fixed_string_base, which itself is derived from detail::basic_string_impl. This is needed to allow both fixed_string and fixed_string_base to have access to the full basic_string interface (like was done in the old implementation). The solution I have taken is to use the basic_string_impl( const CharT * s, size_type l ) constructor and use this to pass the buffer (s) and capacity (l) to the string. This is not ideal since it requires a const_cast to extract the buffer. This required modifying the constructor implementation in basic_string_impl to forward the parameters to Base and not implement them using append. The old implementation had the same problem with swap as the current one, since the string would get clipped when it is copied. For now, I will leave the implementation of swap as is (i.e. clipping and not signalling an exception), but add a note on this issue in the docs so that users are aware of it. Another problem I can forsee is using a custom char_traits or format_policy class, e.g. boost::fixed_string< 20, char, std::char_traits< char > > s1; strcpy( s1, "Hello" ); // ok boost::fixed_string< 20, char, win_char_traits< char > > s2; strcpy( s2, "There" ); // error This is the problem shared with basic_string when implementing functions using std::string. I have also fixed the problems relating to using the strxxx functions with Borland: the compiler may set them as instrinsic and add a macros defining strxxx as __strxxx__. To get around this, I now detect if they are macros and the Borland compiler is being used, then create an inlined function to the __strxxx__ version. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1