RE: [boost] Re: New Iterator Adaptors
David Abrahams wrote: As a last resort this certainly helps. And in a year or so nobody will talk about the transitional CVS versions. But now it would be very helpful, if there was a separate BOOST_ITERATOR_ADAPTOR_VERSION pp constant, which could be used for this needs (BTW Spirit has such a constant from the early beginnings). Please don't get me wrong, I do not want to have a very fine granulated version tracking constant. My point is, that such interface breaking changes _must_ be track-able. Well, here are the problems: 1. There's no definition of this macro in the current sources 2. The new iterator adaptors don't use the same file paths, e.g. boost/iterator/iterator_adaptor.hpp vs boost/iterator_adaptors.hpp. I'm certainly open to any concrete solutions to this problem. Just tell me how to do it. Hmmm... You're removed the boost/iterator_adaptors.hpp file intentionally, right? This makes it even more problematic, because, there is no chance to circumvent compilation errors. What about re-introducing the boost/iterator_adaptors.hpp file: #define BOOST_ITERATOR_ADAPTOR_VERSION 0x2000 #include boost/iterator/iterator_adaptor.hpp This would allow for some version tracking and a smooth migration path for those libraries, willing to support both, the new _and_ the old iterator libs. Thought's? Regards Hartmut ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Math Constants Formal Review - is extensible.
Paul A. Bristow wrote: | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Daniel Frey | Sent: Tuesday, June 10, 2003 10:18 AM | To: [EMAIL PROTECTED] | Subject: [boost] Re: Math Constants Formal Review - is extensible. | | | Paul A. Bristow wrote: | Your example is interesting. I think that providing a Macro value | allows this | sort of UDT extensions code (very like Michael Kenniston's examples). | | I fail to see how this should work. Could you elaborate a bit, please? | | My thesis that 40 decimal digits are enough is because it is enough for all | existing floating point hardware, up to 128 significands. I | believe that anyone | wanting more is likely to be using a separate 'unlimited' precision package | anyway. | | That exactly is my point: People will choose such a package, but how can | it be glued by the user to boost's constants? And to the code the user | already wrote? Taking into account that boost is intended to be some | kind of pre-standard-library, I think we should allow the extension of | constants to be used with new float-types. Using the constants in a | generic way is only possible when we have a standardized way of | accessing them. This is why I concentrated on allowing explicit casting | and the direct use as in pi*(float)(...). I don't see how the user could | use Roguewave's decimal type with Macros (or any other user defined | float-like type. And I don't think that using such a library should | result in a choice for the user to either use constants from boost with | the according interface or hope for the vendor to specify the constants | and use their interface. I imagine that any package will have some decimal digits C string to UDT conversion, for example for quad_float it is to_quad_float(const char*) so ones writes NTL::quad_float my_quad_float = to_quad_float(BOOST_PI); where BOOST_PI is defined as 3.1415926535897932384626433832794 say. I see the 40 decimal digit representations as the 'lowest common denominator'. How else do you propose? | | There is also an example of a UDT _interval_ - a 128-bit quad_float | type, used | by Victor Shoup's NTL package. But it does require using the NTL generator | program to create the exactly representable values. (See | test_quad_float.cpp | example). | I believe that interval constants are an important feature - and | quite novel. | | I don't understand that example, sorry. Thus I also miss the importance | of this feature. What exactly are interval constants? What problem are | they addressing? If you are using the interval library to calculate the intervals of areas of a circle, you need the smallest interval containing pi (as well as interval containing the radius of course). |Isn't it an orthogonal concept to constants like 'pi', | 'e', ...? Should / could it be placed into a separate library (maybe on | top of the basic constants library)? I proposed a separate file containing the interval constants (or should I say constants intervals?) | I also looked at other examples | like test_pi_interval, but I still don't understand the idea that's | behind it. All that I see is a lot of pi_f_l, pi_l_l, pi_l_u4, etc. and | this is IMHO unacceptable for generic programming. The file template_intervals_constants.hpp contains some examples of how the interval library authors and others discussions concluded that the interval values would appear to users - analogous to other intervals. Users would not see pi_f_l, pi_l_l. These are to show that the exactly representable values work OK. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | | Regards, Daniel | | PS: The toy-example I posted only worked for the GCC 3.x, but I extended | it a bit to make it work with the Intel compiler and with older GCCs | (2.95.x). If there is any interest, I can post it... | | -- | 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 | | ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost -- 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
[boost] Re: Math Constants Formal Review - is extensible.
(Sorry for the first post, hit the wrong button)
Paul A. Bristow wrote:
I imagine that any package will have some decimal digits C string to UDT
conversion, for example for quad_float it is to_quad_float(const char*) so ones
writes
NTL::quad_float my_quad_float = to_quad_float(BOOST_PI);
where BOOST_PI is defined as 3.1415926535897932384626433832794 say.
I see the 40 decimal digit representations as the 'lowest common denominator'.
How else do you propose?
I think that most people are able to look up pi (and any other constant)
on the internet if they need more precision. But as shown in the example
for the Roguewave-type, it's possible to allow the user to extend the
system. If the pi_value-stuff is placed in a header called
constant_values.hpp and the definition of the variable pi itself is in
another header, the user could add a specialization for 1000 digits if
he likes. See the example I gave for 'g'. The main point in doing this
is, that you only need to change the header of your project to add a new
type, not the code where pi is used. Here in the company, we use doubles
to develop the code, the RWDecimal-class for the production system and
we might replace the latter by another type as we don't want to use
Roguewave in the future. Of course it might be a nice idea to provide a
string representation of a constant, probably as a specialization:
template struct pi_value std::string {
std::string operator()() const {
return 3.1415926535897932384626422832794;
}
};
Now we could even provide the default case for classes that have a ctor
taking a string like this:
template typename T struct pi_value {
T operator()() const {
return T( pi_value std::string ()() );
}
};
And the user is still able to specify his own version like shown:
template struct pi_value RWDecimal RWMP3Int {
const RWDecimal RWMP3Int operator()() const {
static const RWDecimal RWMP3Int value( ...1000digits... );
return value;
}
};
|Isn't it an orthogonal concept to constants like 'pi',
| 'e', ...? Should / could it be placed into a separate library (maybe on
| top of the basic constants library)?
I proposed a separate file containing the interval constants (or should I say
constants intervals?)
| I also looked at other examples
| like test_pi_interval, but I still don't understand the idea that's
| behind it. All that I see is a lot of pi_f_l, pi_l_l, pi_l_u4, etc. and
| this is IMHO unacceptable for generic programming.
The file template_intervals_constants.hpp contains some examples of how the
interval library authors and others discussions concluded that the interval
values would appear to users - analogous to other intervals. Users would not see
pi_f_l, pi_l_l. These are to show that the exactly representable values work OK.
Now I'm getting closer to it. And if it is in a separate header, it
would not mix up the above design, would it?
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
[boost] Re: [test] first revision to 1.30.0
What I meant is that the files contain data specific to your own programing environment (there are absolute filesystem paths in the 7.1 project files for example). It's the reason why I was suggesting that it may be a mistake with CVS. If there is no mistake and if the files are really usable by other people having MSVC, that's fine. No. There are no important absolute pathes there. Only intermidiate files located forced into c:\temp\boost_test_library\. You shouldn 't have any problems using these project locally. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Review Request: cyclic_buffer
Hi all Cyclics! I want to summarize what we have till now. What should be changed in the proposed cyclic_buffer. - Rename to circular_buffer. - Add push_front() and pop_front(). - resize() to behave similarly to vector::resize(). - change_capacity() becomes again change_capacity(). I think the name change_capacity best reflects what the method really does. The vector::reserve() can only increase the capacity, never decrease - which may be confusing. And at last the circular_buffer is not vector so it can have different methods from vector. - insert() will always increase the size and possibly can increase the capacity (if not sufficient). Regards, Jan ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] VC7/Threads Warnings
Hi all, This discussion was a long time ago, but I didn't get the end of it. As building the thread library I get a lot of warnings I would like to remove them somehow (I'm using the 1.30 release version). So, what would you suggest? Using pragma's is safe enough? If yes, where is the best place to add this ? Thanks, Viv - Original Message - From: William E. Kempf [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 1:10 AM Subject: Re: [boost] VC7/Threads Warnings David Abrahams said: William E. Kempf [EMAIL PROTECTED] writes: David Abrahams said: William E. Kempf [EMAIL PROTECTED] writes: Hmm... this surprised me. Mr. Maclean indicated the warnings were level 1 _and_ 2. Builds with bjam do report errors, so the warning level can't be 0. MSDN indicates Level 2 is the default warning level at the command line. So I assumed that it must be an RTL issue causing the warnings for him. However, experimenting with 'bjam -sTOOLS=vc7 -sBUILD=vc7*cxxflags-W2' does indeed produce the warnings in question. So it appears that MSDN is wrong, and that level 1 is selected if none is supplied? I plan to bump the level up in my own set of bjam tool sets. Suggestion: turn them on with #pragmas in the library's test files. This won't turn them on when compiling the library itself, though. Turning them on only for the test files won't catch many of the warnings. So I suggest you use #pragmas in the library implementation files also. My point is that you shouldn't need a custom toolset to see the warnings, and if it's your aim to avoid triggering them they should show up in the Boost regression tests when you do. I guess I'm wondering if the official toolsets shouldn't be changed. I don't understand why the MSDN indicates it should default to /W2 while we're seeing it default to what I assume is /W1. But, projects created by the IDE default to /W3 (which is also the level recommended by the MSDN), so it makes sense to me that we should probably do the same? Otherwise, users are likely to see warnings that we don't represent in the regression logs. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Imminent Code Breakage
David Abrahams wrote: The permutation iterator in particular is *really* easy. Off-the-cuff: template class ElementIterator, IndexIterator [...] }; I'm just guessing. Why don't you put this through its paces, then contribute revised documentation and tests for the new library? Done. No documentation yet, but header file plus test. Should I commit it, and if so, where to? - Roland ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Math Constants Formal Review - is extensible.
| -Original Message-
| From: [EMAIL PROTECTED]
| [mailto:[EMAIL PROTECTED] Behalf Of Daniel Frey
| Sent: Wednesday, June 11, 2003 8:41 AM
| To: [EMAIL PROTECTED]
| Subject: [boost] Re: Math Constants Formal Review - is extensible.
|
| I think that most people are able to look up pi (and any other constant)
| on the internet if they need more precision.
Of course, but I believe there is great merit in avoiding this by having a
collection of the widely used constants all of which have the same precision and
are used by everywhere (unless there is some exceedingly special reason for
higher precision - can you suggest who needs more than 40 decimal digits - apart
from number theoretic work. Should be enough even for accountants!).
| But as shown in the example
| for the Roguewave-type, it's possible to allow the user to extend the
| system. If the pi_value-stuff is placed in a header called
| constant_values.hpp and the definition of the variable pi itself is in
| another header, the user could add a specialization for 1000 digits if
| he likes. See the example I gave for 'g'. The main point in doing this
| is, that you only need to change the header of your project to add a new
| type, not the code where pi is used. Here in the company, we use doubles
| to develop the code, the RWDecimal-class for the production system and
| we might replace the latter by another type as we don't want to use
| Roguewave in the future. Of course it might be a nice idea to provide a
| string representation of a constant, probably as a specialization:
|
| template struct pi_value std::string {
|std::string operator()() const {
| return 3.1415926535897932384626422832794;
|}
| };
|
| Now we could even provide the default case for classes that have a ctor
| taking a string like this:
|
| template typename T struct pi_value {
|T operator()() const {
| return T( pi_value std::string ()() );
|}
| };
|
| And the user is still able to specify his own version like shown:
|
| template struct pi_value RWDecimal RWMP3Int {
|const RWDecimal RWMP3Int operator()() const {
| static const RWDecimal RWMP3Int value( ...1000digits... );
| return value;
|}
| };
I don't believe that anything I propose conflicts with these sensible ideas.
The proposal is for several header files each containing the same constants,
only one of which would be used for any compilation. (Users have been warned
against using more than one! Nobody has suggested a way to guard against this
mistake, but I think that it would be apparent pretty soon, probably at compile
time, and at link time if not.) The macros constants header is the simplest and
could be used to provide the appropiate value(s) above.
|
| Now I'm getting closer to it. And if it is in a separate header, it
| would not mix up the above design, would it?
No, you would only use the intervals constants header if you were using the
interval library. (And if you were not, it would not compile).
Paul
Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK
+44 1539 561830 Mobile +44 7714 33 02 04
Mobile mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
|
| 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
|
|
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Review Request: cyclic_buffer
Hey, I'm keen on a circular argument... :-) - Rename to circular_buffer. Agree. - Add push_front() and pop_front(). Agree. - resize() to behave similarly to vector::resize(). Agree. That means items will be lost from the right end, if necessary. Or, capacity will be increased, if necessary. - change_capacity() becomes again change_capacity(). I think the name change_capacity best reflects what the method really does. The vector::reserve() can only increase the capacity, never decrease - which may be confusing. And at last the circular_buffer is not vector so it can have different methods from vector. set_capacity()? Agree. Make it clear in the documentation about how change_capacity()/set_capacity() is different to reserve() because of the possibility of data being removed to fit the specified capacity. A std::vector::reserve call is a hint, while a circular_buffer::change_capacity/set_capacity is a hard limit. - insert() will always increase the size and possibly can increase the capacity (if not sufficient). Agree. We should document that circularity (and related constant-time guarantees) applies to push/pop, but not insert. (or erase?) This strikes me as a good compromise. For one thing, it leaves the door open to inserting in a manner that resizes the capacity. (Except for the problem that if the buffer is full, every insert will require O(n) time) --- The thread in relation to automatic resizing has not yet settled, but I would suggest going ahead and doing a rev while that one settles down. --- If you think there is a meaningful way that I can help you out over the weekend, let me know. (Linux, Cygwin, MSVC 6, 7, Solaris, etc...) Regards, Nigel Stewart ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: New Iterator Adaptors
[EMAIL PROTECTED] (Hartmut Kaiser) writes: David Abrahams wrote: As a last resort this certainly helps. And in a year or so nobody will talk about the transitional CVS versions. But now it would be very helpful, if there was a separate BOOST_ITERATOR_ADAPTOR_VERSION pp constant, which could be used for this needs (BTW Spirit has such a constant from the early beginnings). Please don't get me wrong, I do not want to have a very fine granulated version tracking constant. My point is, that such interface breaking changes _must_ be track-able. Well, here are the problems: 1. There's no definition of this macro in the current sources 2. The new iterator adaptors don't use the same file paths, e.g. boost/iterator/iterator_adaptor.hpp vs boost/iterator_adaptors.hpp. I'm certainly open to any concrete solutions to this problem. Just tell me how to do it. Hmmm... You're removed the boost/iterator_adaptors.hpp file intentionally, right? This makes it even more problematic, because, there is no chance to circumvent compilation errors. There are going to be compilation errors anyway, since the interface is drastically different. What about re-introducing the boost/iterator_adaptors.hpp file: #define BOOST_ITERATOR_ADAPTOR_VERSION 0x2000 #include boost/iterator/iterator_adaptor.hpp This would allow for some version tracking and a smooth migration path for those libraries, willing to support both, the new _and_ the old iterator libs. Thought's? OK, that seems reasonable. Libraries can check to see if BOOST_ITERATOR_ADAPTOR_VERSION is defined and use different code in that case. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: New Iterator Adaptors
David Abrahams wrote: Hmmm... You're removed the boost/iterator_adaptors.hpp file intentionally, right? This makes it even more problematic, because, there is no chance to circumvent compilation errors. There are going to be compilation errors anyway, since the interface is drastically different. Sure, but I said, that without boost/iterator_adaptors.hpp there is no way to circumvent them. What about re-introducing the boost/iterator_adaptors.hpp file: #define BOOST_ITERATOR_ADAPTOR_VERSION 0x2000 #include boost/iterator/iterator_adaptor.hpp This would allow for some version tracking and a smooth migration path for those libraries, willing to support both, the new _and_ the old iterator libs. Thought's? OK, that seems reasonable. Libraries can check to see if BOOST_ITERATOR_ADAPTOR_VERSION is defined and use different code in that case. Fine, looking forward. Regards Hartmut ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Review Request: cyclic_buffer
This strikes me as a good compromise. For one thing, it leaves the door open to inserting in a manner that resizes the capacity. (Except for the problem that if the buffer is full, every insert will require O(n) time) I later realised an important point: insert will be O(n) anyway, given the need to make room for the inserted items. So, it seems that allowing automatic resizing in this case does not cost anything in terms of performence implications. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: New Iterator Adaptors
On Wed, 11 Jun 2003, David Abrahams wrote: [EMAIL PROTECTED] (Hartmut Kaiser) writes: What about re-introducing the boost/iterator_adaptors.hpp file: #define BOOST_ITERATOR_ADAPTOR_VERSION 0x2000 #include boost/iterator/iterator_adaptor.hpp This would allow for some version tracking and a smooth migration path for those libraries, willing to support both, the new _and_ the old iterator libs. Thought's? OK, that seems reasonable. Libraries can check to see if BOOST_ITERATOR_ADAPTOR_VERSION is defined and use different code in that case. Can't we just use BOOST_VERSION? (1.31.0 will have the new iterator adaptors anyway) Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Review Request: cyclic_buffer
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Nigel Stewart | Sent: Wednesday, June 11, 2003 2:03 AM | To: [EMAIL PROTECTED] | Subject: [boost] Re: Review Request: cyclic_buffer | | The generally accepted concept of a circular buffer | is a fixed size contiguous memory buffer. Following | the principle of least surprise a circular_buffer | should not decide to resize itself. On the Keep It Simple Sir principle, I agree with this. Indeed, I think that most uses specifically require a fixed at construction size, and I suspect the code will be smaller, faster and correcter if this is the specification. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: New Iterator Adaptors
Douglas Paul Gregor [EMAIL PROTECTED] writes: On Wed, 11 Jun 2003, David Abrahams wrote: [EMAIL PROTECTED] (Hartmut Kaiser) writes: What about re-introducing the boost/iterator_adaptors.hpp file: #define BOOST_ITERATOR_ADAPTOR_VERSION 0x2000 #include boost/iterator/iterator_adaptor.hpp This would allow for some version tracking and a smooth migration path for those libraries, willing to support both, the new _and_ the old iterator libs. Thought's? OK, that seems reasonable. Libraries can check to see if BOOST_ITERATOR_ADAPTOR_VERSION is defined and use different code in that case. Can't we just use BOOST_VERSION? (1.31.0 will have the new iterator adaptors anyway) I think the idea is to allow code to work with CVS versions between 1.30.0 and 1.31.0 -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] mpl size::type varies across compilers
Aleksey and all, mpl::sizeSequence returns integral_clong,.. on gcc, vc7.1 but integral_cint,.. on bcc564. Is this intentional? I am writing specialisations of classes instantiated with the result of mpl::size. The above difference in types means that the specialisations have to be different for bcc. If this is unavoidable could we have (or does it already exits?) a typedef for the the fundamental integer type used in the returned integral type constant? Hugo ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Review Request: cyclic_buffer
On Wednesday, June 11, 2003, at 05:55 PM, Dave Gomboc wrote: Why is a deque inadequate? deque is more expensive than a resizing circular buffer in both performance and code size. One also can not control *when* deque will allocate as one can with a resizing circular buffer. In a nutshell, a resizing circular buffer is often a better deque than std::deque is. ;-( A resizing circular buffer is absolutely awesome when plugged into std::queue. If your queue on average doesn't constantly grow, a resizing circular buffer is efficient, predictable and safe. A std::deque in std::queue will likely continually rellocate buffers as it drops one off one end and adds one to the other (and at annoyingly unpredictable times if you're doing real-time). -Howard ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: More refinement for future(?) more_io
On Tuesday, June 10, 2003, at 4:43 PM, Larry Evans wrote: Daryle Walker wrote: Since my last announcement (a couple of weeks ago) of refining the more_io files that were reviewed a few months ago, I've done another set of revisions. The altered files are in the Boost Sandbox CVS. Besides an altered boost/io_fwd.hpp and libs/io/doc/index.html, we got: boost/io/array_stream.hpp [snip] libs/io/test/array_stream_test.cpp The array_stream_test.cpp includes: typedef boost::io::basic_array_ostreamalphabet_length, char aostream; however, that's not defined in array_stream.hpp. Where can I find its definition? The basic_array_ostream template is hidden under that big ugly macro in the header. Daryle ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: interest in library generating streambufs
Jonathan D. Turkanis wrote:
I've thought a little
more about composition, and I think I see what your getting at. Composing
streambufs is easy if the conversion facilities you want to use are
expressed as codecvts. A wrapper around the code I posted could be used to
generate streambufs like so:
templatetypename Codecvt, typename SrcOrSink
struct compose { }; // Derives from basic_streambuf.., ..
You could then chain this operation: composeCompress, composeEscape,
composeDecrypt, File . But the interface of std::codevt is complicated
by the need to make the member functions const and pass the state as an
The code in files/col_io/test_fwd_streambuf.zip shows another way.
The fwd_ostreambuf simply implements a linked list of streambuf*
each of which forwards the streambuf::overflow arg to the next
link in the chain.
The marg_ostreambuf in that zip file prototypes a simplification of
the marg_ostreambuf in the col_io.zip.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] API Review request: XML APIs for C++
hi there, following some discussion we had some weeks ago, I'd like to invite everybody to review xml++.tgz at http://groups.yahoo.com/group/boost/files/xml/ It's a DOM-like and a SAX-like API currently implemented on top of libxml2 (http://www.xmlsoft.org). What it provides: * parsing of xml files and creation of a document tree * manipulation of document tree, i.e. insertion and deletion of nodes * node iteration, search (xpath based) * document output to a (xml) file * event driven xml file parsing (sax) To be added: * validation (dtd, schema, etc.) * ? Is there any interest in this library evolving into a boost::xml library ? If so, what needs to change, what needs to be added / removed ? Regards, Stefan ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Any Interest in an Adapter for Sequences of Pointers?
Sequences of pointers are relatively common, but the semantics for handling
them can be unwieldy.
For instance, suppose you have an std::vectorconst Widget * that you need
to perform some STL algorithm on (possibly a mutating algorithm). You may be
using this instead of an std::vectorWidget for any number of reasons:
1. You may need to manipulate objects across multiple containers.
2. Widget may be an abstract base class, and the objects you are
manipulating may be instances of different derived classes.
3. Widget objects may be non-copyable.
4. Widget objects may be so large that it is inefficient to copy them, and
it may be cheaper to copy pointers instead.
5. You may not be allowed to rearrange the Widget objects because they are
declared const, or possibly for some other reason.
Whatever your reason for using pointers, handling ranges of them can be
painful. In order to use an STL algorithm that compares Widget objects, you
have to define a custom function object. For example, suppose you wanted to
sort your Widget pointers based on the less-than operator for Widgets, which
you have already defined as follows:
friend bool operator(const Widget lhs, const Widget rhs);
Now you have to define a special predicate for comparing Widget pointers:
struct WidgetComp
{
bool operator()(const Widget * lhs, const Widget * rhs)
{
return (*lhs *rhs);
}
};
Now you can (finally) sort a range of Widget pointers using the following
statement:
std::vectorWidget * widget_ptrs_;
std::sort(widget_ptrs_.begin(), widget_ptrs_().end(), WidgetComp());
But this just gets you a strict weak ordering. In practice, you might also
need an equality comparison. Simply comparing the pointers may be
insufficient, since two pointers can refer to distinct but equal Widget
objects.
Alternatively, you could use something like
boost::iterator_adaptorstd::vectorint *::iterator,
indirect_iterator_policies. However,
passing an indirect iterator to std::sort() would cause the underlying
Widget objects to be sorted rather than the pointers. This may not be what
you want. Ideally, you would be able to choose to sort either the pointers
or the objects they refer to.
Using predicates like these on sorted ranges of pointers has another
disadvantage. There is no safeguard to ensure that NULL pointers are not
inserted into the vector.
Also, ranges of Widget pointers are not interoperable with ranges of
Widgets. Thus, you cannot use the following to generate a range of Widget
pointers from a range of Widgets and then sort them:
std::vectorWidget widgets_;
std::vectorWidget * widget_ptrs_;
. . .
// widgets_ and widget_ptrs_ get populated with some values
. . .
std::copy(widgets_.begin(), widgets_.end(),
std::back_inserter(widget_ptrs_));
std::sort(widget_ptrs_.begin(), widget_ptrs_().end(), WidgetComp());
Instead, you have to use a hand-coded loop:
std::vectorWidget widgets_;
std::vectorWidget * widget_ptrs_;
. . .
// widgets_ and widget_ptrs_ get populated with some values
. . .
for (unsigned int i = 0; i widgets_.size(); ++i)
{
widget_ptrs_.push_back(widgets_[i]);
}
std::sort(widget_ptrs_.begin(), widget_ptrs_().end(), WidgetComp());
While this is not horrible, it would be nice if we could have something like
the first syntax.
The class I am proposing is an adapter for a sequence of pointers. Users
would be able to specify the type of object that the pointers refer to,
along with a sequence type (e.g. vector, deque, list).
I would probably want to name the class permutation, because it would
provide an abstraction that represents a permutation of existing, but not
necessarily contiguously stored objects, and it would have a sequence-like
interface, with all the usual member functions (push_back(), pop_back(),
insert(), erase(), etc.).
This class would not be responsible for allocating or deallocating objects.
It would be up to the user to make sure that a permutation never contains a
dangling pointer.
The underlying sequence would not actually hold pointers. Rather, it would
hold objects that behave much like pointers (I would call them proxies.)
Here is a snippet of what the source code for the preceding example might
look like:
std::vectorWidget widgets_;
boost::permutationWidget widget_perm_;
. . .
// widgets_ and widget_perm_ get populated with some values
. . .
// place pointers to all the objects in widgets_ into widget_perm_
std::copy(widgets_.begin(), widgets_.end(),
std::back_inserter(widget_perm_));
// sort the widget pointers based on the less-than operator for
// class Widget
std::sort(widgets_.proxy_begin(), widgets_.proxy_end(),
std::lessWidget);
// alternatively, we could have sorted the underlying objects instead of
// the pointers with the following function call
[boost] Re: API Review request: XML APIs for C++
* event driven xml file parsing (sax)
I did not really used DOM to much. I may have some comments on SAX though.
Perfunctory look on your interfaces left me wondering: who does it differ
from xerces? Still xmlChar type, tons of virtual functions. We are in modern
C++ world. No need to promote such a Javish solution.
Here is my vision on the problem, couple ideas on XML parser design:
1. No xmlChar type - template parameter
namespace xml {
templatetypename Ch, typename Tr
class parser {...};
}
2. No hardcoded virtual functions. In some refinements it still may come to
use virtual functions here and there. One way to achieve this is to supply
implementation as template parameter:
namespace xml {
templatetypename HandlerImpl
class parser : public HandlerImpl {...};
}
3. Most probably above may not be good enough. For better reusability let
then use multiple template parameters for different types of handlers:
namespace xml {
templatetypename DocumentHandler, typename ErrorHandler, typename
DTDHandler, ...
class parser : public foo( DocumentHandler, ErrorHandler, DTDHandler, ... )
{...};
}
meta function foo should deduce the correct type to inherit from. We may
want to take into an account the fact that if the same type is used as both
document and error handler, we don't want to inherit twice.
Also above interface definitely asks for named template parameters.
4. There maybe several flavors of document handlers. One simple: as usual
concrete handler needs to expose methods like on_start_element and accept
the name plus attributes. As an alternative we may consider document
handlers supporting named callbacks (in a form of boost::function...)
registration. IOW such handler would call a callback when element with
desired name encountered. There are other alternatives.
This way I believe we could create fastest and convenient parser.
I am sure that there also could be Spirit-based or Spirit-like solution.
Check with the Spirit guys.
Regards,
Gennadiy.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
