August 2007 - Boost-users - lists.boost.org

Compiling problem, Intel Compiler 9.1, Boost 1.34.1
by Notger Heinz 20 Aug '07

20 Aug '07

Dear community: I have a problem compiling with Intel 9.1 and Boost 1.34.1. It quits with error message, that says it was unable to find the lib libboost_thread-iw-mt-s-1_34_1.lib. Please, can anyone help me with this? Thank you very much in advance N. Heinz.

1 0

Still cannot cross-build boost libs
by Bruce Reid 20 Aug '07

20 Aug '07

I am trying to use linux-x86 platform to cross-build for linux-ppc. I have followed Vladimir’s suggestion to specify my cross-compiler/archiver by updating user-config.jam with: using gcc : : /path/to/my/linux-ppc-g++ : <archiver>/path/to/my/linux-ppc-ar ; I have confirmed this works IF I build one of the [header-only] example programs. This proves that user-config.jam (located in my home directory) is being found, and the compiler/archiver are specified correctly, since the resulting executable runs on the correct target (ppc) platform. However, when attempting to apply the same user-config.jam file to build boost/serialization, it appears my cross-compiler/archiver directives are ignored, and the resulting libraries are in the native x86 format, since attempting to build a program with one of them using my ppc-g++ compiler produces a spew of link errors. Modifying my makefile to use the native g++ compiler permits a successful linkage with the boost/serialization library, and the resulting executable runs fine on the x86 platform. The command I used to build boost/serialization is: bjam --toolset=gcc --with-serialization --prefix=/my/prefix/path --exec-prefix=/my/exec-prefix/path/linux_ppc --libdir=/my/exec-prefix/path/linux_ppc/lib install I also saved the output from the build, but can’t see any clues to explain where things went wrong. Any ideas why I seem to be so close, but still cannot produce boost library binaries for the desired target platform?

5 10

Re: [Boost-users] Serialization newbie needs help
by Dominick Layfield 19 Aug '07

19 Aug '07

Frank Birbacher wrote: > I now noticed that the link I posted does not reference excatly what I > meant to point at. Your code makes me think that you have not read what > I wanted you to read. Here it goes. > > READ THIS: > > http://www.boost.org/libs/serialization/doc/rationale.html#trap Well, Hector may not have read this, but I did! And it seems that I have the same problem as him. If I make the object I want to serialize a const, the (completely incomprehensible) compile error goes away. Any chance this could be added to a boost::serialization FAQ? It appears that I have a choice between (i) doing a const_cast on every object I want to save, and (ii) inserting a BOOST_CLASS_TRACKING(XXX, boost::serialization::track_never) line into my source code. Both are ugly, and although the former might be safe, it certainly looks dangerous! The "Compile time trap" section of the documentation doesn't actually explain what "object tracking" is all about. Neither (amusingly) does the Boost->Serialization->Reference->Special Considerations->Object Tracking section! After re-reading these sections several times, I realized that this is all related to serializing pointers. To my mind, it is not at all intuitive what should happen if I try to serialize a pointer to an object. What Boost::serialization seems to do is to serialize the object itself, but wrapped up in some magic that remembers the object was output/input through a pointer. i.e. if I create a my_class object, then output a pointer to the object, the object itself is output, and when I come to input the pointer, the library silently creates an object of type my_class, then puts a pointer to the object into my pointer. Is that about right? If so, this is (1) not transparent, and (2) seems ludicrously complex. As alluded to in the documentation, this creates a morass of problems (object-tracking, memory leaks etc.). Having said that, I have to applaud the tour-de-force of C++ wizardry required to make all of this magic work. To quote Bjarne Stroustrup, "...but you have to be very clever. If any of you have seen some of the Boost stuff, you don't want to be that clever!" (from his recent Waterloo talk) It seems to me that a cleaner, simpler (and less ambitious) solution would just be to make serialization of pointers an error. What on earth does it actually mean to serialize a pointer? And why would I want to do such a thing, anyway? -- Dominick

3 2

shared_ptr and thread safety
by gast128 19 Aug '07

19 Aug '07

