- Boost - lists.boost.org

[pool] Tuning the growth characteristics of pool
by Chris Newbold 27 Mar '08

27 Mar '08

Greetings. We've started introducing boost::pool at various places in our software in order to manage allocation of small, short-lived objects. We have run into some difficulty, however, with the algorithm governing the growth of the blocks allocated internally. The currently implementation unconditionally doubles the number of chunks in each subsequent block. This works well for small to medium sized pools, but ends up becoming wasteful and, ultimately, scalability-limiting for pools holding several million objects. Right now we're using the get_next_size() and set_next_size() accessors to meddle with the growth curve and to enforce an absolute limit on next_size. This is somewhat clumsy, however, requiring us to wrap boost::pool with additional logic to inspect next_size and take evasive action when we don't like the new value. I think there might be value in formally parameterizing the algorithm used to expand the pool. My first thought on an interface for controlling the growth algorithm was to add it to the UserAllocator interface. Here's an example of how this might look with the default algorithm hoisted to default_user_allocator_new_delete: // Default UserAllocator implementation for boost::pool; // the block size is doubled on each allocation struct default_user_allocator_new_delete { typedef std::size_t size_type; typedef std::ptrdiff_t difference_type; static char* malloc(const size_type bytes) { ... } static void free(char* const block) { ... } static size_type next_size(size_type size) { return size << 1; } }; // An implementation of the UserAllocator interface for // use with boost::pool which allocates fixed-sized blocks // of 65536 chunks. struct fixed_block_size_allocator : public default_user_allocator_new_delete { static size_type next_size(size_type /* ignored */) { return 2 << 15; } }; One problem I can see with this approach is that "more clever" growth algorithms may want data assigned at runtime-- e.g. an absolute limit at which to stop doubling the block size. This need could be accommodated by making UserAllocators be copy-constructible and changing the boost::pool constructor to take an instance to UserAllocator to be copied and kept internally. Another alternative would be to keep the growth algorithm parameter separate from UserAllocator: // The default pool growth algorithm: it unconditionally doubles // the block size on each successive allocation struct default_growth_algorithm { static size_t operator()(size_t prev_size) { return prev_size << 1; } }; template <typename UserAllocator = default_user_allocator_new_delete typename GrowthAlgorithm = default_growth_algorithm> class pool; The same comments about the potential need to pass a copy-constructible instance of the algorithm to the boost::pool constructor apply to this solution too. I am more than willing to prototype some changes in the code if there is interest in extending boost::pool in this manner. -- Chris Newbold cnewbold(a)mathworks.com The MathWorks, Inc. +1.508.647.8077

2 1

[property_map, graph] optional properties
by Ares Lagae 27 Mar '08

27 Mar '08

Is there any support for optional properties in boost.graph? Suppose I want to write/read a graph to/from a file format that supports edge weights. It should be possible to write a function template that works with all graphs and writes/reads edge weights if those properties are in the graph. Is this currently possible using boost.graph? Would the following make sense: - add an operator bool() to the property_map concept that returns true for existing property map classes - add a class empty_property_map with an operator bool() that always returns false - make Graph.get() return empty_property_map for non-existing properties This would enable constructs such as: edge_weight_property_map = get(edge_weight, graph); if (edge_weight_property_map ) { std::cout >> edge_weight_property_map[0] >> ... } -- Ares Lagae Computer Graphics Research Group, Katholieke Universiteit Leuven http://www.cs.kuleuven.be/~ares/

2 2

[serialization][1.35.0] incompatible change in guid_initalizer?
by Bernd Speiser 27 Mar '08

27 Mar '08

Hi, using the serialization library in various versions, I encounter a problem with exporting guids when changing from boost 1.34.1 to 1.35.0 I am currently using gcc 4.3.0 (recent stable release) under openSuSE 10.2. I am separating the exporting macros into a header xxx_export.h. This is done to avoid excessive compilation times for files in which the export code is not needed. Moreover, various classes which have export code are separated into several files. Thus, I need to #include more than one xxx_export.h header into the final program cpp file. I get the follwing error during compile: header2_export.h:9: error: conflicting declaration ‘const boost::archive::detail::guid_initializer<Derived2>& <unnamed>::boost_serialization_guid_initializer_9’ header1_export.h:9: error: ‘<unnamed>::boost_serialization_guid_initializer_9’ has a previous declaration as ‘const boost::archive::detail::guid_initializer<Derived1>& <unnamed>::boost_serialization_guid_initializer_9’ Obviously, the symbol names are derived from the line number in the header file, right? Using two (or more) different export header files, this leads to confusion. I tried to remedy the situation by enclosing the BOOST_CLASS_EXPORT_GUID () macros in the two export header files in two different namespaces. OK, that worked. HOWEVER - it is not backward compatible with boost version 1.34.1. If I use the code that works with 1.3.50 with the earlier version, I get: In file included from exportTestn.cpp:10: header1n_export.h:10: error: expected initializer before ‘<’ token header1n_export.h:10: error: ISO C++ forbids declaration of ‘type name’ with no type header1n_export.h:10: error: wrong number of template arguments (1, should be 2) /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../include/c++/4.3.0/bits/stl_pair.h:72: error: provided for ‘template<class _T1, class _T2> struct std::pair’ header1n_export.h:10: error: explicit instantiation of non-template ‘int derived1::boost::archive::detail::export_archives_invoke’ header1n_export.h:10: error: expected `;' before ‘<’ token In file included from exportTestn.cpp:12: header2n_export.h:10: error: expected initializer before ‘<’ token header2n_export.h:10: error: ISO C++ forbids declaration of ‘type name’ with no type header2n_export.h:10: error: wrong number of template arguments (1, should be 2) /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../include/c++/4.3.0/bits/stl_pair.h:72: error: provided for ‘template<class _T1, class _T2> struct std::pair’ header2n_export.h:10: error: explicit instantiation of non-template ‘int derived2::boost::archive::detail::export_archives_invoke’ header2n_export.h:10: error: expected `;' before ‘<’ token Am I doing something wrong here? Is there a solution which works for both boost::serialization versions? I have attached the relevant files for reference. Note that files header1.h, header2.h, header1_export.h and header2_export.h are without the additional namespace, while files header1n.h, header2n.h, header1n_export.h, and header2n_export.h are WITH the additional namespace. Thanks for any help. Bernd

3 4

date_time streaming operators bug report
by Maxim Yegorushkin 27 Mar '08

27 Mar '08

Good evening gentlemen, Boost::gregorian::date streaming operators currently alter the locale of the stream by inserting a custom_date_facet allocated on the heap into the locale. The facet never gets explicitly destroyed, rather its ownership is passed to the locale. Locale's destructor destroys the facet eventually. As the code of the streaming operators, the constructor and the (compiler generated) virtual destructor of the facet belong to header files, the vtable for the facet ends up in the object file of the translation unit that first calls a streaming operator and creates the facet. The problem arises when using dynamic linking. It manifests itself most apparently when locale's destructor is invoked. Locale's destructor accesses the vtables of the facets when destroying them. This requires the vtables to be accessible. If the module which contained the vtable of custom_date_facet has already been unloaded, the facet on the heap is left with a dangling vtable pointer. If the virtual address space range of the unloaded module is not accessible any more (has been unmapped), accessing the dangling vtable pointer leads to a crash. The crash was first encountered on Windoze XP SP2 + MSVC 2005 SP1 + boost-1.33.x and reproduced on Linux Fedora 8 + gcc-4.1.4 + boost-1.34.1 on the same day. Here are the steps to reproduce: 1) A (C-language) application without C++ run-time dependencies explicitly loads at run-time two shared libraries (Foo, then Bar) linked dynamically against the same C++ run-time shared library. Loading the first library causes the C++ run-time library to be loaded and initialised. 2) A call is made to library Foo. The library outputs a boost::gregorian::date into std::cout, creating the facet. Another call is made to Bar just in case, which outputs just text into std::cout. 3) The libraries unloaded in the same order (Foo, the Bar). Unloading the second library decrements the reference counter of the C++ run-time dynamic library to zero and causes it do deinitialise. Deinitialising involves destroying the standard streams and eventually the locale the facet belongs to. The vtable pointer of the facet object refers to the address in Foo, which has already been unloaded. The application crashes. Following is output of Linux crush. Please note, in the backtrace in stack frame 0 offending address 0x00135f20 belongs to unloaded foo.so, which can be deduced from the process memory map. A fix might be to avoid passing the ownership of the facet to the locale of the stream (i.e. avoid calling imbue()), rather have the facet allocated statically elsewhere and use it if the stream does not have one already (attached explicitly by the user if desired). Max [max@zen boost_custom_date_facet]$ cat main.c #include <dlfcn.h> #include <stdlib.h> #include <stdio.h> #include <errno.h> #include <string.h> #define CHECK(expr, ...) if(expr) {} else { \ fprintf(stderr, "%s:%d: ", __FILE__, __LINE__); \ fprintf(stderr, __VA_ARGS__); \ fprintf(stderr, "\n"); \ exit(EXIT_FAILURE); \ } typedef void fun_t(); int main() { void *foo_lib, *bar_lib; fun_t *foo, *bar; printf("---- loading foo.so\n"); CHECK((foo_lib = dlopen("./foo.so", RTLD_NOW)), "%s", dlerror()); CHECK((foo = (fun_t*)dlsym(foo_lib, "foo")), "%s", dlerror()); printf("---- foo.so loaded\n"); printf("---- loading bar.so\n"); CHECK((bar_lib = dlopen("./bar.so", RTLD_NOW)), "%s", dlerror()); CHECK((bar = (fun_t*)dlsym(bar_lib, "bar")), "%s", dlerror()); printf("---- bar.so loaded\n"); printf("---- invoking foo()\n"); foo(); printf("---- invoking bar()\n"); bar(); printf("---- unloading foo.so\n"); CHECK(!dlclose(foo_lib), "%s", dlerror()); printf("---- foo.so unloaded\n"); printf("---- unloading bar.so\n"); CHECK(!dlclose(bar_lib), "%s", dlerror()); // <---- crashes here printf("---- bar.so unloaded\n"); return EXIT_SUCCESS; } [max@zen boost_custom_date_facet]$ cat foo.cc #include <iostream> #include <fstream> #include <boost/date_time/gregorian/gregorian.hpp> extern "C" void foo() { boost::gregorian::date d(2008, 3, 26); std::cout << "foo\n" << d << '\n' << std::ifstream("/proc/self/maps").rdbuf() << std::endl ; } [max@zen boost_custom_date_facet]$ cat bar.cc #include <iostream> extern "C" void bar() { std::cout << "bar" << std::endl; } [max@zen boost_custom_date_facet]$ cat test.sh #!/bin/bash -x uname -a rpm -q gcc gcc-c++ boost # exit on compiler errors set -e gcc -o main -g -Wall -Wextra -ldl main.c g++ -o foo.so -D_GLIBCXX_DEBUG -fpic -g -Wall -Wextra -shared foo.cc g++ -o bar.so -D_GLIBCXX_DEBUG -fpic -g -Wall -Wextra -shared bar.cc ls -l main foo.so bar.so # don't exit on main crash set +e ulimit -c unlimited rm -f core* LD_DEBUG=libs ./main gdb -silent main core* <<EOF bt EOF [max@zen boost_custom_date_facet]$ ./test.sh + uname -a Linux zen 2.6.24.3-34.fc8 #1 SMP Wed Mar 12 18:17:20 EDT 2008 i686 i686 i386 GNU/Linux + rpm -q gcc gcc-c++ boost gcc-4.1.2-33 gcc-c++-4.1.2-33 boost-1.34.1-7.fc8 + set -e + gcc -o main -g -Wall -Wextra -ldl main.c + g++ -o foo.so -D_GLIBCXX_DEBUG -fpic -g -Wall -Wextra -shared foo.cc + g++ -o bar.so -D_GLIBCXX_DEBUG -fpic -g -Wall -Wextra -shared bar.cc + ls -l main foo.so bar.so -rwxrwxr-x 1 max max 63878 2008-03-27 00:01 bar.so -rwxrwxr-x 1 max max 835145 2008-03-27 00:01 foo.so -rwxrwxr-x 1 max max 9298 2008-03-27 00:01 main + set +e + ulimit -c unlimited + rm -f core.25031 + LD_DEBUG=libs + ./main 25064: find library=libdl.so.2 [0]; searching 25064: search cache=/etc/ld.so.cache 25064: trying file=/lib/libdl.so.2 25064: 25064: find library=libc.so.6 [0]; searching 25064: search cache=/etc/ld.so.cache 25064: trying file=/lib/libc.so.6 25064: 25064: 25064: calling init: /lib/libc.so.6 25064: 25064: 25064: calling init: /lib/libdl.so.2 25064: 25064: 25064: initialize program: ./main 25064: 25064: 25064: transferring control: ./main 25064: ---- loading foo.so 25064: find library=libstdc++.so.6 [0]; searching 25064: search cache=/etc/ld.so.cache 25064: trying file=/usr/lib/libstdc++.so.6 25064: 25064: find library=libm.so.6 [0]; searching 25064: search cache=/etc/ld.so.cache 25064: trying file=/lib/libm.so.6 25064: 25064: find library=libgcc_s.so.1 [0]; searching 25064: search cache=/etc/ld.so.cache 25064: trying file=/lib/libgcc_s.so.1 25064: 25064: 25064: calling init: /lib/libgcc_s.so.1 25064: 25064: 25064: calling init: /lib/libm.so.6 25064: 25064: 25064: calling init: /usr/lib/libstdc++.so.6 25064: 25064: 25064: calling init: ./foo.so 25064: ---- foo.so loaded ---- loading bar.so 25064: 25064: calling init: ./bar.so 25064: ---- bar.so loaded ---- invoking foo() foo 2008-Mar-26 00110000-00111000 r-xp 00110000 00:00 0 [vdso] 00111000-00147000 r-xp 00000000 08:05 17178033 /home/max/src/boost_custom_date_facet/foo.so 00147000-00149000 rwxp 00036000 08:05 17178033 /home/max/src/boost_custom_date_facet/foo.so 00149000-0014c000 r-xp 00000000 08:05 17178034 /home/max/src/boost_custom_date_facet/bar.so 0014c000-0014d000 rwxp 00002000 08:05 17178034 /home/max/src/boost_custom_date_facet/bar.so 00700000-0070b000 r-xp 00000000 08:01 3649841 /lib/libgcc_s-4.1.2-20070925.so.1 0070b000-0070c000 rwxp 0000a000 08:01 3649841 /lib/libgcc_s-4.1.2-20070925.so.1 007b8000-007d3000 r-xp 00000000 08:01 3647869 /lib/ld-2.7.so 007d3000-007d4000 r-xp 0001a000 08:01 3647869 /lib/ld-2.7.so 007d4000-007d5000 rwxp 0001b000 08:01 3647869 /lib/ld-2.7.so 007d7000-0092a000 r-xp 00000000 08:01 3647870 /lib/libc-2.7.so 0092a000-0092c000 r-xp 00153000 08:01 3647870 /lib/libc-2.7.so 0092c000-0092d000 rwxp 00155000 08:01 3647870 /lib/libc-2.7.so 0092d000-00930000 rwxp 0092d000 00:00 0 00932000-00959000 r-xp 00000000 08:01 3649817 /lib/libm-2.7.so 00959000-0095a000 r-xp 00026000 08:01 3649817 /lib/libm-2.7.so 0095a000-0095b000 rwxp 00027000 08:01 3649817 /lib/libm-2.7.so 0095d000-00960000 r-xp 00000000 08:01 3649815 /lib/libdl-2.7.so 00960000-00961000 r-xp 00002000 08:01 3649815 /lib/libdl-2.7.so 00961000-00962000 rwxp 00003000 08:01 3649815 /lib/libdl-2.7.so 0616a000-0624a000 r-xp 00000000 08:01 4058038 /usr/lib/libstdc++.so.6.0.8 0624a000-0624e000 r-xp 000df000 08:01 4058038 /usr/lib/libstdc++.so.6.0.8 0624e000-0624f000 rwxp 000e3000 08:01 4058038 /usr/lib/libstdc++.so.6.0.8 0624f000-06255000 rwxp 0624f000 00:00 0 08048000-08049000 r-xp 00000000 08:05 17178019 /home/max/src/boost_custom_date_facet/main 08049000-0804a000 rw-p 00000000 08:05 17178019 /home/max/src/boost_custom_date_facet/main 09597000-095b8000 rw-p 09597000 00:00 0 b7f99000-b7f9b000 rw-p b7f99000 00:00 0 b7fb3000-b7fb4000 rw-p b7fb3000 00:00 0 bfec6000-bfedb000 rw-p bffea000 00:00 0 [stack] ---- invoking bar() bar ---- unloading foo.so 25064: 25064: calling fini: ./foo.so [0] 25064: ---- foo.so unloaded ---- unloading bar.so 25064: 25064: calling fini: ./bar.so [0] 25064: 25064: 25064: calling fini: /usr/lib/libstdc++.so.6 [0] 25064: ./test.sh: line 17: 25064 Segmentation fault (core dumped) LD_DEBUG=libs ./main + gdb -silent main core.25064 Using host libthread_db library "/lib/libthread_db.so.1". warning: Can't read pathname for load map: Input/output error. Missing separate debuginfo for ./bar.so Try: yum --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/63/a5b3dd1b5bb0cac7f2460e64314ba4bb271ba1 Reading symbols from /lib/libdl-2.7.so...Reading symbols from /usr/lib/debug/lib/libdl-2.7.so.debug...done. done. Loaded symbols for /lib/libdl-2.7.so Reading symbols from /lib/libc-2.7.so...Reading symbols from /usr/lib/debug/lib/libc-2.7.so.debug...done. done. Loaded symbols for /lib/libc-2.7.so Reading symbols from /lib/ld-2.7.so...Reading symbols from /usr/lib/debug/lib/ld-2.7.so.debug...done. done. Loaded symbols for /lib/ld-2.7.so Reading symbols from /usr/lib/libstdc++.so.6.0.8...Reading symbols from /usr/lib/debug/usr/lib/libstdc++.so.6.0.8.debug...done. done. Loaded symbols for /usr/lib/libstdc++.so.6.0.8 Reading symbols from /lib/libm-2.7.so...Reading symbols from /usr/lib/debug/lib/libm-2.7.so.debug...done. done. Loaded symbols for /lib/libm-2.7.so Reading symbols from /lib/libgcc_s-4.1.2-20070925.so.1...Reading symbols from /usr/lib/debug/lib/libgcc_s-4.1.2-20070925.so.1.debug...done. done. Loaded symbols for /lib/libgcc_s-4.1.2-20070925.so.1 Reading symbols from /home/max/src/boost_custom_date_facet/bar.so...done. Loaded symbols for ./bar.so Core was generated by `./main'. Program terminated with signal 11, Segmentation fault. #0 0x00135f20 in ?? () (gdb) #0 0x00135f20 in ?? () #1 0x061b5b51 in std::ios_base::Init::~Init () at /usr/src/debug/gcc-4.1.2-20070925/obj-i386-redhat-linux/i386-redhat-linux/libstdc++-v3/include/bits/basic_string.h:274 #2 0x061cb0f0 in __tcf_0 () at /usr/src/debug/gcc-4.1.2-20070925/obj-i386-redhat-linux/i386-redhat-linux/libstdc++-v3/include/iostream:76 #3 0x00803907 in __cxa_finalize (d=0x624b588) at cxa_finalize.c:56 #4 0x061a9c54 in __do_global_dtors_aux () from /usr/lib/libstdc++.so.6.0.8 #5 0x062251dc in _fini () from /usr/lib/libstdc++.so.6.0.8 #6 0x007cb0c2 in _dl_close_worker (map=0x9597f48) at dl-close.c:271 #7 0x007cb877 in _dl_close (_map=0x9597f48) at dl-close.c:729 #8 0x0095dd24 in dlclose_doit () from /lib/libdl-2.7.so #9 0x007c61b6 in _dl_catch_error (objname=0x96105c, errstring=0x961060, mallocedp=0x961058, operate=0x95dd00 <dlclose_doit>, args=0x9597f48) at dl-error.c:178 #10 0x0095e30c in _dlerror_run () from /lib/libdl-2.7.so #11 0x0095dd5a in dlclose () from /lib/libdl-2.7.so #12 0x080488b9 in main () at main.c:41 (gdb) quit

1 0

[smart_ptr] get_deleter documentation
by Daniel Frey 26 Mar '08

26 Mar '08

Hi, get_deleter is missing "throws: nothing". At least I hope it never throws... :) Regards, Daniel

2 2

[1.35.0] Release Candidate 2 available
by Beman Dawes 26 Mar '08

26 Mar '08

1.35.0 Release Candidate 2 (RC2) is available at http://boost.cowic.de/rc/ RC2 fixes all of the serious issues reported for RC1. Note that links to the web site from the RC appear to be broken because the restructured web site will not go live until the actual release ships. In the meantime, the new website content is available at beta.boost.org. Please take the time to download RC2, and try to install it on your system. Kick the tires, and report any problems or issues you discover. Report by posting to either boost(a)lists.boost.org or boost-users(a)lists.boost.org. For a list of known issues, see http://svn.boost.org/trac/boost/wiki/MergeOneDotThreeFiveDotZero. Thanks, --Beman

9 19

Re: [boost] [1.35.0] Release Candidate 2 available
by Bruno Lalande 26 Mar '08

26 Mar '08

> > > Is the release mode link error an actual error, or just (un)informative > messages being printed by the linker. Apparently it's not a mere informative message, since the link phase finally ends up in error with a "collect2: ld returned 1 exit status". However, the description of the bug #16276 that originated the bug #16625 says that the issue "may lead to linker failure or corrupted binary", so indeed, it can be what I'm facing. Thanks for the information. Bruno

3 2

Why there is no boost::rational for non IntType ?
by Reetesh Mukul 26 Mar '08

26 Mar '08

Why there is no boost::rational for non IntType ? I think there are cases where we require such type of rationals, e.g. ( 2 + 3i) / (5 + 6i). In std::complex, we don't have any such constraint on element type of the complex number. That is, though std::complex<double> is quite natural we can have the construct std::complex<int> as well. Is boost::rational<> strictly modeled on the basis of rational numbers ? Another question, is there any continued fraction library in BOOST ? With Regards, Reetesh Mukul

4 3

[pool] boost::details::pool::lcm parameters
by dherring＠ll.mit.edu 26 Mar '08

26 Mar '08

Quick question: In boost/pool/detail/gcd_lcm.hpp, why does template <typename Integer> Integer lcm(const Integer & A, const Integer & B); take its parameters as const references instead of just passing the values? I don't see a reason to do this; gdc(A, B) takes values. Thanks, Daniel P.S. As seen in boost_1_35_0_RC2, aka boost-posix-2008-03-21.

2 2

Re: [boost] [Fwd: Re: [proto]possible morphism design (was Re: Proto review: a humble request]
by Eric Niebler 26 Mar '08

26 Mar '08

Larry Evans wrote: > Hi Eric. > > Apparently some of my posts aren't getting through. I posted > the attached before my reply to Hartmut, but it hasn't made it > to the newsgroup yet. So, I thought you might like a look at > it. Do you post messages to GMane or email them to the list. I do the later. From: Larry Evans <cppljevans(a)suddenlink.net> > On 03/24/08 17:15, Eric Niebler wrote: <snip> > > I can't tell where we are getting confused, but I > > suspect that you've been misled by the role of the terminal<>, negate<>, > > plus<>, etc. meta-functions. They are not expression types ... they are > > meta-functions that generate expression types. > > Yes. I'm embarrassed. I was away from the thread awhile and forgot > that in the expr equation here: > > http://archives.free.net.ph/message/20080322.024505.84b8c598.en.html > > expr *only* meant instances of proto::expr<Tag,Args,Arity> > for some Tag,Args, and Arity. > > The reason I added the ::type later was because I remembered that > using the meta-functions required that to produce an expression and > also, somewhere in my testing (can't remember where, ATM) I had to > append ::type to the args to a meta-function template's args to get an > expression. > > Sorry, I should have been more careful. No problem. Glad the fog of confusion is thinning. <snip> > > you can't convert a proto grammar to a proto expression type, in > > general. > > The 'in general' is the key phrase there. I wasn't attempting to > convert the grammars that weren't convertible. The grammars that > *are* convertible are those formed from the 'meta-functions that > generate expression types'( as you said above) *and* whose arguments > have been *similarly converted* (otherwise, an argument could be a > grammar and consequently the conversion result *wouldn't* be an > expression type). > > > We've covered this ground already ... grammar types are a > > super-set of expression types. > > I know. I'm sorry. I just hadn't got firm in my mind that > I was talking about expression types instead of meta-function > generators. The probable reason is that: > > meta-function<Args> is a grammar > > meta-function<Args>::type is an expression_type > (under certain restrictions on Args) Correct. > and: > > expression_type is a grammar > > got me mixed up and lead me to jump to the conclusion: > > expression_type::type is an expression type > > when, in fact, there's no such nested type. I supposed that > expression_type::type simply equaled expression_type (which is what > mpl meta-functions often do, IIRC). Right, expr<> doesn't have a nested ::type typedef. It used to, but it got renamed to ::proto_base_expr. > [snip] > > > > Any formalism that is based on > > converting a proto grammar to a proto expression by accessing a nested > > ::type typedef is wrong. Grammars are not convertible to expressions. > > The meta-functions that generate expression types are not expressions > > themselves. They are meta-functions. > > From: > > The meta-functions are also *usable as grammars* for matching such nodes > > on: > > libs/proto/doc/html/boost_proto/users_guide/expression_construction/tags_and_meta_functions.html > > a meta-function *is* a grammar and can be used to "generate expression > types"(quoting you). Maybe instead of "grammar conversion to > expression" I should have said "meta-function grammar use to generate > an expression". Hmm, ok. > I assume an example of this is: > > terminal<int>::type > > where grammar, terminal<int> (it's a grammar according to the above > .html reference), is used to generate the expression type, > expr<tag:terminal,args0<int> >. > > ============================================== > Now, back to the question of morphisms. If the source algebra is just > meta-function grammars whose arguments are also meta-function grammars, > then there's a morphism from that to the target algebra which is expression > types. The morphism, f, is simply applying the meta-function > recursively. The base case, is of course, the terminals: > > base_case: > > terminal<T> //a meta-function grammar in source algebra. > f<terminal<T> >::type > ==> terminal<T>::type //the corresponding expression in the target > //algebra. Yes. > > recursive_case: > > metafun<M1,M2,...Mn> //a meta-function grammar. > > f<metafun<M1,M2,...,Mn> >::type > ==> metafun<f<M1>::type,f<M1>::type,...,f<Mn>::type>::type > //^the corresponding expression in target algebra. Ah, yes. > here, metafun can be any of the meta-functions listed here: > > libs/proto/doc/html/boost_proto/users_guide/expression_construction/tags_and_meta_functions.html > > (except maybe the if_else_). The attached compiles and shows that the > above at least works for the morphism between 0-ary and 1-ary > meta-functions and expressions. The attached uses morphism instead of > f as the name of the morphism. OK! I understand that, and it is correct in the limited case of those dual-purpose grammars-and-metafunctions. I'm re-attaching your code, in case others want to see it. -- Eric Niebler Boost Consulting www.boost-consulting.com

1 0