July 2003 - Boost-users - lists.preview.boost.org

CRC problem with 8 bit truncated polynomial
by victoriaames 09 Jul '03

09 Jul '03

When I have tried examples using 16 or 32 bit truncated polynomials this library works perfectly. Example that works : unsigned char const data[] = { 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39 }; std::size_t const data_len = sizeof( data ) / sizeof( data[0] ); std::cout << "Expected CRC-CCITT : 29B1" << std::endl; // Simulate CRC-CCITT with the optimal version boost::crc_optimal<16, 0x1021, 0xFFFF, 0, false, false> crc_ccitt2; crc_ccitt2 = std::for_each( data, data + data_len, crc_ccitt2 ); std::cout << "Optimal CRC-CCITT : " << std::hex << crc_ccitt2() << std::endl; However, when I have tried examples using 8 bit truncated polynomials I fail to get a meaningful checksum. Example that doesn't work : std::cout << "Expected CRC-8 : EA" << std::endl; boost::crc_optimal<8, 0x9B, 0, 0, false, false> crc_8; crc_8 = std::for_each( data, data + data_len, crc_8 ); std::cout << "Optimal CRC-8 : " << std::hex << crc_8() << std::endl; The results I get are : Expected CRC-CCITT : 29B1 Optimal CRC-CCITT : 29b1 Expected CRC-8 : EA Optimal CRC-8 : Û Does anyone know why the 8 bit example does not seem to work? Victoria

2 1

[help] thread on intel solaris 8
by meg_r123 09 Jul '03

09 Jul '03

Hi all, I've succesfully compiled the boost library 1.30.0, and the tests for the libthread runs fine, but I get an "abort" when I try to execute a simple test written by me. I suppose it is a link problem, this is the command in the Makefile: (I'm using GCC) CC = g++ OBJS = test_thread.o TARGET = test_thread $(TARGET): $(OBJS) $(CC) -o $(TARGET) $(OBJS) -L$(HOME)/local/lib/ -lboost_thread Any idea to suggest me? Thank you, meg

3 4

[boost::date_time] posix_time::to_simple_string and posix_time::time_from_string
by Russell Hind 08 Jul '03

08 Jul '03

These 2 functions don't seem to work together. to_simple_string will produce a string such as 2003-Jul-08 11:55:47 But time_from_string expects 2003-07-08 11:55:47 This means you can't convert to a string (to store in a text file) then read back in and convert it back to a ptime. Is this a bug, or have I missed a conversion function that can handle this? Thanks Russell

2 3

Const strangeness and indirect_iterator generators.
by Tim Robertson 08 Jul '03

08 Jul '03

