- Boost - lists.boost.org

[pool] Making it honour BOOST_HAS_THREADS
by Markus Schöpflin 29 Apr '05

29 Apr '05

Hello, attached is a patch which makes the pool library honour the general boost threading support flag. As a side effect, it also makes the pool library usable on Tru64 because on that platform you can only include <pthread.h> if you're actually compiling with -pthread. Any objections to applying this patch, anyone? Markus Index: mutex.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/pool/detail/mutex.hpp,v retrieving revision 1.6 diff -u -r1.6 mutex.hpp --- mutex.hpp 28 Sep 2004 12:55:44 -0000 1.6 +++ mutex.hpp 28 Apr 2005 11:41:20 -0000 @@ -19,6 +19,10 @@ #define BOOST_MUTEX_HELPER_WIN32 1 #define BOOST_MUTEX_HELPER_PTHREAD 2 +#if !defined(BOOST_HAS_THREADS) && !defined(BOOST_NO_MT) +# define BOOST_NO_MT +#endif + #ifdef BOOST_NO_MT // No multithreading -> make locks into no-ops #define BOOST_MUTEX_HELPER BOOST_MUTEX_HELPER_NONE @@ -37,12 +41,13 @@ #error Unable to determine platform mutex type; define BOOST_NO_MT to assume single-threaded #endif - -#ifdef BOOST_WINDOWS - #include <windows.h> -#endif -#ifdef _POSIX_THREADS - #include <pthread.h> +#ifndef BOOST_NO_MT +# ifdef BOOST_WINDOWS +# include <windows.h> +# endif +# ifdef _POSIX_THREADS +# include <pthread.h> +# endif #endif namespace boost { @@ -50,6 +55,8 @@ namespace details { namespace pool { +#ifndef BOOST_NO_MT + #ifdef BOOST_WINDOWS class win32_mutex @@ -102,6 +109,8 @@ #endif // defined(_POSIX_THREADS) +#endif // !defined(BOOST_NO_MT) + class null_mutex { private:

2 2

RE: [boost] Re: Steps before moving to Subversion
by Schrom, Brian T 29 Apr '05

29 Apr '05

Do you have a test case that we can reproduce your missing line merge and post back to Subversion? -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Rene Rivera Sent: Thursday, April 28, 2005 7:32 AM To: boost(a)lists.boost.org Subject: [boost] Re: Steps before moving to Subversion David Abrahams wrote: > Rene Rivera <grafik.list(a)redshift-software.com> writes: >>Never mind.. just found the documentation of svnmerge. And hence have >>some answers. > > What are they, please? I don't know them. http://www.dellroad.org/svnmerge/index >>But here's the thing, it solves the book keeping aspect of the svn >>merge. But it doesn't solve the problem I had. It's not like I did not >>follow the procedure of marking the comments with merge points and >>using "-r N:M" to only merge the un-merged changes. My problem was >>that the svn merge operation lost a line, literally. Which means that >>the conflict resolution algorithm has a problem. So unless there's a >>solution out there that doesn't use "svn merge" we might get bitten. > > Oh. Well it's not nice to have a bug, but you have to check your > merge results by hand anyway, don't you? Of course you should check the merge results.. And I did in this case. But what I did was open the source file, which has the usual "<<<" and ">>>" conflict markers, and edit to make sure all the changes where in there. But that conflict result was missing a line. When I did a diff from what I had to the repository version on my branch, the other check I go through when merging, the missing line obviously didn't show either. What I failed to do was do a manual diff between the two other original source files, the head revision and the branch revision, which svn creates when it finds a conflict. I don't consider what I did as unusual, as I was expecting the conflict resolution of a merge to *never* loose information, under any circumstances. -- -- 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

3 2

Re: [boost] Re: Re: [circular_buffer] comparison operators
by Jan Gaspar 29 Apr '05

29 Apr '05

Hi Frederik, the discussion didn't end up with a conclusion. (I appended all the submissions regarding this comparison operators issue.) In my opinion, there was an idea behind the fact the comparison operators don't work for different types at the time the STL was being designed. Although I don't know what idea it was. (Does anyone?) Regardless it was good or not I'd like the circular_buffer to behave the same way as other STL containers. I don't want to break the contract. On the other hand when we consider comparison between 2 circular_buffers of different types, why not to take it one step further and allow comparison of 2 different containers. E.g. circular_buffer<int> x = { 1, 2, 3}; deque<short> y = { 1, 2, 3}; x == y; // makes sense? It doesn't matter that the containers are of different types - it is about comparing content, isn't it? Jan --- Fredrik Blomqvist <fredrik_blomqvist(a)home.se> wrote: > Jan Gaspar wrote: > > Hi Fredrik, > > > > I'm attaching the discussion during the formal > review > > regarding the comparison operators. > Thanks. I now remember reading some of those posts. > Did you reach a conclusion then? (Guess I have to > dig the archives a bit...) > > > into the reading, I'd like to say that my > intension > > was to write STL compliant container nothing less > or > > more and I'd like to stick with this. > That's a goal I fully support! But to my > understanding > making this change wouldn't compromise compliance > (?). > And as mentioned, several other boost components > already > use this scheme, in this context most notably > multi-index. > > Regards > // Fredrik Blomqvist > > > > Subject: RE: [boost] Formal Review: Circular > Buffer > > Date: Tue, 9 Mar 2004 09:44:34 -0800 > > From: "Powell, Gary" <powellg(a)amazon.com> > > To: boost(a)lists.boost.org > > > > > > Shouldn't the comparison functions allow the types > to > > differ? I mean > > don't they still lexigraphically compare as long > as > > there is a comparison > > function F that a F b for each element exists > > > > circular_buffer<T, MyAlloc> x; > > circular_buffer<S, YourAlloc> y; > > > > bool b = x == y; for where the operator T == S is > > valid? And what does > > the allocator have to do with it? > > > > Therefore IMO, all of the comparison functions > should > > change from > > > > template< typename T, typename Alloc> > > bool operator F ( circular_buffer<T, Alloc> &lhs, > > circular_buffer<T, Alloc> &rhs); > > > > to > > > > template< typename T1, typename Alloc1, > > typename T2, typename Alloc2> > > bool operator F ( circular_buffer<T1, Alloc1> > &lhs, > > circular_buffer<T2, Alloc2> > &rhs); > > > > Yours, > > -Gary- > > > > ----------------------------------------------- > > > > > > To: boost(a)lists.boost.org > > From: "Pavel Vozenilek" > <pavel_vozenilek(a)hotmail.com> > > > > Date: Tue, 9 Mar 2004 20:52:29 +0100 > > Subject: [boost] Re: Formal Review: Circular > Buffer > > > > > > Hmm, do you know a STL implementation/some > container > > with this feature? It may be often bug to compare > > containers with > > different types. > > > > /Pavel > > > > > ----------------------------------------------------- > > > > Subject: RE: [boost] Re: Formal Review: Circular > > Buffer > > Date: Tue, 9 Mar 2004 13:55:15 -0800 > > From: "Powell, Gary" <powellg(a)amazon.com> > > To: boost(a)lists.boost.org > > > > > > No, but just because the standard libraries > scr*wed up > > is no reason to perpetuate the mistake. > > > > It's the rule of unexpected consequences. > > > > Is > > circular_buffer<int> x = { 1, 2, 3}; > > circular_buffer<short> y = { 1, 2 ,3}; > > > > x == y ?? or not? > > > > Sure looks like it should work. > > > > The VTL library does it IMO correctly, allowing > that > > if there is an operation T1 F T2, then V1 F V2 > > compiles. Otherwise you just force the user to > write > > what should be library code. > > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > Send instant messages to your online friends http://uk.messenger.yahoo.com

3 3

Re: [boost] Re: Boost to the rescue
by JOAQUIN LOPEZ MU?Z 28 Apr '05

