December 2005 - Boost - lists.preview.boost.org

Review Request: pimpl
by Asger Mangaard 23 Dec '05

23 Dec '05

Hi, I would like to resubmit the pimpl library for a formal review. The suggested library can be found in the sandbox's root. Regards, Asger Mangaard

2 1

Re: [boost] bug in signals library? - segmentation fault (onlylinked) -> exit(11) called
by Oliver.Kowalke＠infineon.com 23 Dec '05

23 Dec '05

Hi, Strange - the segmentation fault disappears if I link with the debug-version of libboost_signals (-lboost_signals-gcc-d-1_33_1)! It seams to me that some assert statements contain required code (removed in release version if signals)?! >> I get an segmentation fault if I try to link against >> libboost_signals-gcc-1_33_1 or libboost_signals-gcc-mt-1_33_1! >> The application consist only of an empty main function and the binary is >> linked against the signals library. >> I've appended an output (tusc.out) of tusc (trace unix system calls) >> which indicates, that exit(11) is called and so a core dump created. > >Can you run the program under gdb debugger, and when hittin segfault >produce >backtrace with the "backtrace" command. That will be more usefull, in any >case, then syscall trace. I'm not familiar with gdb! What I did (hopefully correct): [src]$ /opt/langtools/bin/gdb32 test HP gdb 5.2 for PA-RISC 1.1 or 2.0 (narrow), HP-UX 11.00 and target hppa1.1-hp-hpux11.00. Copyright 1986 - 2001 Free Software Foundation, Inc. Hewlett-Packard Wildebeest 5.2 (based on GDB) is covered by the GNU General Public License. Type "show copying" to see the conditions to change it and/or distribute copies. Type "show warranty" for warranty/support. .. (gdb) run Starting program: /eda-home/kowalke/Projects/test/debug/src/test Program received signal SIGSEGV, Segmentation fault si_code: 0 - SEGV_UNKNOWN - Unknown Error. 0xc0017cd8 in <unknown_procedure> () (gdb) backtrace #0 0xc0017cd8 in <unknown_procedure> () warning: Attempting to unwind past bad PC 0xc0017cd8 #1 0xc0027400 in <unknown_procedure> () #2 0xc0027400 in <unknown_procedure> () Error accessing memory address 0x3e7: Bad address.

3 2

[Boost-bugs] [ boost-Patches-1169756 ] Threads add additional assert to aid in debugging join()
by SourceForge.net 23 Dec '05

23 Dec '05

Patches item #1169756, was opened at 2005-03-24 09:55 Message generated for change (Comment added) made by hxpro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1169756&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: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: hxpro (hxpro) Assigned to: Nobody/Anonymous (nobody) Summary: Threads add additional assert to aid in debugging join() Initial Comment: see discussion at http://article.gmane.org/gmane.comp.lib.boost.user/10093 ---------------------------------------------------------------------- >Comment By: hxpro (hxpro) Date: 2005-12-23 13:59 Message: Logged In: YES user_id=1211438 Closed its done ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-04-02 23:03 Message: Logged In: NO added in Revision: 1.20, Tue Mar 29 16:19:32 2005 UTC by glassfordm ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1169756&group_… ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Patches-1115576 ] Patch 1.32 IRIX MIPSPro 7.4.1 [Test Bind Program Options]
by SourceForge.net 23 Dec '05

23 Dec '05

Patches item #1115576, was opened at 2005-02-03 17:15 Message generated for change (Comment added) made by hxpro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1115576&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: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: hxpro (hxpro) Assigned to: Nobody/Anonymous (nobody) Summary: Patch 1.32 IRIX MIPSPro 7.4.1 [Test Bind Program Options] Initial Comment: Some simple fixes to make the build work... ---------------------------------------------------------------------- >Comment By: hxpro (hxpro) Date: 2005-12-23 13:58 Message: Logged In: YES user_id=1211438 Looks like its all done... ---------------------------------------------------------------------- Comment By: hxpro (hxpro) Date: 2005-02-09 09:54 Message: Logged In: YES user_id=1211438 Yes, its a templated getline that is using a bare '\n' instead of a specialised form for wchar_t or calling widen() etc. Kevin ---------------------------------------------------------------------- Comment By: Vladimir Prus (vladimir_prus) Date: 2005-02-09 09:07 Message: Logged In: YES user_id=321498 I've applied the program_options patches. Thanks. Does the compiler has the same getline problem as Comeau -- calling wide version without explicit L'\n' fails? ---------------------------------------------------------------------- Comment By: hxpro (hxpro) Date: 2005-02-07 11:08 Message: Logged In: YES user_id=1211438 N.B. The boost bind patch is now in revision 1.40 in CVS see http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/bind.hpp?r1=1.40 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1115576&group_… ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Patches-1388901 ] [concept_check.hpp] remove unused variable warning in msvc
by SourceForge.net 23 Dec '05

23 Dec '05

Patches item #1388901, was opened at 2005-12-23 13:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1388901&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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: hxpro (hxpro) Assigned to: Nobody/Anonymous (nobody) Summary: [concept_check.hpp] remove unused variable warning in msvc Initial Comment: simple enough fix ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1388901&group_… ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[signal] performance
by Vladimir Prus 23 Dec '05

