- Boost - lists.boost.org

rational variants/alternatives
by Andras Erdei 26 Mar '05

26 Mar '05

i've started to work on the variants that were brought up in a previous discussion about boost::rational<> the current code can be found at www.ccg.hu/pub/src/rat atm it is only for getting the calculations right, so no templates, optimizations, boostification, nice interface etc, and i only tested it with MSVC 7.1 there is also no implementation yet geared towards an unlimited precision representation the variants are: - legacy boost (no rounding, silently gives wrong results) - exceptions are thrown if the result overflows or cannot be represented - rounding - rounding & maintaining an exactness indicator is there anything missing from the list? there is also a simple test-bed, it runs the four basic operations 10000 times on random inputs, and collects some statistics: addition and substraction overflowed 0 times, and the result was exactly representable 44 times; the average error of the legacy code is 475%, and of the rounding code is 0.005% (the exception-throwing variant throws, so there is no error figure for that) multiplication and division overflowed once, and the result was exactly representable 79 times; the average error of the legacy code is 2025%, and of the rounding code is 0.01% it would be nice to get some advice on how the final interface should look like (and of course regarding everything else, including whether there is a point to continue the work): - any ideas for naming the variants? - how should the parameters of rational<> look like? my favourite would be rational<prec,method> where prec is the maximum absolute value allowed for numerators and denominators, and method is one of the variants from above, e.g. rational<10000,round> would be a rounding rational with four decimal digits for the numerator and denominator. of course this would cripple rational<> to be int-based, so maybe specifying the number of bits to be used instead of the maximum value is a sensible approach. (still don't know though how would user-defined types be selected based on this, so maybe the original boost approach is the only workable one.) br, andras ps: i have tried to search the archive for past discussions about rational<> to avoid repeating old stuff, but with very limited success (only the latest posts seem to be accessible) -- any hints?

3 11

boost::is_convertible failure on abstract classes
by Me here 26 Mar '05

26 Mar '05

Hello, The code below does not compile, when, I believe, it should. Compiler says that you can't instantiate abstact class. I'm really surprised - it is trivial use case, but I did not find a problem report. Do I miss something? Regards, Alexander --------------- sample code ------------ #include <boost/static_assert.hpp> #include <boost/utility/enable_if.hpp> #include <boost/type_traits.hpp> struct Data { virtual foo() =0; }; int main(int argc, char* argv[]) { BOOST_STATIC_ASSERT((boost::is_convertible<Data,Data>::value)); return 0; } --------------- sample code ------------ __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

3 3

test
by Igor Smirnov 25 Mar '05

25 Mar '05

Just a test

1 0

Boost Algorithms Library
by David Abrahams 25 Mar '05

25 Mar '05

