- Boost-users - lists.boost.org

boost shared_ptr - thread safe and non thread safe editions
by Ren� Dalby Carlsen 24 Jul '02

24 Jul '02

Hi. Is there any easy way to get a thread safe edition of the shared_ptr (BOOST_HAS_THREADS) and a "non" thread safe edition (BOOST_DISABLE_THREADS) inside the same project? The thread safe edition of the shared_ptr is a bit slower and I would like to able to use the non thread safe shared_ptr, when I known it only be used on the same thread. As a solution I thought I could do something like this, so I would not have to edit/copy any boost .hpp file : // // MyApp.cpp // #define BOOST_HAS_THREADS #include "boost/smart_ptr.hpp" namespace boost_nothread { #define BOOST_DISABLE_THREADS #include "boost/smart_ptr.hpp" } void f() { boost::shared_ptr <int> spIntTS; // thread safe smart pointer boost_nothread::shared_ptr <int> spInt; // non thread safe smart pointer } //////// The above sample does not work - what should I do instead? Regards, René

2 3

Python: class hierarchies; return pointer to base
by Jacek Generowicz 23 Jul '02

23 Jul '02

Hi, I'm trying to use Boost.Python to create an extension module based on some existing code. Therein I have a class hierarchy which I would like to expose in a way that would make it possible to subclass any of its classes in python. I run into a problem when I try to expose C++ functions which return pointers to the base class of the hierarchy. In the minimal example I am using for testing purposes I have: // An abstract base class class abstract { ... virtual void thing() const = 0; }; // A conctrete subclass implemented in C++ class concrete : public abstract { ... virtual void thing const { ... } }; // Callback to allow happy subclassing of abstract in python class abstract_callback : public abstract { ... }; // Callback to allow happy subclassing of concrete in python class concrete_callback : public abstract { ... }; BOOST_PYTHON_MODULE_INIT(abstract) { ... python::class_builder<abstract, abstract_callback> abs_class(this_module, "abstract"); ... python::class_builder<concrete, concrete_callback> con_class(this_module, "concrete"); con_class.declare_base(abs_class); ... } This all works fine, until I try to expose to python a function such as abstract* ret_p_abs( ... ); When compiling (gcc 2.95.2) the module, I get the error no matching function for call to `py_extension_class_converters (boost::python::type<abstract *>)' I infer from comments in the source code that this is to be expected if the class in question has not been wrapped as an extension class. This makes sense, as abstract has, indeed, not been wrapped ... but I don't think that it should be; abstract_callback was created for that purpose. How should I proceed ? Thanks,

1 0

Regexp linking problems with VC++6.0 + STLPort
by Noel Llopis 22 Jul '02

22 Jul '02

I've read through all the other previous messages dealing with problems with Regexp and VC++, but I wasn't able to find a good answer for my problem. I compiled Regexp++ without any problems. I added the correct directory path for the libraries, so that happens automatically (in my case it links with boost_regex_vc6-stlport_mssd.lib (multithreaded, static run, static link, debug). However, as soon as I try to use any regexp function or class from my code, it comes back with a link error. For example, trying to use the RegExp class, I get: error LNK2001: unresolved external symbol "public: __thiscall boost::RegEx::RegEx(class _STL::basic_string<char,struct std::char_traits <char>,class _STL::allocator<char> > const &,bool)" (?? 0RegEx@boost@@QAE@ABV?$basic_string@DU?$char_trai ts@D@std@@V?$allocator@D@_STL@@@_STL@@_N@Z) bin/XXXXXX.exe : fatal error LNK1120: 1 unresolved externals Can anybody guess as to what might be wrong? I'm using VC++ 6.0 with the latest upgrades and STLPort 4.5.3. Thanks. --Noel llopis(a)comcast.net

2 3

RE: [Boost-Users] Boost Config problem - MSVC 7, boost 1.28.0
by Tom Matelich 22 Jul '02

22 Jul '02

Cool, thanks. I really hate modifying third party libraries. > -----Original Message----- > From: John Maddock [mailto:john_maddock@compuserve.com] > Sent: Saturday, July 20, 2002 5:03 AM > To: Boost-Users(a)yahoogroups.com > Subject: Re: [Boost-Users] Boost Config problem - MSVC 7, boost 1.28.0 > > > > I was running into problems with min and max being macros > when attempting > to > > port my code to .NET. When I went to look at visualc.hpp, > I saw that > > NOMINMAX was only defined when _MSC_VER <= 1200. My break > seems to have > > happened where a boost file was included, then a windows > header came in, > so > > the macros were enabled. > > > > I know we are not supposed to rely on Boost.Config in our > code, but it > sure > > is nice :). > > I've modified the config system so that NOMINMAX is defined > in the win32 > platform configuration rather than for VC6 specifically, > likewise the undefs > for min and max are in there now as well, hopefully this won't break > anything ... :-) > > John Maddock > http://ourworld.compuserve.com/homepages/john_maddock/index.htm > > > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > Access your PC just like Web Mail > http://us.click.yahoo.com/r5uw2C/zncEAA/Ey.GAA/EbFolB/TM > -------------------------------------------------------------- > -------~-> > > Info: <http://www.boost.org> > Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> > Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com> > > > Your use of Yahoo! Groups is subject to > http://docs.yahoo.com/info/terms/ > > ----------------------------------------------------------------------- DISCLAIMER: Information contained in this message and/or attachment(s) may contain confidential information of Zetec, Inc. If you have received this transmission in error, please notify the sender by return email. -----------------------------------------------------------------------

