- Boost-users - lists.boost.org

Re: [Boost-users] boost build interface
by Vladimir Prus 08 Apr '09

08 Apr '09

Green, Jason M NSWCDL, W33 wrote: > Not that I am volunteering, but it isn't that hard to come up with a simple > dialog based mfc project that would set up the commands to properly run the > boost build. I did not claim that coming up with an MFC project is hard per se. However: 1. It will require *me* quite some time, for I was not doing any real windows development in years. 2. It might be best to use some more lightweight solution, but I don't know what are scripting options on modern Windows. - Volodya

3 2

[date_time] local time & date arithmetics
by Filip Konvička 08 Apr '09

08 Apr '09

Hi all, first, thanks for the date_time library. Although I see some issues with it, I still think it is highly needed and does a lot of good stuff for me. Recently I stumbled upon a problem with date arithmetic that involves local_date_time. The following code fragment local_date_time t( ptime(boost::gregorian::date(2008, 4, 7), time_duration(22, 0, 0)), boost::shared_ptr<posix_time_zone>(new posix_time_zone("CET+1CEST,M4.1.0,M10.1.0"))); cout << t.utc_time() << " UTC = " << t << endl; t -= boost::gregorian::days(6); cout << t.utc_time() << " UTC = " << t << endl; yields the following output 2008-Apr-07 22:00:00 UTC = 2008-Apr-08 00:00:00 CEST 2008-Apr-01 22:00:00 UTC = 2008-Apr-01 23:00:00 CET This indicates that the date operation just subtracted 6*24 hours from the internal representation of the local time. It missed the DST change within the time interval. I would rather expect the operation to do the following: 2008-Apr-07 22:00:00 UTC = 2008-Apr-08 00:00:00 CEST 2008-Apr-01 23:00:00 UTC = 2008-Apr-02 00:00:00 CET If the current behavior is intentional, it is not clear to me why have such operations as "+= days(...)" available in local_date_time at all, as they don't seem to obey the general local time semantics (at least as I understand it) - we could just use an UTC ptime for that, right? Another thing related to this is that many functions in local_date_time are inherited from the base class, which has a different semantics. From the user point of view, this seems to be quite dangerous - one has always to verify whether the function being called is overloaded in local_date_time (and so should have local time semantics) or whether it is defined in ptime and so works with the internal UTC representation. Why is the base class not protected? Thanks for any comments, Filip

1 0

Re: [Boost-users] difference b/w regex lib files
by Steven Watanabe 08 Apr '09

08 Apr '09

AMDG Green, Jason M NSWCDL, W33 wrote: > 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? > The boost_regex*.lib files are import libraries for boost_regex*.dll In Christ, Steven Watanabe

1 0

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