- Boost - lists.boost.org

[repost: help with codewarrior 9.4/5 needed] ptr_container issue
by Thorsten Ottosen 06 Mar '06

06 Mar '06

Hi, I really need someone to look at the regression for codewarrior. I suspect it will be fairly easy to find the error. Thanks -Thorsten

1 0

Fw: VisualAge C++: any testers?
by Michael Wong 06 Mar '06

06 Mar '06

Stephen, there is no support for V1R6 and it has not been tested with any release of Boost. The zSeries compiler is now officially up to V1R7. However, it is possible that a future version of the zSeries compiler will be supporting some future combination of Boost. But I can't reveal the exact combination yet. For now, our support is primarily aimed at V8 on pSeries (AIX and Linux) with Boost 1.32.0. Each release of the compiler will be tested with one version of boost. If you have more questions about specific support, please contact me directly ad I will forward you to the correct parties. Thanks. Michael Wong XL C++ Compiler kernel Development IBM Canada Ltd., C2/KD2/8200/MKM 8200 Warden Avenue Markham, Ontario L6G 1C7 W:905-413-3283 F:905-413-4839 http://www.ibm.com/software/awdtools/ccompilers/ http://www.ibm.com/software/awdtools/fortran/ XL Overview http://www-1.ibm.com/support/docview.wss?uid=swg27005175&aid=1 Optimization http://www-1.ibm.com/support/docview.wss?uid=swg27005174&aid=1 XL C/C++ for Mac OS X http://www-1.ibm.com/support/docview.wss?uid=swg27005176&aid=1 XL Fortran for Mac OS X http://www-1.ibm.com/support/docview.wss?uid=swg27005173&aid=1 ----- Forwarded by Michael Wong/Toronto/IBM on 03/06/2006 02:53 PM ----- Stefan Slapeta <stefan(a)slapeta.com> Sent by: boost-bounces(a)lists.boost.org 03/02/2006 08:05 AM Please respond to boost To boost(a)lists.boost.org cc Subject Re: [boost] VisualAge C++: any testers? David Abrahams wrote: > > I note at > http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/summar… > there are no results for VisualAge C++. We're generally reluctant to > apply patches to support any given compiler if there isn't someone > running tests, so we can verify that it makes things better and that > we haven't introduced regressions. Michael told me in Lillehammer > that y'all were running the tests with the results upload step > disabled. If that's the case, you could just start uploading the > results to us on a regular basis and it would be much easier to > support your compiler. > and how about IBM C++ Compiler? AFAIK this is a completely different product, no? z/OS V1R6 C/C++ __COMPILER_VER__=0x41060000 __LIBREL__=0x41060000 __TARGET_LIB__=0x41060000 We planning to use this one on our zOS mainframe and I would also like to run the regression tests. Stefan _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[concept_check] Uncalled const_constraints
by Daniel James 06 Mar '06

06 Mar '06

Hi, A couple of the const_constraints methods aren't called. Patch attached. Daniel

1 0

[python] exec test question
by Vladimir Prus 06 Mar '06

06 Mar '06

Dave, in Boost.Python testsuite, there's test 'exec' defined like this: run ../test/exec.cpp <lib>../build/boost_python : # program args : exec.py : # requirements $(PYTHON_PROPERTIES) <define>BOOST_PYTHON_STATIC_LIB <define>BOOST_PYTHON_STATIC_MODULE Is static linking to Boost.Python intended here specifically, say, because the test will never work with dynamic linking, or just to test static linking? I'm asking because in V2, that uses dynamic linking in this test, the following link error is produced: exec.obj : error LNK2019: unresolved external symbol "class boost::python::api::object __cdecl boost::python::exec( See: http://tinyurl.com/hxo2t I'm about to change V2 Jamfile to use static linking, but wanted to check with you that static linking is indeed required and that the above error is not V2 fault. Thanks, Volodya

2 1

1.34 - When is branch-for-release?
by Beman Dawes 06 Mar '06

06 Mar '06

Any schedule yet? --Beman

2 1

[Boost-bugs] [ boost-Bugs-1444293 ] Calling subgraph::global_to_local on a root graph
by SourceForge.net 06 Mar '06

06 Mar '06

Bugs item #1444293, was opened at 2006-03-06 09:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1444293&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jeremy Siek (jsiek) Summary: Calling subgraph::global_to_local on a root graph Initial Comment: When g is a root subgraph, then g.global_to_local(g.local_to_global(v)) will cause an error. In Fact, the mapping m_local_vertex is not maintained for root subgraphs, so global_to_local and find_vertex would not work correctly. Thanks for fixing it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1444293&group_… ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Bugs-1444271 ] Calling subgraph::global_to_local on a root graph
by SourceForge.net 06 Mar '06

06 Mar '06

Bugs item #1444271, was opened at 2006-03-06 08:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1444271&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jeremy Siek (jsiek) Summary: Calling subgraph::global_to_local on a root graph Initial Comment: When g is a root subgraph, then g.global_to_local(g.local_to_global(v)) will cause an error. In Fact, the mapping m_local_vertex is not maintained for root subgraphs, so global_to_local and find_vertex would not work correctly. Thanks for fixing it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1444271&group_… ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

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 06 Mar '06

06 Mar '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

2 1

Any interest in a portable bitfields?
by Emile Cormier 06 Mar '06

06 Mar '06

First, I'd like to thank everyone who contributed to this wonderful library. We use Boost at work, and I'd like to contribute back. I've come up with a portable mechanism that allows the declaration of bitfields much like the way you do in C++. The syntax for using these bitfields is the same as that of C++ bitfields. My solution doesn't suffer from the ambiguity in C++ where you don't know whether the first bitfield starts at the most significant or least significant end of the word. It also doesn't suffer from the problem in C++ bitfields where the compiler can arbitrarily decide to align bitfields along word boundaries. This solution has been very useful to me when dealing with hardware registers and with 16-bit color formats. I am aware of the existance of std::bitset, but it doesn't handle groups of bits like bitfields do. If there's interest, I'll post some code here. Emile Cormier -- Emile Cormier emilecormier(a)mailcan.com

5 4

[typeof] missing entry from main page etc.
by Joaquín Mª López Muñoz 06 Mar '06

06 Mar '06

Hello, Seems like Boost.Typeof has not yet its entry in various pages as it should: /index.html /libs/libraries.htm /doc/Jamfile.v2 (quickbook generated docs) Wasn't this lib going to be released with Boost 1.34? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1