- Boost - lists.preview.boost.org

[asio] timer cancelling
by Mr. Robert G Palmer Jr. 21 Mar '11

21 Mar '11

boost 1.45.0 WinXP SP3 What is the difference between boost::deadline_timer.cancel() and the cancellation that happens due to boost::deadline_timer.expires_from_now()? I'm doing an async_read_some() inside of a wrapper function I have written (based on http://lists.boost.org/Archives/boost/2007/04/120339.php) I have a read handler and a timer handler (I want the bytes read value and could probably combine the two handlers into one with the appropriate modification to the bind call). The read handler works, and then I cancel the timer, but the NEXT TIME I call the wrapper function, the timer hander fires with a boost::asio::error::operation_aborted. The timer object is local to the wrapper function, but the io_service is not, it is passed in, so it seems the io_service is holding onto the timer completion handler AND the fact that it was cancelled. Is there a way to clean this out before exiting my wrapper function? Is the 'expires_from_now()' calling the timer handler or is it the first call to run_one()? Thanks, -- Robert G. Palmer, Jr. robert.palmer(a)ingenutec.com

1 0

Re: [boost] [Review] Boost.Type Traits Extension ending tomorrow
by Brent Spillner 21 Mar '11

21 Mar '11

On 3/19/2011 11:52 Joachim Faulhaber wrote: >(1) We can think of the triple <T,U,R> of types that plus_assign *is* >applicable on. >(2) Each of those operations assigned to an operator can be decomposed Maybe the set of functions should be something like is_callable<plus, LeftOperandType, RightOperandType> result_of<plus, LeftOperandType, RightOperandType, ReturnType> retval_convertible_to<plus, LeftOperand, RightOperandType, EquivalentReturnType> Similarly, we could have is_prefix_callable<plusplus, OperandType> and is_postfix_callable<plusplus, OperandType>, which helps eliminate the ambiguity that naming-by-syntax would introduce. I favor making the operator name a template parameter because: - I suspect this will encourage a more maintainable code decomposition within the library - It will likely permit simpler extension to free functions or member functions (think is_callable<push_back, ContainerType, ValueType>) - It will likely be easier to use for higher-level libraries such as Phoenix, Proto, etc. that may pass around operator names for a while before caring about the specific operator to which they refer

4 6

[patch] Patch for eliminating some warnings
by Thomas Heller 21 Mar '11

21 Mar '11

Hi, During testing for phoenix i came over some warnings which were fairly easy to fix. The warnings showed up by compiling with -Wall -Wextra -ansi -pedantic on gcc and clang. They are mostly about unused parameters or extra semicolons. The affected files are: hing file boost/fusion/algorithm/iteration/detail/fold.hpp boost/fusion/sequence/intrinsic/has_key.hpp boost/fusion/view/ext_/segmented_iterator.hpp boost/function/function_template.hpp boost/regex/pending/unicode_iterator.hpp Patch is attached. Safe to apply? Greetings, Thomas

1 0

Re: [boost] [lexical cast] Performance improvements
by Antony Polukhin 20 Mar '11

20 Mar '11

>Just one quick question, does your code have the same behaviour as the existing Lexical Cast when casting out of bounds (int -> unsigned int, int -> short, unsigned int -> int)? > >Chris Yes. It has the same behaviour. For checking bounds it uses boost::numeric::conversion_traits from <boost/numeric/conversion/conversion_traits.hpp> Antony

1 0

[context review] Review starts next Monday, Mars 21st
by Vicente BOTET 20 Mar '11

20 Mar '11

