- Boost - lists.boost.org

Re: [boost] Some follow-up on my fixed point code, and safe integers
by james.jones＠firstinvestors.com 27 Apr '07

27 Apr '07

From: "Phil Endecott" <spam_from_boost_dev(a)chezphil.org> > That's interesting. Is there any way to use that from C++? Of course, > it also has a relatively efficient 32x32->64 because it has a single > instruction for 64x64->64. So any code for this problem would have to > be architecture-specific. But here is the sort of thing that I am > thinking about for machines that only have 32x32->32: > > In these figures, each letter represents 16 bits. > > If I want to do 32x32->64, I need to break up the two operands into two > 16-bit portions and do this calculation: > > A B > x C D > --------- > B*D > A*D > C*B > A*C > --------- You could also do it with NO multiplications by shifting one of the operands and adding or not adding it to an accumulator depending on a bit test of the other operand. Of course, integer multiply is fast enough in modern CPUs that this might not help. > (Is this sort of integer arithmetic of interest to people, other than > as the implementation of fixed point? I believe there was a big-int > SoC proposal; does that overlap with this?) It's really interesting to me, which is why I keep talking about my proposal for a decimal library. The algorithms are more general than the sort of fixed-point library you're working on (but also slower), and the use case is slightly different, but the two are related in the sense that they both work essentially with integer math. Incidentally, I have some ideas on how to implement all or at least some of the <cmath> functions in a fixed-point library. This has already come up in my decimal library. - James Jones Administrative Data Mgmt. Webmaster 375 Raritan Center Pkwy, Suite A Data Architect Edison, NJ 08837

1 0

counting_iterator question: Incrementable template argument built on iterator_facade has hack for type conversion in C++ Newton square root example.
by Tom Titchener 27 Apr '07

27 Apr '07

In the process of researching design pattern implementations in C++ I encountered the truly awesome boost iterator library and was able to transmute the Haskell example of the Newton square-root algorithm here http://www.cs.bham.ac.uk/~ard/modules/swh05.html into C++, as below, using counting_iterator and filter_iterator as C++ equivalents to the Haskell list comprehensions. Cool. But the "Incremental" template argument input for counting_iterator, which executes the "improve" method from the example needed a type conversion operator that I would have thought the "dereference" method from the iterator_core_access class would have supplied instead. I'm getting lost sorting through the façade and base classes, though, and was hoping somebody could show me the way. Thanks, Tom Titchener #include <stdio.h> #include <math.h> #include <vector> #include <iostream> #include <functional> #include <boost/iterator/iterator_facade.hpp> #include <boost/iterator/filter_iterator.hpp> #include <boost/iterator/counting_iterator.hpp> //copied from boost template<class InIt, class OutIt> InIt copy_n(InIt first, typename std::iterator_traits<InIt>::difference_type length, OutIt dest) { for (; length--; ++dest, ++first) *dest = *first; return first; } //Newton square root "improve" method modeling forward traversal iterator. class improve_increment : public boost::iterator_facade<improve_increment, float, boost::forward_traversal_tag> { const float x_; float y_; friend class boost::iterator_core_access; void increment() { y_ = (y_ + x_/y_)/2; } bool equal(improve_increment const& other) const { return y_ == other.y_; }; const float& dereference() const { return y_; } //why won't this convert? public: improve_increment(const float& x=0) : x_(x), y_(1) { } operator float() const { return y_; } //hack? }; //Counting iterator adaptor to "count" over improvements. typedef boost::counting_iterator<improve_increment> improve_iterate; //Newton square root predicate to filter incremental "improve" outputs. class satisfactory_test : public std::unary_function<const float&, bool> { const float x_; const float d_; public: satisfactory_test(const float& x=0, const float& d=0.01) : x_(x), d_(d) { } bool operator()(const float& y) const { return abs ((y * y) - x_) < d_; } }; //Top level iterator to filter improvements from test. typedef boost::filter_iterator<satisfactory_test, improve_iterate> satisfactory_filter; //Dump out the first 10 increments of the two iterators. void main(void) { std::cout.precision(10); copy_n( boost::make_counting_iterator(improve_increment(27.3F)), 10, std::ostream_iterator<float>(std::cout, " ") ); copy_n( boost::make_filter_iterator(satisfactory_test(27.3F, 0.001F), improve_iterate(27.3F)), 10, std::ostream_iterator<float>(std::cout, " ") ); }

2 1

boost::proto pattern matching and transforms
by Maurizio Vitale 27 Apr '07

27 Apr '07

I think I haven't really understood how proto handles transforms and pattern matching. I'm probably confused on how exactly result_of, arg and mpl placeholders play together and I kind of get what I want in some cases. For instance, given the pattern: proto::terminal< number<bounds<run_time,_>,_,_,_,_,_> > how can I refer in the rhs of a transform to: a) the entire pattern being matched (e.g. terminal<> or number<>) b) the bound<> subobject c) the expression corresponding to the placeholder inside the bound object d) the expression corresponding to one of the other 5 placeholders in the number<> subtree I'm particular unclear on how placeholders are bound to mpl placeholders: left to right, depth/breath first traversal of the parse tree, some other way. The only examples I've found uses mpl::_ and has a single proto::_ universal matcher in the lhs so is not like I have any evidence of an intention to bind other mpl placeholders. Maybe I have to dissect the matched expression myself, but I need at least to get an handle to the entire expression. This is blocking me at the moment, so if anybody has suggestions, they would be very much appreciated. Best regards, Maurizio

2 2

[Boost-bugs] [ boost-Bugs-1708530 ] Bug in Win32 implementation w/ static linking
by SourceForge.net 27 Apr '07

27 Apr '07

