November 2006 - Boost - lists.preview.boost.org

Proposed addition to the iterator library for iterating over all tuples.
by Alex Mendes da Costa 19 Jun '09

19 Jun '09

Hi folks: I quite often have to write code to do the following: Given N sequences, generate all the N-tuples s.t. the i'th element in each tuple is drawn from the i'th sequence. For example, if sequence S1 is { 1, 2, 3 } and sequence S2 is { 10, 20 }, I need to generate these tuples: (1, 10), (2, 10), (1, 20), (2, 20). I think this problem could be solved elegantly with a iterator similar to zip_iterator. I have some questions: (1) Is there already a way to do this in boost? (2) If not, would this be a worthwhile addition to the iterator library? (3) If so, could I contribute code for this, or must the existing library owners write it? (4) If so, how would I go about getting my code added? Most of the docs seem to be about submitting entire libraries, rather than extensions to existing libraries. Thanks, Alex

4 18

[fusion] list/detail/at_impl.hpp, Suggest recrusive elem_at_c instead of recursive apply
by Larry Evans 24 Oct '07

24 Oct '07

In boost/fusion/.../list/detail/at_impl.hpp the apply is recursive; however, the only reason for the recursion is to "find the right element type". The other reason for apply is the same as that of the apply in.../vector/detail/at_impl.hpp. "find the right element type" in vector's at_impl is done with mpl::at. The similarity between list and vector at_impl would be more apparent if: template <typename Sequence, int N> struct elem_at_c { typedef typename mpl::eval_if< mpl::bool_<N == 0> , mpl::identity<typename Sequence::car_type> , elem_at_c<typename Sequence::cdr_type, N-1> >::type type; }; were used to find the right element type. Then the frist part of list::at_impl::apply would be: template <typename Sequence, typename N> struct apply { typedef elem_at_c<Sequence, N::value> element; typedef typename mpl::eval_if< is_const<Sequence> , detail::cref_result<element> , detail::ref_result<element> >::type type; which is very similar to the counterpart in vector: template <typename Sequence, typename N> struct apply { typedef mpl::at<typename Sequence::types, N> element; typedef typename mpl::eval_if< is_const<Sequence> , detail::cref_result<element> , detail::ref_result<element> >::type type;

2 3

[Ann] Variadic Templates
by Doug Gregor 20 Aug '07

20 Aug '07

