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

Handling core dumps when process is holding boost interprocess lock
by Rajalakshmi Iyer 28 Sep '12

28 Sep '12

Hello, I am working on application where several multi-threaded processes are attempting to acquire a lock on the shared memory files managed via boost interprocess. It appears that if one of these processes dumps a core while holding a lock on the shared memory file, all the other processes end up waiting for this lock to be released. Any ideas on how this can be overcome? I want to ensure that when a process that is holding the lock dies, it should ensure that the lock is released. Thanks, Raj -- *Twitter: @Blismedia <http://twitter.com/#%21/blismobile> BlisMedia 32 Percy Street, London W1T 2DE www.blismedia.com <http://www.blismobile.com/>** *** <http://www.blismobile.com/>* ****[image: Follow on Twitter]* <http://twitter.com/#%21/blismobile>*[image: Blis Website]* <http://www.blismobile.com/> *This communication is from Blis Media Ltd, a company registered in England and Wales with registered number 06455773. Its registered office is 32 Percy Street, London W1T 2DE, United Kingdom.* * * *This communication contains information that is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please (1) notify info(a)blismedia.com<info(a)blismobile.com> by forwarding this email and delete all copies from your system and (2) note that disclosure, distribution, copying or use of this communication is strictly prohibited. Email communications cannot be guaranteed to be secure or free from error or viruses. All emails sent to or from a Blismobile email account are securely archived and stored by an external supplier. This email does not constitute a contractual agreement; such agreements are in specified contractual or Insertion Order (IO) form only and exclusively contain all the terms to which Blis Mobile Ltd will be bound. To the extent permitted by law, Blis Mobile Ltd does not accept any liability for use of or reliance on the contents of this email by any person save by the intended recipient(s) to the extent agreed in a contract or Insertion Order.* * * *Opinions, conclusions and other information in this email which have not been delivered by way of the business of Breeze Tech (UK) Ltd are neither given nor endorsed by it.*

2 1

Review of ODEInt
by Rhys Ulerich 28 Sep '12

28 Sep '12

