[boost] Re: Revised streambuf library

[Jonathan David Turkanis]

"Maxim Egorushkin" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

> support iterators why don't use it? Generally speaking, there should 
be only
> two adapters (input and output) that take any STL sequence represented by
> begin/end iterators.
>

It seems to me that for output one needs at least two adapters: one for 
iterators which are at least forward iterators, whose constructor takes 
a pair of iterators, and one for simple output iterator, whose 
constructor takes a single iterator. The writing algorithm is slightly 
different in the latter case.

Of course, you could force them into one class using some compile-time 
switches, but this is exactly what my factories do.



___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Revised streambuf library

[Jonathan David Turkanis]

"Maxim Egorushkin" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> I don't get the idea of reinventing the stream classes. One can use their
> rdbuf() member function to change the buffer. Could you please elaborate
on
> that?
True, the stream classes are thin wrappers. You don't have to use them if
you don't wan't to.
> You have read/write member functions of your source/sink/filter concepts
> virtual. If one went for efficiency she would stay away from virtual
> functions. With such a design you leave a user no choice.
Source/sink/filter classes don't have to derive from the basic
implementations which use virtual functions. The adapters which call the
source/sink/filters know the fully-derived types of the source/sink/filters
and shouldn't have to use virtual function dispatch. There does seem to be a
need for one non-inlinable function at each junction, if non-trivial
filtering is taking place. I address this in the efiiciency section.
> There are too many adapters, IMHO. It obscures. Since each STL sequence
> support iterators why don't use it? Generally speaking, there should be
only
> two adapters (input and output) that take any STL sequence represented by
> begin/end iterators.
The factory functions address this. You just call new_source or new_sink
with whatever object you want to make into a source/sink. This is less
verbose than using, e.g., streambuf iterators. Also, in the case of strings,
the factories return adapters which are better than generic container
adapters; with SFINAE you should be able to pass a string literal to
new_source.
Examples:

new_source(v);  // simpler than using
  // iterator_source< vector::iterator
>(v.begin(), v.end())
new_sink(sb);   // simpler than using
  // iterator_source< ostreambu_iterator >
  // ( ostreambuf_iterator(sb),
streambuf_iterator() );
new_source("hello");  // simpler than string h("hello");
// iterator_source(h.begin(), h.end()).
...
> P.S. There is a very good article by Alexandre Duret-Lutz and Thierry
Geraud
> "
> Improving Object-Oriented Generic Programming".
I'll look at it. Thanks.

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: More compile problems

[David Abrahams]

Matthias Troyer <[EMAIL PROTECTED]> writes:

> On Monday, July 14, 2003, at 11:04 PM, David Abrahams wrote:
>
>> Matthias Troyer <[EMAIL PROTECTED]> writes:
>>
>>> I now get the following compile-time error on MacOS X using g++
>>> v. 3.1:
>>>
>>> /Users/troyer/src/boost/boost/iterator/iterator_adaptor.hpp:282:
>>> sizeof'
>>> applied to incomplete type
>>> boost::STATIC_ASSERTION_FAILURE'
>>>
>>> Can anybody help?
>>
>> What were you compiling?  Reproducible case, please!
>
> Sorry, Here is an example that shows the problem in a simple case:
>
> #include 
> #include 
>
> int main()
> {
>boost::adjacency_list  boost::no_property, boost::no_property, boost::no_property,
>  boost::vecS> g;
>std::cout << boost::source(*(boost::edges(g).first+4),g) << std::endl;
>return 0;
> }
>
> The problem is adding an integer to an edge iterator of this graph. Is
> this a problem of the iterator adaptor library or of the BGL?

It's a BGL problem, specifically in the way it used to label its
iterators and the way I translated them.  These iterators were always
given the "multi_pass_input_iterator" tag, because they didn't
dereference lvalues yet copies could be guaranteed to traverse the
same elements.  The old iterator adaptors were more permissive in
allowing you to take advantage of operations which weren't accounted
for by the iterator category, when defined (because we didn't have a
good way of expressing the iterator's real category anyway), and I
guess the BGL took advantage of that.  I believe that the BGL's
iterators should really have a traversal category equal to that of
the iterators they're adapting.  It's sort-of too bad we don't have a
way to express that.

Hmm, we could say that when you pass a tag which is just a traversal
category tag or just an access category tag as iterator_adaptor's
Category parameter, it takes the other part of the category from the
Base iterator.

Thoughts?

Who's going to fix up the graph library?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: More compile problems

[Matthias Troyer]

On Monday, July 14, 2003, at 11:04 PM, David Abrahams wrote:

Matthias Troyer <[EMAIL PROTECTED]> writes:

I now get the following compile-time error on MacOS X using g++ v. 
3.1:

/Users/troyer/src/boost/boost/iterator/iterator_adaptor.hpp:282:
sizeof'
applied to incomplete type 
`boost::STATIC_ASSERTION_FAILURE'

Can anybody help?
What were you compiling?  Reproducible case, please!
Sorry, Here is an example that shows the problem in a simple case:

#include 
#include 
int main()
{
  boost::adjacency_list
boost::no_property, boost::no_property, boost::no_property, 
boost::vecS> g;
  std::cout << boost::source(*(boost::edges(g).first+4),g) << std::endl;
  return 0;
}

The problem is adding an integer to an edge iterator of this graph. Is 
this a problem of the iterator adaptor library or of the BGL?

Matthias

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: multi_array and new iterator adaptors fix

[Matthias Troyer]

On Monday, July 14, 2003, at 11:04 PM, David Abrahams wrote:

Matthias Troyer <[EMAIL PROTECTED]> writes:

I do not have documentation of the new version of the iterator
adaptors (either my CVS checkout is messed up or maybe it is not in
the CVS yet)
http://tinyurl.com/gv90
http://tinyurl.com/gv91
I am not sure whether this is the correct fix.
Looks good, but please always post patches as attachments.  This one
failed to be correctly applied on my machine.
I'll remember that.


Can somebody familiar with the iterator adaptor library check the
patch and apply it if it is correct?
Done.
Thanks,

Matthias

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] rw_lock / next thread version

[Howard Hinnant]

On Sunday, July 13, 2003, at 07:04  PM, Howard Hinnant wrote:

class rw_mutex
{
public:
typedef detail::read_lock  read_lock;
typedef detail::write_lock write_lock;
 ...
};
I'm not picky about the names read_lock and write_lock.  Then these 
locks could have the "standard" scoped_lock interface.  So the "A" 
example above would look more like:

class A
{
public:
...
void read() const
{
boost::rw_mutex::read_lock lock(mut_);
...
}
void write()
{
boost::rw_mutex::write_lock lock(mut_);
...
}
...
private:
...
mutable boost::rw_mutex mut_;
};
I've been thinking about this a little more...

A (try_)scoped_lock of multiple (say 2) try_scoped_lock's would be very 
handy.  Something like:

template 
class lock2
{
public:
lock2(TryLock1& m1, TryLock2& m2, bool lock_it = true);
~lock2();

void lock();
bool try_lock();
void unlock();
bool locked() const;
operator int bool_type::* () const;
private:
lock2(const lock2&);
lock2& operator=(const lock2&);
};
(I'm not happy with the name lock2)

TryLock1&2 are models of scoped_try_lock, not try_mutex.  lock2 will 
"atomically" lock m1 and m2 without deadlocking (perhaps using the try 
and back off algorithm).

Given lock2, and if the read/write_lock's model a try_lock, then the 
example "A" above can be expanded to include A's operator=:

A&
A::operator=(const A& a)
{
typedef rw_mutex::write_lock write_lock;
typedef rw_mutex::read_lock read_lock;
typedef lock2 rw_lock;
if (this != &a)
{
write_lock w(mut_, false);
read_lock r(a.mut_, false);
rw_lock lock(w, r);
// Now you can safely do assign ...
}
return *this;
}
Comments?

-Howard

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Re: mpl/loki

[Maxim Egorushkin]

"Aleksey Gurtovoy" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]

> IMO we should just stop using 'void_' for internal purposes and give it
> up to users :).

I think it would be also very nice to 'give up' the mpl::aux::type_wrapper
class. It's quite a useful class and I wonder why it is not public.



___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Revised streambuf library

[Maxim Egorushkin]

"Jonathan D. Turkanis" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]

> I have posted a new version of my library, which has been rewritten to
> incorporate filtering as a basic construct.
> (http://groups.yahoo.com/group/boost/files/streambuf_lib.zip)
>
> In addition to allowing the easy creation of streams and streambuf from
> objects with socket-like interfaces, it provides a convenient interface
for
> defining i/o filters and for combining them in various ways with each
other
> and with types from the standard library (streams, streambufs, containers,
> sequences, codecvts.)

I don't get the idea of reinventing the stream classes. One can use their
rdbuf() member function to change the buffer. Could you please elaborate on
that?

You have read/write member functions of your source/sink/filter concepts
virtual. If one went for efficiency she would stay away from virtual
functions. With such a design you leave a user no choice.

There are too many adapters, IMHO. It obscures. Since each STL sequence
support iterators why don't use it? Generally speaking, there should be only
two adapters (input and output) that take any STL sequence represented by
begin/end iterators.

P.S. There is a very good article by Alexandre Duret-Lutz and Thierry Geraud
"
Improving Object-Oriented Generic Programming". I took some damn good ideas
from there when I was implementing my buffer adapters. You can get it here:
http://www.rsdn.ru/File/5711/duret_lutz.zip






___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Interest in multiindex_set?(again)

[Joaquín Mª López Muñoz]

Daryle Walker ha escrito:

> 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_set deleted]
> >
> > OK, I'm glad we finally got to understand each other :) There's a
> > problem with the name of the class. Others have expressed dislike for
> > "multtindex_set". Alternative candidates are "indexed_set" and
> > "indexed_table". I haven't decided yet for one, plus there's the
> > problem of which namespace should this live in (regardless of whether
> > it is promoted to namespace boost later). The alternatives so far are
> > (name of the class/associated namespace)
> >
> > * multiindex_set/boost::multiindex
> > * indexed_set/??
> > * indexed_table/??
> > * ??/boost::container (proposed by Daryle)
> >
> > boost::container I don't like because some of the associated small
> > utility classes and functions (less_by, get, project) shouldn't really
> > belong into a general-purpose namespace like container which is
> > supposed to hold other contributions. Also, there's the additional
> > problem that the class and the namespace shouldn't be named the same
> > (it makes some compilers choke, this has been discussed in connection
> > with Boost.Tuple). Suggestions in this area are most welcome.
> [TRUNCATE]
>
> If the small utility classes are sufficiently independent from your
> main classes, then put them in separate (possibly unrelated)
> namespaces.  I don't we've ever reviewed a multi-domain package,
> though.  Or we can review the utility parts separately, first.
>
> Daryle

Well, to sum it up, these are the public names of the library:

0 multiindex_set (haven't decided on the final name, still doubting
between indexed_set and indexed_table).
1 swap, equality and comparison operators
2 index_type
3 get (function to retrieve refs to an index of a given multiindex_set)
4 iterator_type
5 const_iterator_type
6 project (function to convert between different indices's iterators)
7 index_list (a type list for specifying the indices composing a multiindex_set)
8 unique and non_unique (index traits classes that go into the index_list)

get() and project() are sufficiently well specified that they won't clash with
similar overloads belonging to namespace boost. But the rest of names,
which are classes instead of functions, are problematic: their names are too
general to be safely put into namespace boost without risk of collision.
So I guess some namespace have to be set up for them.
Besides, there's the problem of the yet to be written member<> utility (that
you're already familiar with). This clearly is a very general utility that has no
particular ties to multiindex_set, so I don't know where it should go.

So the two problems are:

* Where to put 2,4,5,7, and 8? For known reasons, boost::multiindex_set
is not a good candidate (problems with having a class and a namespace named
the same).
* Where to put member<>?

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

>
>
> ___
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Signals and multi_array? [was: Problem compiling boost.filesystem]

[David Abrahams]

Douglas Paul Gregor <[EMAIL PROTECTED]> writes:

>> Doesn't look like there has been any activity on signals and multi_array.
>> Are the developers aware of the need for action?
>
> I'll try to work on Signals tonight.

Hint: turn the body of your policies class into the body of your
iterator.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: plans for a bugfix release ?

[David Abrahams]

The following message is a courtesy copy of an article
that has been posted to gmane.comp.python.c++ as well.

Dominique Devriese <[EMAIL PROTECTED]> writes:

> Hi,
>
> I'm the main developer of Kig [1].  I have just committed the code for
> python scripting to the CVS repository

Using Boost.Python?  Cool!

> but I'm receiving bug reports from people not able to compile the
> new code because of the small typename problem that was fixed in
> Boost.Python some time ago [2] ( the fix is in CVS, right ? ).  

Yes.

> Are there any plans to release a fixed version of Boost.Python any
> time soon

No specific plans, no.

> and what is the policy on Boost.Python releases in general ?

In general, they are released when all of Boost is ready.  I think it
would be a *really* good idea for Boost to do at least one minor
version release shortly after any major version release.  Now that we
have a reasonable testing strategy it should be relatively easy.
Boost 1.30.0 went out with several bugs IIRC.

> thanks
> domi
>
> Footnotes: 
> [1]  http://edu.kde.org/kig
>
> [2]  http://mail.python.org/pipermail/c++-sig/2003-May/003889.html and
>  http://mail.python.org/pipermail/c++-sig/2003-May/003896.html

Until we get our act together, I would suggest you supply people with
a Boost patch.  Use "BOOST_DEDUCED_TYPENAME" instead of "typename" so
you don't break VC6.  Sorry,

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Problem compiling boost.filesystem library

[Beman Dawes]

At 09:17 AM 7/14/2003, David Abrahams wrote:

>> como-win32:
>>
>> "C:\boost\site\boost/iterator/iterator_facade.hpp", line 285: error
>> #864: iterator_facade is not a template
>> BOOST_ITERATOR_FACADE_RELATION(==)
>>
>> msvc:
>>
>> C:\boost\site\boost/iterator/iterator_facade.hpp(365) : error C2899:
>> typename cannot be used outside a template declaration
>
>Please try again.  The msvc bug has been worked-around.  I believe I
>got the right fix for como, but since Greg only gives working
>compilers to you  I can't tell for sure.
OK, all filesystem tests on all Win32 compilers now passing. Thanks!

--Beman

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Signals and multi_array? [was: Problem compiling boost.filesystem]

[Douglas Paul Gregor]

On Mon, 14 Jul 2003, Beman Dawes wrote:

> At 09:50 PM 7/13/2003, David Abrahams wrote:
>
>  >Matthias Troyer <[EMAIL PROTECTED]> writes:
>  >
>  >> ... I hope that multi_array will also be fixed soon
>
>  >Somebody has to make that fix, whatever it is.  multi_array used to
>  >use its own private version of iterator_adaptors.
>
> Doesn't look like there has been any activity on signals and multi_array.
> Are the developers aware of the need for action?

I'll try to work on Signals tonight.

Doug
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: About member extraction

[David Abrahams]

Joaquín Mª López Muñoz <[EMAIL PROTECTED]> writes:

> The really hard part is how to obtain "int A::*" from "&A::x". I don't
> think this is possible, but then again people here sometimes do magic :)

No, it's not possible to do at compile time.  I've long had this
complaint that we can't simply deduce int A::* in contexts like this
one.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: About member extraction

[David Abrahams]

Joaquín Mª López Muñoz <[EMAIL PROTECTED]> writes:

> The really hard part is how to obtain "int A::*" from "&A::x". I don't
> think this is possible, but then again people here sometimes do magic :)

No, it's not possible to do at compile time.  I've long had this
complaint that we can't simply deduce int A::* in contexts like this
one.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] About member extraction

[Joaquín Mª López Muñoz]

John Torjo ha escrito:

> >
> >Subject: Re: [boost] About member extraction
> >   From: Joaquín Mª López Muñoz <[EMAIL PROTECTED]>
> >   Date: Mon, 14 Jul 2003 14:24:37 +0200
> > To: Boost mailing list <[EMAIL PROTECTED]>
> >
> >
> >
> >Daryle Walker ha escrito:
> >
> >> But doesn't the "PtrToMember" template parameter already imply the
> >> "Type" and "Class" parameters?  So specifying all three would be
> >> redundant.  Could we reduce it by:
> >>
> >> //
> >> template < typename PtrToMember >
> >> struct member_extractor
> >> {
> >>// Don't know if this is a real type-traits class
> >>BOOST_STATIC_ASSERT(is_pointer_data_member::value);
> >>
> >>// The extractor traits classes aren't real (yet, maybe)
> >>typedef get_class_type  argument_type;
> >>typedef get_member_type   return_type;
> >>
> >>return_type const &  operator ()( argument_type const &c ) const
> >>  { return c.*PtrToMember; }
> >>
> >>return_type &  operator ()( argument_type &c ) const
> >>  { return c.*PtrToMember; }
> >> };
> >
> >Of the approaches you propose, this is the one that I like best, but
> >I'm afraid it cannot be implemented: Note that PtrToMember is a
> >*type* (something like int A::*), not a pointer to member.
> >member_extractor would have to defined as
> >
> >template < typename PtrToMember, PtrToMember ptr >
> >struct member_extractor
> >
> >and used as
> >
> >member_extractor; // x is an int member of A
>
> Actually, I think it's worse (I don't have a C++ compiler with me right now:-( )
>
> Something in the lines of:
>
> template < typename type, typename result, result type::* ptr >
> struct member_extractor
>
>

Actually, extracting "A" and "int" from "int A::*" is easy:

#include 
#include 

using namespace std;

struct A
{
  int x;
};

template 
struct ptr_to_member_descriptor;

template 
struct ptr_to_member_descriptor
{
  typedef Class  class_type;
  typedef Member member_type;
};

int main()
{
  BOOST_STATIC_ASSERT((
boost::is_same<
  ptr_to_member_descriptor::class_type,
  A>::value));

  BOOST_STATIC_ASSERT((
boost::is_same<
  ptr_to_member_descriptor::member_type,
  int>::value));

  return 0;
}


The really hard part is how to obtain "int A::*" from "&A::x". I don't
think this is possible, but then again people here sometimes do magic :)

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] Problems with CVS?

[Marshall Clow]

Beman wrote:

What I'm now seeing in the US (Virginia) is SSH continuing to be 
very fast when it is working, but with several time periods a day 
when I get:

cvs update: warning: unrecognized response `FATAL ERROR: Network 
error: Connection timed out' from cvs server
cvs [update aborted]: end of file from server (consult above messages if any)
That's been what I've been seeing every time for the last 4 days.
--
-- Marshall
Marshall Clow Idio Software   
Hey! Who messed with my anti-paranoia shot?
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Problems with CVS?

[David Abrahams]

"Toon Knapen" <[EMAIL PROTECTED]> writes:

>> If you are accessing CVS via SSH (developer), you should not have any 
>> problem. In fact CVS access has been very fast and reliable 
>> lately for me 
>> doing SSH access.
>
> Not for me.
> :ext: access using SSH is certainly less unreliable but it's not
> reliable at all. But this might be different in europe and the US (I
> understood from the SourceForge guys that they have mirrored servers in
> europe)

I'm wondering again whether we should take up the offer to have our
CVS hosted elsewhere.  We have unreliable access for both developers
and users at the moment. If we want to keep a repository in synch at
sourceforge that should be fairly easy to automate.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] Problems with CVS?

[Beman Dawes]

At 11:40 AM 7/14/2003, Toon Knapen wrote:
>> If you are accessing CVS via SSH (developer), you should not have any
>> problem. In fact CVS access has been very fast and reliable
>> lately for me
>> doing SSH access.
>
>Not for me.
>:ext: access using SSH is certainly less unreliable but it's not
>reliable at all. But this might be different in europe and the US (I
>understood from the SourceForge guys that they have mirrored servers in
>europe)
What I'm now seeing in the US (Virginia) is SSH continuing to be very fast 
when it is working, but with several time periods a day when I get:

cvs update: warning: unrecognized response `FATAL ERROR: Network error: 
Connection timed out' from cvs server
cvs [update aborted]: end of file from server (consult above messages if 
any)

--Beman

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Problem compiling boost.filesystem library

[Beman Dawes]

At 10:06 AM 7/14/2003, David Abrahams wrote:

>David Abrahams <[EMAIL PROTECTED]> writes:
>
>> Please try again.  The msvc bug has been worked-around.  I believe I
>> got the right fix for como, but since Greg only gives working
>> compilers to you  I can't tell for sure.
>
>Oh, feathers.  My checkin never happened because SF CVS is broken :(
Hum... CVS problems are starting to get worrisome:-(

--Beman

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Problem compiling boost.filesystem library

[Beman Dawes]

At 09:17 AM 7/14/2003, David Abrahams wrote:

>> como-win32:
>>
>> "C:\boost\site\boost/iterator/iterator_facade.hpp", line 285: error
>> #864: iterator_facade is not a template
>> BOOST_ITERATOR_FACADE_RELATION(==)
>>
>> msvc:
>>
>> C:\boost\site\boost/iterator/iterator_facade.hpp(365) : error C2899:
>> typename cannot be used outside a template declaration
>
>Please try again.  The msvc bug has been worked-around.  I believe I
>got the right fix for como ...
Thanks. I'm getting CVS timeout errors right now, so can't test yet.

> but since Greg only gives working
>compilers to you  I can't tell for sure.
Ha, ha! I just spent the last hour installing the latest como beta, and 
then having to back it out because it produced libcomo build errors. The 
recycle bin comes in handy!

--Beman

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] Problems with CVS?

[Toon Knapen]

> If you are accessing CVS via SSH (developer), you should not have any 
> problem. In fact CVS access has been very fast and reliable 
> lately for me 
> doing SSH access.

Not for me.
:ext: access using SSH is certainly less unreliable but it's not
reliable at all. But this might be different in europe and the US (I
understood from the SourceForge guys that they have mirrored servers in
europe)

toon


___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Formal Review: fixed-point decimal library

[Fernando Cacciola]

Hi, this is my review of the Fixed-Point Decimal Library.

I cannot vote as it is now.
I will vote subject to the resolution of the 'scale' issue I explain below:

Problems with 'scale':
==

To understand it, I wrote the following function which just creates two
decimals given a source integer and two scales:

void Show( int s, int scn, int scm)
{
  decimal n(scn, s);
  decimal m(scm, s);

  cout << "s=" << s << endl
   << decscale
   << "[" << scn << ",s]=" << n << endl
   << "[" << scm << ",s]=" << m << endl
   << endl ;
}

When called with:

  Show(numeric_limits::max(),9,10);
  Show(9,17,18);
  Show(10,17,18);
  Show(0,17,18);

the output (in a system were int_type is __int64) is:

s=2147483647
[9,s]=2147483647.0
[10,s]=302809239.6290448384

s=9
[17,s]=9.0
[18,s]=9.00

s=10
[17,s]=10.0
[18,s]=-8.446744073709551616

s=0
[17,s]=0.0
[18,s]=0.00

Furhetmore, the following:

  decimal eps =  numeric_limits::epsilon() ;
  decimal a = eps + 9 ;
  decimal b = eps + 10 ;
  cout << decscale
   << numeric_limits::digits10
   << eps
   << a << endl
   << b << endl ;

outputs:

18
0.01
9.01
-8.446744073709551615

These results seems to clearly show that 'scale' is actually the maximum
number of decimal digits allowed IIF only one digit is used for the whole
part.
If the whole part uses more than one digit, say N, the decimal part won't be
able to represent 'scale' digits, it will only represent 'scale+1-N' digits,
as shown by the following:

max with scale=0 : 9223372036854775807
max with scale=1 : 922337203685477580.7
max with scale=2 : 92233720368547758.07
max with scale=3 : 9223372036854775.807
max with scale=4 : 922337203685477.5807
max with scale=5 : 92233720368547.75807
max with scale=6 : 9223372036854.775807
max with scale=7 : 922337203685.4775807
max with scale=8 : 92233720368.54775807
max with scale=9 : 9223372036.854775807
max with scale=10 : 922337203.6854775807
max with scale=11 : 92233720.36854775807
max with scale=12 : 9223372.036854775807
max with scale=13 : 922337.2036854775807
max with scale=14 : 92233.72036854775807
max with scale=15 : 9223.372036854775807
max with scale=16 : 922.3372036854775807
max with scale=17 : 92.23372036854775807
max with scale=18 : 9.223372036854775807

Notice that the total number of represtanble digits is scale+1.
Therefore, I really dislike the term 'scale' and its explanation.
IMO, it should be called: 'digits', and it should be defaulted to 1 +
[int_type].digits10
(i.e 19),
Additionally, numeric_limits::digits and digits10 should be
max_scale+1,
not max_scale.


Here is a list of other minor issues:
=

I don't think that is_bounded and is_modulo should be inherited from
int_type.

is_bounded is intended to be false only for those types which can represent
numbers in any range. Even if int_type were unbounded (is_bounded=false),
decimal itself will always be bounded, so it should fix is_bounded to true.

Similarly, is_modulo tells whether the numeric type uses modulo arithmetic,
as do the unsigned integral types, yet decimal does not do that even if
int_type where unsigned, so this should be fixed to 'false'.

***

Currently, the library cannot be put in a precompiled header using BCC
because of the 'max_val,min_val' constants. This can be solved by making
those constants inlined functions.
I can send you a patch if you like.



The documentation is clearly written with some 'old' version in mind. I
think all references and comparisons with that older version should be
removed from the docs, or at least, put aside on a 'history' section.

*

IMO the documentation should begin with a brief (but complete) overview of
what is a 'fixed decimal' number, including the concept of a 'scale' (or
'digits' as I much prefer), and of rounding modes.

**

I understand why it is not supported to construct a decimal from an
int_type, but I think that construction from 'unsigned int' should be
supported since, AFAICT, the promotion rules won't give ambiguity if that
additional ctor is added.



The docs say:

"The conversion will be exact if the string contains no more than scale
digits to the right of the decimal point; otherwise the value will be
rounded as specified"

This is incorrect, I think. If the string contains more than (scale+1)
digits, whether to the left or right of the decimal point (or both),
rounding will ocurr.

**

Best,

Fernando Cacciola




___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] CVS login vs Anonymous

[Ben Woodhead]

Hello Everybody

I would just like to tell everybody that Sourceforge has switched to using
backup servers for the anonymous logins, so they are 24 hours behind.

Ben

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Problems with CVS?

[David Abrahams]

Beman Dawes <[EMAIL PROTECTED]> writes:

>  >Beman -
>  >I've read the SF docs, generated some keys, and attempted to
>  >connect to SF using SSH -- all I've got is a bunch of timeouts.

That may be because their ssh has been intermittently broken, as it
is right now:

[EMAIL PROTECTED] /cygdrive/c/src/dcforum
$ ssh -v cvs.sourceforge.net
OpenSSH_3.6.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090702f
debug1: Reading configuration data /home/dave/.ssh/config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: Connecting to cvs.sourceforge.net [66.35.250.207] port 22.
debug1: Connection established.
debug1: identity file /home/dave/.ssh/identity type 0
debug1: identity file /home/dave/.ssh/id_rsa type 1
debug1: identity file /home/dave/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.1p1
debug1: match: OpenSSH_3.1p1 pat OpenSSH_2.*,OpenSSH_3.0*,OpenSSH_3.1*
debug1: Local version string SSH-1.5-OpenSSH_3.6.1p1
debug1: Waiting for server public key.
debug1: Received server public key (768 bits) and host key (1024 bits).
debug1: Host 'cvs.sourceforge.net' is known and matches the RSA1 host key.
debug1: Found key in /home/dave/.ssh/known_hosts:33
debug1: Encryption type: 3des
debug1: Sent encrypted session key.
debug1: Installing crc compensation attack detector.
debug1: Received encrypted confirmation.
debug1: Trying RSA authentication with key '/home/dave/.ssh/identity'

^C (hung)

[EMAIL PROTECTED] /cygdrive/c/src/dcforum
$ ssh -v cvs.sourceforge.net
OpenSSH_3.6.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090702f
debug1: Reading configuration data /home/dave/.ssh/config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: Connecting to cvs.sourceforge.net [66.35.250.207] port 22.
debug1: Connection established.
debug1: identity file /home/dave/.ssh/identity type 0
debug1: identity file /home/dave/.ssh/id_rsa type 1
debug1: identity file /home/dave/.ssh/id_dsa type 2
ssh_exchange_identification: Connection closed by remote host
debug1: Calling cleanup 0x41b2a0(0x0)

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Problem compiling boost.filesystem library

[David Abrahams]

David Abrahams <[EMAIL PROTECTED]> writes:

> Please try again.  The msvc bug has been worked-around.  I believe I
> got the right fix for como, but since Greg only gives working
> compilers to you  I can't tell for sure.

Oh, feathers.  My checkin never happened because SF CVS is broken :(
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Signals and multi_array? [was: Problem compilingboost.filesystem]

[David Abrahams]

Beman Dawes <[EMAIL PROTECTED]> writes:

> At 09:50 PM 7/13/2003, David Abrahams wrote:
>
>  >Matthias Troyer <[EMAIL PROTECTED]> writes:
>  >
>  >> ... I hope that multi_array will also be fixed soon
>
>  >Somebody has to make that fix, whatever it is.  multi_array used to
>  >use its own private version of iterator_adaptors.
>
> Doesn't look like there has been any activity on signals and
> multi_array. Are the developers aware of the need for action?

multi_array is fixed.

Doug, let me know if you need help with signals.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Revised streambuf library

[Jonathan D. Turkanis]

A little over a month ago, I posted a library for creating streambufs from
objects with socket-like interfaces. In response, several people requested
filtering capabilities, and others have since posted filtering streambuf
code (Larry Evans, Daryle Walker, Paul Bristow) and related material (Maxim
Egoruskin.)

I have posted a new version of my library, which has been rewritten to
incorporate filtering as a basic construct.
(http://groups.yahoo.com/group/boost/files/streambuf_lib.zip)

In addition to allowing the easy creation of streams and streambuf from
objects with socket-like interfaces, it provides a convenient interface for
defining i/o filters and for combining them in various ways with each other
and with types from the standard library (streams, streambufs, containers,
sequences, codecvts.)

The library is now implemented as a collection of pluggable components.



___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Problems with CVS?

[Beman Dawes]

At 01:27 PM 7/13/2003, Marshall Clow wrote:
>>At 11:49 AM 7/9/2003, Marshall Clow wrote:
>>
>>>At 7:09 PM -0700 7/6/03, Marshall Clow wrote:
The last 3 or 4 times that I have tried to check out the "latest
>>  >>boost", the checkout gets most of the way through, and then hangs.
>>  >
>>>Is anyone else seeing this, or am I the only one?
>>
>>If you are accessing CVS via SSH (developer), you should not have
>>any problem. In fact CVS access has been very fast and reliable
>>lately for me doing SSH access.
>
>Beman -
>I've read the SF docs, generated some keys, and attempted to
>connect to SF using SSH -- all I've got is a bunch of timeouts.
>
>I would sure appreciate it if you would send me a couple of CVS commands
>that you use to do this.
I use:

   cvs -z9 update -P -d

My CVS_RSH environmental variable is set to the path of the ssh program I 
use. It takes care of all the security stuff; from my perspective it is 
just magic that works without any action on my part.

I just glanced at the S/F Mac OS documentation, and it doesn't seem to give 
a test procedure. The Windows docs have a "Testing automatic 
authentication" section. The idea being to verify the ssh setup using the 
facilities of the ssh client program before actually trying to execute any 
cvs commands. That would seem to be a sensible approach. Some ssh clients 
have "verbose" modes that help greatly in debugging authentication issues.

HTH,

--Beman

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: functors for taking apart std::pair?

[Beman Dawes]

At 06:15 PM 7/12/2003, Aleksey Gurtovoy wrote:

>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 (for the reason
>> you mention above), it can be used with the analogous algorithms in
>> FC++, since the FC++ infrastructure enables return-type-deduction for
>> template function objects.
>
>So do Boost.Lambda and Phoenix infrustructures, and unification of these
>is proposed for the TR1 -
>
>http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1454.html
A slight clarification:

N1454 isn't just "proposed"; it has been accepted by full committee vote:-)

It is possible for the full committee to reverse itself, and remove 
something that has previously been accepted. But that's fairly unusual, so 
you can expect N1454 to be in the TR.

--Beman

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Problem compiling boost.filesystem library

[David Abrahams]

Beman Dawes <[EMAIL PROTECTED]> writes:

> At 06:02 PM 7/13/2003, Matthias Troyer wrote:
>
>  >it now works again ...
>
> It broke again for Win32 due to a Sun fix from Jens that inadvertently
> broke Win32 compiles. That is now fixed.
>
> Also Dave fixed an iterator_facade glitch, so filesystem is working
> for more compilers.
>
> On Win32, there still seem to be iterator_facade issues for como-win32
> and VC++ 6.0 See below.
>
> --Beman
>
> como-win32:
>
> "C:\boost\site\boost/iterator/iterator_facade.hpp", line 285: error
> #864: iterator_facade is not a template
> BOOST_ITERATOR_FACADE_RELATION(==)
>
> msvc:
>
> C:\boost\site\boost/iterator/iterator_facade.hpp(365) : error C2899:
> typename cannot be used outside a template declaration

Please try again.  The msvc bug has been worked-around.  I believe I
got the right fix for como, but since Greg only gives working
compilers to you  I can't tell for sure.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] About member extraction

[John Torjo]

>
>Subject: Re: [boost] About member extraction
>   From: Joaquín Mª López Muñoz <[EMAIL PROTECTED]>
>   Date: Mon, 14 Jul 2003 14:24:37 +0200
> To: Boost mailing list <[EMAIL PROTECTED]>
>
>
>
>Daryle Walker ha escrito:
>
>> But doesn't the "PtrToMember" template parameter already imply the
>> "Type" and "Class" parameters?  So specifying all three would be
>> redundant.  Could we reduce it by:
>>
>> //
>> template < typename PtrToMember >
>> struct member_extractor
>> {
>>// Don't know if this is a real type-traits class
>>BOOST_STATIC_ASSERT(is_pointer_data_member::value);
>>
>>// The extractor traits classes aren't real (yet, maybe)
>>typedef get_class_type  argument_type;
>>typedef get_member_type   return_type;
>>
>>return_type const &  operator ()( argument_type const &c ) const
>>  { return c.*PtrToMember; }
>>
>>return_type &  operator ()( argument_type &c ) const
>>  { return c.*PtrToMember; }
>> };
>
>Of the approaches you propose, this is the one that I like best, but
>I'm afraid it cannot be implemented: Note that PtrToMember is a
>*type* (something like int A::*), not a pointer to member.
>member_extractor would have to defined as
>
>template < typename PtrToMember, PtrToMember ptr >
>struct member_extractor
>
>and used as
>
>member_extractor; // x is an int member of A

Actually, I think it's worse (I don't have a C++ compiler with me right now:-( )

Something in the lines of:

template < typename type, typename result, result type::* ptr >
struct member_extractor


>
>which takes us again to the redundancy we were trying to avoid.
>Something in the way of eliminating this redundancy, however, would be
>a boon. Maybe some metaprogramming gurus here can think of
>something.
>

I would really love to see a solution to this ;-)

Best,
John


>Joaquín M López Muñoz
>Telefónica, Investigación y Desarrollo
>
>___
>Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Problem compiling boost.filesystem library

[Thomas Witt]

Beman Dawes wrote:


msvc:

C:\boost\site\boost/iterator/iterator_facade.hpp(365) : error C2899: 
typename cannot be used outside a template declaration
Fixed.

--
Dipl.-Ing. Thomas Witt
Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet 
Hannover
voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001
http://www.ive.uni-hannover.de

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: More compile problems

[David Abrahams]

Matthias Troyer <[EMAIL PROTECTED]> writes:

> I now get the following compile-time error on MacOS X using g++ v. 3.1:
>
> /Users/troyer/src/boost/boost/iterator/iterator_adaptor.hpp:282:
> sizeof'
> applied to incomplete type `boost::STATIC_ASSERTION_FAILURE'
>
> Can anybody help?