Hello Fellow Boosters, I have just completed implementing support for "Variadic Templates" in GCC. Variadic templates are C++ templates that can accept any number of "extra" template arguments, just like a function that uses C-style varargs (with "...") can accept any number of extra arguments. Unlike C varags, however, variadic templates work both for class templates and function templates, and are completely type-safe. Why do variadic templates matter for Boost? For one thing, they will allow us to eliminate the use of preprocessor metaprogramming in many, many places throughout the library. This can simplify our library implementations drastically, and eliminate those annoying "caps" on the number of arguments one can use (ever tried to use bind () with 11 arguments?). Beyond that, variadic templates are just plain fun, and there are undoubtedly a great number of metaprogramming applications. Here are a few teasers to illustrate what variadic templates can do: We can implement an MPL-like type vector with one line of code: template<typename... Types> struct vector { }; The "ellipsis" means that we can pack any number of arguments into the "template parameter pack" called Types. Of course, we can do the same for MPL's vector_c: template<typename T, T... Values> struct vector_c { }; Unimpressed? Here's an implementation of tuple that accepts any number of element types: template<typename... Values> class tuple; template<> class tuple<> { }; template<typename Head, typename... Tail> class tuple<Head, Tail...> : private tuple<Tail...> { protected: Head m_head; }; We're using recursion to build up the tuple. The ellipsis operator works with partial specializations, too, packing together "extra" arguments at the end. Of course, all of this would be useless if we couldn't write some of the other tuple operations, like operator==: inline bool operator==(const tuple<>&, const tuple<>&) { return true; } template<typename T, typename... TTail, typename U, typename... UTail> bool operator==(const tuple<T, TTail...>& t, const tuple<U, UTail...>& u) { return t.head() == u.head() && t.tail() == u.tail(); } Variadic function templates can accept any number of function arguments, so we can now (finally!) implement a type-safe printf() without mangling the tried-and-true printf() syntax or restricting ourselves to POD types: void printf(const char* s) { while (*s) { if (*s == '%' && *++s != '%') throw std::runtime_error("invalid format string: missing arguments"); std::cout << *s++; } } template<typename T, typename... Args> void printf(const char* s, const T& value, const Args&... args) { while (*s) { if (*s == '%' && *++s != '%') { std::cout << value; return printf(++s, args...); } std::cout << *s++; throw std::runtime_error("extra arguments provided to printf"); } I've also built prototypes of of Function and Bind, among other things. The Bind example is especially interesting, and worth a read (see below) Interested? There is more information and a complete implementation in GCC available at: http://www.generic-programming.org/~dgregor/cpp/variadic- templates.html I've written two documents describing variadic templates in more detail: http://www.generic-programming.org/~dgregor/cpp/brief-intro.pdf : A brief introduction to variadic templates, that walks through the printf() implementation. http://www.generic-programming.org/~dgregor/cpp/variadic- templates.pdf : A complete proposal to introduce variadic templates into C++0x. This contains annotated versions of the tuple, function, and bind prototypes along with a detailed description of the capabilities of variadic templates. The GCC implementation is complete, supporting all of the features described in the proposal. I've used it for proof-of-concept implementations of several libraries. In the (near) future, I hope to introduce variadic templates support into the "official" GCC, but I need your help! Are variadic templates worthwhile? Will they help us build better, cleaner Boost libraries in the future? Should we bring variadic templates to the C++ committee, to enable better implementations of TR1 components and eliminate the need for much of the preprocessor metaprogramming we do today? Feedback is greatly appreciated. Cheers Doug Gregor Open Systems Lab @ Indiana University

20 39

Review Request: Boost Exception
by Emil Dotchevski 07 Jul '07

07 Jul '07

I believe the proposed Boost Exception library is now mature enough for formal review. Please read the documentation at: http://www.revergestudios.com/boost-exception/boost-exception.htm Here is a direct link to the source code, boost build jamfiles and tests. Tested with MSVC 7.1, MSVC 8.0, GCC 3.4.4, and Comeau C++ 4.3.8: http://www.revergestudios.com/boost-exception/boost-exception.zip Regards, Emil Dotchevski

7 21

[BGL] Adapter from bidirectional to undirected graph
by Benoit 05 Jul '07

05 Jul '07

Hello everyone, I have been using the BGL for quite some time with both directed and bidirectional graphs (with adjacency_list). Sometimes i need to use these graphs in algorithms as if they were undirected... AFAICT, this is currently not possible because out_edges() exists in all cases, but don't do the same... The obvious solution consists in writing a dedicated adapter used for translating a bidirectional graph into a directed one at least for out_edges(), and optionally for other stuff (internal properties, vertex and edge descriptors?) to make this subtle change as transparent as possible. Can you think of another way ? Is there already such an adapter somewhere (i have unsuccessfully tried to find one...) ? In case it didn't exist, would anyone else be interested to have one ? Benoît PS : I'd like to thank the authors of the BGL, it's a pleasure to work with it everyday !

3 2

[defer] - comments?
by simon meiklejohn 14 Mar '07

14 Mar '07

Anyone had a play with the defer library in the vault and want to comment on its usefulness? It clearly shares much in common with the asio Dispatcher concept but with the freedom to define more general Dispatchers. (e.g. 'Create thread per callback' and 'Dispatch Callback via Message Pump', both of which violate the specific guarantees of the asio Dispatcher concept, that the callback occur in a thread that has called asio::demuxer::run().) One potential application for defer would be in conjunction with asio, creating the thread(s) which call demuxer::run() in a succinct form. Cheers Simon

3 2

Re: [boost] Optimized portable isnan, isfinite, fpclassify etc
by Boris Gubenko 16 Jan '07

16 Jan '07

Boris Gubenko wrote: > I'm checking with the OS folks and will report back here, > for both HP-UX/ia64 and Tru64 Alpha. And the answer is: > You are correct that both platforms are capable of executing in > either endianness. However, the operating systems operate in only > one. > HP-UX is *always* big endian > Tru64 is *always* little endian > [...] > Summary: > A compile time check is adequate. > So, with current <endian.hpp>, I think, that we are all set for these platforms. Thanks, Boris ----- Original Message ----- From: "Boris Gubenko" <Boris.Gubenko(a)hp.com> To: <boost(a)lists.boost.org> Cc: "Boris Gubenko" <Boris.Gubenko(a)hp.com> Sent: Tuesday, October 17, 2006 9:12 AM Subject: Re: [boost] Optimized portable isnan, isfinite, fpclassify etc >> Now endian.hpp defines BOOST_BIG_ENDIAN on HP-UX. >> This was suggested by Boris Gubenko. >> >> If you are right John, then this seems to be incorrect. >> Shouldn't endian.hpp then define something like >> BOOST_UNKNOWN_ENDIAN on HP-UX? >> >> Boris, do you have any comments on this? > > I'm checking with the OS folks and will report back here, > for both HP-UX/ia64 and Tru64 Alpha. > > Thanks, > Boris > > ----- Original Message ----- > From: "Johan Råde" <rade(a)maths.lth.se> > To: <boost(a)lists.boost.org> > Sent: Tuesday, October 17, 2006 9:00 AM > Subject: Re: [boost] Optimized portable isnan, isfinite, fpclassify etc > > >> John Maddock wrote: >>> I'm not completely certain, but I believe HP-UX falls into this >>> category: >>> the idea is that you can pass binary data from one platform to another, >>> and >>> just switch the endianness bit to access it natively (think distributed >>> applications). >> >> Now endian.hpp defines BOOST_BIG_ENDIAN on HP-UX. >> This was suggested by Boris Gubenko. >> >> If you are right John, then this seems to be incorrect. >> Shouldn't endian.hpp then define something like BOOST_UNKNOWN_ENDIAN on >> HP-UX? >> >> Boris, do you have any comments on this? >> >> Then my fpclassify could use a fast implementation when BOOST_BIG_ENDIAN >> or BOOST_LITTLE_ENDIAN is defined and a slower implementation when >> BOOST_UNKNOWN_ENDIAN is defined. >> >> --Johan >> >> >> >> >> >> >> >> _______________________________________________ >> Unsubscribe & other changes: >> http://lists.boost.org/mailman/listinfo.cgi/boost >> >> >

7 79

Re: [boost] Boost Timer Update
by Stephan Kaiser 08 Jan '07

08 Jan '07

Hello Philippe, Do you also plan to tackle the problem with QueryPerformanceCounter() on multi-core systems? QPC reports problematic/mismatching values on certain multi-core CPUs (e.g. Athlon X2). Cheers, Stephan ----- Original Message ----- From: "Philippe Vaucher" <philippe.vaucher(a)gmail.com> Newsgroups: gmane.comp.lib.boost.devel Sent: Sunday, October 29, 2006 6:16 PM Subject: Boost Timer Update > Hello guys, > > I've been quite away from home in the last months so I wasn't able to work > on the timer, but now I'm back so I'd have some time now. > Today I've implemented Gennaro's device idea for QueryPerformanceCounter() / > timeGetTime(). > > As the vault's down, you can find it at > http://www.unitedsoft.ch/boost/timer_2006_10_29.zip. > > Are you guys still using QuickBook for the documentation ? Before going away > I started using it but it was quite painful. > > Philippe Vaucher > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost >

7 24

[BGL] make_filtered_graph() should accept const Graph&
by Vladimir Sykora 02 Jan '07

02 Jan '07

Hi, Can anyone correct the make_filtered_graph() function on boost/graph/filtered_graph.hpp to accept a const Graph& ? Thanks, --vjs

2 2

interest in pair projection iterators?
by Lewis Hyatt 22 Dec '06

22 Dec '06

Hi All, I am in the middle of writing a large body of numerical code for data analysis and have found the boost library very useful for a number of things. I do a lot of work with std::map and with containers of std::pair objects, and one thing I've always felt annoyed with is the difficulty of interfacing a value_type of std::pair with the STL algorithms. Frequently, for instance, it is nice to represent data as a std::list< std::pair<double,double> > and then to be able to work with the first and second coordinates independently and pass them to std::accumulate() or whatever. The SGI extensions select1st() and select2nd() are somewhat useful but also non-standard, and they frequently require memory-wasting buffers to store only the first or second elements. I have a relatively simple system for solving this problem and it strikes me as the kind of quick thing that might be worth including in boost. The idea is to define a template class, template<typename Iterator> class first_iterator_t { Iterator pair_iter; public: first_iterator_t(Iterator const&); /*...*/ }; which overloads operator*() and operator->() to access the element named "first" of the object returned by Iterator::operator*(). (With something analagous for second_iterator_t.) A function named first_iterator() provides a convenient creation function a-la std::make_pair(). That's it for the most part, the class only needs to provide the required iterator interface which mostly consists of just calls to Iterator::operator functions. There is also the need to define the appropriate iterator_traits typedefs. There is a small issue of deducing whether the iterator needs to be a const iterator or not, which can be solved with partial specialization of a second template class containing nested typedefs. The end result is that something like this is now conveniently available: map<int, double> m; m[1] = 0.1; m[2]=0.2; m[5]=0.5; //prints: 1 2 5 copy(first_iterator(m.begin()), first_iterator(m.end()), ostream_iterator<int>(cout, "\t")); //prints: 0.1 0.2 0.5 copy(second_iterator(m.begin()), second_iterator(m.end()), ostream_iterator<double>(cout, "\t")); I don't see a way to do this otherwise without resorting to something like select1st(), and that also requires the use of std::transform(), which I find distasteful since the required operation is really just a simple copy. So anyway do you think this is useful enough to possibly include in boost somewhere, or is it too trivial? I have what I believe to be correct code, which could be made boost-ready with little effort. Thanks for your advice! -Lewis

4 5

[BoostBook] documentation typo
by Michael Marcin 15 Dec '06

15 Dec '06

http://tinyurl.com/uuqvb "This section describes how to manually configure Boost Boost version 2 (BBv@) for BoostBook." I'm pretty sure that's not quite right :) Probably meant: "This section describes how to manually configure Boost Build version 2 (BBv2) for BoostBook." - Michael Marcin

2 3

property tree library not in CVS?
by Janek Kozicki 13 Dec '06

13 Dec '06

Hello, I recall that Property Tree library has been accepted into boost: http://tinyurl.com/h5nlt I can find its documentation on the web and source to download, but I have downloaded current CVS: cvs -d:pserver:anonymous@boost.cvs.sourceforge.net:/cvsroot/boost login cvs -z3 -d:pserver:anonymous@boost.cvs.sourceforge.net:/cvsroot/boost checkout boost cvs -d:pserver:anonymous@boost.cvs.sourceforge.net:/cvsroot/boost logout And I cannot find it there. Anyone can explain why it's not there? (or maybe I'm just blind) -- Janek Kozicki |

6 12

New getting started guide
by David Abrahams 11 Dec '06

11 Dec '06

I've got a first draft of the new getting started guide ready (enclosed). Comments would be appreciated. I plan to factor it out into separate documents, e.g. one just for *nix, one just for Visual Studio, etc., which should help make it more coherent... but I need to do a small amount of tool writing before I can accomplish that without duplicating information. The source file is checked in at more/getting_started.rst -- Dave Abrahams Boost Consulting www.boost-consulting.com

12 32

GIL Review: GIL extensibility example: packed pixel
by Lubomir Bourdev 10 Dec '06

10 Dec '06

A few reviewers have remarked on whether GIL can handle more complex formats, such as packed RGB565 format, (i.e. 5 bits red, 6 bits green, 5 bits blue). Since we can handle even images representing syntethic functions, we can certainly handle packed pixels. We took a stab at providing a model for packed pixel formats and posted it here: http://opensource.adobe.com/gil/packed_pixel.hpp This just serves as an example. The code could be improved and made more generic. Here is how you can define a packed pixel of three channels: typedef packed3_pixel<rgb_t,boost::uint16_t,boost::uint8_t,5,11> rgb565_pixel_t; This defines an RGB pixel over 16-bit data. The first channel always starts at bit 0. The second channel starts at bit 5, and the third at bit 11. Of course, you can define a whole range of packed pixels. Here is an LAB pixel that fits in a byte: typedef packed3_pixel<lab_t,boost::uint8_t,boost::uint8_t,2,2> lab223_pixel_t; Here is example code of using packed pixels: boost::function_requires<HeterogeneousPixelValueConcept<rgb565_pixel_t> >(); boost::function_requires<ChannelConcept<rgb565_pixel_t::kth_channel_t<0> ::reference> >(); typedef type_from_x_iterator<rgb565_pixel_t*>::view_t rgb565_view_t; typedef image<rgb565_view_t> rgb565_image_t; // Read a test image rgb8_image_t unpacked_image; jpeg_read_image("test.jpg",unpacked_image); // copy it into packed 565 form rgb565_image_t packed565_image(get_dimensions(unpacked_image)); copy_pixels(color_converted_view<rgb565_pixel_t>(view(unpacked_image),pa cked3_color_converter()),view(packed565_image)); // save it back unpacked. You will see dithering artifacts, especially for channels of low bit depth jpeg_write_view("test2.jpg",color_converted_view<rgb8_pixel_t>(view(pack ed565_image),packed3_color_converter())); // Invoke gradient on the packed data directly. Note: You need the most // generic version of x_gradient that supports heterogeneous pixels rgb8_image_t gradient(get_dimensions(unpacked_image)); x_gradient(view(packed565_image), view(gradient)); Note that everything you can do with GIL already automatically extends to packed pixels. You can run GIL heterogeneous algorithms on them. You can color convert them. You can include them in runtime types... Most importantly, GIL core does not need to change. Lubomir

2 2

[date_time]facet questions
by Martin Adrian 08 Dec '06

08 Dec '06

I have a common function to output dates to sql strings. It works like this: std::locale sqllocale(database_type db_type) { switch (db_type) { case MSAccess: return std::locale(std::locale::classic(), new dt::date_facet("#%m/%d/%Y#")); case MSSQLServer: return std::locale(std::locale::classic(), new dt::date_facet("{ d '%Y-%m-%d' }")); ... } } std::ostringstream ss; ss.imbue(sqllocale(MSAccess)); ss << "SELECT * FROM tbl WHERE somedate=" << dt::date(2006,11,24); Now I need to put dates into an excel spreadsheet which uses a date formatted as a date duration. This can't be expressed via the formatters so I created my own facet but discovered some strange things: 1. The "put" function of the date_facet calls "do_put_tm" instead of just "do_put" like standard facets. 2. The virtual "do_put_tm" function takes a struct tm instead of a date argument. Unfortunatly this means extra work. My code now looks like this: case MSExcel: { struct excel_date_facet : public dt::date_facet { excel_date_facet(::size_t ref_count = 0) : dt::date_facet(ref_count) { } virtual std::ostreambuf_iterator<char> do_put_tm( std::ostreambuf_iterator<char> next, std::ios_base& a_ios, char_type fill_char, const tm& tm_value, string_type a_format) const { // Here I now got the date as a struct tm which is pretty useless // when I want to calculate a date duration. // convert it back to a date dt::date d = dt::date_from_tm(tm_value); // +2 here because Excel starts on 1900-0-0 and treats 1900 // as a leap year (!) unsigned long days = ((d - dt::date(1900,1,1)).days() + 2); return std::use_facet<std::num_put<char> >(a_ios.getloc()).put( next, a_ios, fill_char, days ); } }; // struct excel_date_facet return std::locale(std::locale::classic(), new excel_date_facet()); } Can I recommend that the date_facet is changed so that "put" calls "do_put" which converts to a struct tm and calls a "do_put_tm" function. And another question: I asked a long time ago why the default formatting for dates is "2006-Nov-24" instead of the current locale formatting. Don't remember the answer now but I had a look in the TR2 proposal for date_time and saw that it remains that way. Why should something in a standard don't follow the current locale?

2 2

What happened with RTL (Relational Template Library)
by Oliver.Kowalke＠qimonda.com 07 Dec '06

07 Dec '06

Hi, I saw RTL from Dmitriy Arapov and Arkadiy Vertleyb in teh Vault but it seams not to reviewed yet?! Regards, Oliver

2 5

Re: [boost] Preliminary working prototypeofatomic_shared--multithreaded wrapper for shared_ptr.
by Talbot, George 02 Dec '06

02 Dec '06

> Chris Thomasson wrote: > > Sent: Wednesday, November 22, 2006 11:32 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] Preliminary working prototypeofatomic_shared-- > multithreaded wrapper for shared_ptr. > > "Talbot, George" <Gtalbot(a)locuspharma.com> wrote in message > news:acfee74296c36aa7458ec7c5580b0b9c4564c67b@locuspharma.com... > > Hi, > > > I've attached to this e-mail a working prototype of a wrapper for > > shared_ptr that uses a spinlock so that the shared_ptr may be updated > > atomically from multiple threads. For example, two threads can both > > attempt to set the value of the same shared_ptr, and the last one will > > win. This wrapper includes a "compare_and_set" method for performing > > lock-free-style "read, copy, attempt swap, repeat" updating to a data > > structure, though, of course because the wrapper uses a spinlock, it > > isn't truly lock free. > > I suggest you take a look at a mostly lock-free implementation: > > http://appcore.home.comcast.net/vzoom/refcount/ > > Your wrapper uses the spinlock when it doesn't have to... A swap and a cas > to shared locations that contain pointers to the refcount > object do not need to be locked... I know. I was just doing a simple prototype first that has the interface that I want. I figure if I get everything working with the simple stupid spinlock, then I can go back and re-work with atomic operations. > Weak reference count modifications do not need to be > locked... That's good to know. > You don't need to use DWCAS either... Don't I need to do that for assignment and compare_and_set for the actual shared_ptr<>, since it's two words? (pointer to object and pointer to refcount.) This is good feedback. Thank you for the help. -- George T. Talbot gtalbot(a)locuspharma.com

2 1

Re: [boost] boost::shared_ptr<>::compare_and_swap()--AmIinsaneforwanting this?
by Talbot, George 02 Dec '06

02 Dec '06

My mistake. So that seems like a bit of a useless guarantee--basically any structure constructed with shared_ptr can only be read by the same thread that's writing to the structure unless all of the pointer operations are guarded with a mutex or spinlock, right? Ignoring compare-and-swap, have you or anyone else experimented with using a spinlock (as you mentioned previously) to remove the above restriction? What would that do to performance and complexity? Could you use a compare-and-swap type of operation to implement read/write thread safety? -- George T. Talbot <gtalbot(a)locuspharma.com> > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Peter Dimov > Sent: Friday, November 10, 2006 10:16 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] boost::shared_ptr<>::compare_and_swap()-- > AmIinsaneforwanting this? > > Talbot, George wrote: > > > I'm sorry if I'm being too dense here. I think a section in the > > documentation saying exactly what is guaranteed and what isn't would > > help a lot. > > Here you go: > > http://boost.org/libs/smart_ptr/shared_ptr.htm#ThreadSafety > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

4 6

Yet another bignum type
by Daryle Walker 01 Dec '06

01 Dec '06

This is something I've been working on for the past few months. It's in the Sandbox and I just uploaded it to the new Vault as "big_radix_whole.tar.bz2" under the "Math - Numerics" directory, i.e. <http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam e=big_radix_whole.tar.bz2&directory=Math%20-%20Numerics&>. The files might choke on some systems, since I used naked min & max and the test file has #pragma marks all over it. (My IDE function-lists all the test modules as "BOOST_AUTO_TEST_CASE()", without anything in the parentheses, so I needed the marks to navigate the huge file.) I'm using Xcode 2.4, with Apple's special GCC, on a Mac OS X 10.4.8 PowerPC system. The only documentation right now is the Doxygen comments. It's a run-of-the-mill bignum type. It uses the philosophy of the STL containers to use a separate template parameter for the memory allocations. The type is radix-specific, also given as a template parameter. It's of the simplest bignum type, an arbitrary-length unsigned integer class. (Signed integers, fixed-point, floating-point, rational, etc., variants can all be built off of this kind of bignum.) As such, the renditions of the traditional algorithms are fairly pure. The biggest issue from a mathematical standpoint is that the type can't be a proper ring, since it doesn't support additive inverses (besides zero). Every other arithmetic operation (that doesn't need negative values) can work. The work-around for subtraction is the addition of "subtract-absolutely" member functions, which compute the absolute value of the difference, and return a "bool" indicating what the sign would have been. Many of the operations are repeated, each with optimized algorithms for the different sizes of the parameters. Since the traditional method of multiplication is actually a fused-add/multiply, member functions for such fused actions were added. There are many variants for shifting-up where additions/subtractions start since it's faster than doing a separate shifting operation first. And it saves memory, which was an important goal in all the algorithms, along with the strong exception guarantee. Besides the asserts, there is generally no protection for pre-condition violations (except for exceptions for negative results, divides by zero, and conversions). There are commented-out plans for functions that do powers and (truncated) roots, especially squaring and square-roots, and pseudo-reciprocals (for an N-digit value, find another M-digit value, with M <= N, closest to giving a product of Radix**2N, useful to implement exact-division by multiply-by-reciprocal, which is cheaper for huge N). What other routines should be added? Any hints on how to do said routines? Should there be Serialization? Could Spirit and/or Regex be used for the I/O routines? Any compiler workarounds to be added? -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

