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

BOOST_PP_ENUM_z
by er 17 May '11

17 May '11

Could someone please help clarify the meaning of the _z extension? In what situation should one use BOOST_PP_ENUM_z rather than BOOST_PP_ENUM? Usage BOOST_PP_ENUM_ ## z(count, macro, data) Arguments z The next available BOOST_PP_REPEAT dimension. http://www.boost.org/doc/libs/1_33_1/libs/preprocessor/doc/ref/enum_z.html Examples: #include <boost/preprocessor/arithmetic/inc.hpp> #include <boost/preprocessor/repetition/enum_params.hpp> #include <boost/preprocessor/repetition/repeat.hpp> #define MACRO(z, n, _) \ template< \ BOOST_PP_ENUM_PARAMS_Z(z, BOOST_PP_INC(n), class T) \ > class X ## n { \ /* ... */ \ }; \ /**/ BOOST_PP_REPEAT(2, MACRO, nil) #define MACRO1(z, n, _) \ template< \ BOOST_PP_ENUM_PARAMS(BOOST_PP_INC(n), class T) \ > class Y ## n { \ /* ... */ \ }; \ /**/ BOOST_PP_REPEAT(2, MACRO1, nil) int main (int argc, char * const argv[]) { typedef X0<int> x0; typedef X1<int, int> x1; typedef Y0<int> y0; typedef Y1<int, int> y1; return 0; }

2 1

Re: [Boost-users] [interprocess] Lost communications and mysterious names
by Roger 17 May '11

17 May '11

> From: "Ion Gaztañaga" <igaztanaga(a)gmail.com> > To: Boost User List <boost-users(a)lists.boost.org> > Date: Wed, 11 May 2011 21:20:54 +0200 > Subject: Re: [Boost-users] [interprocess] Lost communications and mysterious names > El 10/05/2011 23:18, Roger escribió: >> >> I'm using boost 1.46 on windows XP and I am having occasional issues >> with interprocess. Sometimes I lose communications between programs. >> I've located the directory where the files that enable the >> interprocess communication are created. Usually the files have the >> name I provide to the managed_shared_memory object in the code. >> However, when the problem occurs a file named something like >> "70C0A8E6490FCC01E55D313B550FCC01" appears. When the programs >> terminate this file disappears, while the normally named files >> persist. > > That name is produced when you unlink the shared memory. Code renames in-use file and marks it as delete-on-close so that it's really erased when any attached program ends. This emulates unix-like unlink behaviour. Are you unlinking the shm while in use? > > best, > > Ion I was using shared_memory_object::remove(name), if that's what you mean by unlinking. Actually I'd already solved my problem before I even asked the question - I just accidentally commented that bit out. What I was doing was periodically reopening the shared memory in processes that were reading only. So if another process removed and recreated it, it would eventually find the new copy. Is this a sensible way to do it? Is there a function to test whether the memory has been removed? The only reason I was recreating the shared memory was to ensure a cleanly initialised empty space. Perhaps I should turf the whole recreating process and go with a clearing process instead. That should be fine once what I'm sharing is fixed. But during development it can change, and I recall the programs crashing if they open an old file and try to read a variable which wasn't there in the old version.

2 1

Compiling Issue
by Manoj Jangid 16 May '11

16 May '11

I am trying to compile a small boost thread sample in Windows 64 bit, its give me an error *LINK : fatal error LNK1104: cannot open file 'libboost_thread-vc100-mt-s-1_46_1.lib' *I have searched all the folder, rebuild boost with bjam but there is no *'libboost_thread-vc100-mt-s-1_46_1.lib' * Here is the output C:\personal\boost>cl /W3 /Zi /EHsc thread.cpp Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for x64 Copyright (C) Microsoft Corporation. All rights reserved. thread.cpp Microsoft (R) Incremental Linker Version 10.00.40219.01 Copyright (C) Microsoft Corporation. All rights reserved. /out:thread.exe /debug thread.obj LINK : fatal error LNK1104: cannot open file 'libboost_thread-vc100-mt-s-1_46_1.lib' What I am missing or doing wrong here? Thanks

1 0

xpressive
by Louis Lavery 16 May '11

16 May '11