What were you compiling?  Reproducible case, please!

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: multi_array and new iterator adaptors fix

[David Abrahams]

Matthias Troyer <[EMAIL PROTECTED]> writes:

> I do not have documentation of the new version of the iterator
> adaptors (either my CVS checkout is messed up or maybe it is not in
> the CVS yet)

http://tinyurl.com/gv90
http://tinyurl.com/gv91

> I am not sure whether this is the correct fix. 

Looks good, but please always post patches as attachments.  This one
failed to be correctly applied on my machine.

> Can somebody familiar with the iterator adaptor library check the
> patch and apply it if it is correct?

Done.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: rw_lock / next thread version

[Alexander Terekhov]

Howard Hinnant wrote:
[...]
> class rw_mutex
> {
> public:
> typedef detail::read_lock  read_lock;
> typedef detail::write_lock write_lock;
>   ...
> };
[...]
> This looks slightly more readable and writable to me.  And will avoid
> unlock() having to check what kind of lock (read or write) it is trying
> to unlock.

Yup. 

http://google.com/groups?threadm=3ef71197%40usenet01.boi.hp.com
(Subject: Re: newbie question)



 > And, you know, the fact POSIX threading API doesn't have rdunlock()
 > and wrunlock() operations [separate calls] makes me kinda wonder WHY
 > "someone" was definitely NOT thinking in the direction of reducing
 > the amount of reordering constraints imposed on the implementation
 > [i.e. compiler, in the first place; things like IPA aside] to the
 > absolute minimum that's actually needed when the current threading
 > API was created/voted. You keep telling me about the mutex... think
 > of a read-write lock for a second, please.

 Believe me, I've thought about it for a lot more than a second.

 As for the combined unlock function, all I can say is that I always thought 
 that was a bad idea too. Not just for potential efficiency, but also 
 because it restricts error checking. That is, if someone accidentally calls 
 pthread_rwlock_wrunlock() twice, you can cause it to fail. But readers 
 generally aren't identified, merely counted, so if a writer calls 
 pthread_rwlock_unlock() twice, and on the second call there's one or more 
 readers, the call can do nothing but "successfully" unlock for read. The 
 alternative would be to keep a list of all active readers; but that gets 
 messy quickly when you have to account for a thread possibly holding 
 multiple read locks at the same time.
 
 You can take this as evidence that POSIX doesn't always listen to me. ;-)



