David Abrahams <[EMAIL PROTECTED]> wrote:
> "Joel de Guzman" <[EMAIL PROTECTED]> writes:
>
>> Beman Dawes <[EMAIL PROTECTED]> wrote:
>>
>>> >> In the main CVS? iterator-categories.html is still dated several days
>>> >> ago. Or am I looking in the wrong place?
>>> >
>>> >I guess so. Why woul
In another thread, by Joaquín M López Muñoz, there is talk of a helper
class like:
//
template<
class Class,typename Type,
Type Class::*PtrToMember,
typename Compare=std::less >
struct less_by
{
less_by(const Compare& comp=Co
On Saturday, July 12, 2003, at 9:21 PM, Joaquín M López Muñoz wrote:
Hi again,
- Mensaje Original -
De: Fernando Cacciola <[EMAIL PROTECTED]>
Fecha: Sábado, Julio 12, 2003 7:32 pm
Asunto: [boost] Re: Re: Interest in multiindex_set?(again)
[stuff about conceptual structure of multtindex_se
"Joel de Guzman" <[EMAIL PROTECTED]> writes:
> Beman Dawes <[EMAIL PROTECTED]> wrote:
>
>> >> In the main CVS? iterator-categories.html is still dated several days
>> >> ago. Or am I looking in the wrong place?
>> >
>> >I guess so. Why would I be editing a document in the multi_array lib?
>>
Matthias Troyer wrote:
Dear Boosters,
After a recent cvs update I can no longer compile the boost filesystem
library:
The filesystem library was broken by the update in the main CVS to the
new iterator adapators library, and AFAIK the changes that are needed
have yet to be completed.
---
Jerem
Beman Dawes <[EMAIL PROTECTED]> wrote:
> >> In the main CVS? iterator-categories.html is still dated several days
> >> ago. Or am I looking in the wrong place?
> >
> >I guess so. Why would I be editing a document in the multi_array lib?
>
> I was talking about boost-root/libs/iterator/doc/it
At 07:19 PM 7/12/2003, David Abrahams wrote:
>Beman Dawes <[EMAIL PROTECTED]> writes:
>
>> At 04:17 PM 7/12/2003, David Abrahams wrote:
>>
>> >> A single-pass iterator is required to support r++ (inherited from
the
>> >> incrementable iterator requirements), but I guess that we've
>> >> uninten
Larry Evans wrote:
[snip]
I'm trying to get synopsis to translate into Boost guideline form;
however, I'm having trouble with getting comments properly attached
to the declarations. As soon as that is done, I'll upload it.
The comments are properly attached; however, the ASCII formatter
only fo
Aleksey Gurtovoy <[EMAIL PROTECTED]> wrote:
> David Abrahams wrote:
>> Aleksey Gurtovoy <[EMAIL PROTECTED]> writes:
>>
>>> IMO we should just stop using 'void_' for internal purposes and give it
>>> up to users :).
>>
>> I am still unsure about 'void_' being better than 'nil' or
>> 'null' Us
Dear Boosters,
After a recent cvs update I can no longer compile the boost filesystem
library:
/Users/troyer/src/boost/boost/filesystem/path.hpp:98: `
default_iterator_policies' undeclared in namespace `boost'
Is my CVS checkout in disarray since I can nowhere find
default_iterator_policies,
David Abrahams <[EMAIL PROTECTED]> wrote:
> Aleksey Gurtovoy <[EMAIL PROTECTED]> writes:
>
>> IMO we should just stop using 'void_' for internal purposes and give it
>> up to users :).
>
> I am still unsure about 'void_' being better than 'nil' or
> 'null' Users already have a type, 'void',
Beman Dawes <[EMAIL PROTECTED]> writes:
> At 04:17 PM 7/12/2003, David Abrahams wrote:
>
> >> A single-pass iterator is required to support r++ (inherited from the
> >> incrementable iterator requirements), but I guess that we've
> >> unintentionally dropped the requiremnt for *r++ of readable
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>> Aleksey Gurtovoy <[EMAIL PROTECTED]> writes:
>>
>> > IMO we should just stop using 'void_' for internal purposes and give it
>> > up to users :).
>>
>> I am still unsure about 'void_' being better than 'nil' or
>> 'null'
Fernando Cacciola wrote:
JOAQUIN LOPEZ MU?Z wrote:
[...]
Another thing I couldn't figure out is how to compose indices
hierachically.That is, how to reproduce a typical SQL SELECT *
ORDER BY X,Y,Z.
Since you're modeling an indexed table, this functionality should be
supported.
This is an interesti
Brian McNamara wrote:
> If and when I get FC++ ( http://www.cc.gatech.edu/~yannis/fc++/ ) into
> Boost, FC++ has the same kind of selectors you've shown above (named
> "fst" and "snd", as in Haskell). Whereas these function objects also
> cannot be used with STL algorithms requiring adaptables (fo
At 04:17 PM 7/12/2003, David Abrahams wrote:
>> A single-pass iterator is required to support r++ (inherited from the
>> incrementable iterator requirements), but I guess that we've
>> unintentionally dropped the requiremnt for *r++ of readable
>> single-pass iterator, by allowing incrementable it
On Sat, 12 Jul 2003 20:54:26 +0200, Aleksey Gurtovoy wrote:
> Daniel Frey wrote:
>> I wonder if it's possible to distinguish regressions into "fail" and
>> "not supported", where the latter means that it fails and we
>> (currently?) can't make it work. This way it might be easier to find
>> regres
At 05:47 AM 7/12/2003, Daniel Frey wrote:
>PS: Would it make sense to have a "boost bug bashing week" or something
>to fix some more bugs/regressions? Or do we wait for users to complain
>and provide fixes?
Until recently, figuring out which tests should pass for each compiler was
difficult. Some
On Sat, Jul 12, 2003 at 01:21:49PM +0100, Andy Sawyer wrote:
> There's a third form I've also found useful on occasion:
>
> struct selector1st
> {
> template
> const typename Pair::first_type& operator()( const Pair& a ) const
> {
> return a.first;
> }
> };
>
> Which has the advantage
David Abrahams wrote:
> Aleksey Gurtovoy <[EMAIL PROTECTED]> writes:
>
> > IMO we should just stop using 'void_' for internal purposes and give it
> > up to users :).
>
> I am still unsure about 'void_' being better than 'nil' or
> 'null' Users already have a type, 'void', which means void.
.
David Abrahams <[EMAIL PROTECTED]> writes:
>> That's fine with me - that requirement was a source of bugs in my
>> code and violated the rule of least astonishment as far as I was
>> concerned.
>>
>> But before I remove the test from the filesystem library that verifies
>> the old input iterator s
Hi again,
- Mensaje Original -
De: Fernando Cacciola <[EMAIL PROTECTED]>
Fecha: Sábado, Julio 12, 2003 7:32 pm
Asunto: [boost] Re: Re: Interest in multiindex_set?(again)
[stuff about conceptual structure of multtindex_set deleted]
OK, I'm glad we finally got to understand each other :)
T
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes:
> IMO we should just stop using 'void_' for internal purposes and give it
> up to users :).
I am still unsure about 'void_' being better than 'nil' or
'null' Users already have a type, 'void', which means void.
There's no correspondence between vo
Beman Dawes <[EMAIL PROTECTED]> writes:
> The old input iterator 24.1.1 had a requirement:
>
>*r++ returned type T, semantics {T tmp= *r; ++r; return tmp; }
>
> The new Single Pass Iterators in N1477 have no such requirement.
That's because the requirement mixes access and traversal.
> Th
Daniel Frey wrote:
> > The libraries itself are relatively bug-free, but there are plenty of
> > portability problems with some compilers. For the HP-UX, IRIX, and DEC
> > compilers in the versions I have access to, it's probably a waste of
> > time to try and fix problems, unless it's obvious wha
David Abrahams wrote:
> That's because void_ is for MPL internal use only; it's not a type
> you should manipulate
While I agree that _some_ user needs for a special unique type a
better handled by introducing a new one (otherwise you'll get yourself
into situation like we have right now, only in
The old input iterator 24.1.1 had a requirement:
*r++ returned type T, semantics {T tmp= *r; ++r; return tmp; }
The new Single Pass Iterators in N1477 have no such requirement.
That's fine with me - that requirement was a source of bugs in my code and
violated the rule of least astonishment
Hi Joaquín,
JOAQUIN LOPEZ MU?Z wrote:
> Hi Fernando,
>
> - Mensaje Original -
> De: Fernando Cacciola <[EMAIL PROTECTED]>
> Fecha: Sábado, Julio 12, 2003 1:22 am
> Asunto: [boost] Re: Interest in multiindex_set?(again)
>
>> [snip]
>
> Now, index_n.begin() and index_n.end() let you enumera
Hi Fernando,
- Mensaje Original -
De: Fernando Cacciola <[EMAIL PROTECTED]>
Fecha: Sábado, Julio 12, 2003 1:22 am
Asunto: [boost] Re: Interest in multiindex_set?(again)
> Hi Joaquín,
>
> Unfortunately, I douldn't compile the code with BCC because it
> extensivelyuses non-type template p
On Sat, 12 Jul 2003 12:32:11 +0200, Jens Maurer wrote:
> Daniel Frey wrote:
>> cc-1234 CC: WARNING File =
>> /net/cci/maurer/boost/libs/utility/operators_test.cpp, Line = 52
>> Access control is not specified ("private" by default).
>>
>> : boost::operators >
>>
>> The question is: S
Edward Diener writes:
> Andy Sawyer wrote:
>
> > Marshall's "first" and "second" are slightly different to the HP
> > versions:
> >
> > template
> > struct first: std::unary_function< std::pair , T1>
> > ...
> >
> > vs.
> >
> > template
> > struct select1st
> > : std::unary_function
Daniel Frey wrote:
> I saw a lot of new regression runs on various platforms.
Some of those are mine (HP-UX, IRIX, Solaris).
> One obvious
> question: Should we remove the outdated runs?
First, my setup is not completely cronjob-automated, so my runs
may become outdated. Second, my runs use d
Hello,
I saw a lot of new regression runs on various platforms. One obvious
question: Should we remove the outdated runs?
Now for the real reason of this message: One compiler (the SGI MIPSpro)
complains (with a warning) about:
cc-1234 CC: WARNING File = /net/cci/maurer/boost/libs/utility/operat
> That's because void_ is for MPL internal use only; it's not a type
> you should manipulate (I think Aleksey doesn't believe me, but I'm
> about to prove it... ).
It's quite all right - my code does not use that "other" type, I just
need a type. I could have just as well used my own "class null_t
34 matches
Mail list logo