1 0

HELP, boost::thread in freebsd, run example/monitor core dumped
by wugui 22 Jul '02

22 Jul '02

system: FreeBSD 4.6 gcc: version 2.95.3 prog: example/monitor cause: recursive_mutex ? do_test<boost::recursive_mutex>(); link with: libboost_threadd.a libboost_threadds.a assertion "res == 0" failed: file "libs/thread/build/../src/condition.cpp", line 347 link with: libboost_thread.a libboost_threads.a OK, BUT ! I'M NOT SURE THAT !

1 1

test_pool_alloc.cpp will not compile with CW 8.1
by Ray S. Gallimore 20 Jul '02

20 Jul '02

Sorry if double posted (originally sent via gmane.comp.lib.boost.user but never showed up). To get test_pool_alloc.cpp to compile with CW 8.1 (Windows), I had to define BOOST_NO_PROPER_STL_DEALLOCATE. Once compiled, the test does run ok. Ray Gallimore [Non-text portions of this message have been removed]

1 0

Boost Config problem - MSVC 7, boost 1.28.0
by Tom Matelich 20 Jul '02

20 Jul '02

I was running into problems with min and max being macros when attempting to port my code to .NET. When I went to look at visualc.hpp, I saw that NOMINMAX was only defined when _MSC_VER <= 1200. My break seems to have happened where a boost file was included, then a windows header came in, so the macros were enabled. I know we are not supposed to rely on Boost.Config in our code, but it sure is nice :). ----------------------------------------------------------------------- DISCLAIMER: Information contained in this message and or attachment(s) may contain confidential information of Zetec, Inc. If you have received this transmission in error, please notify the sender by return email. -----------------------------------------------------------------------

3 3

Boost compilation, Windows 98 SE and gcc
by J.Flenter 19 Jul '02

19 Jul '02

