April 2005 - Boost - lists.boost.org

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

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