Bugs item #1708530, was opened at 2007-04-27 09:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1708530&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: threads Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Johan Nilsson (j_nilsson) Assigned to: Mike Glassford (glassfordm) Summary: Bug in Win32 implementation w/ static linking Initial Comment: [reposting this to the bug tracker] Hi, I believe I've found a bug in tss.cpp, for details please ref http://article.gmane.org/gmane.comp.lib.boost.user/26591 . The immediate fix is straightforward, it just involves resetting the native tss value after deleting the pointed-to data at thread exit. Patch is attached to this message. The changes only affects the Win32 platform and I've run the supplied tests under libs/thread/test to verify that it doesn't break anything obvious. As the bug involves dereferencing a dangling pointer and isn't detected most of the time, I'd really appreciate if the patch could be accepted as soon as possible. I'm awaiting Roland Schwartz to "bless" the patch. If he agrees, would it be possible to accept this for 1.34? / Johan ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1708530&group_… ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Type as String Library
by Jared McIntyre 26 Apr '07

26 Apr '07

I have need of a library that converts a compile time type to a string. For example: namespace testNamespace { struct aStruct{}; } void main() { std::cout << TypeString<int>::str() << std::endl; std::cout << TypeString<aStruct>::str() << std::endl; } would output: int testNamespace::aStruct I have been playing around with code that does this, but I wanted to make sure I wasn't duplicating any work that someone else has already done. I looked through the boost sandbox, but didn't find anything. Am I missing something? If not, is this something that there would be interested in having? Clearly it would be compiler dependent but I know I can get it to work on Visual Studio and I think I could do it with gcc. Jared

6 11

[1_34_0] Python Type Conversion Wanring
by Jared McIntyre 26 Apr '07

26 Apr '07

On the 1.34.0 beta (and RC_1_34_0 branch) boost::python gives a warning: boost_1_34_0\boost\python\detail\caller.hpp(52) : warning C4244: 'return' : conversion from 'Py_ssize_t' to 'unsigned int', possible loss of data I'm using Visual Studio 8 SP1 with Python 2.5. I have not tried to use boost::python on 1.33.0, so I don't know if it is there or not. I'm sorry if this has been brought up before, but I did some searching and didn't find anyone reporting this issue before (just found a few build logs). Jared

2 1

Code structure analysis
by David Abrahams 26 Apr '07

26 Apr '07

Reposting for Paul with a better subject line -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com

1 0

boost::proto, improving error handling
by Maurizio Vitale 26 Apr '07

26 Apr '07

I don't know if something can be done, but it would have saved me quite some time. Here what happened: - I was moving my small example to a more realistic case. As ususal, example works and reality doesn't care. - In the example I had terminal<number<_,_> > and all was kosher. I tried to add a template parameter with a default value, just to make sure I could still have patterns with all arguments and everything was fine. - now in reality my number has 6 template arguments. 6 is larger than 5, and with this I've given out what happened, at least to Eric. For others, 5 is the default maximum number of arguments in proto expressions. So far, so good. The problem is that my grammar had a pattern terminal<number<_,_,_,_,_,_> >. I don't know if it is possible to make proto complain hard and loud about building a pattern (or other expressions) with more arguments than the maximum allowed by configuration, but in my case the pattern was not matching causing my expressions to be invalid. And the error from GCC was nothing hinting at grammars, matches or anything. It was just saying that overloads for operators where ambiguous (because of my operator int and unsigned int, I don't know what it would have happened without). And I think that 6 is a better default value for the number of allowed arguments. Just kidding, as long as defining it before including proto headers is officially blessed and documented, I'm ok. Another nice thing to have, although I would only put it in if very easy to code: especially in presence of default parameters it might be nice to have a pattern matching "the rest of the argument list". Something like a proto::___. Cheers, Maurizio

2 3

Re: [boost] Fwd: [1.34.0] Volunteers needed to check tarballs
by Vladimir Prus 26 Apr '07

26 Apr '07

On Thursday 26 April 2007 02:07, Thomas Witt wrote: > Vladimir, > > Any idea what's going on here? See Jeff's report at the bottom for > the problem. > Begin forwarded message: > > > From: Jeff Garland <jeff(a)crystalclearsoftware.com> > > Date: April 25, 2007 2:17:19 PM PDT > > To: Thomas Witt <witt(a)acm.org> > > Subject: Re: [boost] [1.34.0] Volunteers needed to check tarballs > > On the downside, I'm unable to compile, but frankly this isn't a > > new problem for me on the particular machine -- I have the problem > > with the RC too. No doubt it's some kind of 'pilot error' on my > > part...lack of understanding of some new magical v2 process I need > > to follow (yes, I've read Dave's new getting started). The compile > > command from bjam basically spits out this: > > > > bjam --toolset=gcc > > > > -ftemplate-depth-128 -O0 -fno-inline -Wall -g -fPIC - > > pthread .... > > > > meaning it's missing the 'g++-4.0' part of the command. In my user- > > config.jam file I have: > > > > using gcc : 4.0 : g++-4.0 ; > > > > but it doesn't seem to do anything. I have those possibilities: 1. Some wrong Boost.Build is used. Can you add --debug-configuration option to bjam and see where Boost.Build files are being loaded from? 2. Auto-configuration does not like pre-configured version in user-config.jam. Can you try bjam gcc-4.0 3. There's no actually g++-4.0 binary in PATH. Can you check that? If you fail to fix the problem still, please send me the output of --debug-configuration. - Volodya

6 7

[1.34.0] Volunteers needed to check tarballs
by Thomas Witt 26 Apr '07

26 Apr '07

Hi, I would appreciate it, if I could get a few people to look at the beta tarball/zip before I release them. Please shoot me an email if you got time for this today. Thanks Thomas

3 3