15 38

FW: [Boost-users] Suggestion for boost`s smart pointers
by Sohail Somani 01 Dec '06

01 Dec '06

Hi, Please see the following email about additional template parameters for scoped_ptr. The quick hack I wrote for it is below (I've used this in previous project as well). I think it would be very useful to many users and wouldn't change any source using scoped_ptr. Thanks, Sohail ==== I've been thinking something like (just something I hacked together just now). Not sure if there is a nicer way. #include <string> #include <cstdio> #include <iostream> template<typename T> struct DeletingDeleter { DeletingDeleter(T * p) { delete p; std::cout << "DeletingDeleter" << std::endl; } }; struct FileCloser { FileCloser(FILE * f) { std::cout << "Closing file" << std::endl; fclose(f); } }; template<typename T, typename Deleter=DeletingDeleter<T> > struct scoped_ptr { scoped_ptr():p_(0){} scoped_ptr(T * p):p_(p){} ~scoped_ptr() { Deleter d(p_); } T * get() {return p_;} // regular stuff private: T * p_; }; typedef scoped_ptr<FILE,FileCloser> file_ptr; int main() { scoped_ptr<int> a; // maintain old interface scoped_ptr<int> b(new int(5)); file_ptr p(fopen("myfile.txt","w")); fprintf(p.get(),"Hello world!\n"); } > -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of David Klein > Sent: Tuesday, November 28, 2006 4:55 PM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] Suggestion for boost`s smart pointers > > Sohail Somani wrote: > >> -----Original Message----- > >> From: boost-users-bounces(a)lists.boost.org > >> [mailto:boost-users-bounces@lists.boost.org] On Behalf Of > David Klein > >> > >> Sohail Somani wrote: > >> > >>>> -----Original Message----- > >>>> From: boost-users-bounces(a)lists.boost.org > >>>> [mailto:boost-users-bounces@lists.boost.org] On Behalf > Of mark cox > >>>> > >>>> wow, this seems like a great idea, a scoped_ptr with deleter > >>>> would be v.useful. > >>>> mark > >>>> > >>>> > >>> I've been thinking something like (just something I hacked > >>> > >> together just > >> > >>> now). Not sure if there is a nicer way. > >>> > >>> > > [snip] > > > >> +1 vote for this idea :) > >> > >> i actually kind of did this for my current project, > >> because i needed a custom deleter for scoped_ptr, > >> when shared_ptr was to much overhead... > >> > > > > As did I, but it was not for performance but for readability. Shared > > pointers mean... Shared. Scoped don't. > > _______________________________________________ > > Boost-users mailing list > > Boost-users(a)lists.boost.org > > http://lists.boost.org/mailman/listinfo.cgi/boost-users > > > > > > yep exactly, > thatswhy i "ripped" scoped_ptr out of boost and added my > custom_deleter > stuff. > (i only *thought* about shared_ptr to do the job) > > so are there any objections about adding this feature to scoped_ptr? > > -- > regards dave > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users >

