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

difference b/w regex lib files
by Green, Jason M NSWCDL, W33 08 Apr '09

08 Apr '09

I have a number of boost libs that I built (not being sure which one I really needed). I understand the difference b/w them, with the exception of two. All of the libs are libboost_regex..lib except 2 which are just boost_regex...lib What is the difference between the 2? Jason

1 0

[Boost-Users][interprocess]ERROR_ACCESS_DENIED when removing a message_queue
by Laurence Chambenois 07 Apr '09

07 Apr '09

Hi, I'm a beginner with boost, so please don't throw things at me ... I'm using boost message_queue in a sample program, on Windows, that just does : - create the message_queue - remove the message_queue It works fine, if my program does this : try { message_queue mq1(create_only, "toto", 10, 100); } catch (interprocess_exception &err) { return -1; } message_queue::remove("toto"); but if it does : message_queue *mq1=0; try { mq1 = new message_queue(create_only, "toto", 10, 100); } catch (interprocess_exception &err) { return -1; } message_queue::remove("toto"); then the remove return ERROR_ACCESS_DENIED (on tthe DeleteFile call). I don't understand why. Is somebody can tell me what is wrong with my code ? Thanks for your reply.

4 3

interprocess windows_shared_memory implementation
by Brent Arias 07 Apr '09

07 Apr '09

The documentation repeatedly states that "windows_shared_memory has no kernel persistence and is destroyed when all processes using that shared memory are gone." But I'm trying to find out what exactly is used for the implementation of winows_shared_memory? Is it implemented internally as a Windows named pipe? Is it based on using ReadProcessMemory? Anyone know? Brent Arias Software Architect Lumension Security(tm) Tel ~ (602) 692-8088 Fax ~ (480) 970-6323 brent.arias(a)lumension.com<mailto:brent.arias@lumension.com>

3 2

[Serialize] Serialize just the base class of polymorphic pointers
by Brandon Aubie 07 Apr '09

07 Apr '09

I have a base class BASE that stores data. It has a virtual function (empty in base class) that determines how this data is calculated, but there's no data stored in the derived classes. In my program, I'll load a pluging that is based on BASE and implements the function to calculate the data. Right now I have BOOST_EXPORT_CLASS in the plugin header files and I serialize boost::serialization::base_object<BASE>(*this) in the derived class. This lets me save the serialization to file just fine. When I load it back in though, my application isn't aware of the plugins (I'm just analyzing the data). But I don't need the plugins, since I just need the data. So when I try to load in my serialization, I get an "unregistered class" exception. Here's how it works /*************** CODE ******************/ class BASE { public: vector<double> data; virtual calculate() {}; private: friend class boost::serialization::access; template<class Archive> void serialize(Archive &ar, const unsigned int version) { ar & data; } } class Plugin: public BASE { public: virtual calculate() { /* do stuff */ } private: friend class boost::serialization::access; template<class Archive> void serialize(Archive &ar, const unsigned int version) { ar & boost::serialization::base_object<BASE>(*this); } } BOOST_CLASS_EXPORT(Plugin) /*************** CODE ******************/ Class Plugin is loaded dynamically at runtime via dlopen() on linux. So I have a BASE* that points to an instance of A. When I load in the serialized data though, I don't really care about A and would rather just have a BASE* that points to an instance of BASE. Since there's no data described in A. Can I do this somehow? Thanks

2 1

Re: [Boost-users] [mpl]... is there an mpl::string
by raindog＠macrohmasheen.com 07 Apr '09

07 Apr '09

L$$m$Ll$l$l$ ------Original Message------ From: Eric Niebler Sender: boost-users-bounces(a)lists.boost.org To: boost-users(a)lists.boost.org ReplyTo: boost-users(a)lists.boost.org Sent: Apr 7, 2009 10:21 AM Subject: Re: [Boost-users] [mpl]... is there an mpl::string Noah Roberts wrote: > Eric Niebler wrote: >>>>> Andy Stevenson wrote: >>>>>> >>>>>> I recall some discussion of there being an mpl::string >>>>>> template..... Can't see it in the mpl library. Is it elsewhere? >> >> It has been added to trunk as of revision 52208: >> >> https://svn.boost.org/trac/boost/changeset/52208 >> >> No doubt the regression tests will reveal portability problems. Once >> they have been worked out, we can move this to release. > > Why is this better than a metafunction c_str< Sequence >? > > typedef mpl::vector_c<char, 'h', 'e', 'l', 'l', 'o'> str; > > template < char const* sz > > struct x > {}; > > x< c_str<str>::value > test; > > Is there some reason that's not possible or is prone to problems avoided > by mpl::string? That is certainly a valid design. It's somewhat subjective, but IMO multi-character literals give a nicer compile-time string interface. Consider: // With mpl::vector_c mpl::vector_c<char, 'h','e','l','l','o',' ','w','o','r','l','d'> // With mpl::string mpl::string<'hell','o wo','rld'> Neither will win a beauty contest, but my preference is strongly for the latter. -- Eric Niebler BoostPro Computing http://www.boostpro.com _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users Sent from my Verizon Wireless BlackBerry