Hi all, The review of Oliver Kowalke Context library starts next Monday Mars 21st 2011, and will end on Mars 30th. Boost.Context is a basic building block library that is used for more higher abstractions. It is used by Boost.Fiber, Boost.Tasklet and Boost.Task from the same author. I really hope to see your vote and your participation in the discussions on the Boost DEVELOPMENT mailing lists! Please use [context review] as prefix of your post to make easier the review follow up. You can already download a frozen version for the review from the Vault, TinyURL: http://tinyurl.com/5r77rel or --------------------------------------------------- About the library: Boost.Context provides a possibility to switch between different user-level context and is intended to be the basis for a higher abstraction like coroutine and fiber. A user-level context represents the current execution state, including all registers and CPU flags, the instruction pointer, the stack pointer. boost::context encapsulates such a user-level context and is able to store/restore its associated user-level context. This allows multiple execution paths running on a single thread using a sort of cooperative scheduling (in contrast a thread is preemptively scheduled) - the running boost::context decides explicitly when its yields to allow another boost::context to run (user-level context switching). A context can only run on a single thread at any point in time but may be migrated between thread. A context switch between threads costs usually thousands of CPU cycles on x86 compared to a user-level context switch with few hundreds of cycles. Boost.Context differes to setjmp()/longjmp() in the fact that the C99 standard does not require that longjmp() preserves the current stack frame, e. g. jumping into a function which was exited via a call to longjmp() is undefined. Boost.Context allows to select the mechanism provided by the operating system (ucontext on UNIX, Windows Fibers on Windows) or a faster implementation provided by this library (fcontext using assembler). --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - 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? Regards Vicente Review Manager

2 1

Status of boost-build at sourceforge?
by Steve M. Robbins 19 Mar '11

19 Mar '11

Hi, The Boost Sourceforge project has a bunch of directories that appear un-maintained. The following are all a year or more old; are they still relevant? boost-jam 2010-03-22 707,245 downloads boost-build 2007-10-01 174,174 downloads boost-subparts 2006-11-09 In particular: Debian has packages based on boost-build, but I'm not sure really if these 3-year old files have any value today. Do they? Thanks, -Steve

1 0

GSOC: concept_traits
by Vicente Botet 19 Mar '11

19 Mar '11

Hi, Now that we will have operator traits with the reviewed library and member traits macros with Boost.TTI, it left just to define the traits for the concepts/requirements of standard library and why not some boost libraries. This would completely resurrect the abandoned ConceptTraits library. Could be this an acceptable subject for GSOC? Thanks, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/GSOC-concept-traits-tp3388859p3388859.ht… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 3

[1.47] New libraries
by Daniel James 19 Mar '11

19 Mar '11

As far as I'm aware, there are three new libraries intended for 1.47 - chrono, ratio and geometry. Any others? Daniel

13 19

[Review] Boost.Type Traits Extension by Frederic Bron
by Edward Diener 19 Mar '11

19 Mar '11

This is my review of the Boost Type Traits Extension by Frederick Brron. * What is your evaluation of the design? The design is very straightforward, and easy to use. Although I do not anticipate the need to check the return from the operator traits I am glad that is part of the library. The only suggestion I would like to make regarding the design is in the default argument for the return value, which tells the implementation not to check for the return value. While it is wildly improbable that any user of the operator traits would actually want to have a trait whose return is actually 'void', it is still theoretically possible. Therefore I think that the default for the return value, which means to not check for the return value, should be an unspecified marker type in the type_traits::detail namespace. It is a convention of all Boost libraries that any library's detail namespace is to be used only by the implementation of that library and not by a user of that library. So using an unspecified marker type in the type traits detail namespace should be fine. * What is your evaluation of the implementation? I did not look at the source code. I do have a large reservation from reading the documentation, so let me explain it now. The ideal situation when using template metaprogramming constructs, such as the type traits operators metafunctions, is that an instantiation of the metafunction should never produce a compiler error. This is particularly true of metafunctions which return a boolean constant value, since the boolean value can encapsulate the notion of true or false when using the metafunction based on input types. Of course it may be the nature of C++ that this ideal situation can not be met. But then the user of the metafunction has to be able to instruct his end-users about whatever limitation exists and make allowance for it. In the type traits operators library there are documented two major situations where the use of a type will produce a compiler error and not just a false boolean constant value. This is a painful situation. I realize these two situations are fully documented in the "Known Issues" area of the Operator Type Traits documentation. But now let us take a look at the template metaprogrammer who wishes to use some subset of the type traits operators in his own library based on a type his end-user may pass to him. What this programmer wishes to do is to use a type traits operator if a type passed to him supports it, otherwise not use the operator at all. Unfortunately the end-user of that library passes a type which may or may not support such functionality, not knowing that the type will trigger a compiler error because the type traits operators are being used internally and some known issues exist which that type encompasses. What that template metaprogrammer must then do is to add another template parameter to his template, and documentation which explains to his end-user the specific situations whch trigger compiler errors in the type traits operators, that if a type is being passed which could cause the type traits compiler error conditions he must set this other parameter to false so that the compiler error can be avoided. This is a difficult way to program metafunctions successfully. So it is very disappointing that these "Known Issues" exist and it would be very worthwhile if a way could be found around them, by something different in the internal implementation, if that were possible. * What is your evaluation of the documentation? The documentation is thorough and complete. * What is your evaluation of the potential usefulness of the library? I think it is very useful. * Did you try to use the library? With what compiler? Did you have any problems? Tested with VC 8,9,10 and everything worked as expected. I have also integrated into another library on which I am working and that was successful also. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I read the docs, tested the library under Windows, and tried it in my own library, so it was pretty thorough. * Are you knowledgeable about the problem domain? Yes. 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. I vote for the library to be accepted into Boost. I would also like to see if the "Known Issues" could not be solved, not necessarily by the author of the library who has put so much effort and work into it, but possibly by other Boost experts who might find some solution to these issues which mar the library somewhat for me. But even if these issues could never be solved the library is worthwhile enough to be accepted. Edward Diener