regards,
alexander.

P.S. Butenhof is, of course totally wrong in the rest of that article. ;-)

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Review request: enable_if

[David Abrahams]

Markus Werle <[EMAIL PROTECTED]> writes:

> So please keep disable_if.

Oh sure; I wasn't suggesting trashing it.  I just forget about it
sometimes because I've not had it at my disposal so far.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Problem compiling boost.filesystem library

[Beman Dawes]

At 06:02 PM 7/13/2003, Matthias Troyer wrote:

>it now works again ...

It broke again for Win32 due to a Sun fix from Jens that inadvertently 
broke Win32 compiles. That is now fixed.

Also Dave fixed an iterator_facade glitch, so filesystem is working for 
more compilers.

On Win32, there still seem to be iterator_facade issues for como-win32 and 
VC++ 6.0 See below.

--Beman

como-win32:

"C:\boost\site\boost/iterator/iterator_facade.hpp", line 285: error #864: 
iterator_facade is not a template BOOST_ITERATOR_FACADE_RELATION(==)

msvc:

C:\boost\site\boost/iterator/iterator_facade.hpp(365) : error C2899: 
typename cannot be used outside a template declaration 

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Signals and multi_array? [was: Problem compiling boost.filesystem]

[Beman Dawes]

At 09:50 PM 7/13/2003, David Abrahams wrote:

