- Boost - lists.boost.org

[polity_ptr]smart_ptr_test passes, but with SIGSEGV during "clean-up"
by Larry Evans 30 Apr '05

30 Apr '05

The test passes, but during program "clean-up", a segmentation violation occurs. Here's the gdb session: GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /home/evansl/prog_dev/boost-release/boost_1_32_0/bin.v2/sand-box/lje/libs/fields_visitor/test/gcc/debug/smart_ptr_test Running 13 test cases... *** No errors detected Program received signal SIGSEGV, Segmentation fault. 0x00000011 in ?? () (gdb) bt #0 0x00000011 in ?? () #1 0x08083098 in boost::checked_delete<boost::unit_test::report_formatter> (x=0x80a8c00) at checked_delete.hpp:34 #2 0x0807dc75 in ~scoped_ptr (this=0x80a870c) at scoped_ptr.hpp:77 #3 0x4005339d in __static_initialization_and_destruction_0 (__initialize_p=0, __priority=65535) at ../../../../../libs/test/src/unit_test_result.cpp:297 #4 0x4005343a in global destructors keyed to _ZN5boost9unit_test16unit_test_result4Impl6m_headE () at ../../../../../libs/test/src/unit_test_result.cpp:599 #5 0x400435e0 in __do_global_dtors_aux () from /home/evansl/prog_dev/boost-release/boost_1_32_0/bin.v2/libs/test/build/gcc/debug/boost_unit_test_framework.so #6 0x4005d076 in _fini () from /home/evansl/prog_dev/boost-release/boost_1_32_0/bin.v2/libs/test/build/gcc/debug/boost_unit_test_framework.so #7 0x4000c4f6 in _dl_init () from /lib/ld-linux.so.2 #8 0x4019cae2 in exit () from /lib/libc.so.6 #9 0x40186dce in __libc_start_main () from /lib/libc.so.6 #10 0x08066151 in _start () at ../sysdeps/i386/elf/start.S:102 (gdb) up #1 0x08083098 in boost::checked_delete<boost::unit_test::report_formatter> (x=0x80a8c00) at checked_delete.hpp:34 Anyone else encounter this problem? David or Jonathan, I'll try to narrow the problem down (after all, it may be in the boost_unit_test_framework ), but just thought I'd give others a "heads-up".

2 2

Re: [boost] Re: como toolset failures
by JOAQUIN LOPEZ MU?Z 30 Apr '05

30 Apr '05