28 Apr '05

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Miércoles, Abril 27, 2005 11:05 pm Asunto: [boost] Re: Boost to the rescue > "JOAQUIN LOPEZ MU?Z" <joaquin(a)tid.es> writes: > > * As for #3 and #4, I've got this idea round my head > > that Boost would benefit of a "community site" where > > people of various expertise levels could mingle > > together, post Boost-related articles, etc. Something > > like CodeProject or Gamedev, which have a less > > intimidating appearance than www.boost.org. Some months > > ago I asked for a Boost-related forum in CodeProject, > > to no avail :( > > Something wrong with boost-users? There *must* be something wrong with it: Consider the (developer list)/(user list) posting ratio, around 10:1 --I guess (I hope) that the actual developer/user ratio is much lower than that. So, it seems like somehow the list is not so popular. Some hypotheses as of why: * Posting to and scanning a mailing list is not an impulsive action, and takes some will from the part of the poster. * The list could feel a little imposing, as most of the time it is the lib's author herself who responds. Somehow this formality prevents casual chatting, experience sharing etc. I'd hope most of the support to be provided by other users, not the authors. * Response time is not as fast as with a forum. * The looks ain't sexy. * Boost users don't really have that many problems to consult about :) > > If so, I'd be happy to set up a forum at boost-consulting.com, if we > can decide on the right software. > A couple of seemingly popular free bulletin packages are YaBB and MyBulletinBoard. More ambitious community packages are Plone (which has about anything) and Postnuke: these two latter could serve as the basis for a fuller community site. Joaquín M López Muñoz Telefóinca, Investigación y Desarrollo

3 4

[Boost-bugs] [ boost-Bugs-1191985 ] boost/functional addressof collision
by SourceForge.net 28 Apr '05

28 Apr '05

Bugs item #1191985, was opened at 2005-04-28 14:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1191985&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Foster Brereton (fosterbrereton) Assigned to: Nobody/Anonymous (nobody) Summary: boost/functional addressof collision Initial Comment: in boost/functional.hpp, line 473: if (!detail::function::has_empty_target(addressof(f))) { addressof is a function that resides in the Metrowerks namespace as well, so there are instances in boost::bind that will fail with an ambiguous lookup. Specifying boost::addressof explicitly will fix this problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1191985&group_… ------------------------------------------------------- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Big integer continued
by Marcin Kalici�ski 28 Apr '05

28 Apr '05

Hi, I got the big integer proposal document id wrong, it is actually n1744, here's a link to it: http://www2.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1744.pdf I think there are 2 major, separate issues with big integer class: interface and implementation. 1. Interface Class name is 'integer'. Some sort of rationale for this name is in n1744: "just like std::string introduces a variable length string to complement char[N], this class introduces an integer class without a fixed size". It will be a signed integer. Unsigned version could also be done, but does it give anything extra? I plan to make the interface closely resemble that of boost::rational, as it was already accepted into boost. What I like about it is being minimalistic. I'd like to follow that style, it is much easier to add new functions later than to remove existing ones. What I plan to have initially: - construction from long - construction from const char *, possibly also std::string (strings with C-style number literals, but with unlimited length) - addition, subtraction, multiplication, division, modulo - increment, decrement (pre and postfix) - unary plus and minus - all comparisons - bitwise operations (and, or, xor, not). - shifts - conversion to unspecified bool type - stream input and output There's an issue with some of the bitwise operations, as they are only well defined for integers of fixed size. What should for example ~boost::integer(0) return? Ideally an infinitely long integer filled with binary 1s. boost::rational does not have a conversion operator to integer type, which is good as most of rationals are not integers. Should boost::integer have such an operator, with runtime range checking? 2. Implementation Current implementation uses the following representation: bool sign; std::vector<some unsigned integer type> ; The basic question is how far should I go with performance optimization? It is of course impossible for one person to achieve the performance level of some estabilished big integer libraries, such as GMP. Addition and subtraction of large integers can be done very efficiently in assembly language of most processors, for example on 80x86 by utilizing carry flag. Portable C++ implementation would be probably about a magnitude slower. I haven't measured that, but I have a portable implementation and it does a lot of ifs just to detect integer overflows. Unlike boost::rational, implementation of some big integer operations (multiplication, division) is not easy, depending on the performance we are trying to get. There are several multiplication algorithms with different complexity bounds. The fastest known is Strassen multiplication using FFT, as far as I know. There are also some in-the-middle algorithms, such as Karatsuba multiplication. Performance-oriented libraries choose one of them depending on multiplicands sizes. Implementing all that may be a real pain, and implementing that in assembly language optimized for some processor is a task outside my capabilities. And there are also multi-processor multiplication algorithms... Another idea would be to write portable, potentially slow implementations only, and allow boost::integer to use some existing libraries internally, when user really cares about speed. cheers, M.

1 0

[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