- Boost - lists.boost.org

Boost Test - yet more mostly spurious warnings.
by Paul A Bristow 13 Nov '05

13 Nov '05

To get quiet compilations (MSVC 8.0 release 140050727, level 4, no MS extensions), I have had to disable persistent warnings from boost\test\detail\test_tools.hpp by adding to supress_warning.hpp # pragma warning(disable: 4127) // conditional expression is constant. Entirely correct and expected. # pragma warning(disable: 4180) // qualifier applied to function type has no meaning; ignored at: const_string message() const { return !m_message ? const_string() : const_string( m_message->str() ); } ^^ const not useful? but not wrong. # pragma warning(disable: 4224) // nonstandard extension used : formal parameter 'tool_level' was previously defined as a type i:\boost_1_33_0\boost/test/test_tools.hpp(385) : warning C4224: nonstandard extension used : formal parameter 'tool_level' was previously defined as a type i:\boost_1_33_0\boost/test/test_tools.hpp(427) : warning C4224: nonstandard extension used : formal parameter 'tool_level' was previously defined as a type i:\boost_1_33_0\boost/test/test_tools.hpp(427) : warning C4224: nonstandard extension used : formal parameter 'tool_level' was previously defined as a type i:\boost_1_33_0\boost/test/test_tools.hpp(427) : warning C4224: nonstandard extension used : formal parameter 'tool_level' was previously defined as a type i:\boost_1_33_0\boost/test/test_tools.hpp(427) : warning C4224: nonstandard extension used : formal parameter 'tool_level' was previously defined as a type i:\boost_1_33_0\boost/test/test_tools.hpp(427) : warning C4224: nonstandard extension used : formal parameter 'tool_level' was previously defined as a type Is it complaining about re-using the name tool_level? void check_impl( predicate_result const& pr, wrap_stringstream& check_descr, const_string file_name, std::size_t line_num, tool_level tool_level, check_type ct, <<<<<<<<<<<<<< std::size_t num_args, ... ); Of these, only the latter might be worth worrying about? Still works fine, but if you are tidying up sometime... Paul -- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB Phone and SMS text +44 1539 561830, Mobile and SMS text +44 7714 330204 mailto: pbristow(a)hetp.u-net.com www.hetp.u-net.com

2 4

Boost regression notification (2005-11-13 [RC_1_33_0])
by Douglas Gregor 13 Nov '05

13 Nov '05

Boost regression test failures ------------------------------ Report time: 2005-11-13T13:51:12Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 0 failure in 0 library:

1 0

Boost regression notification (2005-11-13 [HEAD])
by Douglas Gregor 13 Nov '05

13 Nov '05

Boost regression test failures ------------------------------ Report time: 2005-11-13T06:00:08Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. io Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 223 failures in 13 libraries: concept_check (12) date_time (2) graph (2) io (1) mpl (1) python (56) serialization (30) spirit (8) thread (4) tr1 (71) tuple (1) typeof (18) xpressive (17) |concept_check| stl_concept_covering: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 vc-7_1 |date_time| testwcustom_time_zone: mingw-3_4_2 testwposix_time_zone: mingw-3_4_2 |graph| graphviz_test: vc-7_1 layout_test: intel-win32-9_0 |io| ios_state_unit_test: intel-win32-9_0 |mpl| size_t: gcc-4_0-darwin |python| andreas_beyer: vc-7_1 args: vc-7_1 auto_ptr: vc-7_1 back_reference: vc-7_1 ben_scott1: vc-7_1 bienstman1: vc-7_1 bienstman2: vc-7_1 bienstman3: vc-7_1 builtin_converters: vc-7_1 callbacks: vc-7_1 const_argument: vc-7_1 crossmod_exception: vc-7_1 data_members: vc-7_1 defaults: vc-7_1 dict: vc-7_1 docstring: vc-7_1 enum: vc-7_1 exception_translator: vc-7_1 extract: vc-7_1 implicit: vc-7_1 injected: vc-7_1 iterator: vc-7_1 keywords: vc-7_1 list: vc-7_1 long: vc-7_1 map_indexing_suite: vc-7_1 minimal: vc-7_1 multi_arg_constructor: vc-7_1 nested: vc-7_1 numpy: vc-7_1 object: vc-7_1 opaque: vc-7_1 operators: vc-7_1 pearu1: vc-7_1 pickle1: vc-7_1 pickle2: vc-7_1 pickle3: vc-7_1 pickle4: vc-7_1 pointer_vector: vc-7_1 polymorphism: vc-7_1 polymorphism2: vc-7_1 polymorphism2_auto_ptr: vc-7_1 properties: vc-7_1 raw_ctor: vc-7_1 return_arg: vc-7_1 shared_ptr: vc-7_1 slice: vc-7_1 staticmethod: vc-7_1 stl_iterator: vc-7_1 str: vc-7_1 test_pointer_adoption: vc-7_1 try: vc-7_1 tuple: vc-7_1 vector_indexing_suite: vc-7_1 virtual_functions: vc-7_1 wrapper_held_type: vc-7_1 |serialization| test_class_info_load_binary_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_binary_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin |spirit| action_tests_debug: gcc-3_4_3-sunos distinct_tests_debug: gcc-3_4_3-sunos escape_char_parser_tests_debug: gcc-3_4_3-sunos grammar_def_test_debug: gcc-3_4_3-sunos switch_problem_debug: gcc-3_4_3-sunos switch_tests_single_debug: gcc-3_4_3-sunos traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |thread| test_condition: gcc-3_4_3-sunos test_mutex: gcc-3_4_3-sunos test_tss: gcc-3_4_3-sunos gcc-3_4_3-sunos |tr1| run_complex_overloads: gcc-2.95.3-linux std_run_complex_overloads: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 mingw-3_4_2 std_run_random: gcc-2.95.3-linux mingw-3_4_2 std_test_bind: gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 std_test_boost: gcc-2.95.3-linux std_test_complex: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 std_test_function: gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 std_test_hash: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 std_test_mem_fn: gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 std_test_reference_wrapper: gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 std_test_regex: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux mingw-3_4_2 std_test_result_of: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 std_test_shared_ptr: gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 std_test_tr1_include: gcc-2.95.3-linux mingw-3_4_2 std_test_tuple: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 std_test_type_traits: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin test_complex: gcc-2.95.3-linux test_hash: gcc-2.95.3-linux test_ios: gcc-2.95.3-linux test_istream: gcc-2.95.3-linux test_iterator: gcc-2.95.3-linux test_limits: gcc-2.95.3-linux test_locale: gcc-2.95.3-linux test_ostream: gcc-2.95.3-linux test_regex: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux mingw-3_4_2 test_result_of: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_streambuf: gcc-2.95.3-linux test_tr1_include: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux mingw-3_4_2 test_tuple: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_type_traits: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin test_utility: gcc-2.95.3-linux tr1_remove_bounds_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin intel-win32-9_0 mingw-3_4_2 vc-7_1 |tuple| tuple_test_bench: gcc-3_4_3-sunos |typeof| data_member_native: cw-9_4 function_native: cw-9_4 function_ptr_native: cw-9_4 function_ref_native: cw-9_4 lvalue_native: cw-9_4 member_function_native: cw-9_4 modifiers_emulation: cw-9_4 modifiers_native: cw-9_4 noncopyable_native: cw-9_4 std_emulation: cw-9_4 std_native: cw-9_4 template_dependent_native: cw-9_4 template_enum_native: cw-9_4 template_int_native: cw-9_4 template_multiword_native: cw-9_4 template_tpl_native: cw-9_4 template_type_native: cw-9_4 type_native: cw-9_4 |xpressive| misc1: mingw-3_4_2 test1: mingw-3_4_2 test2: mingw-3_4_2 test3: mingw-3_4_2 test3u: gcc-3_3-darwin test4: mingw-3_4_2 test4u: gcc-3_3-darwin test5: mingw-3_4_2 test5u: gcc-3_3-darwin test6: mingw-3_4_2 test6u: gcc-3_3-darwin test7: mingw-3_4_2 test8: mingw-3_4_2 test9: mingw-3_4_2 test9u: gcc-3_3-darwin test_cycles: mingw-3_4_2 test_non_char: mingw-3_4_2

1 0

Re: [boost] serialization performance
by David Abrahams 13 Nov '05

13 Nov '05

bwood <brass(a)mailvault.com> writes: > Hi, Dave, Hi Brian > I work on www.webEbenezer.net. I noticed today that Robert > Ramey said "So far so good" regarding some performance tests > he is doing. You might want to encourage him to consider > some of the competition as far as performance. You should probably be doing that, actually ;-) I'm helpfully cross-posting this reply to the Boost developers' list, but next time, please do it yourself so that you get "in the mix" there. Having these kinds of reports in the public record, and having people like you involved in the ensuing discussion, are crucial for the Boost process. Thanks again for writing. > Some recent tests I've done that compare Ebenezer Enterprises > and Boost.serialization's performance show the > Boost.serialization approach to be 7 to 9 times slower than the > Ebenezer Enterprises approach. I'm using Linux 2.6.12, > gcc 4.0.2 (with -O3) and a Boost.serialization library from the > release tree. A test that compared the times to serialize/send > a list<int> took 7.4 times longer with Boost than Ebenezer. > I timed the following > Boost: > oArch & lst; // oArch is a binary_oarchive > > Ebenezer: > msgs.Send(buffer, lst); // In order to compare apples to apples, > // I removed a section of code at the end > > // of the Send function that flushes the > buffer. > > > In a second test I added a deque of int... > Boost: > oArch & lst; > oArch & dq; // std::deque<int> dq; > > Ebenezer: > msgs.Send(buffer, lst, dq); > > In this case Boost took 9.1 times longer than Ebenezer Enterprises > approach. If you want to run these tests with other compilers I > think that would be helpful. I've been warned not to put too much > emphasis on numbers from gcc. > > Regards, > Brian Wood -- Dave Abrahams Boost Consulting www.boost-consulting.com

4 11

Re: [boost] serialization performance
by Martin Slater 12 Nov '05

12 Nov '05

> //build oArch. > Ebenezer: > msgs.Send(buffer, lst); // where I didn't remove anything > // from Send's implementation. > > I think as you say, whether a flush gets embedded in the Send > function should be configurable, but right now it just is. > I'll admit it would be better if I didn't have to remove (#if 0) > the end of the Send function, but I don't think that invalidates > anything. This I humbly disagree with, from a user point of view I would not want to patch either library to get optimal performance, If it is there and required then tests need to be done with it in. It would be simple to speed up boost.serialization by #if 0'ing out per class meta information lookups (versioning etc) but would still be extremely artificial. >>It would be interesting to see what the results are with a vanilla >>version of your library as well as a feature by feature comparision to > > >>see if you really are comparing apples to apples. >> > > Both Boost and s11n.net support things like XML that Ebenezer doesn't. > > Boost in my opinion mistakenly tries to support "versioning." We > don't and I don't think s11n does either. > Well since I use versioning heavily with boost.serialization this is a must have feature for me. This conversation really should be kept to the boost list where there are many knowlegedable experts in this area and both libraries could potentially benifit from the discussion, you can sign up at http://lists.boost.org/mailman/listinfo.cgi/boost cheers Martin -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.13.0/167 - Release Date: 11/11/2005

1 0

Boost regression notification (2005-11-12 [RC_1_33_0])
by Douglas Gregor 12 Nov '05

12 Nov '05

Boost regression test failures ------------------------------ Report time: 2005-11-12T14:42:09Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 0 failure in 0 library:

1 0

[ptr_container] Semicolons after macros
by Boris Burger 12 Nov '05

12 Nov '05

Hello, the issue with extra semicolons at namespace or class scope is surely nothing new and has been discussed extensively. Still, I am not able to handle its incarnation in ptr_container sources, with G++ 3.4.5 (-ansi -pedantic). It goes like this: In ptr_map_adapter.hpp (and elsewhere), definition of class template ptr_map_adapter_base contains: BOOST_PTR_CONTAINER_DEFINE_CONSTRUCTORS( ptr_map_adapter_base, base_type ); at class scope. G++ 3.4.5 reports the extra semicolon as an error (-ansi -pedantic warning level is rather strict here). Due to our company's policy lowering the warning levels is not an option. Patching the ptr_container classes would do the trick but that would require rather painful process of going through the Boost sources with each new version and removing extra semicolons. What is your opinion on this, please? Regards, Boris

4 7

libmdc Preview Release
by Michael Crawford 12 Nov '05

12 Nov '05

libmdc is a set of utility and debugging classes that I expect would be useful in most C++ programs. Mostly it consists of assertion bottlenecks to help you eliminate pointer and memory bugs from your programs. There will be more soon to help with class invariant and design by contract assertions. libmdc - Mike Crawford's C++ Library http://www.goingware.com/libmdc/ It's also meant to make unit testing easier. It includes CPPUnit.mk and CPPUnit.t.mk, sub-makefiles which ease building CPPUnit unit tests with GNU make. My assertion_failed exception class includes a macro which can be used by your own assertion macros to throw an exception upon assertion failure. This enables one to use CPPUnit to test assertion failures without aborting the tests. My mdc_assert can do this. libmdc is Free Software, released under the Boost Software License. It's my intention that when I'm finished writing it, I will submit it for review for possible inclusion in Boost itself. It is not nearly done yet, but this preview release is provided to solicit comments. My question for you is, do you see any obvious mistakes? How can I do better? My valid_ptr template is a non-owning smart pointer that cannot be NULL. I'm also going to write a template I'll call checked_ptr that CAN be NULL. valid_ptr uses and checked_ptr will use the legal_addr template which reads the first byte addressed by any reference or non-NULL pointer. Given an unmapped address, it causes an immediate crash, but probably sooner and easier to debug than letting it snowball through your program. Used with a memory debugger like valgrind, Purify or Spotlight, you can find and fix bad memory references with ease. I have used this technique before and while it's dead-simple, it is also very powerful. libmdc doesn't have proper documentation yet, but there is some in the form of comments in the header files. The unit tests also serve as sample code. The Makefile is extensively commented to show you how to use CPPUnit.mk to build unit tests for your classes. CPPUnit.mk itself contains complete documentation for its use. I build unit tests the way John Lakos advises in Large Scale C++ Software Design: I only link in the class under direct test, and those sources which are absolutely required to make the test link. For reasons that Lakos eloquently explains, I DON'T link in my entire project, as I think is the more common practice. To keep this manageable, I need a separate makefile to build each unit test. CPPUnit.t.mk encapsulates what is common to building all unit tests, so that the *.t.mk unit test makefiles need have little more in them than a list of the dependencies. Following is from the README file: libmdc is a set of utility and debugging classes likely to be useful in many C++ projects. Everything is in the namespace mdc. There aren't any dependencies on anything outside this directory except for the standard C++ library, Boost and CPPUnit for the unit tests. You will need to build and install the Boost C++ library and the CPPUnit automated test framework before you can build this code: http://www.boost.org/ http://cppunit.sourceforge.net/cppunit-wiki/ To build the executables, just take "make". To build and then run the tests (both unit tests and other tests) type "make test". There is no "make install" yet. The library so far contains: CPPUnit.mk, CPPUnit.t.mk Sub-makefiles to make it a lot easier to build CPPUnit unit tests with GNU make. valid_ptr non-owning smart pointer; forbids NULL pointers. legal_addr pointer debugging, best used with valgrind, purify or spotlight. null_ptr_checker throws an exception when given a NULL pointer. null_ptr_exception The exception it throws. mdc_assert Debugging macro, aborts or drops into debugger when its assertion evaluates to false. This is used instead of the standard library assert so it may be separately disabled. Assertions are enabled by default, for release builds, #define MDC_NO_ASSERT 1 or pass -DMDC_NO_ASSERT=1 to the C++ compiler. assertion_failed meant for testing failed assertions in unit tests. You can configure mdc_assert to throw this exception with #define MDC_ASSERTION_EXCEPTION 1 errno_exception on POSIX systems, throw this exception after a system call fails so that the catcher can print a good error message string_invariant The beginning of class invariant assertions for the Standard Library valid_ptr is a smart pointer like auto_ptr, scoped_ptr or shared_ptr, except that it doesn't take ownership of the pointer it holds. Instead, construct a valid_ptr from a pointer that your class or function is given to use, but not manage. It will throw a null_ptr_exception and optionally assert if the pointer is ever NULL. Besides validating the pointer it is given, valid_ptrs serve as documentation to help make ownership issues clear. Using valid_ptrs as class member variables indicates that the pointers are used by, but not owned by the class. Similarly, declaring them as function parameters indicates that the pointers passed in cannot be NULL, and again that ownership of them is not captured by the receiving function. Use either scoped_ptr, shared_ptr or auto_ptr for situations where pointer ownership is required. Which one to use depends on the requirements of each situation. There is sample code too: the tests. There are unit tests for most of the classes that use the CPPUnit automated test framework. There is also a simple program called HeaderCheck that I used to debug some problems with my header files while I was first writing valid_ptr.h. CPPUnit does some extreme macro and template magic, so HeaderCheck serves as a simpler testbed. Enjoy! -- Mike -- Michael D. Crawford GoingWare Inc. - Expert Software Development and Consulting http://www.goingware.com/ crawford(a)goingware.com Tilting at Windmills for a Better Tomorrow.