Hi, I'm trying to compile boost with gcc (the version currently distributed with cygwin: 2.95.3-5 and not the pre-release version 3.1.1) but when I run bjam with either -sTOOLS=gcc-stlport or sTOOLS=gcc I get an error: gcc-Link-action actions too long (max 1023): g++ -Wl,--export-all-symbols -Wl,--exclude-symbols,_bss_end__:_bss_start__: _data_end__:_data_start__ -Wl,--out-implib,libs\regex\build\bin\boost_regex. dll\ gcc-stlport\debug\runtime-link-dynamic\boost_regex.lib -g -shared -o "libs\reg ex\build\bin\boost_regex.dll\gcc-stlport\debug\runtime-link-dynamic\boost_re gex. dll" "libs\regex\build\bin\boost_regex.dll\gcc-stlport\debug\runtime-link-dyn amic\c_regex_traits.obj" "libs\regex\build\bin\boost_regex.dll\gcc-stlport\debug \runtime-link-dynamic\c_regex_traits_common.obj" "libs\regex\build\bin\boost_reg ex.dll\gcc-stlport\debug\runtime-link-dynamic\cpp_regex_traits.obj" "libs\regex\ build\bin\boost_regex.dll\gcc-stlport\debug\runtime-link-dynamic\cregex.obj" "li bs\regex\build\bin\boost_regex.dll\gcc-stlport\debug\runtime-link-dynamic\fi leit er.obj" "libs\regex\build\bin\boost_regex.dll\gcc-stlport\debug\runtime-link-dyn amic\posix_api.obj" "libs\regex\build\bin\boost_regex.dll\gcc-stlport\debug\runt ime-link-dynamic\regex.obj" "libs\regex\build\bin\boost_regex.dll\gcc-stlport\de bug\runtime-link-dynamic\regex_debug.obj" "libs\regex\build\bin\boost_regex.dll\ gcc-stlport\debug\runtime-link-dynamic\regex_synch.obj" "libs\regex\build\bin\bo ost_regex.dll\gcc-stlport\debug\runtime-link-dynamic\w32_regex_traits.obj" "libs \regex\build\bin\boost_regex.dll\gcc-stlport\debug\runtime-link-dynamic\wide _pos ix_api.obj" "libs\regex\build\bin\boost_regex.dll\gcc-stlport\debug\runtime-link -dynamic\instances.obj" "libs\regex\build\bin\boost_regex.dll\gcc-stlport\debug\ runtime-link-dynamic\winstances.obj" -lstlport_cygwin_stldebug Am I doing something wrong? Some may have noticed that I have already posted something on this newsgroup, for which I already had a working version of boost, that's true. Unfortunately I ran in some problems using inherited classes and I found on the internet some bug reports on the Visual Studio 6.0 and the error: error C2275: 'referenceCounter' : illegal use of this type as an expression, this happens at the line linkedList_class.declare_base(referenceCounter); That is the reason why I switched to GCC. However, any help would be appreciated. Jacco Flenter

3 3

Syntax errors when compiling for WIN64
by bufo19312 19 Jul '02

19 Jul '02

Environment boost_1_28_0, Intel 6.0, target = _WIN64. The InterlockedIncrement et.al. interfaces in boost/detail/winapi need to be changed as follows, since they are now intrinsics. Technically, I suppose the guard should be _M_IA64, rather than _WIN64, since other target processors+compilers may not support compiler intrinsics for these interfaces. $ diff -c winapi.hpp winapi_original.hpp *** winapi.hpp Thu Jul 18 08:11:11 2002 --- winapi_original.hpp Fri Mar 15 16:00:10 2002 *************** *** 55,82 **** ulong_ptr_type SpinCount; }; - #if defined( _WIN64 ) - - extern "C" long_type __cdecl _InterlockedIncrement(long_type volatile *); - extern "C" long_type __cdecl _InterlockedDecrement(long_type volatile *); - extern "C" long_type __cdecl _InterlockedExchange(long_type volatile *, long_type); - - #pragma intrinsic(_InterlockedIncrement) - #pragma intrinsic(_InterlockedDecrement) - #pragma intrinsic(_InterlockedExchange) - - inline long_type InterlockedIncrement( long_type volatile* lp ) { return _InterlockedIncrement( lp ); } - inline long_type InterlockedDecrement( long_type volatile* lp ) { return _InterlockedDecrement( lp ); } - inline long_type InterlockedExchange( long_type volatile* lp, long_type l ) { return _InterlockedExchange( lp, l ); } - - #else - extern "C" __declspec(dllimport) long_type __stdcall InterlockedIncrement(long_type volatile *); extern "C" __declspec(dllimport) long_type __stdcall InterlockedDecrement(long_type volatile *); extern "C" __declspec(dllimport) long_type __stdcall InterlockedExchange(long_type volatile *, long_type); - #endif - extern "C" __declspec(dllimport) void __stdcall Sleep(dword_type); extern "C" __declspec(dllimport) void __stdcall InitializeCriticalSection(critical_section *); --- 55,64 ---- Tim Fender

2 1

RE: [Boost-Users] Re: thread & containers
by Jim.Hyslop 19 Jul '02

19 Jul '02

bill_kempf (williamkempf(a)hotmail.com) wrote: > --- In Boost-Users@y..., Herve Blanc <blanc@s...> wrote: > > If not again, why and how do you deal with the problem then? > > Use an external mutex to achieve the proper lock granularity. Herve, for further reading, I suggest Herb Sutter's books "Exceptional C++" and "More Exceptional C++". I think you'll find the section in MXC dealing with copy-on-write and thread-safety particularly enlightening. -- Jim

1 0