Hi, I've been trying to get indirect_iterator working in what seems (to me) to be a straightforward context -- I have a std::vector of boost::shared_ptr objects, and I need both const and non-const iterators into the vector (I'm using the vector as the sole data member of a container class, and I need the iterators to properly handle const and non-const container types). This looks something like this: class MyClass { // ... }; class MyContainer { public: typedef MyClass value_type; typedef value_type & reference; typedef value_type * pointer; // and so on, for const_reference, const_pointer, etc... // ... private: std::vector<boost::shared_ptr<MyClass> > _data; }; Now, the trouble comes when I attempt to define the iterators for MyContainer using the indirect_iterator generators. If I do the obvious: Approach #1: ------------ typedef indirect_iterator_pair_generator< vector<shared_ptr<MyClass> >::iterator, value_type, reference, const_reference, std::random_access_iterator_tag, pointer, const_pointer>::itgen; typedef typename itgen::iterator my_iterator; typedef typename itgen::const_iterator my_const_iterator; I find that the const_iterator generated is inadequate for use in a container context. Particularly, it produces a my_const_iterator that has the following constructor signature: my_const_iterator(shared_ptr<MyClass> *) Whereas, a const std::vector<shared_ptr<MyClass> > will produce const_iterators that look like this: const shared_ptr<MyClass> * const This causes compilation problems, because inevitably, in this context, you'll want to construct a my_const_iterator from a vector::const_iterator. The problem seems obvious: the indirect_iterator_pair_generator class is considering only non-const base iterators. This led me to try the following: Approach #2: ----------- typedef typename indirect_iterator_generator <typename vector<shared_ptr<MyClass> >::iterator, value_type, reference, pointer, std::random_access_iterator_tag>::type my_iterator; typedef typename indirect_iterator_generator <typename vector<shared_ptr<MyClass> >::const_iterator, value_type, const_reference, const_pointer, std::random_access_iterator_tag>::type my_const_iterator; It seemed that this would solve the problem by independently generating the two types of iterators that are needed (note how I've made the base iterator type ::iterator in one, and ::const_iterator in the other). However, with this method I always obtain compilation errors -- whereever there is a use of the operator->(), the following error is produced (g++ 3.0.3 and 3.2 do the same thing, Linux and Mac OSX): "result of `operator->()' yields non-pointer result" I have yet to figure out what is causing this error. This led me to attempt the following "solution" to the problem: Approach #3: ----------- typedef indirect_iterator_pair_generator <typename vector<shared_ptr<MyClass> >::iterator, value_type,reference,const_reference, std::random_access_iterator_tag, pointer,const_pointer> itgen; typedef typename itgen::iterator my_iterator; typedef indirect_iterator_pair_generator <typename vector<shared_ptr<MyClass> >::const_iterator, value_type,reference,const_reference, std::random_access_iterator_tag, pointer,const_pointer> itgen2; typedef typename itgen2::const_iterator my_const_iterator; This actually works! I can't explain why -- it seems like indirect_iterator_pair_generator and indirect_iterator_generator should behave identically when their template parameters are identical.... The way I see it, there's a bug in at least one of the indirect_iterator generator objects. At the very least, indirect_iterator_pair_generator and indirect_iterator_generator are behaving differently when their parameter types are the same (compare approaches #2 and #3). But there's also the issue of why approach #1 didn't work to begin with -- it *seems* like indirect_iterator_pair_generator should produce a const_iterator type that can be initialized with an iterator from a const vector. This isn't the case. If anyone can explain this to me, and convince me that I'm not going insane, I'd appreciate it greatly ;-) (Standard bug-report disclaimers: Current boost distribution, g++ 3.0.x/3.2.x, both Mac OSX and Linux exhibit identical behaviour.) -Tim

2 1

Ublas >> operators
by Amit Bhatia 08 Jul '03

08 Jul '03

Hello All, I was looking for sowe way to write the matrix to some filestream and read the same way from some file stream. Was just wondering if Ublas has any operators as << and >> defined default? I have been able to find none though. thanks, regards, amit.

2 1

Re: Using BOOST_REQUIRE outside the Test framework?
by Gennadiy E. Rozental 08 Jul '03

08 Jul '03

> Is there some macro/facility/whatever which behaves like assert(): > a) works without the Boost Test Framework > b) *AND* integrates into the BTF in those cases where the BTF is used? > > Regards, > > Joaquín M López Muñoz > Telefónica, Investigación y Desarrollo Jonh Torio developing SMART_ASSERT facility that supposed to satisfy your requirements. Look into main list archive. Gennadiy.

1 0

boost_1_30_0: cannot compile red hat gcc
by sebMarc 07 Jul '03

07 Jul '03