I'm trying to get started with boost xpressive, but have problems with this simple attempt... #pragma warning(disable:4180) // MSVC: qualifier applied to function type has no meaning; ignored #pragma warning(disable:4224) // MSVC: nonstandard extension used : formal parameter 'value' was previously defined as a type #pragma warning(disable:4996) // MSVC: 'std::transform' was declared deprecated #include <boost/xpressive/xpressive_static.hpp> void f() { using namespace boost::xpressive; sregex rex = as_xpr('k'); } ...which gives these errors... ------ Build started: Project: miscTest, Configuration: Debug Win32 ------ Compiling... main.cpp c:\boost_1_45_0\boost\xpressive\detail\static\transforms\as_matcher.hpp(27) : error C2146: syntax error : missing ';' before identifier 'data_type' c:\boost_1_45_0\boost\xpressive\detail\static\transforms\as_sequence.hpp(31) : see reference to class template instantiation 'boost::xpressive::grammar_detail::as_matcher::impl<Expr,State,Data>' being compiled with [ Expr=const boost::proto::exprns_::expr<boost::proto::tag::terminal,boost::proto::argsns_::term<char>,0> &, State=boost::xpressive::detail::end_xpression, Data=boost::xpressive::detail::xpression_visitor<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>,boost::mpl::false_,traits_type> ] c:\boost_1_45_0\boost\proto\matches.hpp(828) : see reference to class template instantiation 'boost::xpressive::grammar_detail::in_sequence<Grammar>::impl<Expr,State,Data>' being compiled with [ Grammar=boost::xpressive::grammar_detail::as_matcher, Expr=const boost::proto::exprns_::expr<boost::proto::tag::terminal,boost::proto::argsns_::term<char>,0> &, State=boost::xpressive::detail::end_xpression, Data=boost::xpressive::detail::xpression_visitor<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>,boost::mpl::false_,traits_type> ] c:\boost_1_45_0\boost\xpressive\detail\static\compile.hpp(45) : see reference to class template instantiation 'boost::proto::switch_<Cases>::impl<Expr,State,Data>' being compiled with [ Cases=boost::xpressive::grammar_detail::Cases<char,boost::xpressive::Grammar<char>>, Expr=const boost::proto::exprns_::expr<boost::proto::tag::terminal,boost::proto::argsns_::term<char>,0> &, State=boost::xpressive::detail::end_xpression, Data=visitor_type & ] c:\boost_1_45_0\boost\xpressive\detail\static\compile.hpp(79) : see reference to function template instantiation 'void boost::xpressive::detail::static_compile_impl2<Xpr,BidiIter,traits_type>(const Xpr &,const boost::shared_ptr<T> &,const Traits &)' being compiled with [ Xpr=boost::proto::exprns_::expr<boost::proto::tag::terminal,boost::proto::argsns_::term<char>,0>, BidiIter=std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>, T=boost::xpressive::detail::regex_impl<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>>, Traits=traits_type ] c:\boost_1_45_0\boost\xpressive\detail\static\compile.hpp(99) : see reference to function template instantiation 'void boost::xpressive::detail::static_compile_impl1<Xpr,BidiIter>(const Xpr &,const boost::shared_ptr<T> &)' being compiled with [ Xpr=boost::proto::exprns_::expr<boost::proto::tag::terminal,boost::proto::argsns_::term<char>,0>, BidiIter=std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>, T=boost::xpressive::detail::regex_impl<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>> ] c:\boost_1_45_0\boost\xpressive\basic_regex.hpp(252) : see reference to function template instantiation 'void boost::xpressive::detail::static_compile<Expr,BidiIter>(const Xpr &,const boost::shared_ptr<T> &)' being compiled with [ Expr=boost::proto::exprns_::expr<boost::proto::tag::terminal,boost::proto::argsns_::term<char>,0>, BidiIter=std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>, Xpr=boost::proto::exprns_::expr<boost::proto::tag::terminal,boost::proto::argsns_::term<char>,0>, T=boost::xpressive::detail::regex_impl<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>> ] c:\boost_1_45_0\boost\xpressive\basic_regex.hpp(118) : see reference to function template instantiation 'void boost::xpressive::basic_regex<BidiIter>::compile_<Expr>(const Expr &,boost::mpl::true_)' being compiled with [ BidiIter=std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>, Expr=boost::proto::exprns_::expr<boost::proto::tag::terminal,boost::proto::argsns_::term<char>,0> ] c:\othertrunk\other\misc\src\main.cpp(12) : see reference to function template instantiation 'boost::xpressive::basic_regex<BidiIter>::basic_regex<boost::proto::exprns_::expr<Tag,Args,Arity>>(const Expr &)' being compiled with [ BidiIter=std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>, Tag=boost::proto::tag::terminal, Args=boost::proto::argsns_::term<char>, Arity=0, Expr=boost::proto::exprns_::expr<boost::proto::tag::terminal,boost::proto::argsns_::term<char>,0> ] c:\boost_1_45_0\boost\xpressive\detail\static\transforms\as_matcher.hpp(27) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int c:\boost_1_45_0\boost\xpressive\detail\static\transforms\as_matcher.hpp(27) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int c:\boost_1_45_0\boost\xpressive\detail\static\transforms\as_matcher.hpp(30) : error C2653: 'data_type' : is not a class or namespace name c:\boost_1_45_0\boost\xpressive\detail\static\transforms\as_matcher.hpp(30) : fatal error C1903: unable to recover from previous error(s); stopping compilation Build log was saved at "file://c:\otherTrunk\libs\misc\test\vc\Debug\BuildLog.htm" miscTest - 5 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== tia, Louis.

