February 2006 - Boost-users - lists.preview.boost.org

Re: [Boost-users] [spirit] should be a very simple problem, but I'm stumped
by Todd Day 26 Feb '06

26 Feb '06

>> "ParmName: ParmValue" >> I'm looking for certain ParmNames, and I have to grab the associated >> ParmValue. >[Nat] Maybe the Spirit parser is the wrong place to get specific about >the ParmNames you're seeking? Maybe what you should do is parse *every* >item of that form, stuffing the pairs into a std::map. Then you can >extract from that map the specific items you want. Nat, thanks for the reply. In the course of writing a reply to you explaining what I'm really trying to do, I had an "aha" head-slapping moment. You know how it is... sometimes, just trying to explain a problem is enough to generate the answer. In reply to your quoted text above, yes, I should not be specific about which ParmNames I'm seeking at this level. I was actually using a map; I had just removed that from my example to make it a bit easier to understand. There is a bigger problem that the files I'm looking at may have mismatched single quotes in the parts of the file I don't care about. Like this random-text " random-text random-text In other words, to a parser looking for quoted text, these single quotes would appear as damaged, and the parser would still halt like it does now. The only thing I can be sure of is that "ParmName: ParmValue" will be properly quoted and non-damaged and consistent within itself. So it turns out my basic comprehension problem here is similar to one I had actually gone through when I was first learning pattern matching and regular expressions under Perl. I went and dug up some old Perl code of mine that did a similar search to see how I did it back then. My basic problem is thinking that the parser would continue grinding through non-matches just by putting a kleene-star on the front of it. Once I took this into account, a new strategy emerged. First, search for a single quote. Then try and see if there is a match at that point. If a match, move to just beyond the match, else just move to the next character. Repeat. The code is not as simple as my previous non-working version, since now I have to use iterators. This example also looks for multiple types of ParmNames. It comes out looking like the code below. I love that you can load up a complex map assignment right in the middle of the rule. map<string,string> smap; string key; typedef string::const_iterator iterator_t; typedef scanner<iterator_t> scanner_t; typedef rule<scanner_t> rule_t; typedef parse_info<iterator_t> parse_info_t; rule_t quote = ch_p('"'); rule_t colon = ch_p(':'); rule_t eat_all_non_quotes = *~ch_p('"'); rule_t parm_names = str_p(DWARF_DEVICE_NAME) | DWARF_DEVICE_TYPE | DWARF_DEVICE_SOFTWARE_VERSION | DWARF_DEVICE_COMMENTS; rule_t parm_string = quote >> parm_names[assign_a(key)] >> colon >> *blank_p >> eat_all_non_quotes[insert_at_a(smap, key)] >> quote; string str = "\"broken\" (text \"DeviceName: Altera in Controller\" (blah))"; iterator_t first = str.begin(); iterator_t last = str.end(); parse_info_t pi; while (first != last) { // skip to first quote character pi = parse(first, last, eat_all_non_quotes); first = pi.stop; // make sure we haven't gone past the end if (first != last) { // eat up any matching parms here pi = parse(first, last, parm_string); if (pi.hit) first = pi.stop; else first++; } } Thanks for the help, -todd-

1 0

member selector adapter
by Nico Galoppo 25 Feb '06

25 Feb '06

Hi, is there some utility (templated) adapter type class that I could use to construct an adapter such that an (associative) array of (pointers to) objects behaves like an (associative) array of a member variable of the objects? Something like class A { int val; }; std::map<int, shared_ptr<A> > container_type; container_type amap; shared_ptr<A> elem(new A()); amap[2] = elem; amap[4] = elem; amap[6] = elem; selector_adapter<container_type, &A::val> val_container(&amap); std::cout << val_container[4]; // should output amap[4]->val; --nico -- nico galoppo von borries @ address: 105 creel st., chapel hill comp. graphics phd. student @ north carolina, 27516 USA UNC, chapel hill @ phone: +1 (919) 962-1898 (office) @ +1 (919) 942-7609 (home) @ email: nico at cs dot unc dot edu @ homepage: http://www.cs.unc.edu/~nico --- debian linux :: vim powered

1 0

Boost build problems in Scratchbox, mkdir fails
by Rohit Chaudhri 25 Feb '06

25 Feb '06

Hello, I have recently started to work with Boost 1.33 on Linux. I have an X86 based Ubuntu Linux machine. I have installed Scratchbox 1.0 (www.scratchbox.org) on this machine for embedded linux development. I'm able to build boost on Ubuntu, however when I try to do the same within Scratchbox using an arm-gcc-glibc toolchain, the Boost build scripts fail because mkdir commands are failing. I was able to build Boost.Jam by manually creating the required directories within Scratchbox. Now while building Boost 1.33, I'm trying to build the Boost.Python module and it fails in a similar way on MKDIR. I want to fix this mkdir failure problem because I can't manually keep creating each required directory. Would appreciate it someone could help me out with this. Looking at the archives I've read emails that indicate Boost has been successfully built within Scratchbox. This is probably a problem in my Scratchbox environment, but don't know how to fix it. I'll post a similar email on Scratchbox forums too. Thanks in advance. Rohit

1 0

iterator_adaptor question
by Nico Galoppo 25 Feb '06

25 Feb '06

Hi, regarding iterator_adaptor<>, I've created a custom iterator over a map as below. Basically, it allows to iterate over map values without being worried with key values. Anyway, if I would want to do something like this: typedef map<int,int> map_type; typedef map_data_iterator<map_type::iterator> map_iterator; map_type map; map_iterator it = map_data_iterator(map.begin()); for (; it != map.end(); ++map) ... I'd have to add an equal method to the map_data_iterator class that takes the base type iterator, right? I tried to do so below, but it still complains about not being able to convert: binary '!=' : no operator found which takes a left-hand operand of type 'OpenTissue::DepthFirstTesselator<Types>::prism_iterator' (or there is no acceptable conversion) I know this is probably not the right thing(tm) to do , but I basically need to be able to do this comparison for backward compatibility with deprecated code. Thanks, --nico template <class Iterator> class map_data_iterator : public iterator_adaptor< map_data_iterator<Iterator>, Iterator, typename Iterator::value_type::second_type > { typedef typename map_data_iterator::iterator_adaptor_ super_t; typedef typename Iterator::value_type pair_type; typedef typename pair_type::second_type second_type; friend class iterator_core_access; public: map_data_iterator() {} // should be explicit, but removed to give OpenTissue backwards compatibility map_data_iterator(Iterator x) : super_t(x) {} template<class OtherIterator> map_data_iterator( map_data_iterator<OtherIterator> const& r , typename enable_if_convertible<OtherIterator, Iterator>::type* = 0 ) : super_t(r.base()) {} private: second_type & dereference() const { return this->base()->second; } // added to give support for comparison with base type iterators //bool equal(Iterator const& other) const //{ // return (this->base() == other); //} //bool equal(super_t const& other) const //{ // return (*this == other); //} }; -- nico galoppo von borries @ address: 105 creel st., chapel hill comp. graphics phd. student @ north carolina, 27516 USA UNC, chapel hill @ phone: +1 (919) 962-1898 (office) @ +1 (919) 942-7609 (home) @ email: nico at cs dot unc dot edu @ homepage: http://www.cs.unc.edu/~nico --- debian linux :: vim powered

2 3

Re: [Boost-users] [mpl] newbie question
by james.jones＠firstinvestors.com 24 Feb '06

24 Feb '06

Andy Little wrote: > What can I say? I acknowledge that mpl is a monumental piece of work . > Wonderful... but far from perfect. You can say, "Sorry, that was terribly rude of me. Here's a patch and some test code so that we can work together to make MPL even better." - James

3 2

Re: [Boost-users] Serialization : unregistered_cast & otherquestions
by RIVASSEAU Jean Noel 24 Feb '06

24 Feb '06

Thanks for all your help. I have decided to try to reorganize everything into small parts as you have said, in order to better understand. I am in the process of doing this, but I have already some remarks about your comments. I have chosen the organisation principle you have said: in the class.h, nothing about the serialization is present in serialization/class_serialization.hh : I have the serialization declaration code + some traits in serialization/class_serialization.cc : I have the serialization implementation code + BOOST_EXPORT The only thing where I have not followed your advice is the presence of BOOST_EXPORT on the class_serialization.hh rather than class_serialization.cc. If I put it on the header, since I have to include the header on test.cc, one instantation of something is done while encountering BOOST_EXPORT. Later while compiling class_serialization.cc, since it encounters BOOST_EXPORT one more time another instantiation occurs and I had problems with linking (gcc 3.4 reported multiple definitions of something). I have attached a small set of code that illustrates the problem. As the code is, it will fail to compile (at least on gcc 3.4). If you just remove BOOST_EXPORT from MObject_serialization.hh and put it into MObject_serialization.cc, everything works and the test passes. I'd like to get feedback on this - did I get everything right ?? Jean-Noël Ps: I now even have a clue about why the code failed in my old design, but I am waiting until I am more sure of myself... _____ De : boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] De la part de Robert Ramey Envoyé : jeudi 23 février 2006 17:44 À : boost-users(a)lists.boost.org Objet : Re: [Boost-users] Serialization : unregistered_cast & otherquestions Without actually seeing the code, its hard for me to give intelligent advice. Lucky for you (maybe) that's not going to inhibit me from speculating. Here is what I recommend for anyone making a very large program: a) extended_type_info_no_rtti presumes that all classes serialized as pointers have been exported. Should this not be the case, you'll get the error message indicated. Double check this. b) Serilaization traits should be in the header files so that they are not "missed" anytime something like "ar << x" is invoked. Given you're situation I would recommend a file structure like the following: class.hpp - without seriaiization like you have now. serialization/class.hpp - includes class.hpp. also includes BOOST_EXPORT and any other traits for this "class". serialization/class.cpp c - includes serialization/class.hpp and includes the actual serialization code. Also this should include code instantiation for the archives that you use. Look at demo_pimpl to see how this is done. All the above code should be organized into a library. The reason is that this will generate code for all the archives mentioned but your application may not use all the archives so putting the above code in a library and linking to it will mean that your application will always have what it actuallyuses but nothing it doesn't - avoids "code bloat". Note that in compiling code for the library make sure to specify "function level linking". Take the "least derived class" - that one at the top of the class hierarchy. Make a small test program similar to the tests in the serialization library. This should be a very small job. This code can be class_test.cpp. Run this test on all archives you use. When this test passes, do the same for the other classes until something fails. This might seem to be more work - believe me its not. It will a) guarentee that you make progress toward a robust program b) give you confidence that your program has minimum of hidden bugs c) permit you to re-run the tests automatically when you make future changes. d) should a problem arise with the serialization or other library, it will give a lot more information in order to be helpful. Robert Ramey Now, the problem is where to put the serialization code for these classes. If I just write them on the implementation file (the .cc) for the class, it does not work. At run time I have always errors telling me that either the class is not exported (unregistered_class exception) or an unregistered_cast happens. The only solution I have found is to put *ALL* serialization code into the same big .cc file. If I do just that, it works. However this file is becoming enormous and has to be recompiled every time I change only *one* of the class to be serialized. It is already taking a minute to compile on a fast machine, so I must really break it up into other parts. But everytime I do that everything stops working. Have you any ideas, Robert? I am using extended_type_info_no_rtti, this may be the cause of the problem... Jean-Noël Ps: I still have the std::string bug, which is also uncomprehensible for me. _____ _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

2 1

problem with boost_unit_test : BOOST_CLASS_TEST_CASE seems no the access instance at the right address, on Mac OS X, with gcc 4.0.1/2 with optimization level > 0
by Ananda Tallur 24 Feb '06

24 Feb '06

Hello, I would like to submit a strange problem we recently discovered, when using boost_unit_test. This problem only occurs : on Mac OS X, when using gcc 4 with any optimization level other than 0 (-O, -O1, -O2, etc...). I have tested with gcc 4.0.1 (build 5250 coming with Apple XCode 2.2.1), and also gcc 4.0.2 delivered by darwinports, and the problem is the same. On the other hand, it works perfectly on Linux, with gcc 4.0.2 and optimizations. The problem : it occurs when using BOOST_CLASS_TEST_CASE. BOOST_CLASS_TEST_CASE executes a test method of a class/struct instance, so that the class/struct attributes can be used in the test. With a very simple class, named SampleTest, having only -> one int attribute "a" -> a single test function : void sampleTest (), which only displays value of "a" -> a test declared in boost test suite : BOOST_CLASS_TEST_CASE ( & SampleTest::sampleTest, instance), with instance being shared pointer to a instance of sampleTest, instanciated with a given value of "a" passed as constructor argument. It does not work on Mac OS X, with the conditions described above. Everything happens as if BOOST_CLASS_TEST_CASE was not using the correct address in memory for accessing the instance attributes data. Furthermore, the value displayed for a is wrong, but always the same, it is not random at all, which seems to mean that there is a shift in the memory adress being accessed. Below is the complete sample program, for reproducing the problem : ---- file boost_unit_test_gcc4_pb_sample.cpp --- #include <iostream> #include <boost/test/unit_test.hpp> using boost::unit_test_framework::test_suite; using boost::unit_test_framework::test_case; using namespace std; class SampleTest { public: SampleTest (int val) : a (val) { } int a; void sampleTest () { std::cout << "a : " << a << std::endl; BOOST_CHECK_EQUAL (a, 12345); } }; test_suite* init_unit_test_suite( int argc, char* argv[] ) { test_suite* test= BOOST_TEST_SUITE( "Sample test" ); boost::shared_ptr<SampleTest> instance (new SampleTest (12345)); test->add (BOOST_CLASS_TEST_CASE ( & SampleTest::sampleTest, instance)); return test; } ---- end-of-file boost_unit_test_gcc4_pb_sample.cpp --- * Command used for compiling : BOOST_PATH=<path-to-your-boost-install> /usr/bin/g++-4.0 -O2 -I${BOOST_PATH}/include -L${BOOST_PATH}/lib - lboost_unit_test_framework boost_unit_test_gcc4_pb_sample.cpp -o boost_unit_test_gcc4_pb_sample When compiled when the above command, and running the program on Mac OS X : export DYLD_LIBRARY_PATH=${BOOST_PATH}/lib ./boost_unit_test_gcc4_pb_sample The result is the following : ---- Running 1 test case...a : 13691 boost_unit_test_gcc4_pb_sample.cpp(18): error in " SampleTest::sampleTest": check a == 12345 failed [13691 != 12345] *** 1 failure detected in test suite "Sample test" --- We see that value of "a" is wrong. When compiled without optimization (-O0), and running, the result is : ---- Running 1 test case...a : 12345 *** No errors detected ---- Everything is right in this case. Has anyone some experience using Boost unit_test framework on Mac OS X, using gcc 4, and already experienced this kind of problems ? Any help would be greatly appreciated ! Regards, Anand

1 0

[statechart] Unexpected events
by David Greene 24 Feb '06

24 Feb '06

I had assumed that if a state_machine definition did not mention any reaction for a particular event in a particular state, occurrence of that event in that state would be flagged as a runtime error. It appears that instead, the event is simply dropped. Can this behavior be changed? It would be tremendously helpful for debugging purposes. Adding an error state and a bunch of transitions into it seems like overkill, especially if the cross product between states and events is large but the "in- and out-degree" of states is small. -Dave

2 2

Re: [Boost-users] [statechart] Asynchronous Machines
by Gottlob Frege 24 Feb '06

24 Feb '06

> > Date: Wed, 22 Feb 2006 10:31:06 -0600 > From: David Greene <greened(a)obbligato.org> > Subject: Re: [Boost-users] [statechart] Asynchronous Machines > To: boost-users(a)lists.boost.org > Message-ID: <43FC91CA.8060801(a)obbligato.org> > Content-Type: text/plain; charset=us-ascii > > Gottlob Frege wrote: > > > Very long answer: More correctly the problem isn't really 'cache > > coherence' in the traditional meaning of cache coherency (which is that > > the cache, for your cpu, is consistent with main memory, etc), it is the > > order of memory reads and writes, and Mutex's are guaranteed to do > > whatever is necessary to make sure all queued reads are read before you > > get the mutex lock (ie they force a memory 'acquire' barrier) and they > > make sure all writes are written before the mutex is released (a > > 'release' memory barrier). > > I understand what you're saying and agree with you in that that's the > current way hardware and software is implemented in the vast majority > of cases. > > However, the concepts of serializing access and maintaining memory > consistency and conherence are orthogonal. There have been > architectures (in academia, mostly) that require explicit software > cache control, for example. One would have to include a cache flush in > your examples. The theory is that by separating concerns the programmer > (or compiler) has more freedom to loosen up implementations based > on weaker requirements of the application, thereby gaining performance. > > We're starting to see this much more in HPC systems, for example, where > there are a multitude of synchronization primitives available with > varying semantics that imply performance tradeoffs. Some machines > cache remote memory (often under software control), others don't. > > So I agree with you in the case of the typical machine architecture, > but it won't necessarily hold in the future. Obviously you understand the problems then. But I don't understand what you don't agree with - my explanation (obviously missing some details), or whether mutexes will work in the future? I'm saying that mutexes will always do whatever is necessary. For example, the pthreads spec tries very hard to describe itself in such a way so that it will 'just work' regardless of the underlying problems. And any other mutex/thread library will also work around the problems (flushing caches, doing whatever is necessary) or else not be worth using. P.S. do you have any links to some of the more esoteric synchronization primatives? I've been looking for variations on the typical acquire/release barriers as well as systems that don't have CAS, etc. All in the hopes of making at least a start on a useful atomics library. -Dave Thanks, Tony.

3 2

member traits
by Perry Smith 24 Feb '06

24 Feb '06

I am still on my adventure to implement a library for manipulating bits for device drivers. I want to be able to define a struct or a class that has the same layout as the hardware registers and also define bits for the registers. I want to have compile time checking to make sure that I use the bit definitions with the proper register. Underneath will be something maybe called "access" classes that would pull the data from the hardware device on the bus or write it back out. Sometimes that is just a simple pointer dereference but other times it is a kernel service call. I've worked on this for a couple of weeks (off and on) and I have something that is kinda working but does not do everything that I need. All that to lead up to this question: from what I've determined so far, all this boils down to giving what is equivalent to traits to members of a class or struct. Then I can give traits to the bit fields and have a compile time assert to make sure that the traits match. My only thought so far is to give each member its own unique type and then assign traits to those types. I am wondering if that seems like a viable path or if there are alternate (better?) ways. Thank you, Perry

1 0