- Boost - lists.boost.org

[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

Thread-Safe Signals & Slots
by Braddock Gaskill 29 Jan '07

29 Jan '07

I've implemented some limited thread-safe extensions to the boost signals library for my own use. My signal_mt, connection_mt, and scoped_connection_mt classes provide some basic multi-threaded functionality, although I certainly don't pretend they are particularly mature or elegant. For the curious, my thread-safe extensions can be found at: http://braddock.com/~braddock/signals_mt/ Included is some unit testing code which provides some usage examples and reasonably good code coverage (although it is not fully stand-alone). I was curious if experienced eyes on the list could point out any serious flaws or suggestions. A multi-threaded signal concept inherently needs to be treated with some care, since the slots need to be prepared to be called from any thread -- or, preferably, signaling should be restricted by design to one thread. A particular weakness in this implementation is that the signal remains (recursively) mutex locked during the iteration through connected slot calls. I also have not added code for more than zero, one, or two parameter signals -- although it is trivial to do so. I hoped to get some feedback first (or find more bugs before I had to fix each one in 10 places). -braddock

2 1

[result_of] const-qualified function?
by shunsuke 29 Jan '07

29 Jan '07

Hi, gurus. I have one question about 'result_of': template<class F> struct forward { template<class A> // typename boost::result_of<F(A&)>::type // (1) typename boost::result_of<F const(A&)>::type // (2) operator()(A& a) const { return m_f(a); } explicit forward(F f) : m_f(f) { } private: F m_f; }; (1) or (2).. which is right? In fact, (2) fails to compile if 'F' is a function pointer type; because const function-pointer specialization is missing. Regards, -- Shunsuke Sogame

4 4

[Boost Test] request BOOST_*_CLOSE_COLLECTIONS
by Kevin Wheatley 29 Jan '07

29 Jan '07

It would be nice to be able to check collections for 'close-ness' as well as equality, whilst there I guess 'small-ness' would be good too. I just ran into this again in some of our code, of course I can roll my own loop... Thanks Kevin -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself |

3 5