23 Dec '05

Hi, I've just tried to measure performance of Boost.Function and Boost.Signals using the following simple program: #include <boost/function.hpp> #include <boost/signals.hpp> using namespace std; void do_nothing() {} int main() { boost::function<void (void)> f = do_nothing; void (*pf)(void) = &do_nothing; boost::signal<void (void)> s; s.connect(&do_nothing); for(int i = 0; i < 10000000; ++i) s(); return 0; } and trying calls to 's()', 'pf()' and 'f()'. The timings are, on an Athlon 1700 with g++ 3.3.5 and -O3: Function pointer: 0.05 secs Boost.Function: 0.2 secs Boost.Signals: 9.8 secs Boost.Function is 4 times slower than function pointer, which seems decent for me (not that I mind further improvement). But Boost.Signals is nearly 50 times slower that Boost.Function, and nearly 200 times slower than function pointer. Any chance this will be improved? Say, I don't care about combining the results of signals invocation, or any connection tracking -- I just want to use boost::signals as more convenient variant of vector<boost::function>. Is it possible to have some preprocessor define that throws away all advanced functionality? Or a base class, say "lightweight_signal" that has only basics? TIA, Volodya

7 10

[spirit] [1.33.1] file_iterator needs workaround for VC8
by MB 23 Dec '05

23 Dec '05

Hi, Under VC8 Express Edition: #include <functional> #include <boost/spirit/iterator/file_iterator.hpp> // greeting namespace your { struct plus { }; } namespace my { using namespace your; struct A : plus { }; // error C2872: 'plus' : ambiguous symbol } I don't know what happens, but 'using namespace std;' at <iterator/impl/file_iterator.ipp:line41> does something bad. Simplified Code: namespace standard { struct plus { }; } // almost like 'using namespace standard' under vc8? namespace fileiter_impl { // 'using-directive' here using namespace standard; // 'class template' here template< typename CharT > class std_file_iterator { }; } namespace your { struct plus { }; } namespace my { using namespace your; struct A : plus { }; // error C2872: 'plus' : ambiguous symbol } Regards, MB p-stade.sourceforge.net

1 0

bug in signals library? - segmentation fault (only linked) -> exit(11) called
by Oliver.Kowalke＠infineon.com 23 Dec '05

23 Dec '05

Hello, I get an segmentation fault if I try to link against libboost_signals-gcc-1_33_1 or libboost_signals-gcc-mt-1_33_1! The application consist only of an empty main function and the binary is linked against the signals library. I've appended an output (tusc.out) of tusc (trace unix system calls) which indicates, that exit(11) is called and so a core dump created. System: HP/UX 11.11 PA-RISC Compiler: gcc-3.4.4 (with posix thread support) Code: int main( int argc, char* argv[]) { return 0; } Compiled with: if g++ -DHAVE_CONFIG_H -I. -I/eda-home/kowalke/Projects/test/src -I.. -I/opt/boost/include/boost-1_33_1 -O0 -g3 -MT test.o -MD -MP -MF ".deps/test.Tpo" -c -o test.o /eda-home/kowalke/Projects/test/src/test.cpp; then mv -f ".deps/test.Tpo" ".deps/test.Po"; else rm -f ".deps/test.Tpo"; exit 1; fi /bin/sh ../libtool --tag=CXX --mode=link g++ -O0 -g3 -o test -L/opt/boost/lib test.o -lboost_signals-gcc-1_33_1 mkdir .libs g++ -O0 -g3 -o test test.o -L/opt/boost/lib -lboost_signals-gcc-1_33_1 <<tusc.out>>

2 1

asio pooled_list/hash_map implementation
by christopher baus 23 Dec '05

23 Dec '05

I've been playing around with ways to remove some of the hits to the global allocator from asio/detail/reactor_op_queue.hpp, and decided to try an alternative approach to pooling. Instead of overriding STL allocators or global new/delete, I decided to implement pooled lists in terms of lists themselves. I take advantage of the fact that list::splice doesn't realloc nodes to move value data between the active and free lists during insert and erase operations. Chris's hash_map stores the value data in a std::list. I made that a template parameter, which allowed me to optionally specify the pooled_list. The implementation is here: http://baus.net/static/hash_map.hpp http://baus.net/static/pooled_list.hpp http://baus.net/static/pooled_hash_map.hpp This doesn't address the bigger problem of the handler allocation, but pre-allocing of the hash_map on *nix makes me a bit happier with the implementation. christopher

2 1

Re: [boost] Typeofand mpl(was Interest in dimension/unit-checking library?)
by Andy Little 23 Dec '05

23 Dec '05

"Andy Little" <andy(a)servocomm.freeserve.co.uk> wrote in message news:... > Hi Arkadiy, > > Its late and I'll have to reply on the rest of your post later. Meanwhile > enclosed is a small sample of the error output, which happens when I comment > out > registration for boost::mpl::math::reduced_rational in my registration Sorry I meant boost::mpl::math::simplified_rational rather than reduced_rational in my last post regards Andy Little

1 0