- Boost-users - lists.boost.org

24 Sep '07

hello all, i'm building a scheme interpreter with spirit and boost. it needs to be simple and robust enuf for a demanding production environment. i've looked for evidence of somebody else having built a scheme or lisp with spirit and boost, and have been surprised to find nothing. it seems like something that almost falls out of the existing classes (variant, shared_ptr, spirit..). it amazes me how few people understand the simplicity of power of lisp and the interpreter pattern in general. the first paper on lisp was published in 1958, and you only have to look at xml to see how relevant list processing is today. an optimal lisp implementation built with spirit & boost could be extremely concise and elegant, but i'm pretty new to spirit and i'm not sure i have the time to find it. my efforts so far are pure kludgery. i think a lisp interpreter included in the boost example code, or even a full boost class, would be very useful. with traits specialization it could be very flexible, and it would introduce an interesting tool for prototyping and testing other boostified code. does anybody know of an existing spirit/lisp implimentation, and is there any interest in developing such a project in open source? cheers jono poff Day One Digital Media Ltd. Auckland, NZ

1 0

[type_traits] Interesting problem with is_base_of.
by Seweryn Habdank-Wojewódzki 23 Sep '07

23 Sep '07

Dears There are two codes. The first is workig as it is specified in the documentation, but the second not. Why there are problems with the second code? Regards. // This code works perfectly #include <boost/type_traits.hpp> #include <boost/static_assert.hpp> #include <boost/utility.hpp> template <typename B, typename R> class test { public: test () { BOOST_STATIC_ASSERT((boost::is_base_of<B, R>::value)); } }; int main() { test <int, int> t (); } // The code belo is not working #include <boost/type_traits.hpp> #include <boost/static_assert.hpp> #include <boost/utility.hpp> template <typename B> class test { public: template <typename R> test (R const &) { BOOST_STATIC_ASSERT((boost::is_base_of<B, R>::value)); } }; int main() { test <int> t (static_cast<int>(0)); } -- |\/\/| Seweryn Habdank-Wojewódzki \/\/

1 0

[serialization]Is it ok to use the trunk version?
by Sean Huang 23 Sep '07

23 Sep '07

We really want to get the improvements (header order and threading issue) made on the trunk over 1.34.1 but the regression results make us very nervous. We only intend to use it with Intel 10 and MSVC8 and do not generate any dlls so I assume majority of the test failures do not really matter to us. Still many tests fail on Intel C++ v10. Could somebody explain to me what these errors mean and their impact on product code? I noticed there are still a branch created for the next release so I assume some work is being done. Regards, Sean

1 0

dijkstra_shortest_paths usage problem
by Juho Eskeli 23 Sep '07

23 Sep '07

Hi, I've got a following problem: is it possible to add extra cost to edge weight if changing direction? What I mean is I have created a map of vertexes with weights and each vertex has edges to general cardinal points (n,ne,e,se,s,sw,w,nw). Now that the algorithm has found a shortest distance from origin to, let's say southeast. Now all the other edges than the one going southeast are penalized. Figure of the situation: | -o- <- starting point | Least distance > o-o <- Penalized | o <- Not penalized, moving to south o denotes a vertex, - and | are edges I presume dijkstra visitor should be used for this, but I'm too much of a newbie. Any help appreciated.

1 0

math_toolkit bindings/rr.hpp
by Jordan Kyriakidis 23 Sep '07

23 Sep '07