Here is my review of the proposed ODEInt library... I'm abstaining on the yes/no library acceptance vote. > - What is your evaluation of the design? As a user, I can find my way around. Several particular nits appear in my miscellaneous comments section. I'm not convinced that the interfaces, which differ from many other ODE integration packages, are a marked improvement from those other packages (e.g. GSL, PETSc, Trilinos, SUNDIALS, etc). I think that adding more than classical use cases could be difficult, in particular IMEX schemes. In particular, my personal research code (a turbulence DNS platform requiring semi-implicit time advance for a hyperbolic PDE system) could not be retrofit into this framework. > - What is your evaluation of the implementation? I've not read through the implementation. > - What is your evaluation of the documentation? Fairly good on the whole. I wish the math more clearly appeared using display-style equations rather than inline text. One table appears repeatedly and many links are missing. The applications section is quite nice. > - What is your evaluation of the potential usefulness of the library? I think the collection of features are useful, but I'd not adopt this library over the GSL, PETSc's time steppers, or Trilino's Rythmos when working in C or C++. GSL's APIs are quite easy and have no learning curve. PETSc's steppers are very powerful and support many new, exotic schemes. Rythmos build atop clean C++ vector space abstractions from the rest of Trilinos. odeint-v2 doesn't seem to beat any of these three alternatives at their game nor does it feel like enough of a winning compromise to make it compelling to me. > - Did you try to use the library? With what compiler? Did you have any problems? No. > - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 45 minutes of reading. > - Are you knowledgeable about the problem domain? Somewhat. In conclusion, I'm thrilled to see someone put forward an ODE integration library for Boost but I feel the design doesn't address current application needs and best practices in many portions of the numerical PDE communities. That said, I applaud the authors' effort and I'm sure odeint-v2 will be useful for other folks. - Rhys P.S.: Miscellaneous, jumbled comments: Within the documentation, Table 1.1's stepper algorithm classes should link to the class. Ditto for lists of models within, e.g., http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/concept… Table 1.2 appears to duplicate Table 1.1 and should simply be linked. Ditto for Table 1.7. Stray < and > appear within the generated documentation, e.g. at http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/concept… sys.first(...) and sys.second(...) don't describe what's happening within the ImplicitSystem interface. sys.calculate_dxdt(...) and sys.calculate_dfdx(...) describe the operations involved. That they're called in some sequence shouldn't determine the names. Moreover, sometimes big gains can be made by simultaneously computing the Jacobian and the function evaluation in a single call. ImplicitSystem should be a System, but it's not. System should use a calculate_dxdt(...) method rather than operator(...) so that one has a hierarchy of system concepts. Similar naming concerns apply to the symplectic system concepts. In- versus out-of-place do_step(...) method signatures should differ by more than the method signatures. In my own codes I've used terminology like 'apply' and 'accumulate' and modeled the signatures off Level 1 and Level 2 BLAS calls. WRT ImplicitSystem, either providing or recommending some mechanism for finite differenced or complex-stepped Jacobians would be useful. Naming inconsistencies in the dense output schemes: bulirsch_stoer_dense_out vs rosenbrock4_dense_output Unclear if the design permits low storage Runge Kutta schemes, singly diagonally implicit.schemes, and other fun implicit-explicit things. E.g., there are IMEX schemes with different formal orders of accuracy for the implicit vs explicit portions of the scheme. Unclear if the design permits CFL-related maximum stable step sizes within f(u). The System interface would need to be adapted to have each method return maximum stable eigenvalue magnitudes for first and second order differential operators.` Rather than limiting implicit systems to folks using uBLAS matrices, it may be better to define the abstract operations a class would need to support to plug into the ImplicitSystem infrastructure. Especially because getting a uBLAS "wrapper" around an existing chunk of memory is quite a PITA and relies upon non-standard parts of the uBLAS (See, e.g., http://agentzlerich.blogspot.com/2009/10/boostublasshallowarrayadaptor.html) Why in http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/odeint_… are static_casts preferred to using constructors a la Value(2) / Value(3)?

2 1

[Review] ODEInt review starts today, September 19, ends September 28
by Steven Watanabe 28 Sep '12

28 Sep '12

AMDG The review of Karsten Ahnert and Mario Mulansky's ODEInt library starts today September 19th and will end on September 28. -------------------------------------- About the library: odeint provides routines for numerically solving Ordinary Differential Equations, a task heavily required when approaching scientific problems numerically. In odeint we have implemented the most common algorithms in a modern, generic way which provides several advantages over existing implementations. The main focus of odeint is to separate algorithms from the underlying basic computation unit. This allows for example to easily use the power of modern GPUs via CUDA or OpenCL to speed up computational heavy simulations. Features: - provides most of the standard algorithms, including step size control, dense ouput and extrapolation routines - symplectic routines for Hamiltonian systems - implicit routines based on boost::ublas (MTL4 in progress) - high level integrate functions - interchangeable computation backend with existing bindings to CUDA and OpenCL - native support of ODEs defined for complex values - support of Boost.Units in most of the algorithms - support of arbitrary precision types You can download the library and view the documentation here: zip: http://github.com/headmyshoulder/odeint-v2/zipball/master github: http://headmyshoulder.github.com/odeint-v2/ docs: http://headmyshoulder.github.com/odeint-v2/doc/index.html -------------------------------------- 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? In Christ, Steven Watanabe

5 5

[boost] [containers] wrong flat_xxx::insert(ordered_unique_range_t, first, last) ?
by TONGARI 28 Sep '12

28 Sep '12

Hi there, Say, if I have a set A{0, 1} and now I insert B{0.2, 0.8} into A, using that function, I'd expect A{0, 0.2, 0.8, 1}, but what I really get is A{0, 1}; If A is {0, 0.1}, I'll get A{0, 0.1, 0.2, 0.8} as expected... So it looks like that insert(ordered_unique_range_t...) can only insert elements subsequent to A. If this is the expected behavior, this function is useless to me, or is it a bug? File attached. Thanks.

2 2

Re: [Boost-users] [Polygon] How to put self intersect polygon into PolygonSet
by Luke Simonson 27 Sep '12

27 Sep '12

On Thu, Sep 27, 2012 at 1:25 AM, 李洋(zeal) <li.y-neu(a)neusoft.com> wrote: > I want to put a self intersect polygon > > |\ /| > | \ / | > | \/ | > | /\ | > | / \ | > |/ \| > into a Polygon set ps, > But when I use ps += poly to put it, in the ps the polygon has been cut to > /| > / | > / | > \ | > \ | > \| > > and the left part doesn't exist anymore. > I'm not sure whether I use it in a wrong way, or the library doesn't support this kind of operation? Very few libraries handle self intersecting polygons. This is actually one of Polygon's great strengths. There are three ways to handle self intersection. non-zero winding rule, odd winding rule and positive winding rule. The library does handle self intersecting polygons, just not the way you wanted. Your expectation is that the library applies the non-zero winding rule or the odd winding rule. Polygon uses the positive winding rule. The triangle on the left looks like a hole outside of a polygon to the library and has a winding of -1. Try putting your self intersecting polygon in a vector with a rectangle that is much bigger than it and then do ps += poly_vector and you will get a rectangle with a hole that is the left triangle. >From there you can do a NOT between the original rectangle and the rectangle with the hole to turn the hole positive and then OR it with the right hand triangle. Regards, Luke

1 0

Review Wizard Status Report for September 2012
by Ronald Garcia 27 Sep '12

27 Sep '12

============================================== Review Wizard Status Report for September 2012 ============================================== News ==== 1. Boost 1.51.0 Released. New Libraries: 1) Context 2. Multiprecision Accepted 3. Type Erasure Accepted 4. Contract Reviewed 5. Coroutine Reviewed 6. ODEInt Reviewed 7. Contract Accepted 8. Polygon Extensions integrated into Polygon Open Issues =========== The following libraries have review managers, but have not yet been scheduled for review: * Range Extensions - added May 2012; review manager: Neil Groves. The following libraries have been reviewed and await reports from their review managers: * Predef - reviewed February 2012; review manager: Joel Falcou. * Coroutine - reviewed September 2012; review manager: Hartmut Kaiser. The following libraries have been accepted to Boost, but have not yet been submitted to SVN: * Constrained Value - accepted September 2010; author: Robert Kawulak. * GIL.IO - accepted January 2011; author: Christian Henning. * Contract - accepted September 2012; author: Lorenzo Caminiti. The following libraries have been accepted and submitted to SVN, but have not yet appeared in a release: * Atomic - accepted July 2011; author Helge Bahmann. * Type Traits Introspection - accepted August 2011; author: Edward Diener. * Lockfree - accepted August 2011; author: Tim Blechmann. The following libraries have been accepted provisionally to Boost, but have not been submitted for mini-review and full acceptance: * Endian - accepted provisionally November 2011; author: Beman Dawes. * Log - accepted provisionally March 2010; author: Andrey Semashev. General Announcements ===================== As always, we need experienced review managers. Please take a look at the list of libraries in need of managers and check out their descriptions. In general review managers are active boost participants, including library contributors, infrastructure contributors, and other mailing list participants with a substantial track record of constructive participation. If you can serve as review manager for any of them, email Ron Garcia or John Phillips, "rxg at cs dot cmu dot edu" and "phillips at pacific dot mps dot ohio-state dot edu" respectively. We are also suffering from a lack of reviewers. While we all understand time pressures and the need to complete paying work, the strength of Boost is based on the detailed and informed reviews submitted by you. If you are interested in reviewing a library but won't have time during the review period, you can always prepare your review ahead of time. No rule says you can only work on a review during the review period. A link to this report will be posted to www.boost.org. If you would like us to make any modifications or additions to this report, please email Ron or John. The review schedule is an unordered list of the libraries awaiting review. As such, any library on the schedule can be reviewed once the developer is ready, a review manager has been secured, and the manager, developer, and wizards agree on a date to schedule the review. Review Schedule =============== * Join (M) * Pimpl (M) * Sorting (M) * Quaternions, Vectors, Matrices (M) * Variadic Macro Data (M) * Block Pointer (M) * Singularity (M) * Extended Complex Numbers (M) * Metaparse (M) * Polygon: Voronoi Extensions * Coroutine * Range Extensions * Nowide (M) * Array (M) * TypeIndex (M) ``(M)`` marks libraries that need review managers. -------------------- Join ---- :Author: Yigong Liu :Review Manager: Needed :Download: http://channel.sourceforge.net/ :Description: Join is an asynchronous, message based C++ concurrency library based on join calculus. It is applicable both to multi-threaded applications and to the orchestration of asynchronous, event-based applications. It follows Comega's design and implementation and builds with Boost facilities. It provides a high level concurrency API with asynchronous methods, synchronous methods, and chords which are "join-patterns" defining the synchronization, asynchrony, and concurrency. Pimpl ----- :Author: Vladimir Batov :Review Manager: Needed :Download: https://github.com/boost-vault/Miscellaneous/blob/master/Pimpl.zip :Description: The Pimpl idiom is a simple yet robust technique to minimize coupling via the separation of interface and implementation and then implementation hiding. This library provides a convenient yet flexible and generic deployment technique for the Pimpl idiom. It's seemingly complete and broadly applicable, yet minimal, simple and pleasant to use. Sorting ------- :Author: Steven Ross :Review Manager: Needed :Download: https://github.com/boost-vault/Sorting :Description: A grouping of 3 templated hybrid radix/comparison-based sorting algorithms that provide superior worst-case and average-case performance to std::sort: integer_sort, which sorts fixed-size data types that support a rightshift (default of >>) and a comparison (default of <) operator. float_sort, which sorts standard floating-point numbers by safely casting them to integers. string_sort, which sorts variable-length data types, and is optimized for 8-bit character strings. All 3 algorithms have O(n(k/s + s)) runtime where k is the number of bits in the data type and s is a constant, and limited memory overhead (in the kB for realistic inputs). In testing, integer_sort varies from 35% faster to 2X as fast as std::sort, depending on processor, compiler optimizations, and data distribution. float_sort is roughly 70% faster than std::sort. string_sort is roughly 2X as fast as std::sort. Quaternions, Vectors, Matrices ------------------------------ :Author: Emil Dotchevski :Review Manager: Needed :Download: http://www.revergestudios.com/boost-qvm/ :Description: QVM defines a set of generic functions and operator overloads for working with quaternions, vectors and matrices of static size. The library also defines vector and matrix data types, however it allows users to introduce their own types by specializing the q_traits, v_traits and m_traits templates. Variadic Macro Data ------------------- :Author: Edward Diener :Review Manager: Needed :Download: `Boost Sandbox <http://svn.boost.org/svn/boost/sandbox/variadic_macro_data/>`__ :Description: This library adds support and functionality for variadic macros to Boost as well as integrating variadic macros with the Boost PP library without changing the latter library in any way. Block Pointer ------------- :Author: Phil Bouchard :Review Manager: Needed :Download: https://svn.boost.org/svn/boost/sandbox/block_ptr/ :Description: Deterministic memory manager of constant complexity capable of handling cyclic collections. Singularity ----------- :Author: Ben Robinson :Review Manager: Needed :Download: https://github.com/cppmaven/Singularity :Description: The Singularity Design Pattern allows you to restrict any class to a single instance. Unlike the infamous Singleton, Singularity gives you direct control over the lifetime of the object, does not require you to grant global access to the object, nor does it limit you to the default constructor for that object. Extended Complex Numbers ------------------------ :Author: Matthieu Schaller :Review Manager: Needed :Download: http://code.google.com/p/cpp-imaginary-numbers/ :Description: The library is an extension of the std::complex class addressing two issues: 1. The standard does not guaranty the behaviour of the complex class if instantiated with types other than float/double/long double. 2. Some calculation where pure imaginary numbers (i.e. multiples of sqrt(-1)) appear are unnecessarily slowed down due to the lack of support for these numbers. The code I submit contains two interleaved classes boost::complex and boost::imaginary which can be instantiated with any type T provided T overloads the usual arithmetic operators and some basic (real) mathematical functions depending on which complex function will be used. It is thus an extended version of Thorsten Ottosen's n1869 proposal (http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1869.html) Metaparse --------- :Author: Abel Sinkovics :Review Manager: Needed :Download: http://abel.web.elte.hu/metaparse/metaparse.zip :Description: Metaparse is a library for constructing parsers parsing at compile-time based on template metaprogramming. The parsers built with the library take boost::mpl::strings as input and can produce - types - objects (types with public static members) - callable C++ functions (types with public static method) - template metafunction classes as output (based on the input being parsed). On compilers supporting constexpr the library provides the following syntactic sugar for writing the input of the parsers: BOOST_STRING("this is a string") The library can be used for implementing DSLs in C++, including DSLs making C++ template metaprogramming easier (see examples). Polygon: Voronoi Extensions --------------------------- :Author: Andril Sydorchuk :Review Manager: Lucanus Simonson :Download: http://svn.boost.org/svn/boost/sandbox/gtl/ :Description: This library extends Boost.Polygon with the following features: - Robust and efficient implementation of the sweepline algorithm that allows to construct Voronoi diagram, Delaunay triangulation and medial axis of a set of points and line segments. - Coordinates of the output geometries are computed within the 64 machine epsilon relative error (6 mantissa bits). - Voronoi diagram data structure that allows efficient traversal and data association with the output Voronoi graph. - No 3rd party dependencies (e.g. GMP, MPFR), all the required multiple precision types are implemented as part of the library. - The input and output coordinate type domains are configurable via coordinate type traits, thus allowing to compute coordinates of the Voronoi vertices within any required precision. - The full construction of the Voronoi diagram of 100 000 points takes only 0.27 seconds (see benchmarks). Coroutine --------- :Author: Oliver Kowalke :Review Manager: Hartmut Kaiser :Download: http://gitorious.org/boost-dev/boost-dev/archive-tarball/coroutine :Description: This library is an implementation of coroutines and generators using Boost.Context. Range Extensions ---------------- :Author: Akira Takahashi :Review Manager: Neil Groves :Download: https://github.com/faithandbrave/OvenToBoost :Description: This project adds some features of the Oven Range Library to Boost.Range. Features: - Additional Range Adaptors (taken, taken_while, dropped, dropped_while, elements, elements_key, memoized, outdirected) - Extensions for using Lambda (regular function, regular operator) - Infinite Range (iteration function) - and additional range utilities. Nowide ------ :Author: Artyom Beilis :Review Manager: Needed :Download: http://cppcms.com/files/nowide/ :Description: This library makes cross platform Unicode aware programming easier. It provides an implementation of standard C and C++ library functions, such that their inputs are UTF-8 aware on Windows without requiring to use Wide API. Array ----- :Author: Brian Smith :Review Manager: Needed :Download: https://github.com/BrianJSmith/Array :Description: The array class is a C++11 compatible implementation of static multidimensional arrays. TypeIndex --------- :Author: Antony Polukhin :Review Manager: Needed :Download: https://github.com/apolukhin/type_index :Description: TypeIndex is an extended C++11 type_index library, that * works with disabled RTTI * can store const-volatile-reference info about types (if user requested it) * has all the functionality of std::type_index * has portable across compilers and platforms functionality for getting demangled type names * works across modules/shared libraries * does not require C++11 to work Libraries under development =========================== See http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction for a current listing of libraries under development.

1 0

[reminder] [Review] ODEInt review ends tomorrow September 28
by Steven Watanabe 27 Sep '12

27 Sep '12

AMDG The review of Karsten Ahnert and Mario Mulansky's ODEInt library will end tomorrow. Only a few reviews have been submitted so far. If you plan to submit a review, please let me know. If anyone needs more time, we can see about extending the review period. -------------------------------------- About the library: odeint provides routines for numerically solving Ordinary Differential Equations, a task heavily required when approaching scientific problems numerically. In odeint we have implemented the most common algorithms in a modern, generic way which provides several advantages over existing implementations. The main focus of odeint is to separate algorithms from the underlying basic computation unit. This allows for example to easily use the power of modern GPUs via CUDA or OpenCL to speed up computational heavy simulations. Features: - provides most of the standard algorithms, including step size control, dense ouput and extrapolation routines - symplectic routines for Hamiltonian systems - implicit routines based on boost::ublas (MTL4 in progress) - high level integrate functions - interchangeable computation backend with existing bindings to CUDA and OpenCL - native support of ODEs defined for complex values - support of Boost.Units in most of the algorithms - support of arbitrary precision types You can download the library and view the documentation here: zip: http://github.com/headmyshoulder/odeint-v2/zipball/master github: http://headmyshoulder.github.com/odeint-v2/ docs: http://headmyshoulder.github.com/odeint-v2/doc/index.html -------------------------------------- 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? In Christ, Steven Watanabe