1 0

[MPL] interest in algo that creates all possible permutations of a type?
by Kevin Sopp 11 Nov '05

11 Nov '05

Hi, I just joined the list and I would like to show you what I have done here. Given a type T which is a model of MPL lambda expression, permute<T, Args1, ..., ArgsN>::type is an MPL vector that contains all possible permutations of type T, where ArgsN is a model of an MPL forward sequence. Example: template<class X, class Y> struct base{}; permute< base<_1,_2>, vector<int, float>, vector<double, bool> >::type types; types is an MPL vector containing all possible permutations of base with the supplied argument lists: vector< base<int,double>, base<int,bool>, base<float,double>, base<float,bool> > (not necessarily in this order) I believe I can easily extend this algo to n-ary lambda expressions with some preprocessor macros. The version for binary expressions is attached below because the code is short. I tested the code with gcc 3.4.4. Example usage: I use this algo to create a typelist that is given to my renderer which instantiates a 'dispatch table' (see More Effective C++, Item 31) and the appropriate render functions for these types. Then at runtime the entities to be rendered are dispatched based on their dynamic type to the specialized render functions which only work on concrete types. #ifndef permute_h #define permute_h #include <boost/mpl/apply.hpp> #include <boost/mpl/at.hpp> #include <boost/mpl/bool.hpp> #include <boost/mpl/if.hpp> #include <boost/mpl/eval_if.hpp> #include <boost/mpl/int.hpp> #include <boost/mpl/modulus.hpp> #include <boost/mpl/push_back.hpp> #include <boost/mpl/size.hpp> #include <boost/mpl/vector.hpp> template<class T, class Args1, class Args2, class Seq, int N, int K> struct permute_impl { typedef typename boost::mpl::modulus< boost::mpl::int_<N>,boost::mpl::size<Args2> >::type args2_index; typedef typename boost::mpl::push_back< Seq , typename boost::mpl::apply< T , typename boost::mpl::at_c<Args1, K>::type , typename boost::mpl::at<Args2, args2_index>::type >::type >::type Seq2; typedef typename boost::mpl::eval_if_c< N == 0 , Seq , permute_impl< T , Args1,Args2 , Seq2 , N-1 , boost::mpl::if_c< args2_index::value == 1 , boost::mpl::int_<K+1> , boost::mpl::int_<K> >::type::value > >::type type; }; template<class T, class Args1, class Args2> struct permute { typedef typename permute_impl< T, Args1, Args2, boost::mpl::vector<>, boost::mpl::size<Args1>::value*boost::mpl::size<Args2>::value, 0 >::type type; }; #endif _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

4 4

any interest in BOOST_FINALLY?
by Alexander Nasonov 11 Nov '05

11 Nov '05

Is there an interest to write something like this int i = 2, j = 1; BOOST_FINALLY_BEGIN( (i)(j) ) { std::cerr << i + j << '\n'; } BOOST_FINALLY_END in a code to make sure that a code inside finally block is always executed when leaving a scope? Code is here: http://files.rsdn.ru/21403/finally.cpp Note that it depends on typeof. Preprocessed output is below: // Not thread-safe yet void* _finally_last_params = 0; int main() { int i = 2, j = 1; typedef typeof(i) _finally_typeof_46i; typedef typeof(j) _finally_typeof_46j; struct _finally_params_46 { _finally_typeof_46i & i ; _finally_typeof_46j & j ; } _finally_params_46 = { i, j }; _finally_last_params = &_finally_params_46; struct _finally_guard_46 { void* _finally_params; ~_finally_guard_46() { typedef struct _finally_params_46 params; params* p= static_cast<params*>(_finally_params); _finally_body(p -> i , p -> j , 0); } static void _finally_body( _finally_typeof_46i & i , _finally_typeof_46j & j , int) { // USER CODE HERE std::cerr << i + j << '\n'; } } _finally_guard_48 = { _finally_last_params }; } -- Alexander

4 9