- Boost - lists.boost.org

[test][comeau] problem with va_list
by JOAQUIN LOPEZ MU?Z 28 Apr '05

28 Apr '05

Current tests for Comeau 4.3 show this problem: "G:\boost\boost/test/impl/test_tools.ipp", line 136: error #135: namespace "std" has no member "va_list" std::va_list args; Looks like va_list is not properly injected into std:: (yet BOOST_NO_STDC_NAMESPACE is *not* defined for this platform, and I guess for a good reason.) I've googled for this and found some discussions at the Boost list on the very same problem, with no definitive answer :( 1. Could anyone take a look at Comeau stdlib <cstdargs> and see what's going on? 2. Is it ok to commit an obvious patch to boost/test/impl/test_tools.ipp so as to work around this problem? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 3

[website] Oh the fun..
by Rene Rivera 28 Apr '05

28 Apr '05

I've made a variety of changes to incorporate the variety of concerns people had. There are problem that I likely did not fix. And of course your browser mileage may vary. I'm not going to mention what the changes are. They should either be obvious, and I'd rather not influence perceptions :-) Yes, both the front and history page are updated. http://redshift-software.com/~grafik/boost/index.htm http://redshift-software.com/~grafik/boost/more/version_history.html Enjoy. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

9 15

Re: Formal Review: FOREACH macro
by Sam Saariste 28 Apr '05

28 Apr '05

> > I have used it for more than 6 months now and have added it to my standard > > set of idioms. Once you get into the FOREACH mindset, you don't only want to > > use it for std::for_each type jobs but you would also want to use it for > > std::transform type ones. In situations where you can use push_back on a > > result container, FOREACH serves this purpose as it is. However, I have > > encountered situations where this was not possible and where I wanted a > > second macro, say FOREACH2, that iterates over 2 ranges simultaneously. I > > have had such a need on more than one occasion. One situation was as above > > and in other situations I had to combine the elements of two ranges. > > Try using zip_iterator with BOOST_FOREACH. > Thanks for the suggestion Dave, but I am not sure how I would achieve the same as with the BOOST_FOREACH variant that I am suggesting. I am thinking of something like the following: int a1[] = { 1, 2, 3 }; int a2[] = { 4, 5, 6 }; BOOST_FOREACH2(int e1, a1, int& e2, a2) { e2 += e1; } How would I write this with BOOST_FOREACH using zip_iterator? TIA, Sam

1 0

Re: Possible tuple extensions
by Larry Evans 28 Apr '05

28 Apr '05

On 11/08/2001 10:18 AM, Aleksey Gurtovoy wrote: [snip] > And the extensions themselves are here: > http://groups.yahoo.com/group/boost/files/tuple_ext/ The test code in: libs/tuple_ext/test/tuple_iterator_test.cpp looks like the iterator, to be useful, requires some templated function similar to the: template<class Tuple> void foo(tuples::tuple_iterator<Tuple>) {} in that file. However, the template argument, Tuple, provides no clue to the programmer as to the argument type or which element in the tuple is being passed. Wouldn't a variant argument be more self-documenting? In addition, wouldn't some sort of visitor also be more self-documenting. The visitor would take the same argument as the tuple: visitor<tuple::type_list> BTW, the zip file did not have tuple.hpp; hence, I'm guessing what the appropriate nested type (type_list) for the tuple types would be. Then visitor could be defined as follows: template < typename HeadField , typename OtherFields > struct visited_fields < HeadField , OtherFields > : public OtherFields { virtual void visit_field( HeadField& a_field ) =0 ; }; struct empty_visited_field { protected: void visit_field ( void ) /**@brief * Only to avoid compile error during parse of subclass' * using declaration. */ ; }; }//exit visitors_detail namespace #include <boost/mpl/inherit_linearly.hpp> template < typename type_list > struct visitors : public boost::mpl::inherit_linearly < type_list , visited_fields <boost::mpl::arg<2> , boost::mpl::arg<1> > , empty_visited_field >::type { };

1 1

Re: [boost] Re: [website] Oh the fun..
by brangdon＠cix.compulink.co.uk 28 Apr '05

28 Apr '05