----- Mensaje original ----- De: Bronek Kozicki <brok(a)rubikon.pl> Fecha: Sábado, Abril 23, 2005 9:50 pm Asunto: Re: [boost] Re: como toolset failures > Rene Rivera wrote: > > > Is this specific files? > > > > I ask because there's already a facility in the como-win32 > toolset for > > removing the --a option by specifying that certain files with > > <no-warn>file.cpp > > I'd say that this problem seems to cripple most test results. But > not > all. The flag you mention should be set for all files that > directly or > indirectly include any of Windows headers. Which I suppose is > rather > large set of files. Maybe it would be good to temporarily (for one > or > two days) remove --a globally and then see results; my computer is > running tests continously. This would give some idea how many > errors > might be due to Windows headers included in strict mode. Obviously > this > will not resolve all problems ;) as como does not support DLLs, > which > also means that boost.thread won't work anyway. > > Before you do that, let me comment on this: the situation is probably not as bad as it seems --many libs are actually completely Windows-unaware and its associated tests fail only because they use Boost.Test, which internally includes some Windows headers. These libs are: algorithm/minmax algorithm/string assign crc disjoint_sets format functional/hash io iostreams lambda logic (tribool) math multi_array multi_index numeric/conversion numeric/interval pool property_map ptr_container random range regex serialization tokenizer tuple variant So, if we fix the problem with Boost.Test we'll get a much higher success rate. In its turn, the problem with Boost.Test seems to lie in that it includes (directly or indirectly, I don't know) the file boost/detail/interlocked.hpp, which fails as shown in http://tinyurl.com/73vvo. So I'd say fixing boost/detail/interlocked.hpp would drastically lower the failure count and would give us a much clearer view of where we really are wrt to Comeau support. Just my 2c. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

12 43

[pointer container] copyability
by David Abrahams 29 Apr '05

29 Apr '05

I had this disagreement with Thorsten in Lillehammer (or was it Oxford?) but he was unimpressed with my arguments. I was wondering what Boost as a whole would think: My Thesis: the library should support copying and assignment of pointer containers using the usual copy/assignment syntax, rather than only allowing a copy via a clone() function. Rationale: Not being able to copy and assign pointer containers is an arbitrary restriction that limits usefulness and expressivity. The argument Thorsten gives against copyability is that the elements would have to be clone()d rather than copied, which is expensive because there's a dynamic allocation per element. I don't get it; we don't arbitrarily prohibit copying of std::vector<std::string> even though that incurs a dynamic allocation per element. Example: Consider std::pair<int,some_pointer_container>. Almost nothing works. IIUC, it's not copyable, can't be initialized, and can't be clone()d. -- Dave Abrahams Boost Consulting www.boost-consulting.com

12 61

[ptr_container] ptr_begin & family
by JOAQUIN LOPEZ MU?Z 29 Apr '05

29 Apr '05

Hello, If I'm understanding the Boost.PointerContainer docs, ptr_begin(), ptr_end() etc. are provided so that certain mutating std algorithms can be used on pointer containers. But wouldn't it be more convenient to provide a memfun like ptr_iterator make_ptr_iterator(iterator); for obtaining a ptr_iterator from a regular iterator? This way, one could easily use std algorithms not only with [ptr_begin(),ptr_end()), but also with any other range (for instance, those obtained from equal_range()). With this memfun, the ptr_begin() familiy would be kind of redundant. Just an idea... Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

boost::program_options
by daniel.egloff＠zkb.ch 29 Apr '05

29 Apr '05

Dear boost list It has been discussed several times already that boost::program_options throws an error if an unknown option is encountered. However, for command line options there is a boolean flag to handle unknown option (presumably?) In program_options/details/cmdline.hpp : cmdline(int argc, const char*const * argv, int style, bool allow_unregistered = false); However, common_command_line_parser::run(), when constructing a cmdline object does not forward this flag. I suggest that you change the signature of the run() method to forward that flag, and modify the code section in program_options/src/parsers.cpp current version: parsed_options common_command_line_parser::run() const { parsed_options result(m_desc); detail::cmdline cmd(m_args, m_style); cmd.set_additional_parser(m_ext); if (m_desc) { set<string> keys = m_desc->primary_keys(); for (set<string>::iterator i = keys.begin(); i != keys.end (); ++i) { const option_description& d = m_desc->find(*i); char s = d.short_name().empty() ? '\0' : d.short_name ()[0]; ........... new suggestion: parsed_options common_command_line_parser::run(bool allow_unregistered) const { parsed_options result(m_desc); detail::cmdline cmd(m_args, m_style, allow_unregistered); cmd.set_additional_parser(m_ext); if (m_desc) { set<string> keys = m_desc->primary_keys(); for (set<string>::iterator i = keys.begin(); i != keys.end (); ++i) { const option_description& d = m_desc->find(*i); char s = d.short_name().empty() ? '\0' : d.short_name ()[0]; ........... Does this allow then parsing cmd line option strings which contain unknown options without throwing exceptions? Comment very welcome. Freundliche Grüsse Daniel Egloff Zürcher Kantonalbank, VFEF Josefstrasse 222, 8005 Zürich Tel. +41 (0) 44 292 45 33, Fax +41 (0) 44 292 45 93 Briefadresse: Postfach, 8010 Zürich, http://www.zkb.ch ___________________________________________________________________ Disclaimer: Diese Mitteilung ist nur fuer die Empfaengerin / den Empfaenger bestimmt. Fuer den Fall, dass sie von nichtberechtigten Personen empfangen wird, bitten wir diese hoeflich, die Mitteilung an die ZKB zurueckzusenden und anschliessend die Mitteilung mit allen Anhaengen sowie allfaellige Kopien zu vernichten bzw. zu loeschen. Der Gebrauch der Information ist verboten. This message is intended only for the named recipient and may contain confidential or privileged information. If you have received it in error, please advise the sender by return e-mail and delete this message and any attachments. Any unauthorised use or dissemination of this information is strictly prohibited.

4 5

[1.33.0] Feature freeze tonight
by Douglas Gregor 29 Apr '05

29 Apr '05

At midnight tonight (Friday) the main trunk/CVS HEAD is feature-frozen and only bug fixes may be committed. New features should go on a separate development branch. We have > 700 regressions and > 3000 failures showing up in the regression tests. Library authors, please review the regression test summaries for your libraries and start fixing bugs. If there are bugs that cannot be fixed for release (due to broken compilers, the need for huge changes to the library, etc.), mark them as expected failures or mark the library as "unusable" in status/explicit-failures-markup.xml. I've updated the list of primary platforms for this release, which includes all newer versions of GCC, CodeWarrior, Visual C++, and Intel compilers. If all bugs can't be fixed, focus on the compilers in the "Release View" in the regression tests. Let's fix those bugs! Doug

8 23

Re: [Boost-testing] Re: [thread] test_read_write_mutex breaks regressiontesting
by Caleb Epstein 29 Apr '05

29 Apr '05

OK, after seeing two of these tests continue to perform poorly and hang in some cases, I decided it was time to break out the big guns: Purify. It found a number of problems with test_mutex and test_read_write_mutex, which seem to be triggered by Boost.Test making use of a string after it has been freed. Attached is the Purify output from test_mutex and test_read_write_mutex. -- Caleb Epstein caleb dot epstein at gmail dot com

6 11

FOEACH macro review in progress
by Gennadiy Rozental 29 Apr '05

29 Apr '05

Hi, everybody Just a reminder that FOREACH macro review crossed it's equator and there left 3 days until it's finished. So if you are interested to participate don't hesitate and do so. No pressure, of course - there is still time. Regards, Gennadiy

1 0

[Ann] Proposed Boost.TR1 library: first complete version now available.
by John Maddock 29 Apr '05

29 Apr '05

As some of you already know, I've been working on producing a Boost implementation of the Technical Report on C++ Library Extensions, the first full version is now available from: http://boost-sandbox.sourceforge.net/vault/index.php?&direction=0&order=&di… The documentation can also be viewed online at: http://freespace.virgin.net/boost.regex/tr1/doc/html/tr1.html For those new to the TR, the following are supported in this release: Reference Wrappers Smart Pointers Class template result_of. Function template mem_fn. Function Object Binders. Polymorphic function wrappers. Type Traits. Random Number Generators and Distributions. Tuples. Tuple Interface to std::pair. Fixed Size Array. Hash Function Objects. Regular Expressions. Complex Number Algorithm Overloads. Complex Number Additional Algorithms. The following are not yet supported, but will be as soon as hash-tables make it into Boost: Unordered Associative Set (Hash Table). Unordered Associative Map (Hash Table). The following do not currently have Boost-licence compatible implementations and are not supported: Mathematical Special Functions. C99 Math Functions. Finally, note that I may split the complex number stuff out into a separate submission (I'll post another message about this). As ever, comments are most welcome. John.

6 19

tuple patch (constructing from a pair)
by John Maddock 29 Apr '05

29 Apr '05

The following simple patch to tuple_basic.hpp allows tuples to be constructed from std::pairs (there is already an assignment operator, but the copy constructor is missing for some reason, and is required for TR1 conformity). RCS file: /cvsroot/boost/boost/boost/tuple/detail/tuple_basic.hpp,v retrieving revision 1.28 diff -r1.28 tuple_basic.hpp 627a628,636 > template <class T, class U> > tuple(const std::pair<T, U>& p) > : inherited(p.first, p.second, detail::cnull(), detail::cnull(), > detail::cnull(), detail::cnull(), detail::cnull(), > detail::cnull(), detail::cnull(), detail::cnull()) > { > BOOST_STATIC_ASSERT(length<tuple>::value == 2);// check_length = 2 > } > Is it acceptable to add this? Many thanks, John Maddock.

10 49