Dear all, it is already posted a dozen times, but still I do not get it. I understand that if you have a class, the shared_ptr will not make this thread safe. That's fair. Non const operations accessed by different threads should still be guarded (and probably their const versions then also). But what about the shared_ptr itself. From the doc's (http://www.boost.org/libs/smart_ptr/shared_ptr.htm#ThreadSafety) I read that reading and writing to the shared_ptr object (not the pointee) is safe: 'A shared_ptr instance can be "read" (accessed using only const operations) simultaneously by multiple threads. Different shared_ptr instances can be "written to" (accessed using mutable operations such as operator= or reset) simultaneosly by multiple threads (even when these instances are copies, and share the same reference count underneath.)' However then a couple of examples are listed where both operator= and a dtor call are marked as undefined, and this is of course the most use (share a shared pointer over multiple threads and let them decide who finishes last, but this is then illegal?) >From the code I see that the ref counting is implemented through atomic inc's and dec's, and I would therefore expect that it is thread safe after all, since only the thread which makes the ref count 0 will be assigned the job of 'dispose', and the ref counting is thread safe. who can help this poor programmer... wkr, me

6 13

Looking for ScopeExit Reviews
by Jody Hagins 19 Aug '07

19 Aug '07

The review ends in three days (on Wednesday). The current collection of reviews is very small, thus I am asking for more reviews of this library. Thanks! >From the original announcement... The review period for Scope Exit Time Series, submitted by Alexander Nasonov, runs from Monday, August 13 until Wednesday, August 22. >From the documentation: Nowadays, every C++ developer is familiar with RAII technique. It binds resource acquisition and release to initialization and destruction of a variable that holds the resource. But there are times when writing a special class for such variable is not worth the effort. This is when ScopeExit macro comes into play. You put resource acquisition directly in your code and next to it you write a code that releases the resource. Note that ScopeExit uses PP macros and relies on Boost.Typeof. The latest version can is here: http://boost-consulting.com/vault/index.php?action=downloadfile&filename=sc… It's available also at http://tinyurl.com/2z6qg2 Online documentation is here: http://194.6.223.221/~nasonov/scope_exit-0.04/libs/scope_exit/doc/html/inde… >From the review guidelines here: http://boost.org/more/formal_review_process.htm ... Boost mailing list members are encouraged to submit Formal Review comments: * Publicly on the mailing list. * Privately to the Review Manager. Private comments to a library submitter may be helpful to her or him, but won't help the Review Manager reach a decision, so the other forms are preferred. What to include in Review Comments Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. Here are some questions you might want to answer in your review: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Thanks in advance to every for your participation in this review.

1 0

Re: [Boost-users] regex_search on non-NULL terminated strings.
by Anders Dalvander 19 Aug '07

19 Aug '07

> The ideal interface would be: > 1) terminate when NULL character is found > 2) if NULL character not found, terminate when end marker is reached. char buffer[BUFFER_SIZE]; char* buffer_begin = buffer; char* buffer_end = buffer + BUFFER_SIZE; // TODO fill buffer with string. char* string_begin = buffer; char* string_end = std::find(buffer_begin, buffer_end, 0); // TODO call regex with string_begin and string_end. // Anders Dalvander

2 1

Re: [Boost-users] Serialization newbie needs help
by Hector C. 19 Aug '07

19 Aug '07

Robert Ramey wrote: > Actually, I've considered reviewing all the email in this list and > summarizing > the results in a section "Hints and Troubleshooting Tips". I think this > is useful and necessary and useful, but I just havent gotten around to it. > What about documentation using doxygen (in addition to what is already there)? I spent a lot of time reading the code to understand the usage of many things. For example, in current documentation there is no (semi-obvious) place for BOOST_SERIALIZATION_SPLIT. -- Hector C. ____________________________________________________________________________________ Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC

1 0

gregorian date and julian
by thom_schu＠gmx.de 18 Aug '07

18 Aug '07

Hi all, Can anyone tell me how to construct a date (gregorian) with a julian number ? I tried the constructor "date(special_values sv)" and it looked like it would work, but Im not sure if I can do this (what for is this constructor ?) So after taking a look in the source I found another possibility: greg_year_month_day ymd = gregorian_calendar::from_julian_day_number(2443510); date d(ymd); So are both ways right ? thanks in advance -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

2 1

Re: [Boost-users] Serialization newbie needs help
by Hector C. 18 Aug '07

18 Aug '07

Robert Ramey wrote: Dominick Layfield wrote: Frank Birbacher wrote: I now noticed that the link I posted does not reference excatly whatI meant to point at. Your code makes me think that you have not readwhat I wanted you to read. Here it goes.READ THIS:http://www.boost.org/libs/serialization/doc/rationale.html#trap Well, Hector may not have read this, but I did! C'mon, c'mon ;-) And it seems that Ihave the same problem as him. After I realized what the problem was, I found that it was rathercommon. If I make the object I want toserialize a const, the (completely incomprehensible) compile errorgoes away. Any chance this could be added to a boost::serializationFAQ? you mean change the section named "rationale" to "FAQ"? Perhaps the comments before the trap (code in the hpp file), shouldhave a hyperlink. It appears that I have a choice between (i) doing a const_cast onevery object I want to save, and (ii) inserting aBOOST_CLASS_TRACKING(XXX, boost::serialization::track_never) lineinto my source code. After reading the rationale, I saw that option (ii) allows me topostpone the fight (and I took it). What is more important is that thetrap is there to remember it. Perhaps another solution would be toprovide a base class for tracking objects. This way, instead of usingthe macro, one could derive from such class: class MyClass : private boost::serialization::trackme And this "trackme" class could have parameters in the constructor tosay whether it should be tracked: MyClass()::MyClass() : boost::serialization::trackme(never) {} or MyClass()::MyClass() : boost::serialization::trackme(selectively) {} etc .. This solution would be in addition to the const-reference andBOOST_CLASS_TRACKING ones. It seems to me that a cleaner, simpler (and less ambitious) solutionwould just be to make serialization of pointers an error. I wouldn't do that. C++ must allow me to shot myself if I'm notcareful!! --------------------------------- Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more.

1 0

Serialization newbie needs YET MORE help
by Hector C. 18 Aug '07

18 Aug '07

Hi all, Can anyone give any ideas why uncommenting the #define will give me errors? --Hector C. //#define GiveMeErrors #include <fstream> #ifdef GiveMeErrors # include <boost/archive/binary_woarchive.hpp> #else # include <boost/archive/binary_oarchive.hpp> #endif int main(int argc, char * argv[]) { #ifdef GiveMeErrors std::wofstream off("test.txt", std::ios_base::binary); boost::archive::binary_woarchive oa((std::wostream &)off); #else std::ofstream off("test.txt", std::ios::binary); boost::archive::binary_oarchive oa((std::ostream &)off); #endif return 0; } ---------------------------------- ____________________________________________________________________________________ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC

3 2