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

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

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

24 Feb '06

I forgot the code promised in last email sorry... _____ 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

1 0

using boost libs in a managed C++ dll (vc7.1)
by KonT 24 Feb '06

24 Feb '06

Hi, This is my second attempt to get some help on this issue... Can anyone provide a pointer to the steps required to using a boost lib in a managed C++ dll. I am using boost 1.33.1 with vc7.1. Boost libs were built with default options using bjam (bjam "-sTOOLS=vc-7_1" install). I am able to build a dll, but .net app using the dll crashes when it attempts to call code from the boost libs (in my case date). Building either managed or unmanaged static libs & using in a managed c++ app work fine, so I suspect that the problem is due to dll loader issues. I have tried linking with static & dynamically linked libs (CRT & boost), but the result is the same. I have built the dll with the /NO ENTRY switch & added manual calls to initialise the CRT. This removes the vc warnings, but the dll still cause the app to crash. Thanks in advance Kon Tantos

1 0

[Boost.date-time] Problem with leak with time_from_string? Incorrect use, or other problem?
by Stewart Loving-Gibbard 24 Feb '06

24 Feb '06

We have observed leaky behavior while using the Boost.date-time libraries, with time_from_string specifically. The leak is simple to replicate for us, on both Win32 (Visual Studio .NET 2005) and on Linux (GCC 3.x). This code snippet leaks for us, at a rate of about a MB every 10 seconds: while (true) { time_from_string("2002-01-20 23:59:59"); } As far as I can tell, ptime (what time_from_string returns) is an object that doesn't need to be deallocated with a Boost API function. So, why are we leaking here? Did we compile Boost incorrectly? Is there a way to link Boost that can trigger a leak? (from_iso_string() also appears to leak for us, by the way, while to_iso_string does not. It looks like time_from_string and to_iso_string are in the same neighborhood, so I'm betting they share the same fix.) Any and all help appreciated. This is a blocking issue for us. Stewart

3 4

Re: [Boost-users] [spirit] should be a very simple problem, but I'm stumped
by Nat Goodspeed 23 Feb '06

23 Feb '06

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of Todd Day > Sent: Thursday, February 23, 2006 9:35 AM > To: boost-users(a)lists.boost.org > Subject: [Boost-users] [spirit] should be a very simple problem,but I'm > stumped > > I have to look for strings of the form (including the > quotes) > "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.

1 0

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

23 Feb '06

> Date: Thu, 23 Feb 2006 11:45:00 -0500 > From: Kim Barrett <kab(a)irobot.com> > Subject: Re: [Boost-users] [statechart] Asynchronous Machines > To: boost-users(a)lists.boost.org > Message-ID: <p06230901c02396579da8(a)[192.168.1.102]> > Content-Type: text/plain; charset="us-ascii" ; format="flowed" > > At 2:08 AM -0500 2/23/06, Gottlob Frege wrote: > >All in the hopes of making at least a start on a useful atomics library. > > Are you familiar with the atomic operations library at > http://www.hpl.hp.com/research/linux/atomic_ops > > Yep, thanks. That's probably the level I'm thinking of, but I'd just like to see a few more libraries and know what some of the edges are. Every library I see tends to say that they avoid handling the esoterics, and I would as well, but I'd like to know better what the esoterics are so that they can later be added without redoing everything, if at all possible.

1 0