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

Boost.Statechart and Simulink
by Derek Ditch 22 Nov '08

22 Nov '08

I was wondering if there were any known issues with compiling using Matlab's mex compiler (which in turn uses and links with gcc) and using Boost.Statechart. When I implemented my statechart, I tested it using a separate main() file and it works 100%. When I compile using mex into a Matlab MEX file, I seem to lose the functionality of the event triggers. I've tried several things to figure out what is happening, but all I can ascertain is that if I use the iterators state_begin() and state_end() to access all internal states, the loop never executes. I tried to dereference state_begin(), but got a segfault. My initial approach was to use the state_downcast<>(), but this didn't work in SImulink either. My final suspicion was that it had something to do with the extern "C" business, but admittedly, I don't understand the effects of this statement other than how the symbol appears in the library (i.e. avoiding mangling). I get this same behavior on OS X 10.5 w/ gcc 4.0.1 as well as on Linux x86_64 with gcc 4.2.4. If anyone wants to have my Simulink model to test, I could send that as well. I've attached the following files: ctrl_machine.[ch]pp - My state machine implementation/declaration. main.cpp - My test program air_controller.cpp - The C++ SFunction implementation used in Simulink. mex uses the following compilation steps with gcc/g++ -> g++-4.2 -c -I/opt/matlab/extern/include -I/opt/matlab/simulink/include -DMATLAB_MEX_FILE -ansi -D_GNU_SOURCE -fPIC -fno-omit-frame-pointer -pthread -DMX_COMPAT_32 -O -DNDEBUG "ctrl_machine.cpp" -> g++-4.2 -c -I/opt/matlab/extern/include -I/opt/matlab/simulink/include -DMATLAB_MEX_FILE -ansi -D_GNU_SOURCE -fPIC -fno-omit-frame-pointer -pthread -DMX_COMPAT_32 -O -DNDEBUG "air_controller.cpp" -> gcc-4.2 -c -I/opt/matlab/extern/include -I/opt/matlab/simulink/include -DMATLAB_MEX_FILE -ansi -D_GNU_SOURCE -fexceptions -fPIC -fno-omit-frame-pointer -pthread -DMX_COMPAT_32 -O -DNDEBUG "/opt/matlab/extern/src/mexversion.c" -> g++-4.2 -O -pthread -shared -Wl,--version-script,/opt/matlab/extern/lib/glnxa64/mexFunction.map -Wl,--no-undefined -o "ctrl_machine.mexa64" ctrl_machine.o air_controller.o mexversion.o -Wl,-rpath-link,/opt/matlab/bin/glnxa64 -L/opt/matlab/bin/glnxa64 -lmx -lmex -lmat -lm -lm ----- Thanks, Derek Ditch

2 2

Re: [Boost-users] boost test with assert()
by Hicham Mouline 21 Nov '08

21 Nov '08

Hello, Any ideas re this issue? Can the assert from <cassert> be caught somehow? Regards,

3 6

std::vector and default constructor
by peter_foelsche＠agilent.com 21 Nov '08

21 Nov '08

It would be helpful to have something like std::vector which allows one to pass some argument which is in turn passed to the constructor of every element so that not the default constructor is being called. This would be helpful for e.g. objects located in memory created by memory mapped files. Peter "The first point (using an init() function in preference to a constructor) is bogus. Using constructors and exception handling is a more general and systematic way of dealing with resource acquisition and initialization errors. This style is a relic of pre-exception C++." -- Stroustrup

2 3

[test] new g++ compilation warnings on trunk
by Robert Mecklenburg 21 Nov '08

21 Nov '08

Compiling against the boost trunk I'm getting hundreds of these: g++ -Wall -Wextra -Wno-missing-braces -g -ftrapv -DBOOST_1_36_0 -Iboost-1_37 -MMD -MP -DUSE_TRAPV -c -o src/test/BlobTest.o src/test/BlobTest.cpp boost/test/floating_point_comparison.hpp:224: warning: 'boost::test_tools::<unnamed>::check_is_close' defined but not used boost/test/floating_point_comparison.hpp:246: warning: 'boost::test_tools::<unnamed>::check_is_small' defined but not used Any chance we can fix this? If you need a tester for g++ 4.2.3, I can do it. Thanks, -- Robert

5 5

[Test] Compilation problem
by Greg Ravikovich 21 Nov '08

21 Nov '08

Hello, I'm using boost 1.37 and have the following problem: A blank cpp file containing only: #include <boost/test/test_case_template.hpp> fails to compile on vc9. However a blank cpp containing: #include <boost/test/unit_test.hpp> #include <boost/test/test_case_template.hpp> compiles fine. A file containing #include <boost/test/test_case_template.hpp> #include <boost/test/unit_test.hpp> won't compile as well. Is this intentional? Or is there a missing include directive inside test_case_template? Thanks, Greg

2 1

boost test with assert()
by Hicham Mouline 21 Nov '08

21 Nov '08

Hello, I use this test class: class SimulationIdTest { public: static void TestDestructorAfterAddRemoveSimulation(); static void TestDestructorAfterAddRemoveContractSimulation(); static void AddTests(boost::unit_test::test_suite* suite); }; TestDestructorxxx() are written so that the code inside, indirectly, throws an assert(false) (not my code) I would like to test that indeed, it does throw the assert(false). void SimulationIdTest::AddTests(boost::unit_test::test_suite* suite) { suite->add(BOOST_TEST_CASE(TestDestructorAfterAddRemoveSimulation), 1); } I tried the above by saying there would be 1 failure, however the test suite stops on that failure ( the assert(false) ), even the second argument of suite->add is 1. Is there a solution to this case? Regards,

2 1

tweaking the review process (was: signals2 review results)
by Stjepan Rajko 21 Nov '08

