|
Boost : |
From: David Abrahams (abrahams_at_[hidden])
Date: 2000-11-07 00:54:32
Daryle,
Thanks for taking some of my suggestions. It's still not ready, though:
"bitwise_combinable" would really be a familiar kind of English construct,
but "bitwisingly_combinable" is, I think, a bit too creative. Likewise
"bicremental".
"integrally_multiplicative" seems to indicate some relationship to the
integrals of calculus where "integer_mutliplicative" would do and be less
ambiguous.
========
You seem to have dropped this borland-specific fix:
#ifndef __BORLANDC__
friend D requires_difference_operator(const T& x, const T& y) {
return x - y;
}
#endif
Was that intentional?
=====
The table of contents and expanded contributors section in the docs is very
nice, but it has pushed the rationale section (which I never intended to
apply only to the Arithmetic Operators) too far down the page. Really, the
page should open with Rationale near the top.
IMO, the Arithmetic Operators heading should precede the heading "Simple
Arithmetic Operators", if we need it at all. The initial example should
closely follow the rationale. The Two-Argument Template Forms section should
follow that. Then we should proceed to Arithmetic Operators. Thoughts?
The hot pink of internal links is hard to read. Can we choose a slightly
more subdued color, say green?
I still can't accept "Type to Gain Operators" and "alternate type to work
with operators". They're just too ambiguous.
"Operations supplied by template" is clearer than "Operations from Template"
What does the word "Base" mean in the column heading "Requirements for
Base"?
-----
Rather than writing:
Supports the operations and needs the requirements of the following <T>
templates:
a.. less_than_comparable
b.. equality_comparable
Can we write in the column header
"supplies operations and has all requirements of"
And then in the cell, write:
less_than_comparable<T>
equality_comparable<T>
This will factor out repeated common language and make the table smaller.
---- In the sentence "They combine several of the previous simple and grouped operator templates together", the word "together" is redundant and should be stricken. ----- In the iterator helpers table you write "Based from forward_iterator_operators<T, P>.". Correct english would be "Based on forward_iterator_operators<T, P>." But even then, what does it tell us about operations and requirements (the column header) that it is based on another class? ===== In operators_test.cpp: You are avoiding the use of base class chaining for a reason, I suppose? It wouldn't hurt to be explicit about it. Wrapped2 uses boost::bidirectionally_shiftable<Wrapped2<T, U>, U > instead of boost::bidirectionally_shiftable2<Wrapped2<T, U>, U > I think this will cause compilation failures under MSVC. I asked before, but you haven't explained: why does Wrapped use operator void* while Wrapped2 uses operator bool? ----- Original Message ----- From: <boost_at_[hidden]> To: <boost_at_[hidden]> Sent: Monday, November 06, 2000 9:49 PM Subject: [boost] New file uploaded to boost > > Hello, > > This email message is a notification to let you know that > a file has been uploaded to the Files area of the boost > group. > > File : /dlw_oprs.zip > Uploaded by : darylew_at_[hidden] > Description : Extension to operators.hpp; version 10 > > You can access this file at the URL > > http://www.egroups.com/files/boost/dlw_oprs%2Ezip > > To learn more about eGroups file sharing, please visit > > http://www.egroups.com/help/files.html > > > Regards, > > darylew_at_[hidden] > > > > > > >
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk