March 2013 - Boost - lists.boost.org

[scope_exit] D-style scope(failure) and scope(success) in C++
by Evgeny Panasyuk 30 Sep '13

30 Sep '13

Hello all, D language has scope(exit), scope(success) and scope(failure) features - http://dlang.org/statement.html#ScopeGuardStatement : "... scope(exit) executes NonEmptyOrScopeBlockStatement when the scope exits normally or when it exits due to exception unwinding. scope(failure) executes NonEmptyOrScopeBlockStatement when the scope exits due to exception unwinding. scope(success) executes NonEmptyOrScopeBlockStatement when the scope exits normally. ..." Andrei Alexandrescu describes some of uses cases for scope(exit), scope(success), scope(failure) at his recent talk : http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/Three-Unlikely-Suc… There is Boost.ScopeExit library which emulates D's scope(exit) via BOOST_SCOPE_EXIT macro, but there are no analogues for D's scope(failure) and scope(success). Current alternative for these features is ScopeGuard idiom ( http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Scope_Guard , http://www.drdobbs.com/cpp/generic-change-the-way-you-write-excepti/1844037… ). Boost.ScopeExit library itself suggests to use ScopeGuard - http://www.boost.org/doc/libs/1_51_0/libs/scope_exit/doc/html/scope_exit/al… : " Boost.ScopeExit is similar to scope(exit) feature built into the D programming language. A curious reader may notice that the library does not implement scope(success) and scope(failure) of the D language. Unfortunately, these are not possible in C++ because failure or success conditions cannot be determined by calling std::uncaught_exception (see Guru of the Week #47 for details about std::uncaught_exception and if it has any good use at all). However, this is not a big problem because these two D's constructs can be expressed in terms of scope(exit) and a bool commit variable (similarly to some examples presented in the Tutorial section). " I have made small library ( https://github.com/panaseleus/stack_unwinding#d-style-scope-guardsactions ) which supplies primitives (class unwinding_indicator, UNWINDING_AWARE_DESTRUCTOR macro) to determining when object destructor is called due to stack-unwinding or due to normal scope leaving. Currently it is implemented on top of platform-specific implementation of uncaught_exception_count function and tested on: {MSVC2005, MSVC2008, MSVC2010, MSVC2012, GCC4.1.2, GCC4.4.6, Clang3.2}x{x32, x64}x{default settings}. uncaught_exception_count is a function similar to std::uncaught_exception from standard library, but instead of boolean result it returns unsigned int showing current count of uncaught exceptions. Such primitives allow us to implement scope(success) and scope(failure) features in C++. I have made several proof-of-concepts: * https://github.com/panaseleus/stack_unwinding/blob/master/examples/scope_ac… * https://github.com/panaseleus/stack_unwinding/blob/master/examples/example_… * https://github.com/panaseleus/stack_unwinding/blob/master/examples/scope_gu… * https://github.com/panaseleus/stack_unwinding/blob/master/examples/boost_sc… boost_scopes.cpp example shows usage of BOOST_SCOPE_FAILURE and BOOST_SCOPE_SUCCESS: try { cout << "Case #1: stack unwinding" << endl; BOOST_SCOPE_EXIT(void) { cout << "exit" << endl; } BOOST_SCOPE_EXIT_END BOOST_SCOPE_FAILURE(void) { cout << "failure" << endl; } BOOST_SCOPE_FAILURE_END BOOST_SCOPE_SUCCESS(void) { cout << "success" << endl; } BOOST_SCOPE_SUCCESS_END throw 1; } catch(int){} { cout << "Case #2: normal exit" << endl; BOOST_SCOPE_EXIT(void) { cout << "exit" << endl; } BOOST_SCOPE_EXIT_END BOOST_SCOPE_FAILURE(void) { cout << "failure" << endl; } BOOST_SCOPE_FAILURE_END BOOST_SCOPE_SUCCESS(void) { cout << "success" << endl; } BOOST_SCOPE_SUCCESS_END } Output is: " Case #1: stack unwinding failure exit Case #2: normal exit success exit " Currently BOOST_SCOPE_FAILURE and BOOST_SCOPE_SUCCESS are implemented based on boost_1_51_0/boost/scope_exit.hpp by copy-paste and replace (just for proof-or-concept, of course it is possible solution with much less duplication). Semantically meaningful changes can be viewed as diff at https://github.com/panaseleus/stack_unwinding/commit/d5513404323490ea99d9b6… Before posting here, I made posts on several C++ forums, but unfortunately get only a few feedbacks regarding ScopeFailure and ScopeSuccess. What do you think? Thank you. P.S. Related discussion: http://lists.boost.org/Archives/boost/2010/09/171051.php Best Regards, Evgeny Panasyuk

6 27

[thread] synchronized_value: value and move semantics
by Vicente J. Botet Escriba 24 Sep '13

24 Sep '13

Hi, boost::synchronized_value (not released yet [1][2][3]) is based on [4]. See below part of this paper adapted to the Boost.Thread interface. Currently boost::synchronized_value is in addition Copyable and Swappable. I was wondering if it is worth adding value and move semantics to synchronized_value. Making it EqualityComparable, LessThanComparable and Movable if the underlying type satisfy these requirements will allow to store them on a Boost.Container/C++11 container. Do you see something completely wrong with this addition? Has some of you had a need for this? Could you share the context? Best, Vicente [1] https://svn.boost.org/svn/boost/trunk/boost/thread/synchronized_value.hpp [2] https://svn.boost.org/svn/boost/trunk/libs/thread/example/synchronized_valu… [3] https://svn.boost.org/svn/boost/trunk/libs/thread/example/synchronized_pers… [4] "Enforcing Correct Mutex Usage with Synchronized Values" by Anthony Williams http://www.drdobbs.com/cpp/enforcing-correct-mutex-usage-with-synch/2252002… ------------- [section The Problem with Mutexes] The key problem with protecting shared data with a mutex is that there is no easy way to associate the mutex with the data. It is thus relatively easy to accidentally write code that fails to lock the right mutex - or even locks the wrong mutex - and the compiler will not help you. std::mutex m1; int value1; std::mutex m2; int value2; int readValue1() { boost::lock_guard<boost::mutex> lk(m1); return value1; } int readValue2() { boost::lock_guard<boost::mutex> lk(m1); // oops: wrong mutex return value2; } Moreover, managing the mutex lock also clutters the source code, making it harder to see what is really going on. The use of synchronized_value solves both these problems - the mutex is intimately tied to the value, so you cannot access it without a lock, and yet access semantics are still straightforward. For simple accesses, synchronized_value behaves like a pointer-to-T; for example: boost::synchronized_value<std::string> value3; std::string readValue3() { return *value3; } void setValue3(std::string const& newVal) { *value3=newVal; } void appendToValue3(std::string const& extra) { value3->append(extra); } Both forms of pointer dereference return a proxy object rather than a real reference, to ensure that the lock on the mutex is held across the assignment or method call, but this is transparent to the user. [endsect] [/The Problem with Mutexes] [section Beyond Simple Accesses] The pointer-like semantics work very well for simple accesses such as assignment and calls to member functions. However, sometimes you need to perform an operation that requires multiple accesses under protection of the same lock, and that's what the synchronize() method provides. By calling synchronize() you obtain an strict_lock_ptr object that holds a lock on the mutex protecting the data, and which can be used to access the protected data. The lock is held until the strict_lock_ptr object is destroyed, so you can safely perform multi-part operations. The strict_lock_ptr object also acts as a pointer-to-T, just like synchronized_value does, but this time the lock is already held. For example, the following function adds a trailing slash to a path held in a synchronized_value. The use of the strict_lock_ptr object ensures that the string hasn't changed in between the query and the update. void addTrailingSlashIfMissing(boost::synchronized_value<std::string> & path) { boost::strict_lock_ptr<std::string> u=path.synchronize(); if(u->empty() || (*u->rbegin()!='/')) { *u+='/'; } } [endsect] [/Beyond Simple Accesses] [section Operations Across Multiple Objects] Though synchronized_value works very well for protecting a single object of type T, nothing that we've seen so far solves the problem of operations that require atomic access to multiple objects unless those objects can be combined within a single structure protected by a single mutex. One way to protect access to two synchronized_value objects is to construct a strict_lock_ptr for each object and use those to access the respective protected values; for instance: synchronized_value<std::queue<MessageType> > q1,q2; void transferMessage() { strict_lock_ptr<std::queue<MessageType> > u1 = q1.synchronize(); strict_lock_ptr<std::queue<MessageType> > u2 = q2.synchronize(); if(!u1->empty()) { u2->push_back(u1->front()); u1->pop_front(); } } This works well in some scenarios, but not all - if the same two objects are updated together in different sections of code then you need to take care to ensure that the strict_lock_ptr objects are constructed in the same sequence in all cases, otherwise you have the potential for deadlock. This is just the same as when acquiring any two mutexes. In order to be able to use the dead-lock free lock algorithms we need to use instead unique_lock_ptr, which is Lockable. synchronized_value<std::queue<MessageType> > q1,q2; void transferMessage() { unique_lock_ptr<std::queue<MessageType> > u1 = q1.unique_synchronize(boost::defer_lock); unique_lock_ptr<std::queue<MessageType> > u2 = q2.unique_synchronize(boost::defer_lock); boost::lock(u1,u2); // dead-lock free algorithm if(!u1->empty()) { u2->push_back(u1->front()); u1->pop_front(); } } [endsect] [/Operations Across Multiple Objects]