>Matthias Troyer <[EMAIL PROTECTED]> writes:
>
>> ... I hope that multi_array will also be fixed soon
>Somebody has to make that fix, whatever it is.  multi_array used to
>use its own private version of iterator_adaptors.
Doesn't look like there has been any activity on signals and multi_array. 
Are the developers aware of the need for action?

--Beman

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] About member extraction

[Joaquín Mª López Muñoz]

Daryle Walker ha escrito:

> But doesn't the "PtrToMember" template parameter already imply the
> "Type" and "Class" parameters?  So specifying all three would be
> redundant.  Could we reduce it by:
>
> //
> template < typename PtrToMember >
> struct member_extractor
> {
>// Don't know if this is a real type-traits class
>BOOST_STATIC_ASSERT(is_pointer_data_member::value);
>
>// The extractor traits classes aren't real (yet, maybe)
>typedef get_class_type  argument_type;
>typedef get_member_type   return_type;
>
>return_type const &  operator ()( argument_type const &c ) const
>  { return c.*PtrToMember; }
>
>return_type &  operator ()( argument_type &c ) const
>  { return c.*PtrToMember; }
> };

Of the approaches you propose, this is the one that I like best, but
I'm afraid it cannot be implemented: Note that PtrToMember is a
*type* (something like int A::*), not a pointer to member.
member_extractor would have to defined as