21 Nov '08

Hi Paul, On Fri, Nov 21, 2008 at 1:00 AM, Paul Baxter <pauljbaxter(a)hotmail.com> wrote: > On Thu, Nov 20, 2008 at 11:40 PM, vicente.botet <vicente.botet(a)wanadoo.fr> wrote: >> I would like to make some suggestion to improve the review management: > > <valid points snipped> > > Whilst I understand your points, unlike our day job, people do have other > more pressing commitments and, for many, the extensive effort given to > reviewing boost libraries is time given in an ad-hoc manner. > > Whilst it is good to have the timetable and a specific method for submitting > reviews, I don't think we need to go further and be more regimented. The > existing flexibility is a positive part of the process, IMHO. I also tend to prefer flexibility when people are volunteering their time. > > [ I do have problems with some libraries actually getting to the point of > review before interest, maturity of interface or implementation are right, > but that doesn't apply here and has been covered in previous discussions.] > I think I was guilty of this / have been bit by this myself. Anyway, there are two things that I think can help here: * requiring a certain number of committed reviewers before scheduling a review * the review manager being more active in examining the library before the actual review About the latter - in both reviews I managed, there was a number of issues (e.g., documentation shortfalls) that came up during the review that I, as review manager, could have discussed privately with the author beforehand had I done a more thorough review of the library. These issues could have been fixed before a review was scheduled, and the reviews could have been more focused on other issues. The review process page states: "The Review Manager... Checks the submission to make sure it really is complete enough to warrant formal review. See the Boost Library Requirements and Guidelines. If necessary, work with the submitter to verify the code compiles and runs correctly on several compilers and platforms." Well, in both cases I had examined the library, tried it on several compilers, read the docs, glanced at the implementation, etc. But it wasn't a thorough review. I think, had I actually gone through the reviewer's list of questions and wrote a full review, it would have given the authors some idea of possible areas that can be improved before the review (being careful not to react prematurely in possibly contentious areas where the opinion of just one person is not enough). Doing something like this would require additional effort from the review manager, but I think it would result in a much better review (and one where it is possibly easier to make a decision because there are fewer remaining problems). Best, Stjepan

2 2

error LNK2019: :assertion_failed wrt boost::detail::basic_timed_mutex::lock
by Joseph A. Marks 21 Nov '08

21 Nov '08

Hi! Could anyone please help me out with the following error? : error LNK2019: unresolved external symbol "void __cdecl boost::assertion_failed(char const *,char const *,char const *,long)" (?assertion_failed@boost@@YAXPBD00J@Z) referenced in function "public: void __thiscall boost::detail::basic_timed_mutex::lock(void)" (?lock@basic_timed_mutex@detail@boost@@QAEXXZ) Thanks in Advance! Joseph A. Marks PHONE: 612-788-9658 e-mail: josephamarks(a)yahoo.com

1 0

tweaking the review process (was: signals2 review results)
by Stjepan Rajko 21 Nov '08

21 Nov '08

On Fri, Nov 21, 2008 at 2:06 AM, Robert Jones <robertgbjones(a)gmail.com> wrote: > On Fri, Nov 21, 2008 at 6:40 AM, vicente.botet <vicente.botet(a)wanadoo.fr> > wrote: >> >> * I had notice only at the end of the the review that the review tokes >> place on two mailing lists (devel ans user). Maybe this is usaual on Boost >> reviews but I was not aware. It will be more transaparent if all the reviews >> were posted to the same mailing list, maybe a specific one should be >> created. >> > > A specific maillist for reviews strikes me as an excellent idea. In Joels' > review > of his Phoenix 2.0 library there were some outstanding contributions from > people I don't see posting very often, but who apparently feel moved to do > important stuff like reviewing. These comments did much to give me some > historical context, and understanding of structure, alternatives and > implementation > decisions. These will inevitably be lost in the general background noise of > on going developments, and it would be nice to have a clear place for these > review comments. > Perhaps it would be sufficient to *strongly stress* that any post related to the ongoing review should have [review] in the subject line? (although that doesn't address the problem of having the review on both the dev and user lists...) Stjepan

1 0

asio: i/o cancellation under Linux/ARM broken?
by Stefan Sichler 21 Nov '08

21 Nov '08

Hello, I'm developing a major application using asio that is ported to Windows x86/ia64, Linux x86 and Linux on an ARM processor. It seems i/o cancellation is broken on Linux/ARM, which is a major problem for me. I added a small test case below for demonstration. On Windows, the test case will work correctly, running the loop 10 times. On Linux, it will hang after the first loop pass. Please help! (boost 1.37, Debian Linux 2.6.27) Regards, Stefan Sichler >> code follows: #ifdef WIN32 #define BOOST_ASIO_ENABLE_CANCELIO #endif #include <iostream> #include <boost/asio.hpp> using namespace std; using namespace boost::asio; using namespace boost::asio::ip; // boost asio cancellation testcase bool g_io_completed= false; void completionHandler(const boost::system::error_code& err, size_t bt) { cout<<"completed err="<<err<<" bt="<<bt<<endl; g_io_completed= true; } int main(int argc, char* argv[]) { io_service ios; udp::socket sock(ios); sock.open(udp::v4()); sock.bind(udp::endpoint()); cout<<"note: if this test hangs, the cancel test failed!"<<endl; char buf[64]; for (int i=0; i<10; ++i) { cout<<"loop start i="<<i<<endl; g_io_completed= false; sock.async_receive(buffer(buf),completionHandler); for (int t=0; t<1000; ++t) // spend some time.... ios.poll(); sock.cancel(); while (!g_io_completed) // wait for completion handler ios.poll(); cout<<"loop end i="<<i<<endl; } cout<<"cancel test completed successfully!"<<endl; return 0; }

1 0