3 4

[boost.thread] Atomic condition notify/mutex lock
by Eugene Prystupa 01 Dec '06

01 Dec '06

I'm trying to find a way to atomically pulse a condition variable and acquire a mutex, something I get used to in the .Net world. It doesn't seem that this operation exists in boost/thread. Anyone has done this with boost? Thanks, Eugene

5 9

Re: [boost] [dynamic_any] multimethods
by Steven Watanabe 30 Nov '06

30 Nov '06

AMDG Alexander Nasonov wrote: > Steven Watanabe wrote: > >> > typedef any_tuple<_1, _1, _2, >> > where_<random_access_iterator<_1>, callable<_2, bool(deref_result<_1>, >> > deref_result<_1>)> > > sort_args; >> > void sort_impl(mpl::at<sort_args, _1>::type&, mpl::at<sort_args, >> > _1>::type&, mpl::at<sort_args, _2>::type&); >> > template<class Iter, class F> >> > void sort(Iter begin, Iter end, F f) { >> > sort_args args(begin, end, f); >> > sort_impl(get<0>(args), get<1>(args), get<2>(args)); >> > } >> > I don't quite understand how it's connected to dynamic_any::any > objects. Does object 1 stores an iterator to a beginning of a sequence > while object 2 stores past-the-end of the sequence? Yes. In a cpp file sort_impl would just be void sort_impl( mpl::at<sort_args, _1>::type& begin, mpl::at<sort_args, _1>::type& end, mpl::at<sort_args, _2>::type& f) { std::sort(begin, end, f); } The idea was the each element of the tuple would be like a dynamic_any::any object with operations on several elements like f(*begin, *next(begin)). So, in my example deref_result<_1> is a placeholder for the type of *begin. I think it would be defined something like: template<class> struct deref_result : placeholder {}; I'm not sure about the functions. Single functions should be defined almost like what you already have except that there would be many placeholder types. groups of functions like random_access_iterator need to be made possible. template<class T> struct random_access_iterator : compound_concept<...> {}; A similar effect could be achieved by simply putting a boost::tuple in a dynamic_any::any. The advantage of this method is to allow individual objects to be copied independently. I'm mostly wondering whether a significant proportion of the uses of multimethods could be handled in this way. >> > Would such a class be useful? >> > Any better ideas for the interface? >> > >> > The big problem is the amount of metaprograming needed. >> > 10 operations were more than msvc 7.1 could handle with >> > my version of dynamic_any::any<> and this is much worse. >> > Definitely. I think, it this case we should find a good balance > between compile-time and runtime. I don't like an interface where > functions for different arguments variantions are registred at > runtime, but if there is no other solution, I can accept it. But in > this case it would be better to start with multimethods library and > then use it for dynamic_any. Originally, I wanted to get close to > untyped languages where you can multiply numbers and strings and > things like this. This means that you have a limited set of types > (bool, integers, floats, chars, strings and references to objects). > This set can be bigger in C++ because you may want to handle > references to different base classes differently but it's still, I > thought, can be enumerated in one place. All combinations of 20 types > gives 400 variants. It's big for mpl::vector but I believe modern > compilers can process typelists of this length if a library is > carefully crafted. If the number of types is really fixed then variant would be a better solution, I would think. The method I suggested before: template<class Operation, class T> struct overload; allows all the variations associated with T to be loaded the first time the constructor of dynamic_any::any runs. Probably to make the lookup efficient for large numbers of functions, some dynamic loading would be needed anyway (unless there is some trick I haven't heard of for getting a unique integer from a type at compile time). What I currently have is not very efficient. It takes about 60 ns. per dispatch for all possible combinations of a ternary function with 4 types (a total of 64). Compare that to the single dispatch case which only takes about 6 ns. In Christ, Steven Watanabe