As part of my work on the MTL rewrite (http://www.boost-consulting.com/projects/mtl) I have to re-implement the FAST library (http://www.osl.iu.edu/research/mtl/reference/html/#fast) I am re-imagining FAST to use "iterators" whose positions are represented in their types. This is a similar concept to that of a fusion iterator (http://www.boost.org/libs/spirit/fusion/readme.txt) That will allow full loop unrolling for fixed size arrays and their subranges -- the whole point of FAST -- without having to explicitly supply integral constants. Naturally such iterators can't be incremented in-place; traversal will be done with next(i). There will be a function to convert FAST iterators into regular std:: iterators. FAST iterators are different from Fusion iterators in that respect; fusion iterators are heterogeneous in general and so can't have a single value_type. It turns out that OSL (and probably Boost in general) are going to be writing several kinds of algorithm implementations for different kinds of iterators, including segmented algorithms (http://lafstern.org/matt/segmented.pdf) We also have the standard algorithms, Fusion algorithms, and who-knows-what-else so it makes sense to try to supply a common interface that can be used generically, without regard to the kinds of sequences are being operated on. It would also be nice to make the system extensible, so there's at least a chance of providing new algorithm implementations for new kinds of iterator and having things "mostly work." I am planning a sequence/range-based (as opposed to iterator-based) interface, to make sequence adaptation and chaining easier. In case you disagree, I consider that a comparatively uninteresting and orthogonal point, so I'd prefer to save any arguments on that for later. As far as I can tell, the only reasonable way to unify these libraries extensibly is to provide a central algorithm dispatcher that is called with qualification, e.g.: boost::algorithm::transform(input_sequence, op, output_sequence) The easiest way to do dispatching is to use ADL based on tags associated with the sequences or their iterators, something like: // algorithm.hpp namespace boost { namespace algorithm { template <class I, class Op, class O> something transform(I input_sequence, Op op, O output_sequence) { return transform_impl( input_sequence , algorithm::get_tag(input_sequence) , op , output_sequence , algorithm::get_tag(output_sequence)); } }} // fast.hpp namespace boost { namespace algorithm { namespace fast { struct fast_tag {}; template <class I, class Op, class O, class T> something transform_impl( I input_sequence, fast_tag, Op op, O output_sequence, T) { // ... whatever ... } }}} I believe ambiguities will be the greatest obstacle to extensibility, especially because many algorithms (e.g. the 2-sequence version of transform) can operate on utterly different sequences. It's possible to add another transform overload without the tag arguments in fast:: so that users can explicitly invoke fast::transform in case algorithm::transform is ambiguous, but that won't help when transform is being invoked from within some library whose code the user doesn't control. Another problem is that determining the type of "something" for the outer transform can be complicated. That's related to the use of ADL dispatching because we might have to determine how the ADL works out just to understand where to find the return type calculation. Yes, typeof would solve that problem. The ambiguity problem can be resolved by going to a specialization-based dispatch. It allows us to silently choose one of many equal implementations in case of ambiguity, which can be neccessary if you want to prevent ambiguities from arising in libraries over which the user has no control. The user can also add specializations to resolve the ambiguity, though that leads to the risk of clashing specializations. That approach adds a great deal of machinery for something we haven't even seen to be a problem in practice yet. For an example, see the end of the message. I am inclined to go with ADL-based dispatching, at least for now. Whether results should be lazy (as in Fusion) or greedy, as in standard algorithms, or whether both variants should be provided somehow, are interesting questions. The answers change the usage pattern, i.e.: copy(transform(s1,op), output) or output = transform(s1,op) // if output supports it vs. transform(s1,op,output) Your thoughts on these topics would be much appreciated. ---------- // Specialization-based dispatch example // algorithm.hpp namespace boost { namespace algorithm { // algorithm identifier struct transform_tag {}; // Map some implementation identifier into a transform implementation. template <class IO> struct transform_impl; // A metafunction to trace refinement relations among sequence // concept tags. E.G., // refines<random_access_sequence_tag>::type // yields bidirectional_sequence_tag. We can work out a protocol // for "multiple refinement," if neccessary. template <class Tag> struct refines; // implementation -- produce an implementation for an algorithm // and set of sequence types and category tags // // ID must be a function type of the form: // algorithm-identifier ( Seq1, tag1, ... SeqN, tagN ) // template <class ID> struct implementation { typedef mpl::false_ is_specialized; typedef mpl::int_<0> score; }; // If there's no closer specialization, then try again with the // "base" sequence category. template <class Algorithm, class S1,class Tag> struct implementation<Algorithm(S1,Tag)> : implementation<Algorithm(S1,typename refines<Tag>::type)> { typedef typename mpl::next< typename implementation< Algorithm(S1,typename refines<Tag>::type) >::score >::type score; }; // If there's no closer specialization, then try again with the // "base" sequence categories. template <class Algorithm, class S1, class Tag1, class S2, class Tag2> struct implementation<Algorithm(S1,Tag1,S2,Tag2)> : best_scoring< // definition left as exercise ;-) mpl::vector2< implementation< Algorithm(S1,typename refines<Tag1>::type,S2,Tag2) > , implementation< Algorithm(S1,Tag1,S2,typename refines<Tag2>::type) > > >::type {}; // ... // impl -- dispatch an algorithm and sequence types to a given // implementation // // ID must be a function type of the form: // algorithm-identifier ( Seq1, ... SeqN ) // template <class ID> struct impl; template <class Algorithm, class S1> struct impl<Algorithm(S1)> : implementation<Algorithm(S1, typename sequence_tag<S1>::type)> {}; template <class Algorithm, class S1, class S2> struct impl<Algorithm(S1)> : implementation< Algorithm( S1, typename sequence_tag<S1>::type , S2, typename sequence_tag<S2>::type )> {}; // ... // Dispatching wrapper for transform implementations template <class I, class Op, class O> impl<transform_tag(I,O)>::result_type transform(I input_sequence, Op op, O output_sequence) { impl<transform_tag(I,O)> ::execute(input_sequence, op, output_sequence); } }} // fast.hpp namespace boost { namespace algorithm { namespace fast { struct tag {}; // identify FAST sequences }}} namespace boost { namespace algorithm { // A transform algorithm implementation for FAST input sequences template <class I, class O, class OTag> struct implementation< transform_tag(I,fast::tag,O,OTag) > { // ... } }} -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 4

[serialization] typo's in is_abstract.hpp
by Eelis van der Weegen 25 Mar '05

25 Mar '05

Line 25 in boost/serialization/is_abstract.hpp uses _GNUC__ and __GNU_MINOR. Both are incorrectly spelled; the correct names are __GNUC__ and __GNUC_MINOR__. Regards, Eelis

2 1

Weird "new vault" download behavior
by David Abrahams 25 Mar '05

25 Mar '05

If I click the leftmost link for Arkadiy's typeof() implementation, I get a window containing: File : typeof.zip Print Download Fatal error: session_start(): Failed to initialize storage module: user (path: /tmp) in /home/groups/b/bo/boost-sandbox/htdocs/vault/include/common.php on line 62 Something's not quite right here, I think. -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 3

[test] Boost.Test broken on MSVC and CW 8.3?
by Jonathan Turkanis 25 Mar '05

25 Mar '05

Gennadiy, All the iostreams regression tests are failing on cw-8_3, msvc and msvc-stlport; the compiler output just links into the reports for Boost.Test. Looking at the regression reports for Boost.Test, it looks like just about everything is failing on these platforms. Just wanted to alert you if you don't already know. Jonathan

2 2

Interest poll: Define named char/wchar_t string constants in header files
by Alf P. Steinbach 25 Mar '05

25 Mar '05

Following the guidelines for Boost submission at <url: http://www.boost.org/more/submission_process.htm#interest> this is a request for interest. I've posted the file + one little file it depends on at <url: http://groups.yahoo.com/group/boost/files/named_strings/>. This utility lets you use literal strings in char/wchar_t-templated code (and even as template arguments): you can write things such as BOOST_DEF_NAMED_STRING( eq, "=" ) template< typename Char > bool is_assignment_op( std::basic_string<Char> const& s ) { return s == literal::eq::s<Char>(); }

1 0

re: How much should I care about allocators?
by Michael Stevens 24 Mar '05

24 Mar '05

Dan, I looked into allocators last year when implementing uBLAS's storage abstraction using allocators. You should definitely make use of the ISO standard text when working with allocators! On Monday 21 March 2005 04:19, Dan Rosen <dan.rosen(a)gmail.com> wrote: > In other words, to respect the allocator I've been given, I need to > make sure my internal node structure uses the rebound node allocator's > pointer and value types, and so forth. So my first question is, is > this assumption correct? This is correct but requires a lot of library programmer discipline! > The reason I ask is that looking over the > standard library implementation that comes with gcc 4.0, I noticed > that their implementation of std::list<> has nodes which contain > straight pointers, rather than the allocator typedef equivalents. To > me that seems to contradict my assumption, assuming the gcc > implementation is correct. GCC is correct. There is a get out clause in the library standard. Look at section 20.1.5 "Allocator requirements" paragraph 4: Implementations of containers described in this International Standard are permitted to assume that their Allocator template parameter meets the following two additional requirements beyond those in Table 32. All instances of a given allocator type are required to be interchangeable and always compare equal to each other. The typedef members pointer, const_pointer, size_type, and difference_type are required to be T*, T const*, size_t, and ptrdiff_t, respectively. I suspect many implementation (including those not in the standard) have this requirement! > My second question is about allocator's construct() method. The > implementation of std::allocator has construct() invoking the copy > ctor using placement new(). That much is self-explanatory. It also > seems reasonable to me that allocator does not have construct() > methods taking arbitrary parameters. But I'm not sure I understand the > reason why it does not have a construct() method to invoke an object's > default ctor.? In Table 32 "Allocator requirements" construct is specified as a.construct(p,t) Effect: new((void*)p) T(t) >From this I conclude the construct is semantically identical to calling placement new. In effect construct does nothing other then provide a nice bit of syntax. I could just as well use placement new syntax directly or indeed call placement new for any other constructor such as the default constructor. > What that implies to me, and seems to be supported by > gcc's list implementation, is that the nodes in my tree mustn't have a > default ctor that actually does anything, because the only way to > properly initialize objects using an allocator is through copying. Is > that correct I think not. My interpretation is that allocators require that their value_type is Copy Constructable but place no restriction on other ways they may be constructed. That said, STL containers have been carefully designed to avoid the need default construct an object which will be subsequently assigned to. They can keep memory in an uninitialised state until an element is needed and then use copy construction. All the standard containers require their value_type to be Assignable but not Default Constructable. Interestingly no mention is made of Copy Constructable in the value_type requirements. I assume this is inherited in the Allocator requirements. Hope this help, Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

6 7

boost::iostreams: only with std::cout?
by Dirk Griffioen 24 Mar '05

24 Mar '05

Hi, I would love to use the boost::iostreams lib, so I created a filter (which, in this case, does encryption) but instead of passing it std::cout I would like to pass it some other stream, a stringstream for instance (or any kind of ostream/istream, depending on the direction). However, I was very surprised to find the following code taking 100% cpu and not returning. It probably means I did something wrong, but I can't seem to find it. void test_encryption_filter() { const char* speech = "They sorely misunderestimate the American people if they " "think we will let them obtain nucular weapons. This " "malfeance will not stand."; // std::ostream which writes to standard output, filtered by a // encryption_output_filter. boost::io::filtering_ostream out; out.push(encryption::code_book::output_filter()); //out.push(std:cout); //this works std::ostringstream os; out.push(os); //this does not // Print unfiltered code. std::cout << "**** Speech unfiltered ****\n" << speech << "\n\n"; // Print filtered code: std::cout << "**** Speech with encryption filter ****\n"; out << speech << "\n\n"; } (testing puspose) filter looks like (namespace omitted): struct output_filter : public multichar_output_filter { template<typename Sink> void write(Sink& snk, const char* s, streamsize n) { while (n-- > 0) boost::io::put(snk, toupper(*s++)); } }; With std::cout this works fine, with std::ostringstream it does not. So could anyone please tell me what I am missing? Thanks in advance, Dirk ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this email in error please notify our system management at postmaster(a)optiver.com and immediately and permanently delete this message and any attachments. ********************************************

2 3