1 0

[program_options] Specify the same flag multiple times
by KSpam 07 Apr '09

07 Apr '09

I would like to be able to specify a flag multiple times on the command line. For instance, imagine a program that has two levels of verbosity. The first level of verbosity would be activated by specifying "-v" on the command line, and the second level of verbosity would be activated by specifying "-vv" or "-v -v" on the command line. Display verbose print statements: myProgram -v Display very verbose print statements: myProgram -vv In digging through the documentation, it is not evident to me how I can accomplish this with Boost.Program_Options. Any help would be appreciated. Thanks, Justin

1 0

building Boost with -fPIC on x86_64 linux box
by Francois Mauger 07 Apr '09

07 Apr '09

Hi boosters, He is my problem: I have a AMD 64 Linux box with boost installed on it, particularly with the Boost.Python component. Boost version is 1.34.1 (an old one but the same problem occurs with new 1.38.0 as explained below). also gcc version is 3.4.6. I use the standard: ./configure --with-xxxx; make; make install; sequence to build/install the libs. Unfortunately I cannot figure out if the -fPIC is activated while compiling the code... and I don't know how to check the PIC status from the resulting .so files (it is possible and does it make sense? I'm not an expert with this concept). I only know that if I missed the -fPIC flag on this system, I have linker errors. Next step, I have my own 'datatools' library with some classes using Boost stuff. I use plain makefiles for it and I garantee the -fPIC flags is activated to generated my 'libdatatools.so' shared library. Finally, I try to build a Boost.Python wrapper for my classes, trying to link against the 'libdatatools.so' file and 'libboost-xxxx.so' stuff. [Note this procedure works perfectly under 32 bits ubuntu system with gcc 4 and boost 1.34.1] Unfortunately I get this nasty well known error: >>> g++ datatools.cc ... -I.../sw/boost/install-1_38_0-Linux-x86_64-gcc34/include/boost-1_38 -I/usr/local/include/python2.5 -fno-strict-aliasing -DN DEBUG -g -O3 -Wall -I.../sw/datatools/pro/include -I.-shared -fPIC -O -DBOOST_PYTHON_DYNAMIC_LIB -L../Linux-x86_64/lib -ldatatools -lboost_iostreams-gcc34-mt -lboost_filesystem-gcc34-mt -fPIC -L.../sw/boost/install-1_38_0-Linux-x86_64-gcc34/lib -lboost_python-gcc34-mt -lboost_serialization-gcc34-mt -L/usr/local/lib/python2.5/config -lpthread -ldl -lutil -lpython2.5 -lm -o datatools.so /usr/bin/ld: /usr/local/lib/python2.5/config/libpython2.5.a(abstract.o): relocat ion R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/python2.5/config/libpython2.5.a: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [datatools.so] Error 1 <<< So what is the problem? I used -fPIC for my classes and I used -fPIC during the Boost-Python wrapping procedure. Does it mean the Boost library itself has not been compiled with -fPIC despite the fact that it is recommended/mandatory with 64 bits architecture. Or does it mean there is something wrong with 'libpython2.5.a' which is provided by the sysadmin and out of my privilege scope? It seems this kind of issue has already been addressed before but scanning the list archives left me rather confused with no clear solution/hint. I tried to enforce the -fPIC flags adding the following line in user-config.jam with boost 1.38.0: >>> using gcc : : : <cxxflags>-fPIC ; <<< But it did not help... I'd really appreciate any hints about this issue. Thanks a lot. regards frc -- François Mauger Département de Physique - Université de Caen Basse-Normandie courriel/e-mail: mauger(a)lpccaen.in2p3.fr tél./phone: 02 31 45 25 12 / (+33) 2 31 45 25 12 fax: 02 31 45 25 49 / (+33) 2 31 45 25 49 Adresse/address: Laboratoire de Physique Corpusculaire de Caen (UMR 6534) ENSICAEN 6, Boulevard du Marechal Juin 14050 CAEN Cedex FRANCE