3 5

[tasklet] micro-tasks with cooperative scheduler
by Oliver Kowalke 19 Mar '11

19 Mar '11

Hi, I've uploaded version 0.2.0 of boost.tasklet: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost.… boost.tasklet provides a framework for cooperatively scheduling micro-tasks (some kind of user-level threads). It comes with an scheduler, synchronisation primitives - mutex, condition, barrier, event-variables (auto- and manual-reset and count-down variable), future and channel. boost::tasklets::packaged_task< std::string > pt( helloworld_fn); boost::tasklets::unique_future< std::string > fu = pt.get_future(); boost::tasklet t( boost::move( pt), boost::tasklet::default_stacksize); boost::scheduler::schedule( t); boost::scheduler::schedule( my_function, 1, "abc"); for (;;) { while ( boost::scheduler::run() ); if ( boost::scheduler::empty() ) break; } std::cout << fu.get() << std::endl; In order to let functions/actions be executed in a separate thread boost.tasklet provides a scheduler_thread: boost::scheduler_thread st; boost::shared_future< void > f1( st.schedule( some_fn ) ); boost::shared_future< std::string > f2( st.schedule( other_fn) ); f1.wait(); std::cout << "future 2 result: " << f2.get() << std::endl; regards, Oliver

2 5

lambda compile error
by Andy Venikov 18 Mar '11

18 Mar '11

Hi, I thought that lambda expressions of the form: (var(actual_var) = _1)(new_value) are supposed to work. Here's a small code that does not compile with boost 1.42 and gcc4.5: #include <map> #include <boost/lambda/lambda.hpp> using namespace std; void foo() { using namespace boost::lambda; typedef multimap<int, int> MP; MP mp1; MP mp2; (var(mp1) = _1)(mp2); //compile-time error here } Are standard maps special in that regard? Thanks, Andy.

2 4

Re: [boost] [Review] Boost.Type Traits Extension by Frederic Bron
by Jeffrey Lee Hellrung, Jr. 18 Mar '11

18 Mar '11