I must be freakin stupid. I have the simplest config possible, gcc 2.96 with a red hat system. Downloaded boot1_30_0, unzipped it, tried to compile thread and got: bash-2.05a$ bjam "-sTOOLS=gcc" ...found 341 targets... ...updating 37 targets... MkDir1 ../../../libs/thread/build/bin-stage : command not found MkDir1 ../../../libs/thread/build/bin : command not found mkdir: cannot create directory `\r': File exists mkdir ../../../libs/thread/build/bin ...failed MkDir1 ../../../libs/thread/build/bin... Being jam ignorant, this is it, i am stuck :-(. Sigh.. Tried to run configure and got: bash-2.05a$ chmod +x configure bash-2.05a$ ./configure : bad interpreter: No such file or directory Seb.

3 3

Memory leaks in Solaris
by Lev Assinovsky 07 Jul '03

07 Jul '03

Hi All! I caught a memory leak (24 bytes) when using recursive_mutex class. This class initializes a pthread_mutexattr attribute but never destroys it thus leaving the leak. We use tons of the recursive mutexes in our huge app and that leak leads to significant memory loss. Regards, Lev Assinovsky Aelita Software Corporation O&S Core Division, Programmer ICQ# 165072909

1 0

Using BOOST_REQUIRE outside the Test framework?
by Joaquín Mª López Muñoz 07 Jul '03

07 Jul '03

I'm deploying a library which implements some basic invariant checking when a certain control macro is defined. class A { void foo1(){VERIFY(*invariant conditions *); ...} ... void foon(){VERIFY(*invariant conditions *); ...} }; I use the word VERIFY for reference purposes only. Now, VERIFY is resolved to a call to assert(), which is sensible enough as: * Invariant errors are critical * Invariant checking is only enabled explictly by the user, presumably under testing conditions. On a second thought, it'd be nice if VERIFY could be seamlessly integrated into the Boost Test Framework, i.e. invariant errors are caught by the test execution monitor as other errors defined by BOOST_CHECK, BOOST_REQUIRE etc. Unfortunately, replacing VERIFY with say BOOST_REQUIRE forces the user to link with the Boost Test Framewok object modules. So my question is: Is there some macro/facility/whatever which behaves like assert(): a) works without the Boost Test Framework b) *AND* integrates into the BTF in those cases where the BTF is used? Regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

multi_array performance
by Marco Segurini 07 Jul '03

07 Jul '03

Hi, I am very new in using Boost library. I start replacing row memory array with 'multi_array' class template but the performace slow down a lot. Running this test program... //begin------------------ #include "windows.h" #include <iostream> #include "boost\multi_array.hpp" using namespace std; using namespace boost; int main() { const size_t DimX = 2000; const size_t DimY = 1500; const size_t DimZ = 1; multi_array<int,3> V3(extents[DimZ][DimY][DimX]); int iVal; unsigned long time1 = GetTickCount(); for (size_t Z=0; Z<DimZ; ++Z) for (size_t Y=0; Y<DimY; ++Y) for (size_t X=0; X<DimX; ++X) iVal = V3[Z][Y][X]; unsigned long time2 = GetTickCount(); cout << "Multi_array: " << time2-time1 << endl; int * pInt = V3.data(); time1 = GetTickCount(); for (size_t Z=0; Z<DimZ; ++Z) for (size_t Y=0; Y<DimY; ++Y) for (size_t X=0; X<DimX; ++X) iVal = pInt[(Z*DimY+Y)*DimX+X]; time2 = GetTickCount(); cout << "Pointer....: " << time2-time1 << endl; return 0; } //end------------------ ... the output (using vc++ in release mode with no optimization) is Multi_array: 1663 Pointer....:70 So, where am I wrong? Thanks. Marco.

6 6

[BGL] dijkstra_shortest_paths and the single-pair problem
by Richard Jepps 04 Jul '03

04 Jul '03

I would like to use the dijkstra_shortest_paths algorithm to find the shortest path from one specified vertex to another. The standard Boost implementation will find this, but it will continue until it has found the shortest paths to all nodes in the graph (i.e. solved the single source problem). The BGL book (Section 5.1, pp76) says: "It turns out that there are no algorithms for solving the single-pair problem that are asymptotically faster than the algorithms that solve the single-source problem". I think this is because the single-source algorithms all have the property that it is possible to determine whether the shortest path to any given node has been found during the execution of the algorithm, therefore you can use the same algorithm to solve both types of problem provided that the termination criterion is appropriate to the problem. Consider this problem: "find the shortest path from a source vertex u to a nearby destination vertex v in an infinitely large directed weighted graph G in finite time." The single-source problem can only be solved in infinite time, but the single-pair problem can be solved relatively quickly (because the two vertices are near each other). I think that the termination criterion is quite straightforward using a DijkstraVisitor - it is when vis.finish_vertex(u, g) is called and u == destination_node. Unfortunately I can't see how to stop the algorithm in a reasonable way. An unreasonable solution is to provide a custom graph and turn off all its edges when the termination criterion is met. This is unreasonable because the responsibility for termination belongs to the algorithm, not the data structure - I shouldn't have to modify the data structure to terminate the algorithm. It's also unreasonable because I have to customise both the graph and the algorithm to do something very simple. Is there a better way? Thanks Richard

3 5

function object with lambda
by Matt Hurd 04 Jul '03

04 Jul '03

Not sure how to force a for_each with a lambda to invoke the random function object successively. In the for_each version below get_long is called just once. Not sure how to use var, std_function, bind or something else to overcome this. I'm sure the answer is straight forward... anyone? Regards, Matt. #include <iostream> #include <boost/random.hpp> #include <vector> #include <boost/lambda/lambda.hpp> #include <boost/lambda/bind.hpp> typedef boost::mt19937 base_generator_type; base_generator_type generator( 100123u ); boost::uniform_int<base_generator_type,long> gen_long(generator,-100,100); using namespace std; using namespace boost::lambda; int main(int argc, char *argv[]) { vector<long> v(10); for_each(v.begin(),v.end(), _1 = gen_long() ); for_each(v.begin(), v.end(), cout << _1 << ' '); cout << "\n"; for( vector<>::iterator i = v.begin(); i != v.end(); ++i ) { *i = gen_long(); } for_each(v.begin(), v.end(), cout << _1 << ' '); cout << "\n"; system("PAUSE"); return 0; }

2 4

Re: [Boost-Users] [BGL] dijkstra_shortest_paths and the single-pair problem
by JOAQUIN LOPEZ MU?Z 03 Jul '03

03 Jul '03

Throw an exception? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo ----- Mensaje Original ----- De: Richard Jepps <yg-boost-users(a)m.gmane.org> Fecha: Martes, Julio 1, 2003 3:00 pm Asunto: [Boost-Users] [BGL] dijkstra_shortest_paths and the single-pair problem > I would like to use the dijkstra_shortest_paths algorithm to find the > shortest path from one specified vertex to another. > > The standard Boost implementation will find this, but it will > continue until > it has found the shortest paths to all nodes in the graph (i.e. > solved the > single source problem). > > The BGL book (Section 5.1, pp76) says: "It turns out that there > are no > algorithms for solving the single-pair problem that are asymptotically > faster than the algorithms that solve the single-source problem". > I think this is because the single-source algorithms all have the > propertythat it is possible to determine whether the shortest path > to any given node > has been found during the execution of the algorithm, therefore > you can use > the same algorithm to solve both types of problem provided that the > termination criterion is appropriate to the problem. > > Consider this problem: "find the shortest path from a source > vertex u to a > nearby destination vertex v in an infinitely large directed > weighted graph G > in finite time." > The single-source problem can only be solved in infinite time, but the > single-pair problem can be solved relatively quickly (because the two > vertices are near each other). > > I think that the termination criterion is quite straightforward > using a > DijkstraVisitor - it is when vis.finish_vertex(u, g) is called and > u == > destination_node. Unfortunately I can't see how to stop the > algorithm in a > reasonable way. > > An unreasonable solution is to provide a custom graph and turn off > all its > edges when the termination criterion is met. > This is unreasonable because the responsibility for termination > belongs to > the algorithm, not the data structure - I shouldn't have to modify > the data > structure to terminate the algorithm. > It's also unreasonable because I have to customise both the graph > and the > algorithm to do something very simple. > > Is there a better way? > > Thanks > > Richard > > > > > > > > ------------------------ Yahoo! Groups Sponsor -------------------- > -~--> > Get A Free Psychic Reading! Your Online Answer To Life's Important > Questions.http://us.click.yahoo.com/Lj3uPC/Me7FAA/ySSFAA/EbFolB/TM > ------------------------------------------------------------------- > --~-> > > Info: <" target="l">http://www.boost.org> > Wiki: <" target="l">http://www.crystalclearsoftware.com/cgi- > bin/boost_wiki/wiki.pl>Unsubscribe: <')" >mailto:boost-users- > unsubscribe(a)yahoogroups.com> > > Your use of Yahoo! Groups is subject to > http://docs.yahoo.com/info/terms/ > > >

5 5

boost::numeric::ublas::map_array support for the complete std::map interface?
by Markus Werle 03 Jul '03

03 Jul '03

Hi! While trying to test boost::numeric::ublas::map_array as replacement for a std::map in my own code, I found that some memfuns like lower_bound and key_comp are missing. I also found that these can be added quite easily, since e.g. lower_bound exists as external function and only needs to be called in an appropriate way. Though the functions mentioned may not be useful in ublas apps, they would help improve the reusability of map_array. Before I start stalking through the code: Are there any plans to add these features already? Or is there somebody who knows the ublas code better than me and can help me avoid breaking existsing code? best regards, Markus -- Build your own Expression Template Library with Daixtrose! Visit http://daixtrose.sourceforge.net/

2 1

RE: [Boost-Users] Re: [BGL] dijkstra_shortest_paths and the singl e-pair problem
by Jim.Hyslop 03 Jul '03

03 Jul '03

Mark Sizer wrote: > Eeek! Exceptions as flow control are, well, not exceptions. > > I have no solution to offer (I don't even fully understand the > question), but I hope someone has a better answer. At this time, the only solution is to throw an exception. This whole issue was discussed in September, including the morality of using exceptions for flow control. Please see the thread entitled "[BGL] Best way to abort an algorithm from within a visitor?": http://groups.yahoo.com/group/Boost-Users/message/1819 -- Jim

2 1

regular expression control
by Enrico 03 Jul '03

03 Jul '03

Hi all, I'm using regex with a list of regular expressions written by my team. They start from a set of rules and write down the expression (s). What I'm requested to do now is a function that given a regular expression write down all the combinations available, with some limitations of course: if for example an expression has an infinity of combination this could not be achieved. Since all the expression have a limited number of combinations in this case a warning will suffice. I searched for such a function in the regex code but didn't find it. Any idea? Thanks, Enrico

1 0

Boost.Thread and fork
by Pavol Droba 02 Jul '03

02 Jul '03

Hi, I have problem with boost.threads on linux ( under gcc ). I have a multithreaded aplication using Boost.Thread. It works just fine. However, I want to make a daemon out of it. So I tried to fork() at the start of the program and run all the relevant code ( including all threading ) in the child process. But when I do so, first call to create_thread hangs the process. I'm quite new to linux threading, so it is possible, that the problem is not related to Boost.Threads. Any hints? Thanks in advance. Pavol

4 4

another newbie question on bjam
by Karsten Weinert 01 Jul '03

01 Jul '03

Hi, still trying to set up bjam, I am stumbling on the following problem: I want to use jamfile.jam instead of jamfile (because my editor uses extensions to define actions on files). But when I run bjam on it, with bjam -f jamfile.jam -sTOOLS=mingw it complains about an unknown rule exe. What can I do? Here is the jamfile.jam: exe hello : hello.cpp : <include>c:$(SLASH)dev-cpp$(SLASH)include$(SLASH)c++ <include>c:$(SLASH)dev-cpp$(SLASH)include$(SLASH)c++$(SLASH)mingw32 <include>c:$(SLASH)dev-cpp$(SLASH)include$(SLASH)c++$(SLASH)backward ; Furthermore, can you please advise me how to simplify this jamfile? In my opinion, the include-statements belong to mingw-tools.jam, but how can I specify several include directories there? Any comments appreciated, Karsten

2 1