4 4

libboost_date_time: undefined reference to __sync_fetch_and_add_4
by Carsten Raas 07 Apr '09

07 Apr '09

Hello! I built a (complete) Boost 1.38 library with the Intel compilers 10.1.021, 11.0.073, and 11.0.081 for an EM64T (x86_64) Linux architecture. But I end up with the same problem for all builds: the shared version of libboost_date_time cannot be linked to this simple demo program: # cat conftest.cpp ----------------------------------------------------------------- #include <boost/date_time/date_generators.hpp> int main () { const char *ptr = boost::date_time::nth_as_str(0); return 0; } ----------------------------------------------------------------- # icpc -V Intel(R) C++ Intel(R) 64 Compiler Professional for applications running on Intel(R) 64, Version 11.0 Build 20090131 Package ID: l_cproc_p_11.0.081 ----------------------------------------------------------------- Static linking: # icpc -I /opt/boost/1.38/intel/include conftest.cpp \ /opt/boost/1.38/intel/lib/libboost_date_time.a => Works. ----------------------------------------------------------------- Shared linking: # icpc -I /opt/boost/1.38/intel/include conftest.cpp -L /opt/boost/1.38/intel/lib -lboost_date_time /opt/boost/1.38/intel/lib/libboost_date_time.so: undefined reference to `__sync_fetch_and_add_4' ----------------------------------------------------------------- Shared linking with gcc: # g++ -I /opt/boost/1.38/intel/include conftest.cpp \ -L /opt/boost/1.38/intel/lib -lboost_date_time /opt/boost/1.38/intel/lib/libboost_date_time.so: undefined reference to `__sync_fetch_and_add_4' collect2: ld returned 1 exit status ----------------------------------------------------------------- Shared linking with gcc to libraries compiled with gcc itself: # g++ -I /opt/boost/1.38/gcc/include conftest.cpp \ -L /opt/boost/1.38/gcc/lib -lboost_date_time => Works. ----------------------------------------------------------------- I have been googling around for a while, but all I found was related to GCC sync primitives (e.g. sync_lock_test_and_set, sync_fetch_and_add) and different architectures (armel, sparc, etc.). I also tried the workaround with #define BOOST_SP_USE_PTHREADS in boost/config/user.hpp, without success. I also checked 1.37 and today's SVN version, but they show the same problems. Any hints what I should look at next? Best regards, -Carsten

4 9

[threads] recursive shared_mutex
by joaquin＠tid.es 07 Apr '09

07 Apr '09

Hi, As the docs do not explicitly say otherwise, I guess I must assume that boost::shared_mutex is not recursive with respect to unique ownership, that is, the following behavior ensues: shared_mutex mutex; lock_guard<shared_mutex> lock1(mutex); lock_guard<shared_mutex> lock2(mutex); // DEADLOCK Is this so? In case boost::shared_mutex is indeed non-recursive, I've read the following assertion on Hinnant's paper N2406 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2406.html ): "A recursive shared mutex could be built upon shared_mutex if desired, but this is not proposed." Does anyone has a reference on how to construct a recursive shared_mutex from a non-recursive one? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Boost, GCC, TR1 question
by Anthony Foglia 07 Apr '09

07 Apr '09

We've stumbled across an incompatiblity in mixing TR1 stuff from GCC 4.3 and Boost. The smallest test case is simply #include <tr1/array> #include <boost/tr1/tuple.hpp> This fails because GCC's array declares and specializes the GCC's tuple_size and tuple_element, while boost/tr1/tuple.hpp by default uses ::boost::fusion::tuple_size and tuple_element. It appears that defining BOOST_HAS_GCC_TR1 before including the boost libraries will solve the problem. Is there a better way? More importantly, this is code in part of library used by a number of other projects. Will we have to recompile the boost libraries (we're using the current Ubuntu package), and/or any of our projects that link against this code, or should linkage not be a problem? -- Anthony Foglia Princeton Consultants (609) 987-8787 x233

2 1