In-Reply-To: <d4ovvk$vbv$1(a)sea.gmane.org> gmane(a)contacts.eelis.net (Eelis van der Weegen) wrote (abridged): > I think this layout makes unreasonable assumptions about the browser > window width, and looks terrible when viewed in a slightly less wide > browser window. At the narrowest setting the shaded grey border consumes about 1/7th of the width. In my view that's rather a lot to spend on something that provides no useful information. It's annoying if it is the reason you have to scroll. -- Dave Harris, Nottingham, UK.

2 1

[rational] Announcing new maintainer -- call for feature requests
by Jonathan Turkanis 28 Apr '05

28 Apr '05

Dear All, Several months ago I became the official maintainer of Boost.Rational, and am just now getting around to considering proposed modifications to the library. I would like to know: 1. Do people use Boost.Rational, and if so, what is it used for, and with what template parameters? 2. What changes or additions would people like to see? Here are the changes that have been proposed: A. [me and others] Make int_type (and possibly param_type) public. This will be done. B. [Andras Erdei] Make rational more usable with limited precision integral types by providing automatic rounding when the result of a computation can not be represented exactly, or by asserting or throwing an exception in such cases. C. [Andras Erdei] Provide automatic selection of the underlying int_type which would be fastest for representing rational arithmetic with a specified precision. ---- Proposal B Andras's original proposal, if I understood it correctly, was to use a form of rounding which could be computed as the natural side-effect of the existing algorithm to compute a rational arithmetic operation, in the case that the actual result could not be represented exactly using the underlying int_type. At the time, I questioned whether it would be acceptable to change the current behavior of rational, since some current users may be relying on it. This is partly why I am asking question 1) above. A more general solution would be to add an optional template parameter representing a rounding policy, which could - implement no rounding, silently resulting garbage in some cases (this is the current implementation) - implement Andras's rounding method - throw an exception if rounding would be required - assert if rounding would be required, or - (possibly) implement some other rounding algorithm The reason I qualified the last option with "possibly" is that implementing alternate rounding policies may require completely different algorithms for the basic operations, meaning that the implementations of the basic operations would have to be moved into the rounding policy, which I'm reluctant to do. Andras, please let me know if I have misrepresented your ideas. For background, see these threads: http://lists.boost.org/MailArchives/boost/msg76375.php http://lists.boost.org/MailArchives/boost/msg80121.php ---- Jonathan

15 55

XML output from Test library
by Richard Jennings 28 Apr '05

28 Apr '05

I am using the CVS head of Boost.Test up to date this morning and producing the log output in XML format. I find that the resulting file is not not well-formed XML according to Firefox and Saxon. There are two issues: there are angle brackets in the attribute values and a single file contains two node trees. The first issue is indirectly caused by using the BOOST_FUNC_TEMPLATE_TEST_CASE macro. The log output then becomes: <TestLog><TestSuite name="Shared/Pulse"><TestCase name="ShortPulses<Imaging::AirSamplePeakFind_c>">... Where "ShortPulses" is the templated test function and "Imaging::AirSamplePeakFind_c" is the name of the type. The angle brackets in attribute valule is not allowed. The second issue is that the output stream contains the <TestLog> node tree which is then followed by the <TestResult> tree so the XML document has two top level nodes. Previously the TestLog output used to go to stdout and TestResult went to stderr (I believe), meaning that I could capture them to different files, or redirect the TestLog ouptut and leave TestResult on the terminal if I wanted to. I'm not sure what the solution is if it's preferred not to send TestResult to stderr. Perhaps the XML document needs a higher level node such as <Boost.Test> that contains <TestLog> and <TestResult>. I notice also that the XML stream is all on one line, wc under cygwin reports zero lines and a line length of 38438 in my case. This is perfectly readable by browsers and Saxon however not by standard text editors. Would it be possible to put some line breaks in so that the file could be more easily viewed in text editors? For reference I am running my test program as: > ./TestPulse.exe --log_level=ALL --output_format=XML > TestResult.xml Using cygwin under Windows. The test harness is compiled using Borland BCB6. Richard

3 2

Re: Formal Review: FOREACH macro
by Sam Saariste 28 Apr '05

28 Apr '05