The function template <class V> void assign_large_int(V a) inside boost::math::ntl::RR contains the lines t = static_cast<double>(a & 0xffff); m_value += ldexp(RR(t), exp).value(); My compiler (powerpc-apple-darwin8-g++-4.0.1) complains about the second line: error: cannot convert 'boost::math::ntl::RR' to 'double' for argument '1' to 'double ldexp(double, int)' I assume this is because it cannot see the function definition for RR ldexp(RR r, int exp) defined further down in RR.hpp. This trivial patch fixes the error for me: math_toolkit/boost/math/bindings$ svn diff rr.hpp Index: rr.hpp =================================================================== --- rr.hpp (revision 39435) +++ rr.hpp (working copy) @@ -25,6 +25,9 @@ namespace ntl { +class RR; +RR ldexp(RR r, int exp); + class RR { public: math_toolkit/boost/math/bindings$ but there may (probably?) be similar errors for the other functions. Cheers, Jordan

2 4

A need for a COOKBOOK
by dhruva 23 Sep '07

23 Sep '07

Hi, I am trying to get more into BOOST than what I am using currently (which is quite minimal compared to what BOOST has to offer these days) and which does not include a whole lot of new things that have got into BOOST. Are there any BOOST professionals willing to come up with a COOKBOOK for using BOOST libraries? The book "Beyond the C++ Standard Library: An Introduction to Boost" has a decent coverage but is quite dated compared to the leap BOOST library suite has seen in the recent days. As a user of BOOST, I request someone with good knowledge to come up with a COOKBOOK (like the PERL/PYTHON cookbook) for the benefit for BOOST users. It could be modeled along the PYTHON COOKBOOK. Activestate has a site to submit recipes and those are taken up, polished and edited into a nice book. with best regards, dhruva -- Dhruva Krishnamurthy Contents reflect my personal views only!

5 9

[iterator_facade] problem with dereference method
by Jeffrey Holle 23 Sep '07

23 Sep '07

I'm attempting to write a simple iterator, but am having problems with it. The following code snippet shows the datum that is used to feed the iterator, the beginning of the iterator class, the method that is producing a compiler error, and the error. typedef std::vector<DataEdge> Edges; struct NeighboringEdgeInfo { NeighboringEdgeInfo() : size(0),current_pos(0) {} NeighboringEdgeInfo(size_t size_,size_t current_pos_) : size(size_),current_pos(current_pos_) {} Edges::const_iterator start; size_t size; size_t current_pos; }; class AdjacentEdgeIter : public boost::iterator_facade<AdjacentEdgeIter,DataEdge,boost::forward_traversal_tag> { .... inline const DataEdge& AdjacentEdgeIter::dereference() const { return *(node.start+node.current_pos); <<< produces the error } The error: iterator_facade.hpp:517: error: invalid initialization of reference of type 'boost::detail::edge_desc_impl<boost::bidirectional_tag, unsigned int>&' from expression of type 'const boost::detail::edge_desc_impl<boost::bidirectional_tag, unsigned int>' Note that I have tried to make the NeighboringEdgeInfo::start iterator mutable to avoid this error, but it didn't help. Can somebody explain what is going on??

1 1

Iteration with cycling and clamping.
by Michael Marcin 22 Sep '07

22 Sep '07

I have some code which cycles through items in a list as the user presses buttons. I need to be able to move forward and backwards through this list and apply a filtering predicate. For lists that cycle through the available items when operator++ is called on the last iterator before end that satisfies the predicate it the iterator should point to the first element that satisfies the predicate. When operator-- is called on that iterator it should point to the last iterator before end again. For lists that traverse the available items without cycling when operator++ is called on the last iterator before end that satisfies the predicate the iterator should point to the same element. When operator-- is called on the first iterator that satisfies the predicate the iterator should point to the same element. The logic isn't very hard but I'd rather not duplicate it. Are there any available iterator adaptors that perform these operations at the range limits? Thanks, Michael Marcin

2 1

container performance on 64 bit systems
by Bruce Adams 22 Sep '07

22 Sep '07

Hi, This may seem slightly off topic initially but bear with me. I have recently been having fun with the ordinary STL containers on a 64bit linux system. In particular the sorted associative containers set and map bloat the memory usage to an unacceptable level. Part of this is down to 64 bit pointers versus 32 bit pointers. In a standard Red-Black tree implementation each node has 3 pointers, these double in size as do any pointers in the containers themselves. There are also issues with allocating on 8byte and 16byte boundaries. I measured and discovered that an otherwise highly efficient structure took *10* times as much memory on a 64bit machine vs. the 32bit one. I can half the memory usage for a std::set by replacing it with a std::vector and sorting it manually. Nothing too out of the ordinary there. To solve my problem I have replaced a large number of 64bit pointers with indices and manipulate std::vector's of these instead of using associative containers. Are there any 'better' implementations of std::set etc. (preferably open source GNU/Linux compatible) out there? Are any planned? Does boost contain any suitable replacements? Does boost itself suffer from or tackle this 64bit bloat problem? Regards, Bruce. ____________________________________________________________________________________ Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow

3 2

Re: [Boost-users] [multi-index] possible extension
by Ovanes Markarian 21 Sep '07

21 Sep '07

Joaquin, to be honest I did it also the way deriving from the boost::noncopyable and multi_index_container class. The only problem is the need of initializing constructors, which are either not available or must be explicitly overridden in the derived class. If standard containers are lacking this functionality it is not a reason to avoid it in a lib which stands for technology or ideas after standard containers. On the other hand I would like to point out that it is possible to specify a default policy of being copyable for a container. Only if someone wishes the container to be noncopyable she/he can/should specify it. There would be no change in the external interface for usage if the user is not aware of this feature. Best Regards, Ovanes. > On 9/21/07, Joaquin M Lopez Munoz <joaquin(a)tid.es> wrote: > > > > Hello Ovanes, > > > > Ovanes Markarian <om_boost <at> keywallet.com> writes: > > > > > > > > Hello Joaquín,I would like to make a proposal for additional feature > > of > > > optionaly making multi-index container non-copyable (via copying > > policy > > > class). The same way as a user can decide which indicies to use she/he > > > could specify whether the new data-structure should be copyable or > > not. > > > In my case I was assuming to pass container by reference, but it was > > > copied by some function object. Which produced despite the performane > > > issue wrong results. Using the non-copyable policy I would simply get > > a > > > compiler error. > > > > With all due respect, I don't think this is a feature > > worth including into the lib because: > > > > 1. All standard containers are copyable, I don't see > > any compelling reason to deviate from that. > > 2. The overlook you mention could have happened with almost > > any other kind of object, having this particular type patched > > makes little difference In the grand scheme of things. > > > > Anyway, you can have your own noncopyable_multi_index_container > > by simply deriving from multi_index_container and providing > > the necessary forwading constructors (save copy, of course). > > Maybe this is sufficient for your needs. > > > > Best, > > > > Joaquín M López Muñoz > > Telefónica, Investigación y Desarrollo > > > > _______________________________________________ > > Boost-users mailing list > > Boost-users(a)lists.boost.org > > http://lists.boost.org/mailman/listinfo.cgi/boost-users > > >

1 0