- Boost-users - lists.preview.boost.org

Linker Problems with VC 7.1/ Boost 1.32 / Stlport 4.61
by Adrian Grigore 02 Aug '05

02 Aug '05

Hi, I've been happily using Boost 1.32 with Visual C++ 7.1 for a few months. Now I'd like to switch to STLPort, but can’t get my project to compile with STLPort due to linker errors (LNK2019 and LNK2001) in every boost library I use (signals, filesystem, thread). First I installed STLPort and to make sure that it is working properly with a dummy (boostless) project. Then I re-compiled boost with the stlport toolset: bjam "-sTOOLS=vc-7_1-stlport" "-sSTLPORT_PATH=C:\Programme\Microsoft Visual Studio .NET 2003\add-ons" "-sSTLPORT_VERSIONS=4.6.1" "-sPYTHON_ROOT=c:/Programme/Python24" install Last but not least, I recompiled my project (multithreaded, static runtime) which is using boost. I got 9 errors such as these: WxNonogram error LNK2001: unresolved external symbol "public: __thiscall boost::signals::detail::signal_base::signal_base(class boost::function2<bool,class boost::any,class boost::any,class _STL::allocator<class boost::function_base> > const &,class boost::any const &)" (??0signal_base@detail@signals@boost@@QAE@ABV?$function2@_NVany@boost@@V12@V?$allocator@Vfunction_base@boost@@@_STL@@@3@ABVany@3@@Z) WxNonogram error LNK2019: unresolved external symbol "bool __cdecl boost::filesystem::native(class _STL::basic_string<char,class _STL::char_traits<char>,class _STL::allocator<char> > const &)" (?native@filesystem@boost@@YA_NABV?$basic_string@DV?$char_traits@D@_STL@@V?$allocator@D@2@@_STL@@@Z) referenced in function "public: virtual bool __thiscall CMyWxApp3_wxstaticApp::OnInit(void)" (?OnInit@CMyWxApp3_wxstaticApp@@UAE_NXZ) I also defined BOOST_LIB_DIAGNOSTIC to see which libraries are linked against to. Strangely enough, it seems to link to the correct libraries as I got messages such as these: "Linking to lib file: libboost_signals-vc71-mt-sgdp-1_32.lib" and it still complains about signals not being resolved after linking. Unfortunately I do not have a clue on how to proceed. Any help would be appreciated. Thanks! :-) - Adrian

2 3

Re: [Boost-users] multi_array_ref timing issue
by Sohail Somani 02 Aug '05

02 Aug '05

Can you give me some tests? I can run them and check. Also, you can profile your object code and use kcachegrind to check which really is the bottleneck (i.e., are you passing multi_array's by value?) > -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of > Grant Goodyear > Sent: Tuesday, August 02, 2005 9:54 AM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] multi_array_ref timing issue > > > > Just as an aside, I get nearly-identical results with the > boost-1.33.0_rc1 release candidate. > -- > Grant Goodyear > web: http://www.grantgoodyear.org > e-mail: grant(a)grantgoodyear.org > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users >

2 1

How to get length of mpl::vector as an int?
by Stephen Gross 02 Aug '05

02 Aug '05

Is there a way to get the length of an mpl vector as a static int? Thanks, --Steve Stephen Gross Case Western School of Medicine Cleveland, OH "By Grabthar's hammer, by the sons of Worvan, you shall be avenged." - Dr. Lazarus

2 1

multi_array_ref timing issue
by Grant Goodyear 02 Aug '05

02 Aug '05

We have a real-space convolution code that we noticed was running notably slower in our c++ version than it was in our f90 version. So, we extracted out the key part of the code and started seeing if we could find a bottleneck. Removing multi_array_ref and using painful pointer arithmetic seems to show that the multi_array_ref's are the bottleneck: bmb24 reconstruct > g++ -v Reading specs from /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/specs Configured with: /var/tmp/portage/gcc-3.4.4/work/gcc-3.4.4/configure --enable-version-specific-runtime-libs --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/3.4.4 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.4 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.4/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.4/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/include/g++-v3 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --enable-multilib --disable-libgcj --enable-languages=c,c++,f77 --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 3.4.4 (Gentoo 3.4.4, ssp-3.4.4-1.0, pie-8.7.8) bmb24 reconstruct > g++ -O3 arraysimple.cpp bmb24 reconstruct > time a.out 1.33693e+07 6.85547e+09 real9m40.203s users9m8.390s system0m1.889s bmb24 reconstruct > g++ -O3 arraynoboost.cpp bmb24 reconstruct > time a.out 1.33693e+07 6.85547e+09 real9m401m13.103s users9m81m10.551s system0m10m0.343s Boost version: boost-1.32.0 Can anybody confirm these results, or suggest a fix? Thanks, Grant Goodyear -- Grant Goodyear web: http://www.grantgoodyear.org e-mail: grant(a)grantgoodyear.org

1 1

Fw: shared_array EXC_BAD_ACCESS
by Peter Dimov 02 Aug '05

02 Aug '05

Rene Rivera wrote: > Peter Dimov wrote: >> I'm forwarding the following post from boost-users >> >> http://lists.boost.org/boost-users/2005/08/12938.php >> >> since it describes a pretty severe configuration problem on Mac OS X >> that apparently leads to inconsistent definitions of >> BOOST_HAS_THREADS and all kinds of interesting ODR violations. > > I think that problem is fixed. The original post doesn't mention the > Boost version so it's hard to be sure. The checks for threading and > the type of target getting built is considerably more complicated now > than just the TARGET_CARBON check :-) > > It would be awesome if the original poster could test with 1.33 to > make sure it's fixed.

1 0

Re: [Boost-users] Regexp without ^ and $
by Merrill Cornish 02 Aug '05

02 Aug '05

Stuart & John, Thanks for the information. I made the dangerous assumption that I "knew" what a match would do and that it would work like Perl. Thanks again, Merrill

1 0

Re: [Boost-users] shared_array EXC_BAD_ACCESS
by Christopher Hunt 02 Aug '05

02 Aug '05

>> When UTFStringHolder is instantiated, I get an EXC_BAD_ACCESS and my >> stack trace shows that pthread_mutex_init is being called. Here's the >> complete stack trace: >> >> #0 0x90012730 in _pthread_mutex_init >> #1 0x00088424 in boost::detail::lightweight_mutex::lightweight_mutex() >> at lwm_pthreads.hpp:47 > > These things usually happen when you have inconsistent definitions of > BOOST_HAS_THREADS in the source files or libraries that form your > program. > Does the code still fail when you try it as a single self-contained > source > file? If it does, can you post a minimal example that fails? Unfortunately it is not reproducible in a single self-contained file... which is interesting isn't it... Also, I've managed successfully to have a shared_array member as part of another class's instantiation. The only difference that I see is the timing of when they're instantiated. Could it be anything to do with the initialisation of my pthread environment? (what initialises pthreads?) I'll do some experiments around this. If it is of interest, this is all being done in a Mac OS X Cocoa Objective-C environment. Cocoa likes to know when it is going multi-threaded (http://developer.apple.com/documentation/Cocoa/Conceptual/ Multithreading/articles/CocoaDetaching.html) and I do let it know, but maybe I should let it know earlier. Thanks for your help. I'll do some more experimentation around the timing of instantiation. Cheers, -C

2 4

Why Boost.Build says that subinclude, and project-root fules are unknown
by Voronkov Konstantin 02 Aug '05

02 Aug '05

Hello, All! I'm trying to build project from folder which differs from BOOST_ROOT. But it gives me error: >H:\tmp\Boost\Tutorials\sample1>bjam --clean >Jamfile:14: in load-aux >rule project-root unknown in module >Jamfile</H:/tmp/Boost/Tutorials/sample1>. >C:/Echo/Boost/boost-build/build\project.jam:310: in load-jamfile >C:/Echo/Boost/boost-build/build\project.jam:68: in project.load >C:/Echo/Boost/boost-build\build-system.jam:80: in load >C:\Echo\Boost\boost-build\kernel\modules.jam:259: in import >C:\Echo\Boost\boost-build\kernel\bootstrap.jam:120: in boost-build >C:\Echo\Boost\boost-build\boost-build.jam:1: in module scope What is the root of the error and how can I fix it? Best Regards, Voronkov Konstantin

1 0

Regexp without ^ and $
by Merrill Cornish 02 Aug '05

02 Aug '05

I am using regex_match() from Boost 1.32.0. I am well famililar with Perl's regular expression, but I got a surprise from Boost's regex_match(). My basic code is static const regex CHAR(" char "); regex_match(newSpec, CHAR) If newSpec is " char ", then it matches, of course. However, if newSpec is " char * ", it doesn't match. Hmmmm. In my Perl experience, a regex of " char " says match those six characters if found ANYWHERE in newSpec. This would mean that a Boost regex of " char " would match a newSpec of " char * ", but it doesn't seem to. If I change the regex to ".* char .*", then it matches, implying that Boost's regex of " char " is being treated as if it were Perl's "^ char $". I could add the ".*" before and after each of my (many) regular exressions. However, I'm guessing there is a match_flag_type value which would do this for me. Unfortunately, none of the match constant descriptions seem to be what I need. How should I write a Boost regex so that it would find " char " anywhere in the input string regardless of any prefix or suffix? Merrill

3 2

a few questions about boost:any
by Shishir Ramam 01 Aug '05

01 Aug '05

Hello fellow boosters! I am looking to use boost:any. While gaining an understanding of how to use it, it strikes me that the real purpose it serves is that the virtual table functionality is exposed to the user. It seems that efficiency of table lookup are then the application responsibility. My first question - Is this a reasonable understanding? I have been looking to see if tag dispatching can somehow circumvent the cost of table lookup that would be necessary, and the only thing that strikes me is to - store a type id within the type boost::any represents, - retrieve this id and either use it in an if/else structure, or a function pointer lookup in an array. A complete tag dispatch implementation seems impossible, since the type id within the boost::any structure is a run time quantity. My second question - Are there better ways to do it than an index into an array of functions? TIA. -shishir -- It is not because things are difficult that we do not dare, it is because we do not dare that things are difficult. - Seneca

1 0