* What is your evaluation of the design? Very good. It's very easy to use and the support for lvalues access to container/range elements is very powerful and convenient. Also when using overloaded operators on the elements, the resulting code is much cleaner with FOREACH than with an iterator based loop. * What is your evaluation of the implementation? Brilliant * What is your evaluation of the documentation? Good. The library doesn't need too much documentation really. Maybe some pitfall section as already has been mentioned would be a useful addition. * What is your evaluation of the potential usefulness of the library? Very useful - it lets you express small ad-hoc algorithms in an elegant way and in the place where you want them. I have used it for more than 6 months now and have added it to my standard set of idioms. Once you get into the FOREACH mindset, you don't only want to use it for std::for_each type jobs but you would also want to use it for std::transform type ones. In situations where you can use push_back on a result container, FOREACH serves this purpose as it is. However, I have encountered situations where this was not possible and where I wanted a second macro, say FOREACH2, that iterates over 2 ranges simultaneously. I have had such a need on more than one occasion. One situation was as above and in other situations I had to combine the elements of two ranges. I implemented such a FOREACH2 macro myself based on Eric's implementation and it appeared to be relatively straightforward. For this reason, I would like to request this as an enhancement to the library. Users of FOREACH wouldn't be affected by such an additional macro, so I see little reason why people would object to it. Similarly, I could imagine use for a 3 range version, where the elements of two ranges are combined and the results get written into the third range exactly as you can do with std::transform. * Did you try to use the library? With what compiler? Did you have any problems? As mentioned above, I have used the library on a regular basis for over 6 months. All my experience is based on using it with VC7.1. I have not had any problems. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 6 month experience with the library from a user perspective. After reading Eric's article on Artima, I have studied the implementation in quite a bit of detail so that I could implement an extended version that would iterate over 2 ranges. * Are you knowledgeable about the problem domain? Not more or less than other experienced C++ developers. * Do you think the library should be accepted as a Boost library? YES, definitely. Cheers, Sam Saariste

2 1

aligned_storage not a POD?
by Peter Dimov 28 Apr '05

28 Apr '05

boost::aligned_storage is supposed to be an implementation of TR1 aligned_storage, which yields a POD. I even see a specialization of is_pod for aligned_storage in the header. However the class itself (::type only echoes its type back) does not seem a POD at all. It has a default constructor, destructor, a private copy constructor and whatnot. aligned_storage_test does not test its PODness, it only looks at is_pod. I think that a reasonable test for PODness would be to try to initialize with = {} (if nonscalar) and/or use it in a union. -- Peter Dimov http://www.pdimov.com

4 12

Small tuple extension
by Giovanni P. Deretta 28 Apr '05

28 Apr '05

Hi, I have been using a small extension to the tuple library 'get' function, that I have found very handy. It allows the extraction of an element of a tuple by specifying its type instead of the index. Example: given the tuple boost::tuple<type1, type2, type3> get<type1> returns the first element of the tuple of that type. This allows one to write more self describing code: you don't need to look up the tuple element type when you find an indexed get function buried deep inside some code. This is especially useful with nested tuples where for example 'get<3>(get<5>(get<0>(my_tuple)))' looks more like line noise than real code :). I use type wrappers to wrap built-in types and give them unique names (a typedef that creates unique objects instead of aliases would be really useful here!). Anyway, here is my code. It is really a quick hack, i probably did get returns type wrong (probably works only for value type elements), and I'm sure metaprogramming experts here can do much better. namespace detail { namespace mpl = boost::mpl; template <typename Tuple, typename Type, int Index> struct traverse { typedef typename ::boost::tuples::element<Index, Tuple>::type this_type; typedef typename mpl::if_ <boost::is_same <this_type, Type>, mpl::int_<Index>, typename traverse<Tuple, Type, Index-1>::type >::type type; }; template<typename Tuple, typename Type> struct traverse <Tuple, Type, -1> { typedef boost::mpl::int_ <boost::tuples::length<Tuple>::value> type; }; template <typename Tuple, typename Type> class index_of_type { public: typedef typename traverse<Tuple, Type, boost::tuples::length<Tuple>::value-1>::type type; }; } template <typename Type, typename Tuple> Type& get(Tuple& tp) { typedef typename detail::index_of_type<Tuple, Type>::type index; return boost::tuples::get<index::value>(tp); } template <typename Type, typename Tuple> const Type& get(const Tuple& tp) { typedef typename detail::index_of_type<Tuple, Type>::type index; return boost::tuples::get<index::value>(tp); } }

6 24