6 19

[asio] Randomly having problems reading from the socket
by Torben Wiggerich 29 Jul '13

29 Jul '13

Hi all, I have some problems using the boost.asio.read for a TCP-socket. So far it works fine, but it randomly stops the transfer for at least 5 seconds. To resolve the error I used a simple synchronous server and client from the boost examples and modified it too send a larger amount of data. (307400 Bytes; this size comes from the program I'm trying to get run). On the client side I also changed the reading from the socket to read the complete data with boost.asio.read and transfer_all as argument. Both, server and client, measure the time for sending and reading to the socket and will give an error if it needs more than 1 second. Here is the sourcecode for the server: #include <iostream> #include <string> #include <boost/asio.hpp> #include <boost/date_time/posix_time/posix_time.hpp> using boost::asio::ip::tcp; using namespace boost::posix_time; int main() { try { boost::asio::io_service io_service; tcp::acceptor acceptor(io_service, tcp::endpoint(tcp::v4(), 8002)); tcp::socket socket(io_service); acceptor.accept(socket); unsigned char * array = new unsigned char[307400]; for (;;) { boost::system::error_code ignored_error; ptime startTime = microsec_clock::universal_time(); boost::asio::write(socket, boost::asio::buffer( array, 307400 ), boost::asio::transfer_all(), ignored_error); time_duration neededTime = microsec_clock::universal_time() - startTime; if ( neededTime.total_milliseconds() > 1000 ) { std::cout << "ERROR needed too much time: " << neededTime.total_milliseconds() << "ms" << std::endl; } } } catch (std::exception& e) { std::cerr << e.what() << std::endl; } return 0; } My client sourcecode: #include <iostream> #include <boost/array.hpp> #include <boost/asio.hpp> #include <boost/date_time/posix_time/posix_time.hpp> using boost::asio::ip::tcp; using namespace boost::posix_time; int main(int argc, char* argv[]) { try { if (argc != 2) { std::cerr << "Usage: client <host>" << std::endl; return 1; } boost::asio::io_service io_service; boost::asio::ip::tcp::endpoint endpoint( boost::asio::ip::address::from_string( argv[1] ), 8002 ); tcp::socket socket(io_service); boost::system::error_code error = boost::asio::error::host_not_found; socket.connect( endpoint, error ); if (error) throw boost::system::system_error(error); int counter = 0; unsigned char* array = new unsigned char[307400]; for (;;) { boost::system::error_code error; ptime startTime = microsec_clock::universal_time(); size_t len = boost::asio::read( socket, boost::asio::buffer( array, 307400 ), boost::asio::transfer_all(), error ); time_duration neededTime = microsec_clock::universal_time() - startTime; if ( error ) { printf( "body read error %s\n", error.message().c_str() ); } if ( counter % 5000 == 0 ) { std::cout << "passed: " << counter << "\r"; } ++counter; if ( neededTime.total_milliseconds() > 1000 ) { std::cout << "ERROR needed too much time: " << neededTime.total_milliseconds() << "ms" << std::endl; } } } catch (std::exception& e) { std::cerr << e.what() << std::endl; } return 0; } To reproduce the error just let it run for a while. It can take up to 30 minutes or even more... After a while it will produce the line: "ERROR needed too much time: 5007ms". Maybe with slightly different times, but all around 5 seconds. I tested it on different machines with Windows Vista and Seven. So am I'm doing sth. wrong? Is the reading from the socket correct? I'm using boost version 1.44. Kind regards Torben Wiggerich

6 12

safe bool not safe enough ?
by John Maddock 28 Jul '13

28 Jul '13

Just discovered (oops!) that the so called safe bool ideom is not as safe as it appears, for example: class Testable { bool ok_; typedef void (Testable::*bool_type)() const; void this_type_does_not_support_comparisons() const {} public: explicit Testable(bool b=true):ok_(b) {} operator bool_type() const { return ok_==true ? &Testable::this_type_does_not_support_comparisons : 0; } }; Testable t(true); bool b = t; // Compiles OK - Ooops! Which is causing multiprecision to misbehave when used in conjunction with uBlas: https://svn.boost.org/trac/boost/ticket/8292#comment:2 I guess making the conversion explicit in C++11 mode would help (I still need to test that), but is there a C++03 solution? Thanks, John.

4 9

A more convenient Variant visitation syntax
by Kevin Wu Won 19 Jul '13

19 Jul '13

While Boost Variant is a wonderful library that fills a genuine hole in the C++ language, it is not as nice to use as it could be. The "correct" way to unwrap a variant is to apply a static visitor, but this method carries a high syntactic burden because it needs the user to define a class (probably somewhere far away) just so they can "switch" on the type of the object stored in the variant. I came up with a solution where the handler functions can be specified inline with C++11 lambdas. Here's an example: boost::variant< int, std::string > u("hello world"); int result = match(u, [](int i) -> int { return i; }, [](const std::string & str) -> int { return str.length(); }); The `match` function accepts the variant followed by the handler functions. The functions can be specified in any order. It will fail to compile if the functions do not match the types of the variant, if the return types are not all the same, or if a non-unary function is supplied. This is C++11 only because it's quite pointless without lambda functions. I've tested it with gcc 4.7. It doesn't work on gcc 4.6, which can't handle the variadic templates. Here's the code: https://github.com/exclipy/inline_variant_visitor What do you think? This started out for me as an exercise to learn template metaprogramming and C++11, but hopefully, it can actually evolve into something useful.

7 8

Static initialization of boost shared objects question
by Juan Carlos Franzoy 02 Jul '13

02 Jul '13

Hello. Thanks for reading my question. I fell into a deadlock in static initialization of boost shared objects. The deadlock occurs in a reentrant call to a function which contains a definition of a static variable. Apparenlty gcc protects the initialization of such variables with a condition variable. Looking at the c++ code nothing at all make anybody suspect about reentrancy. My "interpretation of the fact" may be titled 'something in gcc, ld, ld.so, c++language made the call to be reentrant' - There is a function boost::system::generic_category() that has a static variable V - V type is boost::system::annonymous-namespace::generic_error_category - boost::system::annonymous-namespace::generic_error_category is subclass of boost::system::error_category. - boost::system::annonymous-namespace::generic_error_category has no declared/defined constructor as well as all its superclasses - The compilation process generate the constructor boost::system::error_category::error_category() as a weak symbol inside every shared object that uses it. - There is a static variable boost::system::posix_category in one of the shared objects that is initialized calling boost::system::generic_category(). - when the static initialization of a shared object boost::system::posix_category get initialized - which calls boost::system::generic_category() - Inside boost::system::generic_category() starts the initialization of V which calls boost::system::error_category::error_category() - It may happend that the runtime calls an instance of boost::system::error_category::error_category() that resides in a shared object that is still not loaded - So that .so get loaded and it is called its own static initialization - which can call boost::system::generic_category() - BOOM I would love if you can confirm of refute my humble "interpretation". Details follows ------------------- boost version: 1-52-0 Operating system: uname -a SunOS bcpp-solaris10 5.10 Generic_147441-25 i86pc i386 i86pc $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/export/home/local/gcc-4.6.2/libexec/gcc/i386-pc-solaris2.10/4.6.2/lto-wrapper Target: i386-pc-solaris2.10 Configured with: ../src/gcc-4.6.2/configure --prefix=/export/home/local/gcc-4.6.2 --with-gmp=/export/home/local/gcc-4.6.2/gmp-4.3.2 --with-mpfr=/export/home/local/gcc-4.6.2/mpfr-3.0.0 --with-mpc=/export/home/local/gcc-4.6.2/mpc-0.8.2 --with-libelf=/export/home/local/gcc-4.6.2/libelf-0.8.12 --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --enable-languages=c,c++ --with-as=/usr/local/bin/as --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-plugin --enable-multilib --enable-version-specific-runtime-libs --enable-bootstrap --enable-ssp --enable-libssp --with-included-gettext --enable-lto --host=i386-pc-solaris2.10 --build=i386-pc-solaris2.10 Thread model: posix gcc version 4.6.2 (GCC) Callstack backtrace (lines begining with = are my comments): = = deadlock here: the threads is waiting itself = #0 0xfd459019 in __lwp_park () from /lib/libc.so.1 #1 0xfd45365e in cond_sleep_queue () from /lib/libc.so.1 #2 0xfd453817 in cond_wait_queue () from /lib/libc.so.1 #3 0xfd453b94 in cond_wait_common () from /lib/libc.so.1 #4 0xfd453d02 in _cond_wait () from /lib/libc.so.1 #5 0xfd453d2d in cond_wait () from /lib/libc.so.1 #6 0xfd453d66 in pthread_cond_wait () from /lib/libc.so.1 #7 0xfd632898 in __gthread_cond_wait (g=0xfd822ea8) at ...build-gcc/out/i386-pc-solaris2.10/libstdc++-v3/include/i386-pc-solaris2.10/bits/gthr-default.h:846 #8 __gthread_cond_wait_recursive (g=0xfd822ea8) at ...work/build-gcc/out/i386-pc-solaris2.10/libstdc++-v3/include/i386-pc-solaris2.10/bits/gthr-default.h:860 #9 __gnu_cxx::__cond::wait_recursive (g=0xfd822ea8) at ...build-gcc/out/i386-pc-solaris2.10/libstdc++-v3/include/ext/concurrence.h:377 #10 __cxa_guard_acquire (g=0xfd822ea8) at .../src/gcc-4.6.2/libstdc++-v3/libsupc++/guard.cc:289 = = Reentrant call to boost::system::generic_category() = #11 0xfd812313 in boost::system::generic_category () at libs/system/src/error_code.cpp:425 #12 0xfe85cd38 in __static_initialization_and_destruction_0(__initialize_p=1, __priority=65535) at ./boost/system/error_code.hpp:214 #13 0xfe85d05f in _GLOBAL__sub_I_instantiate_re2c_lexer_str.cpp () at libs/wave/src/instantiate_re2c_lexer_str.cpp:56 = = static initization of boost.wave library = #14 0xfe8868fd in __do_global_ctors_aux () from ...boost/lib/libboost_wave-gcc46-mt-d-32-SOLARIS-X86-1_52.so.1.52.0 #15 0xfe88692a in _init () from ...boost/lib/libboost_wave-gcc46-mt-d-32-SOLARIS-X86-1_52.so.1.52.0 #16 0xfefce37e in call_init () from /usr/lib/ld.so.1 #17 0xfefce1cf in is_dep_init () from /usr/lib/ld.so.1 #18 0xfefdaa4b in elf_bndr () from /usr/lib/ld.so.1 #19 0xfefc2ab4 in elf_rtbndr () from /usr/lib/ld.so.1 #20 0xfee60688 in ?? () #21 0xfee0c8f6 in boost::exception_detail::get_static_exception_object<boost::exception_detail::bad_alloc_>() at ./boost/exception/detail/exception_ptr.hpp:119 #22 0xfee0c0d2 in __static_initialization_and_destruction_0(__initialize_p=1, __priority=65535) at ./boost/exception/detail/exception_ptr.hpp:138 #23 0xfee0c271 in _GLOBAL__sub_I_future.cpp () at libs/thread/src/future.cpp:60 = = static initization of boost.thread library = #24 0xfee0d98d in __do_global_ctors_aux () from ...boost/lib/libboost_thread-gcc46-mt-d-32-SOLARIS-X86-1_52.so.1.52.0 #25 0xfee0d9ba in _init () from ...boost/lib/libboost_thread-gcc46-mt-d-32-SOLARIS-X86-1_52.so.1.52.0 #26 0xfefce37e in call_init () from /usr/lib/ld.so.1 #27 0xfefce1cf in is_dep_init () from /usr/lib/ld.so.1 #28 0xfefdaa4b in elf_bndr () from /usr/lib/ld.so.1 #29 0xfefc2ab4 in elf_rtbndr () from /usr/lib/ld.so.1 #30 0xfdce0688 in ?? () = = First calll to boost::system::generic_category() = #31 0xfd81232a in boost::system::generic_category () at libs/system/src/error_code.cpp:425 #32 0xfd812386 in __static_initialization_and_destruction_0(__initialize_p=1, __priority=65535) at ./boost/system/error_code.hpp:214 #33 0xfd8123ed in _GLOBAL__sub_I_error_code.cpp () at libs/system/src/error_code.cpp:430 = = static initialization of boost.system = #34 0xfd8126ed in __do_global_ctors_aux () from ...boost/lib/libboost_system-gcc46-mt-d-32-SOLARIS-X86-1_52.so.1.52.0 #35 0xfd81271a in _init () from ...boost/lib/libboost_system-gcc46-mt-d-32-SOLARIS-X86-1_52.so.1.52.0 #36 0xfefce37e in call_init () from /usr/lib/ld.so.1 #37 0xfefcd7d5 in setup () from /usr/lib/ld.so.1 #38 0xfefdba3e in _setup () from /usr/lib/ld.so.1 #39 0xfefc299c in _rt_boot () from /usr/lib/ld.so.1 #40 0x08047540 in ?? () #41 0x08047670 in ?? () More thanks for reading all.

3 4

De Bruijn Bind (alternate bind syntax) Interest?
by David Sankel 23 Jun '13

23 Jun '13

Hello all, I've been working on an alternate bind syntax based on De Bruijn indices[1]. The syntax is very simple, yet the terms are very powerful. Here is an example of a function const that takes in an argument c and returns another function that, for all input, returns c: //λx.λy.x = λλ1 with De Bruijn indices. auto const_ = abs<1>( abs<1>( var<1,0>() ) ); More examples, further explanation, and an implementation are available here[2]. I'm thinking that this library could also be useful as a core for more syntax heavy bind variations. David [1] http://en.wikipedia.org/wiki/De_Bruijn_index [2] http://bitbucket.org/camior/de-bruijn-bind/ -- David Sankel Sankel Software www.sankelsoftware.com 585 617 4748 (Office)

11 73

[gil] Ok to merge new gil's extension to release branch?
by Christian Henning 19 May '13

19 May '13

Hi, is it ok? The merge would include io, toolbox, numerics and some other changes to gil's code itself. Regards, Christian

6 92

[bootstrap/1.53] jam0.exe crashes when bootstrapping for VC2012 AMD64
by rjeczalik 10 May '13

10 May '13

Hi, I'm trying to build Boost 1.53 using VC2012 amd64 (toolset=msvc-11.0 address-model=64) and Windows Server 2012 Standard. Bootstrapping fails with jam0.exe crash - some crash info: Crash stacktrace: ntdll.dll!000007f9bc781069() KernelBase.dll!000007f9b978764e() KernelBase.dll!000007f9b97d3658() jam0.exe!_findnext64i32(__int64 hFile, _finddata64i32_t * pfd) Line 165 jam0.exe!file_dirscan(_object * dir, void (void *, _object *, int, __int64) * func, void * closure) Line 180 jam0.exe!builtin_glob(frame * frame, int flags) Line 718 jam0.exe!function_run(_function * function_, frame * frame, _stack * s) Line 3390 jam0.exe!evaluate_rule(_object * rulename, frame * frame) Line 264 jam0.exe!function_call_rule(_jam_function * function, frame * frame, _stack * s, int n_args, const char * unexpanded, _object * file, int line) Line 468 jam0.exe!function_run(_function * function_, frame * frame, _stack * s) Line 3950 jam0.exe!parse_file(_object * f, frame * frame) Line 57 jam0.exe!main(int argc, char * * argv, char * * arg_environ) Line 488 jam0.exe!__tmainCRTStartup() Line 241 jam0.exe!mainCRTStartup() Line 164 kernel32.dll!000007f9b9de167e() ntdll.dll!000007f9bc7a3501() Line where it crashed was: if (!FindNextFile((HANDLE)hFile, &wfd)) { I've tried to watch the values of arguments passes to FindNextFile() - hFile looked like proper handle, however wfd.cFileName and wfd.cAlternateFileName contained garbage. Is this a known issue for 1.53? I've compiled version 1.52 using the same environment and the same configuration and everything went ok, I did not manage to reproduce the crash. It looks like only version 1.53 is affected. Regards, Rafael Jeczalik

5 5

[TypeErasure] references
by Chapman, Alec 09 May '13

09 May '13

Hi Steven, I have a somewhat-generic type erasure class that I would like to switch to yours. The main difficulty I can see is in the way capturing by reference is handled. The approach I take in my class is to pass a boost::reference_wrapper to the constructor: typedef mpl::vector<copy_constructible<>, type_id_<>, incrementable<> > requirements; int i = 0; any<requirements> x(boost::ref(i)); // capture i by reference ++x; // i == 1 any<requirements> y(x); // makes a copy of i ++y; // i == 1, any_cast<int>(y) == 2 My motivation is that I have a bunch of template functions already written that I often call directly, but in other cases I need to compile them separately by instantiating them with any<...>: ---------------------- module 1 ------------------------- // some long algorithm that I don't want to modify to be aware of any<...> template<class T> void f(T& t) { ++t; T t2 = t; ++t2; // do something with t2 } // make a type-erased version for separate compilation void any_f(any<requirements>& x) { return f(x); } -------------------- module 2 ---------------------------- // provide a thin wrapper that applies type erasure before calling any_f template<class T> void f_fwd(T& t) { any<requirements> x(boost::ref(t)); any_f(x); } // some function that needs to call f void g(int& i) { // do something with i... // then pass it to f f_fwd(i); } Is something like this possible with your method? Are there advantages that I'm not seeing to having the type signature contain information about whether the object is held by reference? Thanks, Alec

3 6