template < typename PtrToMember, PtrToMember ptr >
struct member_extractor

and used as

member_extractor; // x is an int member of A

which takes us again to the redundancy we were trying to avoid.
Something in the way of eliminating this redundancy, however, would be
a boon. Maybe some metaprogramming gurus here can think of
something.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: mpl/loki

[Howard Hinnant]

On Monday, July 14, 2003, at 05:18  AM, John wrote:

class nat {nat();};
How about not_a_type?

It's a little more to type, but looks much better (IMHO).

And shouldn't it be :

struct not_a_type {};
As Peter pointed out, such a class can have several uses.  In some of 
the contexts I've used it, I wanted to make sure that client code could 
not construct an instance.  Perhaps such a constraint would not be 
appropriate in all use cases.

-Howard

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] More compile problems

[Matthias Troyer]

Hi,

I now get the following compile-time error on MacOS X using g++ v. 3.1:

/Users/troyer/src/boost/boost/iterator/iterator_adaptor.hpp:282: 
`sizeof'
   applied to incomplete type `boost::STATIC_ASSERTION_FAILURE'

Can anybody help?

Matthias

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] multi_array and new iterator adaptors fix

[Matthias Troyer]

Dear Boosters,

Since the update of the iterator adaptor library broke boost 
multi_array (or at least my CVS version of it), I tried to fix it and 
came up with the patch below which makes my codes compile again. Since 
I do not have documentation of the new version of the iterator adaptors 
(either my CVS checkout is messed up or maybe it is not in the CVS 
yet), I am not sure whether this is the correct fix. Can somebody 
familiar with the iterator adaptor library check the patch and apply it 
if it is correct?