1 0

Re: [boost] using lambda's pointer to member function and, boost::function
by Steven Watanabe 30 Nov '06

30 Nov '06

AMDG "Rodolfo Lima" wrote: > >> try boost::lambda::bind(&aux::a, _1, x); > Thanks for your advice, but that's not the kind of solution that I'm looking > for. There are some constraints > on aux that forbids me to use bind. Please read the thread > http://lists.boost.org/boost-users/2006/11/23754.php where I explain the > whole situation. > Ok. how about boost::lambda::bind<int>(&_1->*&aux::a, x)? > Thanks, > Rodolfo Lima. > In Christ, Steven Watanabe

1 0

Boost regression notification (2006-11-30 [RC_1_34_0])
by Douglas Gregor 30 Nov '06

30 Nov '06

Boost Regression test failures Report time: 2006-11-30T12:49:52Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… 73 failures in 10 libraries concept_check (22) iostreams (13) math (8) random (1) serialization (7) signals (4) statechart (8) test (8) utility (1) xpressive (1) |concept_check| class_concept_fail_expected: borland-5.6.4 borland-5.8.2 hp_cxx-71_006_tru64 intel-vc8-win-9.1 msvc-6.5 msvc-7.0 msvc-7.1 msvc-8.0 msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_gpp concept_check_fail_expected: borland-5.6.4 borland-5.8.2 hp_cxx-71_006_tru64 intel-vc8-win-9.1 msvc-6.5 msvc-7.0 msvc-7.1 msvc-8.0 msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_gpp |iostreams| bzip2_test: msvc-7.1 msvc-7.1 msvc-8.0 msvc-8.0 finite_state_filter_test: cw-9.4 gzip_test: msvc-7.1 msvc-7.1 msvc-8.0 msvc-8.0 zlib_test: msvc-7.1 msvc-7.1 msvc-8.0 msvc-8.0 |math| common_factor_test: borland-5.8.2 cw-9.4 msvc-6.5 msvc-7.0 msvc-7.1 msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_gpp |random| random_test: intel-linux-9.0 |serialization| test_no_rtti_xml_archive_dll: qcc-3.3.5_gpp test_reset_object_address: msvc-7.0 test_reset_object_address_dll: msvc-7.0 test_variant_xml_archive: borland-5.8.2 test_variant_xml_archive_dll: borland-5.8.2 test_variant_xml_warchive: borland-5.8.2 test_variant_xml_warchive_dll: borland-5.8.2 |signals| deletion_test: msvc-6.5 ordering_test: msvc-6.5 signal_n_test: msvc-6.5 trackable_test: msvc-6.5 |statechart| FifoSchedulerTestBoth: msvc-7.1 msvc-8.0 FifoSchedulerTestNative: msvc-7.1 msvc-8.0 FifoSchedulerTestNormal: msvc-7.1 msvc-8.0 FifoSchedulerTestRelaxed: msvc-7.1 msvc-8.0 |test| prg_exec_fail1: intel-vc71-win-9.1 intel-vc8-win-9.1 msvc-6.5 msvc-7.0 msvc-8.0 prg_exec_fail2: darwin-4.0.1 prg_exec_fail3: cw-9.4 test_fp_comparisons: cw-9.4 |utility| operators_test: gcc-3.4.5_linux_x86_64 |xpressive| test3u: qcc-3.3.5_cpp

2 1

Boost inspection notification (2006-11-30/RC_1_34_0) *X*
by Rene Rivera 30 Nov '06

30 Nov '06

