August 2004 - Boost - lists.stage.boost.cppalliance.org

New implementation of remove_xxx for vintage compilers
by Peder Holt 28 Mar '06

28 Mar '06

Hi. I have started implementing some of the missing type_traits functionality for vintage compilers using typeof. The following are complete, and seem to work flawlessly on VC 6.5 and 7.0: remove_pointer remove_reference remove_bounds The source is available at: http://groups.yahoo.com/group/boost/files/typeof_vintage.zip The use of typeof in this respect, makes remove_xxx much more flexible. Would it be possible to start using this scheme for compilers without partial template specialization support? #define BOOST_MAX_TYPEOF_SIZE 20 #include <boost/test/minimal.hpp> //Include typeof_define.hpp in all header files where new types are added to typeof. #include <boost/typeof/typeof_define.hpp> #include <complex> #include <boost/type_traits/remove_reference.hpp> #include <boost/type_traits/remove_pointer.hpp> #include <boost/type_traits/remove_bounds.hpp> #include <boost/type_traits/is_same.hpp> template<typename A0> struct X {}; template<typename A0,unsigned int A1> struct Y {}; template<typename A0,typename A1,long A2> struct Z {}; BOOST_TYPEOF_DEFINE_TEMPLATE(X,1,(typename)) BOOST_TYPEOF_DEFINE_TEMPLATE(Y,2,(typename,unsigned int)) BOOST_TYPEOF_DEFINE_TEMPLATE(Z,3,(typename,typename,long)) BOOST_TYPEOF_DEFINE_TEMPLATE(std::complex,1,(typename)) int test_main(int, char*[]) { BOOST_TEST((boost::is_same<X<int>* const[8][9],boost::remove_bounds<X<int>* const[5][8][9]>::type>::value)); BOOST_TEST((boost::is_same<Z<X<double&>,Y<bool[4][7],12324>,0>* const*,boost::remove_pointer<Z<X<double&>,Y<bool[4][7],12324>,0>* const**volatile>::type>::value)); //VC7.1 fails to compile remove_reference. BOOST_TEST((boost::is_same<Y<int,345>** const,boost::remove_reference<Y<int,345>** const&>::type>::value)); typedef BOOST_TYPEOF(5.+std::complex<double>(6,7)) result_type; BOOST_TEST((boost::is_same<result_type,std::complex<double> >::value)); return 0; } -- Peder Holt

1 0

[graph] non-recursive version of undirected_dfs
by Synge Todo 24 Nov '04

24 Nov '04

Dear Boosters, I'm posting a non-recursive version of undirected_dfs, which should have advantages in space and time over the current implementation based on recursion, especially for huge graphs. It's a direct counterpart of the non-recursive version of depth_first_search for digraphs. I have confirmed that libs/graph/example/undirected_dfs.cpp as well as my own programs using undirected_dfs reproduce the identical outputs as those with the original recursive version. Best regards, Synge *** boost/graph/undirected_dfs.hpp 6 Aug 2004 05:02:41 -0000 1.1.1.1 --- boost/graph/undirected_dfs.hpp 19 Aug 2004 05:11:32 -0000 1.2 *************** *** 28,38 **** --- 28,106 ---- #define BOOST_GRAPH_UNDIRECTED_DFS_HPP #include <boost/graph/depth_first_search.hpp> + #include <vector> namespace boost { namespace detail { + // Define BOOST_RECURSIVE_DFS to use older, recursive version. + // It is retained for a while in order to perform performance + // comparison. + #ifndef BOOST_RECURSIVE_DFS + + template <typename IncidenceGraph, typename DFSVisitor, + typename VertexColorMap, typename EdgeColorMap> + void undir_dfv_impl + (const IncidenceGraph& g, + typename graph_traits<IncidenceGraph>::vertex_descriptor u, + DFSVisitor& vis, + VertexColorMap vertex_color, + EdgeColorMap edge_color) + { + function_requires<IncidenceGraphConcept<IncidenceGraph> >(); + function_requires<DFSVisitorConcept<DFSVisitor, IncidenceGraph> >(); + typedef typename graph_traits<IncidenceGraph>::vertex_descriptor Vertex; + typedef typename graph_traits<IncidenceGraph>::edge_descriptor Edge; + function_requires<ReadWritePropertyMapConcept<VertexColorMap,Vertex> >(); + function_requires<ReadWritePropertyMapConcept<EdgeColorMap,Edge> >(); + typedef typename property_traits<VertexColorMap>::value_type ColorValue; + typedef typename property_traits<EdgeColorMap>::value_type EColorValue; + function_requires< ColorValueConcept<ColorValue> >(); + function_requires< ColorValueConcept<EColorValue> >(); + typedef color_traits<ColorValue> Color; + typedef color_traits<EColorValue> EColor; + typedef typename graph_traits<IncidenceGraph>::out_edge_iterator Iter; + typedef std::pair<Vertex, std::pair<Iter, Iter> > VertexInfo; + + std::vector<VertexInfo> stack; + + put(vertex_color, u, Color::gray()); + vis.discover_vertex(u, g); + stack.push_back(std::make_pair(u, out_edges(u, g))); + while (!stack.empty()) { + VertexInfo& back = stack.back(); + u = back.first; + Iter ei, ei_end; + tie(ei, ei_end) = back.second; + stack.pop_back(); + while (ei != ei_end) { + Vertex v = target(*ei, g); + vis.examine_edge(*ei, g); + ColorValue v_color = get(vertex_color, v); + EColorValue uv_color = get(edge_color, *ei); + put(edge_color, *ei, EColor::black()); + if (v_color == Color::white()) { + vis.tree_edge(*ei, g); + stack.push_back(std::make_pair(u, std::make_pair(++ei, ei_end))); + u = v; + put(vertex_color, u, Color::gray()); + vis.discover_vertex(u, g); + tie(ei, ei_end) = out_edges(u, g); + } else if (v_color == Color::gray()) { + if (uv_color == EColor::white()) vis.back_edge(*ei, g); + ++ei; + } else { // if (v_color == Color::black()) + ++ei; + } + } + put(vertex_color, u, Color::black()); + vis.finish_vertex(u, g); + } + } + + #else // BOOST_RECURSIVE_DFS + template <typename IncidenceGraph, typename DFSVisitor, typename VertexColorMap, typename EdgeColorMap> void undir_dfv_impl *************** *** 69,74 **** --- 137,145 ---- } put(vertex_color, u, Color::black()); vis.finish_vertex(u, g); } + + #endif // ! BOOST_RECURSIVE_DFS + } // namespace detail template <typename Graph, typename DFSVisitor,

2 2

Boost license
by Falk Hueffner 23 Nov '04

23 Nov '04

Hi, the boost license (http://www.boost.org/LICENSE_1_0.txt) does not allow redistributing modified versions. Is that intentional or an oversight? -- Falk

4 5

file modes in boost cvs
by Neal Becker 16 Oct '04

16 Oct '04

I noticed that in boost cvs files seem to have random modes. Many sources show up as executable when checked out of cvs onto my Linux box. Hopefully this will be fixed before release.

8 39

Review of Daryle Walker's "More IO" library begins today, August 21, 2004.
by tom brinkman 12 Oct '04

12 Oct '04

The review of Daryle Walker's "More IO" library begins today, August 21, 2004. Download: http://groups.yahoo.com/group/boost/files/more_io_4.zip [or] http://boost-sandbox.sourceforge.net/more_io_4.zip Description: Provides a multitude of I/O-oriented extensions. Some are extra manipulators; variants of "std::endl", a resetting manipulator, and a configurable manipulator. The library includes a set of base class templates for wrapping a new stream-buffer type around a stream class. Changes from the last interim version (called "more_io_3b.zip"): * split the manipulator header into several headers * refined the license statements in some already-affected files Changes from the first formal review (called "more_io.zip"): * refined the interface and implementation of array-streams and stream-buffer wrappers (including a wrapping example) * added the null-stream, value-stream, and pointer-stream headers * added generalizations to the new-line and skip-line manipulators * added the non-oriented 'reset' and 'form' manipulators * split the manipulator header into several headers * changed the license statements 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. Here are some questions you might want to answer in your review: What is your evaluation of the design? What is your evaluation of the implementation? What is your evaluation of the documentation? What is your evaluation of the potential usefulness of the library? Did you try to use the library? With what compiler? Did you have any problems? How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Are you knowledgeable about the problem domain? And finally, every review should answer this question: 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. For information about submitting a Formal Review, see http://www.boost.org/more/formal_review_process.htm The Review manager is: Tom Brinkman reportbase(a)yahoo.com

4 16

RFI: RMI in C++
by Francis ANDRE 03 Oct '04

03 Oct '04

Hi Listers I am looking for a good C++ package that implements something quite close to Java RMI (NO Corba/IIOP please!) , I have looked at the WWW, and the boost.org but I did not found any serious answer except the article of A Batov in the "C/C++ Users Journal" http://www.cuj.com/documents/s=8206/cujweb0304batov/ Now that the serialization library is part of boost, could this be a item to add the the wishlist at boost.org??? Regards FA

2 1

explicite failures question
by Robert Ramey 21 Sep '04

21 Sep '04

I'm struggling with the explicit-failures XML. About 40% of the serialization tests will fail on platforms which do not include support from wchar_t streams. As Understand the current schema (XML is not all that clear to me) I would have to specify one line for each pair of toolset-test that fails on this scenario. I my case this means 100 test * 6? Toolsets = ? 600 lines of xml added to this file. Robert Ramey

5 13

Regression Tests, Boost.Serialization
by Martin Wille 18 Sep '04

18 Sep '04

Hi, Houston, we have a problem. The 209 recently added B.S tests apparently result in ~20MB binaries each for gcc-3.x compilers. For me this means that the nests will need ~20GB more disk space. All the other tests with all compilers I'm testing for together take ~10GB. This is not only slightly unbalanced, it also came as a surprise to me when I suddenly saw the unexpected disk full errors. Why does this kind of things always happen so short before a release? Please, everyone, if you do something that will have serious impact on the tests being run, please, notify the testers in advance. (I still think we should have a separate list for regression test related stuff, btw.) I had a few GB of disk space left a few days ago. Now, I'm unable to run all the tests. I could drop one of the gcc-3.4 versions. However, I'd still be short by ~10GB after that. Is there a way of reducing the number of tests in Boost.Serialization? Would it be viable to strip the test binaries (thereby losing debug information)? Any other suggestions? Compilers do drop? Regards, m PS: Yes, I'm already trying to clean my disks ;-)

2 1

RE: [boost] Re: xtime_get unsafe on Windows for IA64
by Ben Hutchings 17 Sep '04

17 Sep '04

Michael Glassford <glassfordm(a)hotmail.com> wrote: > Ben Hutchings wrote: > > The implementation of the boost::xtime_get() function in > > libs/thread/src/xtime.cpp includes the following code for Windows: <snip> > > The pointer casts are not safe because although the representations > > of FILETIME and __int64 are compatible, FILETIME is only 32-bit- > > aligned whereas __int64 must be 64-bit-aligned on IA64 (in some > > processor modes). > > > > One can instead use union { FILETIME ft; __int64 i64; } and read out > > i64, though I'm not sure this code should be unconditionally using > > __int64 anyway. There is a longer explanation at > > <http://weblogs.asp.net/oldnewthing/archive/2004/08/25/220195.aspx>. > > How about this instead: > > const boost::uint64_t TIMESPEC_TO_FILETIME_OFFSET = > (static_cast<boost::uint64_t>(27111902UL) << 32) > + 3577643008UL; I think this should use the UINT64_C macro instead of messing about with casts. > const boost::uint64_t ft64 = > (static_cast<boost::uint64_t>(ft.dwHighDateTime) << 32) > + ft.dwLowDateTime; > > xtp->sec = static_cast<int>( > (ft64 - TIMESPEC_TO_FILETIME_OFFSET) / 10000000 > ); The cast should be to int_fast64_t rather than to int. > xtp->nsec = static_cast<int>(( > ft64 - TIMESPEC_TO_FILETIME_OFFSET > - (static_cast<boost::uint64_t>(xtp->sec) * 10000000) > ) * 100 > ); > > ? The cast should be to int_fast32_t. Also the use of multiplication and subtraction to calculate the remainder seems to be a premature optimisation that obscures what's really going on. A smart compiler can combine the division and remainder operations, and I have confirmed that Visual C++ 7.1 does so when generating optimised i386 code (even for 64-bit division where it uses a subroutine rather than a single instruction). So I would suggest: static const boost::uint64_t TIMESPEC_TO_FILETIME_OFFSET = UINT64_C(116444736000000000); const boost::uint64_t ft64 = (static_cast<boost::uint64_t>(ft.dwHighDateTime) << 32) + ft.dwLowDateTime; // or use the union trick which MS appears to have blessed xtp->sec = static_cast<int_fast64_t>( (ft64 - TIMESPEC_TO_FILETIME_OFFSET) / 10000000 ); xtp->nsec = static_cast<int_fast32_t>( ((ft64 - TIMESPEC_TO_FILETIME_OFFSET) % 10000000) * 100 ); Ben.

2 2

IOStreams formal review start
by Jeff Garland 14 Sep '04

14 Sep '04

All - Today (August 28th, 2004) is the start of the formal review of the Iostreams library by Jonathan Turkanis. I will be serving as review manager. Note that this is a somewhat unusual situation in that we have several libraries that overlap in the same area, so comments related to the MoreIo overlap are needed. As usual, please state in review comments how you reviewed the library and whether the you think the library should be accepted into Boost. Further guidelines for writing reviews can be found on the website at: http://www.boost.org/more/formal_review_process.htm#Comments ********************************************** Library Synopsis ********************************************** The Iostreams Library serves two main purposes: * To allow the easy creation of standard C++ stream and stream buffer classes for new data sources and sinks. * To provide a convenient interface for defining i/o filters and attaching them to standard streams and stream buffers. The library focuses on freeing users from writing boiler plate code and allowing them instead to create highly reusable components. In addition to providing an abstract framework the library provides a number of concrete filters, sources and sinks which serve as example applications of the library but are also useful in their own right. These include components for accessing memory-mapped files, for file access via operating system file descriptors, for code conversion, for text filtering with regular expressions, for line-ending conversion and for compression and decompression in the zlib, gzip and bzip2 formats. The latest package can be found at the following locations: http://home.comcast.net/~jturkanis/iostreams/ Thanks, Jeff

1 0