5 9

Boost-serialization "unsupported version" exception
by Marco Piacentini 16 May '11

16 May '11

Hi guys...I have this scenario...A client which uses the version 1.46.1 of boost and serializes some structs, and a server which (must)uses the version 1.38 of boost. The problem is that when I try to deserialize the data on the server side, I've got the "unsupported version" exception... Is there any way to serialize with a downgrade version?Other suggestions?Thanks in advance...

1 0

[boost-users][GIL] Colors broken after moving to New IO
by Szymon Gatner 15 May '11

15 May '11

Hi, Since New IO is now accepted to BOOST I could replace old one with new version (review one). Problem is, the moment I replaced header file and png_load_file() to load_image() all images have invalid colors. Am I doing to little by just replacing those 2? Regadrds, Szymon

3 13

Stack over flow error in the Chrobak_Payne_drawing.hpp
by Nishchal Devnur 14 May '11

14 May '11

> Hi All, > > I am trying to use the Chrobak_Payne_straight_line_drawing function to get > a straight line drawing of a biconnected and maximally planar graph. But I > am getting a stackoverflow error in the the Chrobak_Payne_drawing.hpp file. > https://docs.google.com/leaf?id=0B4H5FyR7-PhTYTg1ZmFjNDctNmE1ZC00NzYyLWIwM2… is the link to the screenshot of the stacktrace. The accumulate_offset > in the hpp file is being recursively called and hence the stackoverflow. I > am not sure whats the cause of this error. > > Here is the piece of my code : > > embedding_storage_t embedding_storage2(num_vertices(tempGraph)); > embedding_t embedding2(embedding_storage2.begin(), > get(vertex_index,tempGraph)); > isplanar = boyer_myrvold_planarity_test(boyer_myrvold_params::graph = > tempGraph, > boyer_myrvold_params::embedding = > &embedding2[0] > ); > // Find a canonical ordering > typedef std::vector<graph_traits<Graph>::vertex_descriptor> > ordering_storage_t; > ordering_storage_t ordering; > > planar_canonical_ordering(tempGraph, embedding2, > std::back_inserter(ordering)); > ordering_storage_t::iterator oi; > for ( oi = ordering.begin();oi!=ordering.end();oi++) > cout<<*oi<<endl; > > //Set up a property map to hold the mapping from vertices to coord_t's > typedef std::vector< planar_coord > straight_line_drawing_storage_t; > typedef boost::iterator_property_map > <straight_line_drawing_storage_t::iterator,property_map<Graph, > vertex_index_t>::type> straight_line_drawing_t; > > straight_line_drawing_storage_t > straight_line_drawing_storage(num_vertices(tempGraph)); > straight_line_drawing_t > straight_line_drawing(straight_line_drawing_storage.begin(),get(vertex_index,tempGraph)); > > chrobak_payne_straight_line_drawing(tempGraph, > embedding2, > ordering.begin(), > ordering.end(), > straight_line_drawing > ); > > Also the same code works in some cases when the size of the graphs is > small, but as the size of the graph grows I am getting this stackoverflow > error. Could anyone kindly letme know why this error occurs and if there is > any other extra care I need to take care off ? > > Thanks, > Nishchal. > -- Nishchal Devanur