Boost Inspection Report Run Date: 17:04:52 UTC, Thursday 30 November 2006 An inspection program <http://www.boost.org/tools/inspect/index.html> checks each file in the current Boost CVS for various problems, generating this as output. Problems detected include tabs in files, missing copyrights, broken URL's, and similar misdemeanors. Totals: 11421 files scanned 890 directories scanned (including root) 242 problems reported Problem counts: 0 files with invalid line endings 0 bookmarks with invalid characters 3 invalid urls 175 broken links 21 unlinked files 7 file/directory names issues 1 files with tabs 0 violations of the Boost min/max guidelines 35 usages of unnamed namespaces in headers (including .ipp files) Summary: archive (3) bind (1) boost-root (1) build (2) date_time (1) doc (2) filesystem (37) graph (3) inspect (1) interprocess (1) iostreams (4) lambda (4) more (66) mpl (1) multi_array (2) numeric (1) parameter (2) program_options (1) ptr_container (1) python (7) regex (1) regression (14) serialization (1) signals (1) test (81) tuple (1) type_traits (1) utility (1) Details: *R* invalid (cr only) line-ending *A* invalid bookmarks, invalid urls, broken links, unlinked files *N* file/directory names issues *T* tabs in file *M* uses of min or max that have not been protected from the min/max macros, or unallowed #undef-s *U* unnamed namespace in header |archive| boost/archive/basic_streambuf_locale_saver.hpp: *N* name exceeds 31 characters boost/archive/impl/xml_wiarchive_impl.ipp: *U* unnamed namespace at line 53 boost/archive/iterators/remove_whitespace.hpp: *U* unnamed namespace at line 57 |bind| boost/bind/placeholders.hpp: *U* unnamed namespace at line 25 |boost-root| index.htm: *A* broken link: ../doc/html/signals.html |build| tools/build/v2/example/make/main.cpp.pro: *N* name contains more than one dot character ('.') tools/build/v2/test/test_system.html: *A* unlinked file |date_time| libs/date_time/xmldoc/date_time_docs_howto.html: *A* unlinked file |doc| doc/html/boost_math/inverse_complex.html: *A* unlinked file doc/html/jam.html: *A* unlinked file |filesystem| libs/filesystem/doc/do-list.htm: *A* invalid URL (hardwired file): file://?/ *A* invalid URL (hardwired file): file://?/UNC/ libs/filesystem/doc/i18n.html: *A* broken link: convenience.htm#basic_recursive_directory_iterator *A* broken link: exception.htm *A* broken link: operations.htm *A* broken link: operations.htm#Do-the-right-thing *A* broken link: operations.htm#is_directory *A* broken link: operations.htm#is_file *A* broken link: operations.htm#status libs/filesystem/doc/index.htm: *A* broken link: ../build/Jamfile *A* broken link: convenience.htm *A* broken link: fstream.htm *A* broken link: operations.htm#create_directory *A* broken link: operations.htm#create_hard_link *A* broken link: operations.htm#current_path *A* broken link: operations.htm#directory_iterator *A* broken link: operations.htm#equivalent *A* broken link: operations.htm#file_size *A* broken link: operations.htm#initial_path *A* broken link: operations.htm#is_file *A* broken link: operations.htm#is_symlink *A* broken link: operations.htm#status *A* broken link: operations.htm#symlink_status *A* broken link: path.htm#Canonical *A* broken link: path.htm#Grammar *A* broken link: path.htm#Normalized *A* broken link: path.htm#default_name_check *A* broken link: path.htm#name_check_mechanism *A* broken link: path.htm#normalize *A* broken link: path.htm#operator_eq *A* broken link: path.htm#synopsis libs/filesystem/doc/portability_guide.htm: *A* broken link: path.htm#name_check_typedef libs/filesystem/doc/tr2_proposal.html: *A* invalid URL (hardwired file): file:///C|/boost/site/libs/filesystem/doc/operations.htm#complete_note |graph| boost/graph/maximum_cardinality_matching.hpp: *N* name exceeds 31 characters libs/graph/doc/lengauer_tarjan_dominator_tree.htm: *N* name exceeds 31 characters libs/graph/doc/sorted_erdos_renyi_generator.html: *N* name exceeds 31 characters |inspect| tools/inspect/index.html: *A* broken link: build/Jamfile |interprocess| libs/interprocess/index.html: *A* broken link: doc/html/index.html |iostreams| libs/iostreams/doc/acknowledgments.html: *A* unlinked file libs/iostreams/doc/concepts/multi-character.html: *A* unlinked file libs/iostreams/doc/installation.html: *A* broken link: ../../../tools/build/v1/build_system.htm |lambda| boost/lambda/core.hpp: *U* unnamed namespace at line 62 boost/lambda/detail/lambda_functors.hpp: *U* unnamed namespace at line 25 boost/lambda/exceptions.hpp: *U* unnamed namespace at line 24 libs/lambda/doc/index.html: *A* broken link: ../../LICENSE_1_0.txt |more| more/getting_started.html: *A* broken link: ../Jamfile *A* broken link: ../tools/build/v1/borland-tools.html *A* broken link: ../tools/build/v1/build_system.htm *A* broken link: ../tools/build/v1/build_system.htm#build *A* broken link: ../tools/build/v1/como-tools.html *A* broken link: ../tools/build/v1/cw-tools.html *A* broken link: ../tools/build/v1/darwin-tools.html *A* broken link: ../tools/build/v1/dmc-stlport-tools.html *A* broken link: ../tools/build/v1/dmc-tools.html *A* broken link: ../tools/build/v1/edg-tools.html *A* broken link: ../tools/build/v1/gcc-nocygwin-tools.html *A* broken link: ../tools/build/v1/gcc-stlport-tools.html *A* broken link: ../tools/build/v1/gcc-tools.html *A* broken link: ../tools/build/v1/intel-linux-tools.html *A* broken link: ../tools/build/v1/intel-win32-tools.html *A* broken link: ../tools/build/v1/kcc-tools.html *A* broken link: ../tools/build/v1/kylix-tools.html *A* broken link: ../tools/build/v1/mingw-stlport-tools.html *A* broken link: ../tools/build/v1/mingw-tools.html *A* broken link: ../tools/build/v1/mipspro-tools.html *A* broken link: ../tools/build/v1/msvc-stlport-tools.html *A* broken link: ../tools/build/v1/msvc-tools.html *A* broken link: ../tools/build/v1/sunpro-tools.html *A* broken link: ../tools/build/v1/tru64cxx-tools.html *A* broken link: ../tools/build/v1/vacpp-tools.html *A* broken link: ../tools/build/v1/vc-7_1-stlport-tools.html *A* broken link: ../tools/build/v1/vc-7_1-tools.html *A* broken link: ../tools/build/v1/vc-8_0-tools.html *A* broken link: ../tools/build/v1/vc7-stlport-tools.html *A* broken link: ../tools/build/v1/vc7-tools.html more/version_history.html: *A* broken link: ../tools/build/v1/intel-linux-tools.html *A* broken link: ../tools/build/v1/intel-win32-tools.html *A* broken link: ../tools/build/v1/msvc-stlport-tools.html |mpl| boost/mpl/alias.hpp: *U* unnamed namespace at line 17 |multi_array| boost/multi_array/base.hpp: *U* unnamed namespace at line 69 libs/multi_array/test/generative_tests.hpp: *U* unnamed namespace at line 57 |numeric| libs/numeric/conversion/index.html: *A* broken link: ../../LICENSE_1_0.txt |parameter| libs/parameter/doc/html/python.html: *A* broken link: tag::x(int *A* broken link: tag::y*(int |program_options| libs/program_options/doc/index.html: *A* broken link: ../.../../LICENSE_1_0.txt |ptr_container| libs/ptr_container/doc/tutorial_example.html: *A* unlinked file |python| libs/python/doc/building.html: *A* broken link: ../../../tools/build/v1/build_system.htm *A* broken link: ../../../tools/build/v1/build_system.htm#user_globals *A* broken link: ../../../tools/build/v1/build_system.htm#variants libs/python/doc/tutorial/index.html: *A* broken link: ../../../LICENSE_1_0.txt libs/python/doc/v2/May2002.html: *A* broken link: ../../../../tools/build/v1/build_system.htm *A* broken link: ../../../../tools/build/v1/gen_aix_import_file.py libs/python/doc/v2/faq.html: *A* broken link: ../../../../tools/build/v1/build_system.htm |regex| libs/regex/performance/input.html: *A* unlinked file |regression| regression/.htaccess: *N* leading character of ".htaccess" is not alphabetic tools/regression/index.htm: *A* broken link: build/Jamfile tools/regression/xsl_reports/xsl/html/issues_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/html/library_developer_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/html/library_user_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/html/make_tinyurl.html: *A* unlinked file tools/regression/xsl_reports/xsl/html/summary_developer_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/html/summary_user_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/v2/html/issues_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/v2/html/library_developer_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/v2/html/library_user_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/v2/html/make_tinyurl.html: *A* unlinked file tools/regression/xsl_reports/xsl/v2/html/summary_developer_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/v2/html/summary_user_legend.html: *A* unlinked file |serialization| libs/serialization/src/basic_xml_grammar.ipp: *U* unnamed namespace at line 43 |signals| boost/signals/detail/named_slot_map.hpp: *T* |test| boost/test/floating_point_comparison.hpp: *U* unnamed namespace at line 206 *U* unnamed namespace at line 228 boost/test/impl/cpp_main.ipp: *U* unnamed namespace at line 42 boost/test/impl/exception_safety.ipp: *U* unnamed namespace at line 400 boost/test/impl/framework.ipp: *U* unnamed namespace at line 199 boost/test/impl/plain_report_formatter.ipp: *U* unnamed namespace at line 45 boost/test/impl/progress_monitor.ipp: *U* unnamed namespace at line 38 boost/test/impl/results_collector.ipp: *U* unnamed namespace at line 106 boost/test/impl/results_reporter.ipp: *U* unnamed namespace at line 48 boost/test/impl/unit_test_log.ipp: *U* unnamed namespace at line 79 boost/test/impl/unit_test_monitor.ipp: *U* unnamed namespace at line 35 boost/test/impl/unit_test_parameters.ipp: *U* unnamed namespace at line 50 boost/test/results_collector.hpp: *U* unnamed namespace at line 40 boost/test/test_tools.hpp: *U* unnamed namespace at line 255 boost/test/utils/iterator/token_iterator.hpp: *U* unnamed namespace at line 166 boost/test/utils/named_params.hpp: *U* unnamed namespace at line 216 boost/test/utils/runtime/cla/dual_name_parameter.ipp: *U* unnamed namespace at line 43 boost/test/utils/runtime/cla/modifier.hpp: *U* unnamed namespace at line 34 boost/test/utils/runtime/env/modifier.hpp: *U* unnamed namespace at line 34 boost/test/utils/runtime/file/config_file.hpp: *U* unnamed namespace at line 169 *U* unnamed namespace at line 64 *U* unnamed namespace at line 74 boost/test/utils/runtime/file/config_file_iterator.hpp: *U* unnamed namespace at line 68 boost/test/utils/trivial_singleton.hpp: *U* unnamed namespace at line 52 *U* unnamed namespace at line 61 libs/test/build/msvc71_proj/config_file_iterator_test.vcproj: *N* name exceeds 31 characters libs/test/doc/components/prg_exec_monitor/compilation.html: *A* broken link: ../../../build/Jamfile libs/test/doc/components/prg_exec_monitor/index.html: *A* broken link: ../../../../../boost/test/cpp_main.hpp libs/test/doc/components/test_tools/index.html: *A* broken link: ../../tests/boost_check_equal_str.html libs/test/doc/components/test_tools/reference/BOOST_CHECK_CLOSE.html: *A* broken link: BOOST_CHECK_CLOSE_FRACTION.html libs/test/doc/components/test_tools/reference/BOOST_CHECK_MESSAGE.html: *A* broken link: BOOST_MESSAGE.html libs/test/doc/components/test_tools/reference/BOOST_CHECK_SMALL.html: *A* broken link: BOOST_CHECK_CLOSE_FRACTION.html libs/test/doc/components/test_tools/reference/tools_list.html: *A* broken link: ../../btl1.gif *A* broken link: BOOST_CHECK_CLOSE_FRACTION.html libs/test/doc/components/utf/compilation.html: *A* broken link: ../../../build/Jamfile libs/test/doc/components/utf/components/index.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/components/test_case/abstract_interface.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/auto_register_facility.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/boost_function_tc.html: *A* broken link: ../../../../../../../boost/test/unit_test_suite_ex.hpp *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/class_tc.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/function_tc.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/index.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/param_boost_function_tc.html: *A* broken link: ../../../../../../../boost/test/unit_test_suite_ex.hpp *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/param_class_tc.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/param_function_tc.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/tc_template.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_log/custom_log_formatter.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_log/index.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_result/index.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_suite/index.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/index.html: *A* broken link: getting_started/index.html libs/test/doc/components/utf/parameters/build_info.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/catch_system_errors.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/detect_memory_leaks.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/index.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/log_format.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/log_level.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/no_result_code.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/output_format.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/random.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/report_format.html: *A* broken link: ../../../../../LICENSE_1_0.txt *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/report_level.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/show_progress.html: *A* broken link: ../../btl1.gif libs/test/doc/examples/unit_test_example1.html: *A* broken link: ../../example/unit_test_example1.cpp libs/test/doc/examples/unit_test_example2.html: *A* broken link: ../../example/unit_test_example2.cpp libs/test/doc/examples/unit_test_example3.html: *A* broken link: ../../example/unit_test_example3.cpp libs/test/doc/examples/unit_test_example4.html: *A* broken link: ../../example/unit_test_example4.cpp libs/test/doc/examples/unit_test_example5.html: *A* broken link: ../../example/unit_test_example5.cpp *A* broken link: ../../example/unit_test_example5.input libs/test/doc/tests/auto_unit_test_test.html: *A* broken link: ../../test/auto_unit_test_test.cpp libs/test/doc/tests/auto_unit_test_test_mult.html: *A* broken link: ../../test/auto_unit_test_test_mult1.cpp *A* broken link: ../../test/auto_unit_test_test_mult2.cpp libs/test/doc/tests/unit_test_suite_ex_test.html: *A* broken link: ../../test/unit_test_suite_ex_test.cpp libs/test/doc/tutorials/hello_the_testing_world.html: *A* broken link: ../../../../../LICENSE_1_0.txt *A* broken link: ../execution_monitor/index.html libs/test/doc/tutorials/new_year_resolution.html: *A* broken link: ../../../../../../LICENSE_1_0.txt |tuple| libs/tuple/index.html: *A* broken link: ../../site/LICENSE_1_0.txt |type_traits| libs/type_traits/cxx_type_traits.htm: *A* unlinked file |utility| libs/utility/index.html: *A* broken link: ../../site/LICENSE_1_0.txt

1 0