1 0

[GIL] copy_and_convert_pixels vs transform_pixels
by Mateusz Loskot 27 Sep '12

27 Sep '12

Hi, What is relation, if any, and differences between these two Boost.GIL algorithms? They seem to be similar or the copy_and_convert_pixels seems like a specialisation of the transform_pixels. Is that correct understanding of these algorithms? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

How to Boost serialize a Eigen::Matrix class
by Dip Ghosh 27 Sep '12

27 Sep '12

Hi, I have used Eigen::Matrix class in my project. Now i wants to serialize the value of it through Boost::Serialize. Can someone help me on how to achieve that. My class is following, class RandomNode { private: friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & is_leaf_; ar & depth_; ar & num_classes_; ar & num_features_; // Split node members ar & random_feature_indices_; ar & random_feature_weights_; ar & threshold_; ar & leftChild_; ar & rightChild_; } bool is_leaf_; int depth_; int num_classes_; int num_features_; // Split node members VectorXi random_feature_indices_; VectorXd random_feature_weights_; double threshold_; RandomNode* leftChild_; RandomNode* rightChild_; // Methods and so on } And i am getting the following error : /usr/include/boost/serialization/access.hpp:118:9: error: ‘class Eigen::Matrix<double, 10000, 1>’ has no member named ‘serialize’ thanks in advance. Regards, Dip

3 4

Preprocessor sequence of "pairs"
by driscoll＠cs.wisc.edu 26 Sep '12

26 Sep '12

I have a question about the use of the preprocessor library. I'll describe my ultimate goal in a moment, but I've simplified my first problem to the following. Also, I know what I'm doing looks a lot at first glance like Fusion's ADAPT_STRUCT, but I took a quick look at that documentation and I don't think it matches. However, if you disagree with me and think it does, or can suggest a totally different solution, feel free to describe how. == My problem == I don't like C's struct syntax, so I'm trying to define my own. (</sarcasm> Really for purposes of this section I'm just doing this to figure out all the steps I'll need.) What I want to do is something like the following: #include <boost/preprocessor/seq/for_each.hpp> #define DEFINE_FIELD(r, os, field_pair) [....] #define DEFINE_STRUCT(struct_name, fields) \ struct struct_name { \ BOOST_PP_SEQ_FOR_EACH(DEFINE_FIELD, ~, fields) \ } DEFINE_STRUCT(mystruct, (int, x)(int, y)(double, z)) but this doesn't work, because the sequence is made up of pairs instead of single preprocessor arguments. (GCC complains about "macro "BOOST_PP_SEQ_SIZE_0" passed 2 arguments, but takes just 1" and same for PP_EXPR_IIF_0.) I can get it to work by double-parenthesizing the stuff in the sequence (saying "((int, x))((int, y))((double, z))") then defining DEFINE_FIELD as follows: #define DEFINE_FIELD_REAL(type, name) type name; #define DEFINE_FIELD(r, os, field_pair) DEFINE_FIELD_REAL field_pair but this is less than optimal. Is there a way that I can do this easily, or would I effectively have to re-implement SEQ_FOR_EACH? (And how hard would that be if it's necessary?) == What I'm actually trying to do == What I'm actually doing is trying to write a macro that will define a function like the following: DEFINE_SERIALIZED_STRUCT(mystruct, (int, x)(int, y)(double, z)) | V struct mystruct { int x; int y; double z; }; void serialize(ostream & os, mystruct const & s) { os << "x: " << s.x << "\n"; os << "y: " << s.y << "\n"; os << "z: " << s.z << "\n"; } (I didn't see a way to recover the field names from a Fusion-adapted struct -- from what I can tell, it more just seems to be a way to iterate over the fields.)

4 3