3 3

Error closing an asio::socket
by Claude 14 May '11

14 May '11

Hello. In a program server in c++ I create an asio::socket and I listen it on a port (myPortNumber). Then I connect to my program using telnet (linux) with: telnet localhost myPortNumber The communication works fine, except that when I close the terminal window, the server closes with an error message: "terminate called without an active exception Aborted Process returned 134 (0x86)" Why? How can I prevent the server program is interrupted? -- View this message in context: http://boost.2283326.n4.nabble.com/Error-closing-an-asio-socket-tp3521153p3… Sent from the Boost - Users mailing list archive at Nabble.com.

2 3

[asio] How socket::shutdown() safe is within multithreaded usage?
by Slav 14 May '11

14 May '11

Hello, my server runs single io_service and asynchronosly accepts incoming connections (creating new sockets for each incoming connection). Usage of connection happens in such ways: - calls to socket::async_write() from multiple threads (embraced to mutex) at any time - handling socket::acync_read() (which runs within io_service' thread as I understand the documentation) - single call to socket::shutdown() at any moment from some other thread Previusly I used multiple of mutexes to cleanly wait for all current asynchronous read/write handlers: write function incremented "writes" variable which then was used on socket shutdown to wait the same amount of write handlers - but deadlock sometimes happend at moment of waiting write handlers. So I referred to socket::shutdown()'s documentation which say "Any asynchronous send, receive or connect operations will be cancelled immediately" - and don't wait any asynchronous operations for now and everything seems to work fine for now (what scares me). Is it safe to do so? How must I safely handle all currenlty running asynchronous read/write handlers? In case of boost.asio waits for all asynchronous operations to stop inside socket::shutdown/close so, then, if to call it within one of such operations - deadlock will (theoretically must) happen - so, socket::close/shutdown isn't safe? Thank you.

1 0

Boost.Context review result
by Vicente BOTET 14 May '11

14 May '11

Hi, this was my first experience as review manager and it has been more difficult than I had expected. Apologies if I forget some important things or I misunderstood others. I hope that the major points have been taken in account. Here it is the result of the Boost.Context review. The library is accepted provisionally and will need to address some mandatory points before a mini review (4/5 days). There were not too much complete reviews (5) but globally all the reviewers voted for acceptation and two subject to some major redesign modifications. I hope I didn't miss somebody. YES Gordon Woodhull YES/Cnd Giovanni Piero Deretta YES Artyom YES Nat Linden YES Phil Endecott YES/Cnd, Jeffrey Lee Hellrung, Jr Thanks to all the review participants Gordon Woodhull, Giovanni Piero Deretta , Artyom, Nat Linden, Holger Grund, Phil Endecott, Jeffrey Lee Hellrung, Jr.. Special thanks to Giovanni Piero Deretta showing some major flaws in the global design and Holger Grund for showing a (possible) major bug on the Windows implementation. I know Oliver that you have already redesigned your library, but if there are points that you have not been addressed yet or have some difficulties addressing them, I will suggest you to work closely with Giovanni, he know well the domain and have a lot of good ideas, and exchange on this ML. You should follow up more closely the discussions during the mini review and even try to get feedback from the ML posting how you see your redesigned library. Point to be addressed before the mini review: Design 1. Separation of the context class in two interface: - A C-like interface that defines a POD struct that is memcpy-able and that can be implemented either using platform libraries, as ucontext, fibers or directly using assembler when a robust implementation is available. The context swap implementation don't need to save the signals as ucontext does. The following is just for illustrations purposes. struct boost_context; typedef void boost_context_fn_t(intptr_t); extern "C" void boost_context_make(boost_context* ctx, boost_context_fn_t * f, intptr_t p, ...); extern "C" void boost_context_swap(boost_context* from, boost_context const* to); extern "C" intptr_t boost_context_destroy( boost_context* fc); boost_context_make is a merge of get_context with make_context + some fields assignations. "A user will have lower expectations from such a low level API and at the same time will give more freedom for other people to implement on top of it higher abstractions as Boost.Corutines, Boost.Fibers ..." - A non-copiable but movable safe context class on top of the low level C-like interface, that will provide modern and efficient C++ interface, that is usable by a user in a safe way. The safe context class would just be one of the client of the C-like interface, other library authors could either use the underlying C-like API directly or the class context depending on wether they need the speed or safety. * The context class will not be templated any more, and the use of type erasure will ensure that. * The constructor will accept any C++ callable, function pointers, functors, ... * At this high level interface, the function provided by the user could throw exceptions, and the library must wrap the user function and needs to store the exception raised and provide an interface to retrieve them. 2. The stack implementation must ensure that the stack is unwound before it is destroyed. A stack should only be safely deallocated if either has been completely unwound or if it doesn't own any resources. A basic stack without protection seems mandatory. For debug purposes it has been required to provide some stack usage functions that allow to know the max size used for example. Implementation 3. The assembler implementation on Windows must be disallowed if the ABI bug reported by Holger is confirmed. As far as Windows provides a fiber implementation that is as efficient as the assembler one, the assembler implementation is not mandatory and the user of the provided Windows fiber is a preferable choice. 4. Most of the 'throw' statements in the context class should actually be asserts. 5. The provided stack should be used to store any context parameters as far as no major impediment is found during the implementation. This will avoid further allocations on the safe context class. Documentation 6. The documentation is very minimalist and should be expanded with a discussion on context switching and use cases. Take care of all the grammar/spelling improvements suggested by the reviewers (It will be great if Jeffrey could review the documentation before the mini-review). Some user land examples should be provided (why not the yield example). 7. The concept of (Movable) Stack must be clearly defined, as it is done in the standard, using expression requirements with semantic constraints. 8. The assembler implementation should be carefully documented, so others could maintain the code and add other implementations if needed. 9. Some performance measure should be added. Providing the number of cycles on each implemented platform would be nice. Build system 10. The default build on a platform must work (It must be ABI compatible with the underlying platform) and take care of the specific features. Of course, the build needs to support cross compiling, so the user should be able to override the default values. Others points that are not required but that can make the library more usable or efficient: 1. The assembler implementations could be simplified if the context itself was represented as a single pointer to the top of the stack. This would save some instructions to move the source address from the stack return address to the context struct and back. 2. Instead of supporting a 'fc_link' a-la ucontext, have the callback function return a new context (it is void now). 'fc_link' is useful only on some limited cases (usually when you have an external scheduler managing your contexts), while the having the callback return the 'next continuation' has more applications (note that fc_link can be implemented easily in term of the continuation returning variant, but the reverse is harder). This will be very useful, for example, to implement some kind of 'exit_to' functionality (unwind the stack and restore another context), a key piece for safe context destruction. 3. Give to boost_context_swap the ability to exchange a parameter with the other context: boost_context_parm_t boost_context_swap( boost_context * ofc, boost_context const* nfc, boost_context_parm_t parm) where boost_context_parm_t is either union boost_context_parm_t { void * ptr; int int_; }; or simply intptr_t; boost_context_swap saves the current context in ocf and restores the context ncf as usual; additionally, if ofc was 'captured' on a call to boost_context_swap, this call will return the value of parm on the original context. This extra parameter is equivalent to the second parameter of longjmp. If ofc was created with boost_context_swap, 'parm' will be an extra parameter to the function. Note that this can be potentially implemented with little or no overhead. 4. Add a variant of boost_context_swap that allows executing a function on the destination context (in this case 'parm' would be passed parameter to this function. This is mostly useful for injecting an exception on the destination context. This can be potentially implemented on top of the existing functionality, but would slow down every context switch; a possible efficient implementation would manipulate the destination stack to add a call to the function on top of it, so that the cost is paid only when required. 5. Add a current context function (thread local). Vicente Review Manager

1 0