Matthias

cvs diff -u iterator.hpp
Index: iterator.hpp
===
RCS file: /cvsroot/boost/boost/boost/multi_array/iterator.hpp,v
retrieving revision 1.4
diff -u -r1.4 iterator.hpp
--- iterator.hpp30 Jan 2003 16:55:31 -  1.4
+++ iterator.hpp14 Jul 2003 08:30:31 -
@@ -21,6 +21,7 @@
 #include "boost/multi_array/base.hpp"
 #include "boost/multi_array/iterator_adaptors.hpp"
 #include "boost/iterator_adaptors.hpp"
+#include "boost/iterator/reverse_iterator.hpp"
 #include 
 #include 
@@ -150,7 +151,7 @@
   typedef typename iterator_gen_helper
 reference_type,tag,difference_type>::type it_type;
 public:
-  typedef typename boost::reverse_iterator_generator::type 
type;
+  typedef boost::reverse_iterator type;
 };

 template 
@@ -161,7 +162,7 @@
   typedef typename iterator_gen_helper
 reference_type,tag,difference_type>::type it_type;
 public:
-  typedef typename boost::reverse_iterator_generator::type 
type;
+  typedef boost::reverse_iterator type;
 };

 } // namespace multi_array

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: mpl/loki

[Daniel Frey]

Peter Dimov wrote:
David Abrahams wrote:

But that's only true as long as void_ is being used for internal
purposes.  Once you "give it up to users" as you suggest, it loses
that correspondence, and we'll have some other internal name which
has that correspondence to void.
Maybe the problems are caused by overloading void_. I haven't looked at MPL
recently, but as a general observation I have identified at least three uses
of a void_-like entity.
1. A type parameter used to emulate a variable argument template. I use
'_missing' for this purpose (leading underscore for implementation details.)
template struct F;

2. An optional parameter that, when not supplied, has a reasonable
(dependent) default. I use 'unspecified'.
template ... bind(F f);

3. A type that is guaranteed to be distinct from all other useful types.
'nil' is what Lisp calls it; void_ is fine, too.
From my experience it's a bad idea to have one general, user-documented 
type that is used as a default for variable argument templates. The 
problem is that when a user knows the type's name and thus the type (be 
it called void_, nan or whatever), he might also expect to be able to 
work with it like with any other type. If forming a container-type 
(mpl::vector, ...), it should be possible to inject the type like all 
other types because otherwise, well, it wouldn't be a type and the user 
will be surprised no matter whether you document it or not.

I therefore think that each library should have an internal type that 
the user doesn't know about and that might then be put it into a 
namespace detail or something and called depending on it's semantics. 
Makes it easier to understand the type's role inside the library, thus 
increases readability and maintainability and improved orthogonality of 
different libraries.

Also, I wonder what reasons are there to create a general type for this 
purpose. Avoiding code duplication doesn't sound reasonable as we only 
replace a single line per such class with an include. Some libraries 
might even need a declaration-only-type, other might needs an (empty) 
implementation. So, what benefit would a general type give to us?

Regards, Daniel

--
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: [EMAIL PROTECTED], web: http://www.aixigo.de
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: mpl/loki

[John]

>> 3. A type that is guaranteed to be distinct from all other useful 
>> types.
>> 'nil' is what Lisp calls it; void_ is fine, too.
>
>Another possible spelling for this animal is:
>
>class nat {nat();};
>
>Inspired from nan.  In this case means Not A Type.  It is nice and 
>short which comes in handy for when there are a lot of template 
>parameters to default.  It is easily pronounceable, and won't be 
>confused with any other type when discussed verbally.

How about not_a_type?

It's a little more to type, but looks much better (IMHO).

And shouldn't it be :

struct not_a_type {};

?

Best,
John
>
>-Howard
>
>___
>Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Review request: enable_if

[Markus Werle]

Thomas Witt wrote:

> 3. To me the disable templates don't add any value. They are just
> duplicating the amount of code without any real benefit. I know this is
> a matter of taste, it's just that I would prefer a minimal interface.

Following David's arguments towards mpl compatibility and removing
direct use of && || etc.
I'd prefer 

template 
typename disable_if, is_vector >,...>::type
operator*(const T& t, const U& u);  

and feel uncomfortable about adding another "not", just because 
_my_ code is ugly enough already


template 
typename enable_if, 
 is_vector >,...> >::type
operator*(const T& t, const U& u); 


So please keep disable_if.


Markus

-- 

Build your own Expression Template Library with Daixtrose!
Visit http://daixtrose.sourceforge.net/ 

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Review request: enable_if

[Markus Werle]

Howard Hinnant wrote:

> On Wednesday, July 9, 2003, at 04:31  PM, Jaakko Jarvi wrote:
> 
>> Yes it would be possible. Just committed in.
> 
> Thanks!
> 
>> Breaks in g++ 3.2.
>>
>> ICC 7 accepts.
>>
>> Metrowerks? Must works, you wouldn't have asked otherwise, right :)
> 
>   Yes, it works, and yes I do have ulterior motives, though
> they are probably not what it would seem.  I'm hoping this will work in
> g++ asap, and I figured this was the fastest way. :-)

Well, a bug report at http://gcc.gnu.org/bugzilla/
has a similar effect. See e.g. 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11511
which crops up with boost::mpl.

Putting gcc-killer code in boost is a nice approach
but has the disadvantage of some delay until developers
get aware of it. 

Also the side effect is that my boost-based code does not 
compile with gcc from time to time, which leaves me rather 
unproductive.

Please (!) go and file an appropriate bug report at the site I mentioned.


Markus - who hopes the new gcc parser will get stable some day :-( 


-- 

Build your own Expression Template Library with Daixtrose!
Visit http://daixtrose.sourceforge.net/ 

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost