November 2010 - Boost - lists.preview.boost.org

[process] How to run test cases
by Boris 23 Jan '11

23 Jan '11

As Boost.Process 0.3 has been released it would be great if the test cases are run on various platforms. So far I've tested Boost.Process on WinXP with MSVC 9.0, Cygwin with g++ 3.4.4 and Solaris with g++ 3.4.6 and Sun C++ 5.9. To make it as easy as possible for others to run the test cases here's a short description of how to proceed. Nearly all test cases depend on a program called "helpers". This program is built first and is started by many test cases as a child process. In order to find the program "helpers" the test cases must know its location. As there is no way to get the location at runtime it is hardcoded in the file libs/process/test/misc.hpp. As the location differs depending on what compiler is used YOU MUST CHECK FIRST THE PATH IN libs/process/test/misc.hpp! Otherwise most of the test cases will fail as they look for a program "helpers" in the wrong directory. As of today only those paths are correct and have been tested which are set for Windows, Cygwin and Solaris. Only after you have checked and maybe updated the path in libs/process/test/misc.hpp you should try to build and run the test cases: WinXP/MSVC 9.0 ************** With MSVC 9.0 you only need to open the Visual Studio 2008 Command Prompt, change to the directory with the test cases and run bjam: C:\boost_1_36_0\libs\process\test> ..\..\..\bjam.exe -q Cygwin/GCC 3.4.4 **************** On Cygwin it's important to know if the Boost libraries have been built for the POSIX or Windows API. By default Boost libraries on Cygwin use the Windows API. With the Windows API the Boost.Process test cases are not passed successfully though (there are compiler errors where I'm not sure currently if they are a Boost.Process problem and how they could be fixed). If you want to run the test cases on Cygwin you must (re-)build the Boost libraries to use the POSIX API: $ cd ~/boost_1_36_0 $ ./bjam cxxflags=-DBOOST_POSIX_API Afterwards you can run the test cases: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam cxxflags=-DBOOST_POSIX_API -q Solaris/GCC 3.4.6 ***************** At first you have to put the following line in ~/user-config.jam: using gcc : : : <linker-type>sun ; Then start building the Boost libraries: $ cd ~/boost_1_36_0 $ ./bjam --toolset=gcc cxxflags=-mcpu=ultrasparc For the test cases to be passed successfully you must update Boost.Test. Change line 624 in ~/boost_1_36_0/boost/test/impl/execution_monitor.ipp temporarily to: - , m_CHLD_action( SIGCHLD, catch_system_errors, attach_dbg, alt_stack ) + , m_CHLD_action( SIGCHLD, false, attach_dbg, alt_stack ) It is important that the second parameter is false as the signal SIGCHLD should not be handled by the execution monitor and should not be reported as an error. Afterwards the test cases can be run: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam --toolset=gcc cxxflags=-mcpu=ultrasparc -q Solaris/Sun C++ 5.9 ******************* Build the Boost libraries with the sun toolset: $ cd ~/boost_1_36_0 $ ./bjam --toolset=sun stdlib=sun-stlport For the test cases to be passed successfully you must update Boost.Test. Change line 624 in ~/boost_1_36_0/boost/test/impl/execution_monitor.ipp temporarily to: - , m_CHLD_action( SIGCHLD, catch_system_errors, attach_dbg, alt_stack ) + , m_CHLD_action( SIGCHLD, false, attach_dbg, alt_stack ) It is important that the second parameter is false as the signal SIGCHLD should not be handled by the execution monitor and should not be reported as an error. If you run the test cases now you'll get this compiler error for one test case: "../../../boost/asio/detail/socket_ops.hpp", line 218: Error: Cannot assign void* to char*. "../../../boost/asio/detail/socket_ops.hpp", line 229: Error: Cannot assign void* to char*. "../../../boost/asio/detail/descriptor_ops.hpp", line 66: Error: Cannot assign void* to char*. "../../../boost/asio/detail/descriptor_ops.hpp", line 72: Error: Cannot assign void* to char*. The bug has been reported to the Boost.Asio mailing list. If you want to build that one test case, too, you need to fix the two files in Boost.Asio 1.36.0 yourself. All the test cases can be built and run with: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam --toolset=sun stdlib=sun-stlport -q

4 9

review request: addition to type_traits library of has_operator_xxx
by Frédéric Bron 19 Jan '11

19 Jan '11

I would like to propose to your review the following addition to the type_traits library, available at the following addresses: https://svn.boost.org/trac/boost/browser/sandbox/type_traits http://dl.free.fr/lRm4VL6WP/type_traits.tar.bz2 The purpose of the addition is to add type traits to detect if unary and binary operators can be applied to given types. For example, is "x<y" or "!x" or "x+y" meaningful? If required, the return type of such an expression is checked to know if it is convertible to a given type. Default behaviour is to not check the return type. The following traits are added: // binary operators: template < typename LHS, typename RHS=LHS, typename RET=void > == has_operator_equal_to != has_operator_not_equal_to > has_operator_greater >= has_operator_greater_equal < has_operator_less <= has_operator_less_equal + has_operator_plus - has_operator_minus * has_operator_multiplies / has_operator_divides % has_operator_modulus && has_operator_logical_and || has_operator_logical_or & has_operator_bit_and | has_operator_bit_or ^ has_operator_bit_xor // unary operators: template < typename RHS, typename RET=void > + has_operator_unary_plus - has_operator_unary_minus ! has_operator_logical_not This new version reflects the discussions we had on the list: http://thread.gmane.org/gmane.comp.lib.boost.devel/194625 In particular about the check or not of the return type. All operators are now included and not only comparison binary operators. Example: has_operator_less<LHS, RHS, RET>::value_type is the type bool. has_operator_less<int> inherits from true_type. has_operator_less<int, int, std::string> inherits from false_type. has_operator_unary_minus<int, long> inherits from true_type. has_operator_unary_minus<double, int> inherits from true_type. has_operator_unary_minus<int, std::string> inherits from false_type. Documentation is accessible at libs/type_traits/doc/html/index.html in the archive. Regards, Frédéric PS: tested with g++ 4.4.5 on i686-linux.

14 53

[Boost][BGL] New isomorphism test algorithm contribution
by Carlos Cardeñosa Pérez 17 Jan '11

17 Jan '11

Hi, I have been developing a new implementation for test graphs isomorphism, named conauto <http://sites.google.com/site/giconauto/> algorithm (based on José Luis López Presa thesis). I would like to contribute it to BGL. This is a more efficient algorithm than the current one. You can study all its details from conauto thesis at here<http://www.diatel.upm.es/jllopez/tesis/thesis.pdf> . Once developed the first conauto BGL-style version, I am sure that there are many advises and comments that could help to enhance it and eventually will be acceptable for BGL maintainers. Find attached both the source code and some measurements graphics. Please, do not hesitate ask me for any additional information. Best regards, Carlos Cardeñosa.

2 7

[system][chrono] header-only libs
by vicente.botet 06 Jan '11

06 Jan '11

Hi, after discussion with Ion about whether Boost.Interprocess could use Boost.Chrono and Boost.System he has found as major drawback that both are not header-only libs. I have implemented Boost.Chrono as a header only lib. If the user wants Boost.Chrono be a header-only lib s/he needs to define the BOOST_CHRONO_INLINED macro. While this could be useful, there is a problem as Boost.Chrono depends on Boost.System that is not a header-only lib. * I have added this on the configuration file #ifdef BOOST_CHRONO_INLINED #define BOOST_CHRONO_INLINE inline #define BOOST_CHRONO_DECL #else #define BOOST_CHRONO_INLINE // as before #endif * Copied all the .cpp files to the detail/inlined directory. * Renamed the .cpp file by .hpp files * Included in the old .cpp files the corresponding .hpp file in the detail/inlined directory * I've replaced the prefix suffix as follows: #ifndef BOOST_CHRONO_INLINED #include <boost/config/abi_prefix.hpp> // must be the last #include #endif #ifndef BOOST_CHRONO_INLINED #include <boost/config/abi_suffix.hpp> // pops abi_prefix.hpp pragmas #else #include <boost/chrono/detail/inlined/file_name.hpp> #endif * prefixed the definitions of the function in the .cpp files by BOOST_CHRONO_INLINE While doing this I have found a minor issue on Windows platform. I hve nedeed to sorrounded by () all the use of min and max functions on the test files to avoid the macros defined on the windows.h file. That means that a header-only lib could break user sources as it will include implicitly some platform files. Another drawback that I have no inspected yet could be the increase in size and compilation time of the user code. Beman do you mind if I try to make your library configurable as header-only, so Ion could use Boost.System and Boost.Chrono and preserve Boost.Interprocess as a header-only lib? Best, Vicente P.S. You can see the sandbox for the last modifications _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

8 23

[Review] Formal Review of Proposed Boost.Chrono Library Starts TOMORROW
by Anthony Williams 05 Jan '11

05 Jan '11

Hi everyone, The review of Vicente Botet's Chrono library starts TOMORROW (November 6th) and lasts until November 15th unless an extension occurs. What is it? ======== Boost.Chrono aims to implement the new time facilities in C++0x, as proposed in N2661 - A Foundation to Sleep On (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm) That document provides background and motivation for key design decisions and is the source of a good deal of information in this documentation. See the current C++0x working draft at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3126.pdf for details of what was accepted. The Boost.Chrono library provides: * A means to represent time durations: managed by the generic duration class . Examples of time durations include days, minutes, seconds and nanoseconds, which can be represented with a fixed number of clock ticks per unit. All of these units of time duration are united with a generic interface by the duration facility. * A type for representing points in time: time_point. A time_point represents an epoch plus or minus a duration. The library leaves epochs unspecified. A time_point is associated with a clock. * Several clocks, some of which may not be available on a particular platform: system_clock, monotonic_clock and high_resolution_clock. A clock is a pairing of a time_point and duration, and a function which returns a time_point representing now. * To make the timing facilities more generally useful, Boost.Chrono provides a number of additional clocks that are thin wrappers around the operating system's time APIs, thereby allowing the extraction of read (wall clock) time, user CPU time, system CPU time, - process_real_cpu_clock, captures real (wall clock) CPU times. - process_user_cpu_clock, captures user-CPU times. - process_system_cpu_clock, captures system-CPU times. - A tuple-like class __process_cpuclock_, that captures real, user-CPU, and system-CPU times together. - A thread_clock thread monotonic clock, when supported by a platform. * Boost.Chrono also includes typeof registration for duration and time_point to permit using emulated auto with C++03 compilers. * Boost.Chrono also provides I/O for duration and time_point. It builds on <boost/ratio/ratio_io.hpp> to provide readable and flexible formatting and parsing for types in <boost/chrono.hpp>. The duration unit names can be customized through a new facet: duration_punct. Getting the library ============= The latest version of this library may be downloaded from vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=chrono… SVN: http://svn.boost.org/svn/boost/sandbox/chrono Boost.Chrono depends on Boost.Ratio http://www.boostpro.com/vault/index.php?action=downloadfile&filename=ratio.… and optionaly Boost.System Header Only http://www.boostpro.com/vault/index.php?action=downloadfile&filename=system…. and the docs may be viewed here HTML: http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/doc/html/index.ht… PDF: http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/doc/chrono.pdf You can get all these information also (which should avoid some long links) from http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Chrono Writing a review ================ If you feel this is an interesting library, then please submit your review to the developer list (preferably), or to the review manager. Here are some questions you might want to answer in your review: - 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? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Anthony Review Manager for the proposed Boost.Chrono library -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

9 32

[smart_ptr] enable_shared_from_this and multiple inheritance solution
by Philippe Cayouette 03 Jan '11

03 Jan '11

Fellow boosters, A little while ago I found a pernicious problem with enable_shared_from_this when used with multiple inheritance. Here is an example: #include <boost/smart_ptr.hpp> #include <boost/enable_shared_from_this.hpp> class Base1 : public boost::enable_shared_from_this< Base1 > { public: Base1() {} virtual ~Base1() {} boost::shared_ptr< Base1 > GetBase1() { return shared_from_this(); } }; class Base2 : public boost::enable_shared_from_this< Base2 > { public: Base2() {} virtual ~Base2() {} boost::shared_ptr< Base2 > GetBase2() { return shared_from_this(); } }; class Derived : public Base1, public Base2 { }; int main() { boost::shared_ptr< Derived > wDerived(new Derived()); // Either of the following lines crashes with GCC, but the first one // passes on VS2005 boost::shared_ptr< Base1 > wBase1 = wDerived->GetBase1(); boost::shared_ptr< Base2 > wBase2 = wDerived->GetBase2(); return 0; } Since Derived inherits from two bases that each inherits from enable_shared_from_this, it has two internal weak_ptr. These weak_ptr are usualy initialised in the constructor of the shared_ptr and I have observed two different behavior with the above code depending if I build it with VS2005 or GCC. With VS2005, the first base class in the inheritance list of Derived (here Base1) get its internal weak_ptr initialized, but not the second one, thus it crashes when we try to access the Base2 weak_ptr via shared_from_this. On GCC, neither base classes get their internal weak_ptr initialized and both base classes access to their internal weak_ptr provokes a crash. To prevent that kind of problem, I created a SmartPtrBuilder and a (very) slightly modified EnabledSharedFromThis (only one assert was removed). Here is the same program with the modifications: #include <boost/smart_ptr.hpp> #include "EnableSharedFromThis.h" #include "SmartPtrBuilder.h" class Base1 : public Generic::EnableSharedFromThis< Base1 > { public: Base1() {} virtual ~Base1() {} boost::shared_ptr< Base1 > GetBase1() { return SharedFromThis(); } }; class Base2 : public Generic::EnableSharedFromThis< Base2 > { public: Base2() {} virtual ~Base2() {} boost::shared_ptr< Base2 > GetBase2() { return SharedFromThis(); } }; class Derived : public Base1, public Base2 { public: // Factory method static boost::shared_ptr< Derived > Create() { return Generic::SmartPtrBuilder::CreateSharedPtr< Base1, Base2 >(new Derived()); } private: Derived() {} }; int main() { boost::shared_ptr< Derived > wDerived = Derived::Create(); // No more crashes boost::shared_ptr< Base1 > wBase1 = wDerived->GetBase1(); boost::shared_ptr< Base2 > wBase2 = wDerived->GetBase2(); return 0; } As you can see, Derived has now a factory method that uses the SmartPtrBuilder to create the shared_ptr. Two template arguments are used on CreateSharedPtr, allowing it to initialize the internal weak_ptr of each base classes. The SmartPtrBuilder I did can support up to 10 base classes as template arguments and I also did a variadic template version which has no limit. By using the factory method, the users of Derived don't need to know which of its base classes need its internal weak_ptr need to be initialized. Source code for the SmartPtrBuilder and the modified EnableSharedFromThis: http://spoluck.ca:8000/boost/EnableSharedFromThis.h http://spoluck.ca:8000/boost/SmartPtrBuilder.h That builder might be incorporated to the boost smart pointer library so that anyone could use its facilities to prevent the problem mentioned earlier. No modification to the mighty shared_ptr class required, only the addition of a builder. What do you think? Philippe

3 7

[SoC] BGL project idea
by Gautam Sewani 03 Jan '11

03 Jan '11

Hi, I am a Computer Science student hoping to contribute to Boost for this year's summer of code. I had a few questions regarding the BGL project idea (https://svn.boost.org/trac/boost/wiki/SoC2010#Boost.Graph) for SOC 2010. 1. I can think of only a few places where the suggested algorithms will be used. Does the community think that these algorithms are used frequently enough to put them in a library? How important does the community consider this project? 2. Will the project proposal be expected to include the API design? Thanks and Regards Gautam

5 29

[Review][Ratio] Boost.Ratio has been ACCEPTED
by Anthony Williams 01 Jan '11

01 Jan '11

Hi, I am pleased to announce that Boost.Ratio has been ACCEPTED into Boost. There were not as many reviews for Boost.Ratio as for some libraries, but they were overwhelmingly positive. Boost.Ratio is an important building block for other upcoming submissions, and provides an implementation of the C++0x rational arithmetic facilities. A few changes were requested by the reviewers, which I will list below. I know that Vicente has already started working on some of these. These changes should be addressed before the library appears in a Boost release. * Some of the macros had names with RATIO_RATIO in. These should be changed to just RATIO * The ratio_add, ratio_sub, ratio_multiply and ratio_divide templates should derive from the resulting ratio type as well as providing the nested ::type member, in order to closely emulate the template alias facility from C++0x * The typos in the documentation should be fixed, and the documentation reviewed for correctness and clarity (though several of the reviewers made positive comments on the quality of the documentation). * The library needs more tests under the Boost Software License. * All references to names from the boost namespace should be qualified with boost:: to avoid potential name clashes and ambiguity with names from the global namespace. * Sections commented out with #if 0 should be removed * The extensions beyond the facilities required by the C++0x draft should be able to be enabled or disabled through use of a configuration macro. * References to the tests, examples and documentation from within the code should be checked for correctness. I would like to thank Vicente for submitting the library and those that took the time to write a review. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

2 2

[Bug Sprint] The Boost bug sprint has begun!
by Marshall Clow 18 Dec '10

18 Dec '10

As of 7 AM PDT, there are 939 open bugs. [ I see that Vicente and Mattias have already started - that's great! ] General information about the bug sprint is here: https://svn.boost.org/trac/boost/wiki/BugSprintNov2010 General information about how the Trac system works is here: https://svn.boost.org/trac/boost/wiki/TicketWorkflow If you're looking for some way to contribute, I would suggest looking at the oldest active tickets, <https://svn.boost.org/trac/boost/report/1?sort=created&asc=1&page=1> and see if they are still valid. There are about 90 active tickets from 2005-2007. [ Many of them are feature requests, but there are bugs there too. ] Here are a couple of summary tables to give you an idea of where we are: https://svn.boost.org/trac/boost/report/20 Type Tickets Bugs 549 Feature Requests 250 Patches 99 Tasks 28 Support Requests 13 https://svn.boost.org/trac/boost/report/21 Milestone Tickets To Be Determined 352 Boost 1.43.0 102 Boost 1.44.0 98 Boost 1.42.0 75 Boost 1.36.0 50 Boost 1.40.0 48 Boost 1.39.0 44 <blank> 41 Boost 1.41.0 40 Boost 1.38.0 30 Boost 1.37.0 25 Boost-1.45.0 15 Boost-1.46.0 11 Website 1.X 4 Boost-1.47.0 1 Boost.Jam 3.1.18 1 Boost.Jam 4.0.0 1 https://svn.boost.org/trac/boost/report/19 Component Tickets date_time 61 thread 50 Python 48 filesystem 42 build 40 asio 38 mpl 38 smart_ptr 37 Useful reports: https://svn.boost.org/trac/boost/report/1 -- full list of tickets https://svn.boost.org/trac/boost/report/18 -- ticket counts by owner https://svn.boost.org/trac/boost/report/19 -- ticket counts by component https://svn.boost.org/trac/boost/report/20 -- ticket counts by ticket type https://svn.boost.org/trac/boost/report/21 -- ticket counts by milestone -- Marshall

6 12

Provisional Boost.Generic and Boost.Auto_Function (concepts without concepts)
by Matt Calabrese 16 Dec '10

16 Dec '10

For those of you who were following the Boost.Auto_Function call for interest, this thread sort of spawned off of that. Boost.Generic (not a part of boost) is a C++0x library intended to replace BCCL as a way of specifying concepts and concept maps, and, when used in conjunction with Boost.Auto_Function (also not a part of boost, though it's in the sandbox and has online documentation at http://www.rivorus.com/auto_function ) as a way to get concept-based function template overloading. For anyone who followed the original thread, I'm happy to say that I'm just a few days away from being able to fully and automatically recognize standard library and user-defined iterator types, though I've had a [not so] surprising amount of compiler crashes and workarounds along the way. For an example of how concept mapping will look (revised from earlier versions as I've made much more progress with implementation), see http://codepaste.net/n47ocu And for an example of how this will be used by Boost.Auto_Function, see http://codepaste.net/1faj21 . At this point I'm not trying to do the equivalent of what would have been C++0x "scoped" concept maps, though at some point I may try to support them, but it would imply calling algorithms through macro invocations (yuck). During development, I've come to some realizations that I'd like discussion about here, mostly concerning concept map lookup and ODR. Essentially, the way the library works is by assembling a compile-time list of concept maps piecewise throughout a translation unit for a given type or combination of types via a clever use of overload resolution that I talked about briefly in the BOOST_AUTO_FUNCTION call for interest thread. Underneath the hood, there is something that resembles tag-dispatching, however it is all done entirely within decltype. In short, the way the concept-based overloading works is that the macro used for specifying a function that dispatches based on concept maps generates something along the lines of this. The "magic" shown in comments is something I'm able to already do, as talked about in the other thread: ///// template< class It > void foo( It&& it ) { typedef decltype ( function_returning_type_with_a_nested_static_function ( /* magical way to get a type that inherits from all concept tags */() ) ) fun_holder; fun_holder::impl( std::forward< It >( it ) ); } ///// Now, this is great, but I'm wondering what this means with respect to ODR. If the user is working with the algorithm "correctly", the typedef will resolve to the same type regardless of the translation unit, however, the "path" taken when inside of the decltype via overload resolution may vary depending on the translation unit when different, orthogonal concept maps are specified for the same type in one translation unit but not in the other (or if concept maps are specified in a different order I.E. via different #include orders). My question is, does this violate ODR in any meaningful sense? Since technically the typedefs should resolve to the same type in each translation unit, not including user error, is there a problem? The next question is much more devious and I have a feeling implies a blatant violation of ODR. Consider the following code, assuming "foo" does concept-based dispatching in a way similar to the above: ///// foo( 5 ); /* a concept map that specifies "int" models a concept that may affect dispatching */ foo( 5 ); ///// With the definition of foo given above, what would effectively happen is that the second call to "foo" will not be able to dispatch based on the new concept map! The reason why is because both calls will use foo< int >, and since it was already instantiated once for int, that first definition will be used. Note that this problem technically even exists with traditional tag dispatch, though I wonder if there may be some sort of solution that is standard. A hackish workaround I've come up for this is if we change the defintion of "foo" to be generated as the following: ///// // Uses C++0x function template default arguments template< class It, class TagType = /* magical way to get a type that inherits from all concept tags */ > void foo( It&& it ) { typedef decltype ( function_returning_type_with_a_nested_static_function ( TagType() ) ) fun_holder; fun_holder::impl( std::forward< It >( it ) ); } ///// Going back to the example calling code, "foo" will now correctly dispatch differently if the intermediate concept map should affect concept-based dispatch. This might seem like a perfect solution, but now we are pretty much definitely violating ODR, since a function that calls "foo" in different translation units will very possibly see different TagTypes even though the overload resolution internal to "foo" would resolve the same. Am I clear on this problem and why I believe my solution only works if you don't consider ODR violations? The final solution that I believe sidesteps all ODR violations would be if I force calls to such algorithms to be done via a macro. The macro would internally do the trick that is currently shown inside of the definition of "foo", only it would now do it at the caller's scope. If I decide to eventually try to support scoped concept maps I would be forced down such a route anyway, so my question ends up being at what point does the library cease being a convenience? Is it worth supporting concepts as accurately as possible, including the above desired behavior, if the calling code has to become: ///// BOOST_GENERIC_CALL( (foo)( 5 ) ); /* a concept map that specifies "int" models a concept that may affect dispatching */ BOOST_GENERIC_CALL( (foo)( 5 ) ); ///// or, if you want a more practical example: ///// BOOST_GENERIC_CALL( (advance)( vector_.begin(), 5 ) ); ///// This is a problem that I would prefer to be resolved sooner rather than later since I want to reduce code rewrites. Any feedback is greatly appreciated, especially if you have insight into these problems. I'll try to get Boost.Generic in its current, very limited form up on the sandbox and the docs online as soon as possible. -- -Matt Calabrese

6 32