- Boost - lists.boost.org

Re: [boost] regression looks much better now
by Ames Andreas 30 Jan '07

30 Jan '07

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock > Sent: Tuesday, January 30, 2007 11:39 AM > Subject: Re: [boost] regression looks much better now > > Roland Schwarz wrote: > > 3) Failing test tests: > > This is a DLL issue. In file > > boost/test/test/unit_test_suite_impl.hpp > > the compiler coplains about base class test_unit > > not defined, despite it is. The compiler seems > > to have problems to see this class as defined. > > Something (possibly templated memebers?) are > > prohibiting this when the class is flagged as > > _declspec(dllexport). > > *) Is this a known issue? > > *) Can we safely flag these tests as n/a? > > A comment in libs/test/build/Jamfile.v2 > > let me believe so. > > This one is truely weird: it looks like an obvious compiler > issue to me. I haven't seen the compiler messages, so just a wild guess: Could this be related to http://msdn2.microsoft.com/ru-ru/library/twa2aw10(VS.80).aspx (item 4, i.e. C4275)? NB: This issue is also documented at least for vc 7.1. cheers, aa -- Andreas Ames | Programmer | Comergo GmbH | Voice: +49 711 13586 7789 | ames AT avaya DOT com

2 1

[1.34.0] borland tlib fixes
by Vladimir Prus 30 Jan '07

30 Jan '07

I've fixed the attached to increase the magic 'page size' parameter to tlib. The borland.jam has two places where tlib was invoked -- cygwin case and non-cygwin case, and the former passed the "right" value while the latter passed nothing. With the too small value, tlib would fail with various funny messages. I'd appreciate another borland tests re-run. Thanks, Volodya

2 1

regression looks much better now
by Roland Schwarz 30 Jan '07

30 Jan '07

After having applied the suggestions from John Maddock the errors have dropped considerably. 1) A summary for other regression runners: *) download spirit-1.6.3.zip from http://sourceforge.net/project/showfiles.php?group_id=28447 *) unpack it to DRIVE:\spirit-1.6.3 *) Add to user-config.jam : using msvc : 6.5 : "C:/Program Files/Microsoft Visual Studio/VC98/Bin/cl.exe" : <cxxflags>-I"DRIVE:/spirit-1.6.3/boost" ; using borland : 5.8.2 : "C:/Programm Files/Borland/BDS/4.0/Bin/bcc32.exe" : <cxxflags>-I"DRIVE:/spirit-1.6.3/boost" ; 2) The remaining borland errors: @nicola: Does the spirit-1.6.3 still need a patch, or is this the static link issue? 3) Failing test tests: This is a DLL issue. In file boost/test/test/unit_test_suite_impl.hpp the compiler coplains about base class test_unit not defined, despite it is. The compiler seems to have problems to see this class as defined. Something (possibly templated memebers?) are prohibiting this when the class is flagged as _declspec(dllexport). *) Is this a known issue? *) Can we safely flag these tests as n/a? A comment in libs/test/build/Jamfile.v2 let me believe so. Roland

2 1

[wave] Recent check-ins broke wave on Tru64/CXX/RC_1_34_0
by Markus Schöpflin 30 Jan '07

30 Jan '07

The compilation of wave actually succeeds, but linking libboost_wave-d-1_34.so.1.34.0 complains about multiply defined symbols. See http://tinyurl.com/ysqbex for further details. This has been broken recently (not more than 2 weeks ago) and I noticed that there are some check-ins related to wave in this time frame. Does that ring a bell with anyone? BTW, there are two references to 1.34 in the name of the generated library. Is that how it's supposed to be? Isn't the 1.34.0 suffix after .so somehow wrong? Markus

5 20

[1.34.0] Documentation/Script updates needed in various libraries
by Thomas Witt 30 Jan '07

30 Jan '07

Hi, The following list was compiled by Vladimir Prus (Thanks!). It shows files that potentially need updating with respect to the build v2 transition. Could the respective library authors please check and report back. Thanks Thomas > libs/date_time/xmldoc/buildinfo.xml > > Requires update to V2. > > libs/iostreams/doc/installation.html > > Needs update. > > libs/python/doc/building.html > > Needs update. > > libs/python/doc/tutorial/doc/html/python/hello.html > libs/python/doc/tutorial/doc/tutorial.qbk > libs/python/doc/v2/faq.html > libs/python/example/README > > Did not look. > > libs/regex/doc/install.html > > Needs update. > > libs/serialization/doc/archive_reference.html > > Needs update. > > libs/serialization/test/runtest.bat > libs/serialization/test/runtest.ksh > libs/serialization/test/runtest.sh > > Need update. > > libs/signals/doc/tutorial.xml > > Possibly needs update. > > libs/statechart/test/RunTests.bat > > Needs update. > > libs/statechart/example/BuildExamples.bat > > Needs update. > > libs/test/doc/components/prg_exec_monitor/compilation.html > > Needs update. > > libs/test/doc/components/utf/compilation.html > > Needs update. > > libs/test/test/auto-link-test/run_bjam.bat > > Needs update. > > libs/thread/doc/build.xml > > Needs update. > > more/separate_compilation.html > > -- Thomas Witt witt(a)acm.org

8 11

Re: [boost] mcs::units informal review request
by Steven Watanabe 30 Jan '07

30 Jan '07

AMDG Noah Roberts wrote: > Matthias Schabel wrote: > > >> Any input on optimizing the library would be most welcome - I expect >> that it should >> be possible to have code using quantities run exactly as fast as for >> built in types, >> but that remains to be proven... >> > > So far that seems to run true if you use the highest optimization level > for g++. In VC++ I'm finding otherwise. > The cause is probably that quantity defines a destructor. It does exactly what the compiler generated one does, so there is no reason to define it explicitly. Just comment it out. msvc refuses to inline any function that returns a type with a non-trivial destructor when exceptions are enabled. In Christ, Steven Watanabe

3 2

insert_const, nested_iterator
by Ben FrantzDale 30 Jan '07

30 Jan '07

I've been using Boost increasingly in my work and am loving it. There are two utilities I've beens surprised Boost lacks: First, I would like to see an "insert_const" metafunction that would work like this: template <typename T> struct insert_const<T*> { typedef typename add_const<T>::type* type; }; That is, it would insert a const into the thing pointed to by a pointer type. (I am interfacing with a C-style interface to C++ code. The interface passes around "pFoo" and "pBar" – pointers to Foos and Bars. I've used the above metafunction to create typedefs for const_pFoo and const_pBar, like so: typedef typename<insert_const<pFoo> >::type const_pFoo; typedef typename<insert_const<pBar> >::type const_pBar; Would this be a desirable addition? Second, I often find myself wanting to iterate over every element in a nested container. For example, a vector<list<double> >. I've made a partly-functional nested_iterator class that models ForwardIterator. My implementation defaults to use ".begin()" and ".end()" to find the inner range, but can be adapted with a function object. Has anyone considered adding this sort of iterator to Boost? —Ben

2 2

[date_time] marking tests as expected failures on HP-UX/aCC
by Boris Gubenko 29 Jan '07

29 Jan '07

Four date_time library tests rely on undefined behaviour: 17.4.3.6 - Other functions [lib.res.on.functions] -2- In particular, the effects are undefined in the following cases: ... o if an incomplete type (basic.types) is used as a template argument when instantiating a template component. These tests fail on HP-UX/aCC because default STL on this platform -- Rogue Wave library rw libstd v2.2 -- does not allow this usage (Rogue Wave library on Tru64: rw libstd v2.0, as well as gnu libstdc++ and STLport, allow this). Attached a reproducer. In June 2006, I discussed this issue with Jeff Garland. I was going to look at creating a patch, but did not have any chance. According to Jeff, "it sounds like a major bit of work" and now it is, obviously, too late for 1.34. Besides, there is an enhancement request for Rogue Wave library (now Apache stdcxx) to allow this usage, so, perhaps, there will be no need to mess with the boost date_time library at all. My understanding from a mail from the 1.34 release manager is that while boost libraries' code is frozen for non-essential fixes, explicit failures markup file can be updated. So, can the four date_time library tests below be marked as expected failures on HP-UX/aCC (toolset name="acc") in both 1.34 and the HEAD: testdate_input_facet_dll testtime_input_facet testlocal_time_input_facet testdate_input_facet Thanks, Boris x.cpp ----- #include <map> struct string_parse_tree { typedef std::multimap<char, string_parse_tree> ptree_coll; ptree_coll m_next_chars; }; string_parse_tree x; bash-2.03$ aCC -V aCC: HP aC++/ANSI C B3910B A.06.10 [Mar 22 2006] bash-2.03$ aCC -c x.cpp "/opt/aCC/include_std/utility", line 100: error #2070: incomplete type is not allowed second_type second; ^ detected during: ... bash-2.03$ aCC -c -I $STLPORT_ROOT/stlport x.cpp bash-2.03$ g++ -c x.cpp bash-2.03$ cxxosf.zko.hp.com> cxx -V Compaq C++ V7.1-006 for Compaq Tru64 UNIX V5.1B (Rev. 2650) Compiler Driver V7.1-006 (cxx) cxx Driver cxxosf.zko.hp.com> cxx -c x.cpp cxxosf.zko.hp.com>

1 0

Re: [boost] boost_unit_test_framework cannot be built as DLL withmsvc-6.5
by Sohail Somani 29 Jan '07

29 Jan '07

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Roland Schwarz > Is this a known issue? > Are there any work-arounds possible? Maybe one solution is to link to the unit test library statically?

1 0

[graph] adjacency_list serialization
by David Keller 29 Jan '07

29 Jan '07

Hi, I would like to report some issues in RC_1_34_0 (and persisting in the latest CVS-version) concerning an inconsequent usage of boost::serialization::make_nvp during the serialization of adjacency_list which lead to compilation errors when serializing to and from xml-archives (boost::serialization::xml_iarchive and boost::serialization::xml_oarchive). The problem arises due to missing nvp-wrappers for the serialization of edges and properties. You can find a patch containing my changes to the latest CVS-version attached to this message. Furthermore, the inclusion of <boost/archive/text_iarchive.hpp> in <boost/pending/property.hpp> is apparently no longer required there. I've run an xml-ed version of the test in libs/graph/test/serialize.cpp which works on my platform. However, it would be nice to rebuild this test to include all the archives provided by boost::serialization. Regards, David Keller

2 1