On 3/14/2011 12:48 AM, Joel Falcou wrote: > Dear All, > > This is the first day of the fast track review of Frédéric Bron's > extensions to the Type Traits Library.This reviews will last until March > 18th, 2011 under my management. All comments and reviews are > very welcome. [...] I vote for inclusion, pending resolution of my comments below (that is, I'm hoping the community will reach some consensus, not necessarily that all my suggestions will be adopted). I've perused a few pages of the documentation and a good chunk of the implementation source. As far as the naming, I'm fine with the has_operator_xxx convention. In my own implementation of such traits, I use names such as is_pre_incrementable, is_left_shiftable, etc., which I find equally good, but as John Maddock pointed out, the has_operator_xxx names are conveniently grouped in the alphabetical reference. Perhaps an additional section of the documentation under "Type Traits by Category" should be added called "Operator Traits" which can section out these new operator traits, and then the fact that all the operator traits are nicely grouped together in the alphabetical reference would be less of an issue. For the arithmetic operators, I prefer "plus" and "minus" to "add" and "subtract", respectively, and likewise "plus_equal" to "add_assign", but it's not a strong preference, and perhaps consistency with other Boost libraries should dictate these, I don't know. I do more strongly prefer "post_decrement" to "postfix_decrement", and to have "increment" and "decrement" spelled out. "bit_op" versus "bitwise_op" is another one that I have no strong preference either way, so I would probably look at other Boost libraries for precedent. One could provide aliases for the more contentious trait names...? There is precedent for this in Boost.Fusion with accumulate and fold... At least one example in the documentation utilizing one of these operator traits would be useful. I like the idea posited earlier of a generic streaming function, maybe for debugging purposes, which uses << if available, else streams out some default string containing the type of the argument. It is implicit in the documentation, and likewise verified from looking at the implementation, that all arguments are assumed to be lvalues. That is, a reference qualifier is automatically added to the argument types given to an operator trait. Thus, the only way to query if an operator is applicable to an rvalue is to query using a const-qualified type, and even then I think you could get back false negatives in C++0x and even C++03 with Boost.Move rvalue-reference emulation (consider only operator_xxx(T&&) available). Further, rvalueness and lvalueness does enter into overload resolution (rvalues can't bind to T& when T is deduced), hence it does influence the result type of the operation. For these reasons, I believe the traits should strive to differentiate between lvalue and rvalue argument types. In either case, whether arguments are treated as presently or as propositioned above, this treatment of the arguments should be spelled out explicitly. As Vicente pointed out, the use of make in the implementation can be replaced with the declval that common_type uses. I don't have strong feelings on whether to use "void" to signify that one "doesn't care" about the result type or to use some "dont_care" type. I've personally used "void" in my operator traits implementation. If the latter solution is settled upon, I believe it should be a documented part of the interface, and not in a detail namespace, to allow users to explicitly supply it. I still believe an extra template parameter representing a Boost.MPL metafunction to apply to the result type would be useful, relatively easy to add, and will not change the existing interface. It seems, however, that I'm the only one that likes this idea, and it's use cases are relatively limited. I've mostly used such a feature to further constrain the result beyond just "convertible". For example, one may want to prevent returning references to locals from functions. That is, the function's return type is fixed to be T const &, and the function logically returns the result of an operator applied to a local variable. If the operator returns U which is implicitly convertible to T, then everything compiles fine but it's probably asking for a crash, as the function's return value is a dangling reference. You'd hope you'd get a compiler warning, but better to either create a hard error in such cases or provide an alternate implementation of the function. I think that covers everything. Well done Frederic! - Jeff

2 1

[Review] Boost.Type Traits Extension by Frederic Bron
by Joel Falcou 18 Mar '11

18 Mar '11

Dear All, This is the first day of the fast track review of Frédéric Bron's extensions to the Type Traits Library.This reviews will last until March 18th, 2011 under my management. All comments and reviews are very welcome. =========== What is it? =========== This extension adds 37 new traits corresponding to the following 37 operators: - binary: ==, !=,<,<=,>,>=, , +, -, *, /, %, +=, -=, *=, /=, %=, , &&, ||, ,&, |, ^,<<,>>,&=, |=, ^=,<<=,>>= - prefix: ++, --, +, -, !, ~, * - postfix: ++, -- Each trait can detect if the operator can be used with particular types and if needed, if the return type is convertible to some type. =================== Getting the library =================== The latest version can be downloaded by different ways: - from the vault with unix line ending: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_t… - from the vault with dos line ending: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_t… - from the sandbox:http://svn.boost.org/svn/boost/sandbox/type_traits/ The entry point of the documentation is type_traits/libs/type_traits/doc/html/boost_typetraits/category/value_traits/operators.html The library has been tested with: - MSVC 8, 9, 10 on Windows, - g++ 4.4.5 on Linux, - intel 10.0 and 11.1 on Linux. To test the library, the simplest is to untar the headers in your boost include directory. For this, you can download the header part of the extension: - from the vault with unix line ending: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_t… - from the vault with dos line ending: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_t…

12 63

bcp (and config.hpp, user.hpp, shared_ptr.hpp) problem
by Michael Matthews 18 Mar '11

18 Mar '11

I am trying to compile (with VS2008) using a few boost tools pulled out using bcp. I've used bcp before without trouble, but I just upgraded to boost_1_46_1, and now I'm having trouble. I pulled the boost subset out with: C:\Program Files\boost\boost_1_46_1>bcp filesystem.hpp foreach.hpp property_tree shared_ptr.hpp fromBoost\ During compile, the problem is with shared_ptr. The shared_ptr.hpp file includes this line at the top: #include <boost/config.hpp> // for broken compiler workarounds which causes config.hpp to be used (and it is correctly pulled by bcp), which then causes this compile error (because user.hpp is not pulled, though other files in boost/config/ are): \fromboost\boost\config.hpp(26) : fatal error C1083: Cannot open include file: 'boost/config/user.hpp': No such file or directory which is from these lines in the config.hpp file: // if we don't have a user config, then use the default location: #if !defined(BOOST_USER_CONFIG) && !defined(BOOST_NO_USER_CONFIG) # define BOOST_USER_CONFIG <boost/config/user.hpp> #endif // include it first: #ifdef BOOST_USER_CONFIG # include BOOST_USER_CONFIG #endif What is the source of the problem, and what can I do to fix it? I am not familiar with config.hpp or what it's used for, but a quick look at the documentation makes me think that I shouldn't have to worry about it as a library user. Should I manually being #defining BOOST_NO_USER_CONFIG? That seems like a hack. Thanks, Michael

2 3

Deprecation guidelines?
by Daniel Herring 18 Mar '11

18 Mar '11

I was trying to figure out how Boost handles deprecated classes, functions, headers, macros, etc. The following command finds several approaches within boost $ grep -ir deprecate boost-1.44.0/include/boost/* \ | grep -v "This header is deprecated" \ | grep -v BOOST_SPIRIT_DEPRECATED Surprisingly, none of these use compiler support. e.g. http://stackoverflow.com/questions/295120/c-mark-as-deprecated Where can one find guidelines on how to deprecate things in Boost? What is the proper way to check that code using Boost is clean? Thanks, Daniel

6 6

Boost Trunk LKGR
by Joshua Boyce 18 Mar '11

18 Mar '11

Hey all, I was wondering if there was any way to query for the Last Known Good Revision of the Boost trunk? It would be great if there was a file or something on the website that had the revision number of the latest build to compile cleanly and pass all tests, either for all platforms, or one file for each platform. For an example of this in practice elsewhere, see the Chromium project: https://sites.google.com/a/chromium.org/dev/developers/how-tos/get-the-code… <https://sites.google.com/a/chromium.org/dev/developers/how-tos/get-the-code…> Thanks.

3 3

Deprecation of compilers and libraries
by Jeroen Habraken 18 Mar '11

18 Mar '11

Hi, It seems the acceptance of Phoenix V3 has raised the question on how to handle the deprecation of compilers and libraries again. I believe it is important to reach a consensus and to make an official statement regarding it, as it's important for both users and developers. Below I've assembled a set of questions I would like to see answered: Compilers: 1. What minimum of compilers should a library support for it to be considered for review? 2. What is necessary for a compiler previously supported to be removed from this list? Libraries: 3. Should library X be marked as preferred over library Y, since multiple solutions to a similar problem are becoming more common and the right choice might not be obvious to a user? 4. Can an existing library be marked "deprecated"? 5. Once deprecated will a library be removed from boost after X releases? 6. Should a backwards compatible solution exist for a library to be removed? Personally I believe dead branches should, in due time, be cut from the tree for boost to remain at the forefront of C++ development. Especially now the number of libraries is growing, we should aim for clarity. Regards, Jeroen Habraken

3 2

[phoenix] Upcoming release - What about the rest?
by Thomas Heller 18 Mar '11

18 Mar '11

Hi all, The next boost release is nearing and I want to include Phoenix. However, there are some questions that needs to be solved. How to deal with Boost.Bind and Boost.Lambda? First of all, I don't think its a good idea to remove either of those. However, should Phoenix deprecate Boost.Bind and Boost.Lambda? If yes, how should this deprecation be handled? My main concern is that most users will just continue to use BB and BLL just because of their names. What about Phoenix V2? For V2 I have a clearer vision. I would like to have three phases: 1) Have V2 and V3 coexist in the tree, have a macro that decides which version should be included. will default to V2 2) deprecate V2, change the default of the macro introduced in 1) to V3 Alternatives: 3 a) remove phoenix v2 3 b) move phoenix v2 to another namespace so that V3 and V2 don't interfere anymore Best regards, Thomas

2 2

[valid_ptr] proposing a new type of pointer object that allows validity tracking without memory management and object ownership
by Dan Walters 17 Mar '11

17 Mar '11

Dear all, I am posting to propose a new light weight pointer object library (boost.valid_ptr) that provides safe validity checking without having to take ownership or the the responsibility of memory management of the object pointed to. The intention is to develop a useful pointer object that is easy to use and handles validity in a simple and invisible manner, to be used just like a normal pointer and in a way that a programmer would be familiar with, to produce cleaner and more intuitive code than other pointer libraries for its problem domain. The library would be best used when it is difficult to determine when an object will be released, for example, when pointing to objects higher on the stack, objects that are members of other objects or objects contained within a boost.ptr_container. The library is to be practically useful and most useful where boost.smart_ptr and boost.ptr_container libraries are not appropriate (for example, due to memory management or ownership not being required). The valid_ptr library is to be optimized for access rather than fast assignment / de-assignment. Detailed proposal: https://docs.google.com/document/pub?id=1wod4CbeL9x8rLJ2S8815akMAGmYj-fCq90… I am posting here in the hope it will generate suitable interest that it may be worth developing as a full library for submission. Best wishes, Dan

6 12

compile error with boost::archive::text_oarchive
by Eun-Sung Kim 17 Mar '11

17 Mar '11

Hi, all Compile error is occurred in the following program "VerySimpleCase .cpp" on http://www.boost.org/doc/libs/1_46_1/libs/serialization/doc/tutorial.html#s…. The statements in line no. 45 and 56 cause problems. Could you fix it up? Thanks, --Kim ps 1) VerySimpleCase .cpp 1 #include <fstream> 2 3 // include headers that implement a archive in simple text format 4 #include <boost/archive/text_oarchive.hpp> 5 #include <boost/archive/text_iarchive.hpp> 6 7 ///////////////////////////////////////////////////////////// 8 // gps coordinate 9 // 10 // illustrates serialization for a simple type 11 // 12 class gps_position 13 { 14 private: 15 friend class boost::serialization::access; 16 // When the class Archive corresponds to an output archive, the 17 // & operator is defined similar to <<. Likewise, when the class Archive 18 // is a type of input archive the & operator is defined similar to >>. 19 template<class Archive> 20 void serialize(Archive & ar, const unsigned int version) 21 { 22 ar & degrees; 23 ar & minutes; 24 ar & seconds; 25 } 26 int degrees; 27 int minutes; 28 float seconds; 29 public: 30 gps_position(){}; 31 gps_position(int d, int m, float s) : 32 degrees(d), minutes(m), seconds(s) 33 {} 34 }; 35 36 int main() { 37 // create and open a character archive for output 38 std::ofstream ofs("filename"); 39 40 // create class instance 41 const gps_position g(35, 59, 24.567f); 42 43 // save data to archive 44 { 45 boost::archive::text_oarchive oa(ofs); // compile error at here !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 46 // write class instance to archive 47 oa << g; 48 // archive and stream closed when destructors are called 49 } 50 51 // ... some time later restore the class instance to its orginal state 52 gps_position newg; 53 { 54 // create and open an archive for input 55 std::ifstream ifs("filename"); 56 boost::archive::text_iarchive ia(ifs); // compile error at here !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 57 // read class state from archive 58 ia >> newg; 59 // archive and stream closed when destructors are called 60 } 61 return 0; 62 } 63 ps2) compile error message (partly) /tmp/ccnNHOct.o: In function `boost::archive::text_iarchive& boost::smart_cast_impl::reference<boost::archive::text_iarchive&>::polymorphic::cross::cast<boost::archive::detail::basic_iarchive>(boost::archive::detail::basic_iarchive&)': VerySimpleCase.cpp:(.gnu.linkonce.t._ZN5boost15smart_cast_impl9referenceIRNS_7archive13text_iarchiveEE11polymorphic5cross4castINS2_6detail14basic_iarchiveEEES4_RT_+0x1b): undefined reference to `typeinfo for boost::archive::detail::basic_iarchive' /tmp/ccnNHOct.o: In function `boost::archive::text_oarchive& boost::smart_cast_impl::reference<boost::archive::text_oarchive&>::polymorphic::cross::cast<boost::archive::detail::basic_oarchive>(boost::archive::detail::basic_oarchive&)': VerySimpleCase.cpp:(.gnu.linkonce.t._ZN5boost15smart_cast_impl9referenceIRNS_7archive13text_oarchiveEE11polymorphic5cross4castINS2_6detail14basic_oarchiveEEES4_RT_+0x1b): undefined reference to `typeinfo for boost::archive::detail::basic_oarchive' /tmp/ccnNHOct.o: In function `void boost::archive::text_oarchive_impl<boost::archive::text_oarchive>::save<int>(int const&)': VerySimpleCase.cpp:(.gnu.linkonce.t._ZN5boost7archive18text_oarchive_implINS0_13text_oarchiveEE4saveIiEEvRKT_+0x15): undefined reference to `boost::archive::basic_text_oarchive<boost::archive::text_oarchive>::newtoken()' /tmp/ccnNHOct.o: In function `void boost::archive::save_access::save_primitive<boost::archive::text_oarchive, int>(boost::archive::text_oarchive&, int const&)': VerySimpleCase.cpp:(.gnu.linkonce.t._ZN5boost7archive11save_access14save_primitiveINS0_13text_oarchiveEiEEvRT_RKT0_+0x15): undefined reference to `boost::archive::detail::basic_oarchive::end_preamble()' /tmp/ccnNHOct.o: In function `void boost::archive::text_oarchive_impl<boost::archive::text_oarchive>::save<boost::archive::class_id_reference_type>(boost::archive::class_id_reference_type const&)': VerySimpleCase.cpp:(.gnu.linkonce.t._ZN5boost7archive18text_oarchive_implINS0_13text_oarchiveEE4saveINS0_23class_id_reference_typeEEEvRKT_+0x15): undefined reference to `boost::archive::basic_text_oarchive<boost::archive::text_oarchive>::newtoken()' /tmp/ccnNHOct.o: In function `void boost::archive::save_access::save_primitive<boost::archive::text_oarchive, boost::archive::class_id_reference_type>(boost::archive::text_oarchive&, boost::archive::class_id_reference_type const&)': VerySimpleCase.cpp:(.gnu.linkonce.t._ZN5boost7archive11save_access14save_primitiveINS0_13text_oarchiveENS0_23class_id_reference_typeEEEvRT_RKT0_+0x15): undefined reference to `boost::archive::detail::basic_oarchive::end_preamble()' /tmp/ccnNHOct.o: In function `void boost::archive::text_oarchive_impl<boost::archive::text_oarchive>::save<boost::archive::class_id_type>(boost::archive::class_id_type const&)': VerySimpleCase.cpp:(.gnu.linkonce.t._ZN5boost7archive18text_oarchive_implINS0_13text_oarchiveEE4saveINS0_13class_id_typeEEEvRKT_+0x15): undefined reference to `boost::archive::basic_text_oarchive<boost::archive::text_oarchive>::newtoken()' /tmp/ccnNHOct.o: In function `void boost::archive::save_access::save_primitive<boost::archive::text_oarchive, boost::archive::class_id_type>(boost::archive::text_oarchive&, boost::archive::class_id_type const&)': VerySimpleCase.cpp:(.gnu.linkonce.t._ZN5boost7archive11save_access14save_primitiveINS0_13text_oarchiveENS0_13class_id_typeEEEvRT_RKT0_+0x15): undefined reference to `boost::archive::detail::basic_oarchive::end_preamble()' /tmp/ccnNHOct.o: In function `void boost::archive::text_oarchive_impl<boost::archive::text_oarchive>::save<float>(float const&)': VerySimpleCase.cpp:(.gnu.linkonce.t._ZN5boost7archive18text_oarchive_implINS0_13text_oarchiveEE4saveIfEEvRKT_+0x15): undefined reference to `boost::archive::basic_text_oarchive<boost::archive::text_oarchive>::newtoken()'

1 0

[1.47] Serialization for std::tr1::unordered
by Jim Bell 17 Mar '11

17 Mar '11

Since we're talking about 1.47, I'd like to draw some attention to TR1 and serialization. I submitted a patch to serialize std::tr1::unordered, the std container not presently covered. <https://svn.boost.org/trac/boost/ticket/5265> Any chance of getting this into 1.47?

1 0

Maintainer of Boost.Bind and Boost.Lambda
by Thomas Heller 17 Mar '11

17 Mar '11

Hi all, Who are the maintainers of Boost.Bind and Boost.Lambda? I couldn't find a list of active maintainers of the different boost libraries. I think such a list would be great in general. Regards, Thomas

4 3

Boost profile for ODB
by Boris Kolpackov 17 Mar '11

17 Mar '11

Hi, I would like to briefly mention that we have released the Boost profile for ODB, an open-source object-relational mapping (ORM) system for C++. The Boost profile provides glue code that seamlessly integrates various Boost components, such as smart pointers, containers, and value types, with ODB. This initial release of the profile covers the most commonly used types from the smart_ptr, unordered, and date_time Boost libraries. For example, now we can easily persist a class like this: #pragma db object class employee { ... boost::gregorian::date born_; boost::unordered_set<std::string> emails_; boost::shared_ptr<employer> employer_; }; For a more detailed discussion of the Boost profile, see the following blog post: http://www.codesynthesis.com/~boris/blog/2011/03/16/odb-1-2-0-released/ Or refer directly to Part III, "Profiles" in the ODB Manual: http://www.codesynthesis.com/products/odb/doc/manual.xhtml#III Boris

1 0

[Review] Boost.Type Traits Extension by Frederic Bron
by Joachim Faulhaber 17 Mar '11

17 Mar '11

... went accidental to Boost-users only 2011/3/17 Joachim Faulhaber <afojgo(a)googlemail.com>: > 2011/3/17 Paul A. Bristow <pbristow(a)hetp.u-net.com>: >> * Some simpler (trivial even) examples might help newcomers to the library? >> The examples given are 'interesting' but quite complicated. > > Are there examples in the docs? > > As far as I can see, there is an example on the implementation only. > No examples on usage. They seem to be missing from the > libs/type_traits/example directory as well. > > Regards, > Joachim > > P.S.: Thanks to Frederic (and assisting operatorists) for this effort > and good teamwork. The library extension looks pretty well to me :) > > -- > Interval Container Library [Boost.Icl] > http://www.joachim-faulhaber.de

1 0

[asio] Read timeout and failures
by Mr. Robert G Palmer Jr. 17 Mar '11

17 Mar '11

I'm running boost v1.45 on WindowsXP SP3 I've read all the stuff on using async reads if you want a timeout and I'm going to switch to the from my current synchronous read code. However, I have a question regarding failures. I have been using a synchronous read_some() call. This states that it will return/throw an error/exception on an error condition. If I'm connected on a TCP socket to another device and I UNPLUG the network cable, does this not shutdown the socket and shouldn't the read_some() return/throw an error/exception. Unplugging the cable seems like an error condition to me, but in my case, the code just hangs at the read_some() call and never returns. Thanks, -- Robert G. Palmer, Jr. Ingenutec, LLC

2 2