- Boost - lists.boost.org

Compile-time conditional function invocation
by Jeff Mirwaisi 18 Feb '05

18 Feb '05

Below I have outlined my need and implementation for a compile-time conditional function invocation utility. I thought it might be generally useful to others using simmilar metaprogramming techniques. If suitable solutions can be found for some of the outstanding issues perhaps it will prove suitable for inclusion in boost. The following quick documentation and a snapshot of the implementation can be found at http://dump.qxxy.com/execute_if/ and (intermitantly) http://66.1.253.185:8080/src/execute_if/index.html Any feedback would be appreciated. Thanks Jeff Mirwaisi Introduction The following is a simple compile-time conditional function invocation and binding utility type. Generic code often needs to handle a subset, of all the types, in a slightly different way than the rest. template <typename T> void f(T t) { t.a(); t.b(); ... if ( has_member_function_c<T>::value ) t.c(); } This solution obviously will not work if type T has no member function c. The compiler expects all the types used with the template function f to have a member function c even though its clear the conditional expression is either true or false at compile time. One possible workaround for this situation is to use SFINAE and enable_if to overload template function f for types which have a member function c and those that do not. template <typename T> void f(T t, typename enable_if<has_member_function_c<>,T>::type* SFINAE = 0) { t.a(); t.b(); ... t.c(); } template <typename T> void f(T t, typename enable_if<not<has_member_function_c<T> >,T>::type* SFINAE = 0) { t.a(); t.b(); ... } This solution works! Unfortunately it forces us to repeat the majority of the implementation of the two template function overloads f, and it does not scale. If we add a second conditional invocation, the number of overloads jump to four, the same is true of conditional callers, e.g. a second group of two template functions overloads g if theres a single conditional invocation, four if there are two conditional calls etc. To combat this overload explosion we could isolate the conditional call to member function c with a helper type. template <bool> struct call_member_function_c { static inline void invoke(T& t) {t.c();} }; template <> struct call_member_function_c<false> { static inline void invoke(T& t) {} }; template <typename T> void f(T t) { t.a(); t.b(); call_member_function_c< has_member_function_c<T> >::invoke(t); }; This solution improves on the previous one, it scales well as we add conditional member function invocations (call_member_function_d,call_member_function_e,...) and as we increase the number of callers(f,g,h,...). But it has introduced an explicit no-op function for each call_member_function_X helper type, and a partial specialization for each helper type to select whether to generate a call or a no-op. This "helper" type can be formalized and we can provide a generic no-op implementing replacement for all "helpers" which reduces our problem to the simplest solution allowed by C++. Target Holders Unfortunately the limitations of the current language wont allow us to create a generic "helper" type which can be loaded with different template function targets. Instead the user is expected to provide a minimal holder type which delegates to the target template function. Note that the following example is also a late template argument binding function object. This allows the user to either invoke the conditionally executed target immediately or produce a function object which can be stored and called at a later point. template <typename T> void template_fn_target(T) {} struct template_fn_target_holder { typedef void result_type; template <typename Arg> inline result_type operator()(Arg arg) {return template_fn_target(arg);} template <typename Arg> static inline result_type invoke(Arg arg) {return template_fn_target(arg);} }; The target holder type provides the result type of the operation to the user, the function object usage expects a function call overload that can handle the arguments specified, if the call is to be made instantly than we can simplify the use by calling a static member function of the target holder type named invoke. execute_if template <typename Condition > struct execute_if { template< typename TargetHolder > static inline typename TargetHolder::result_type invoke( arg1,...,argN ); template< typename TargetHolder > static inline TargetHolder bind(); }; When the condition value is true the subsequent invoke or bind operation are performed on the target type, if the value is false a no-op invoke or bind are generated. execute_if_c template < bool > struct execute_if_c { template< typename TargetHolder > static inline typename TargetHolder::result_type invoke( arg1,...,argN ); template< typename TargetHolder > static inline TargetHolder bind(); }; The execute_if_c variation on the above execute_if type provides a less generic version of enable_if which uses a boolean value as the condition upon which to select either the specified target or a no-op. execute_if_else template <typename Condition > struct execute_if_else { template< typename TargetHolderA,typename TargetHolderB > static inline typename TargetHolder?::result_type invoke( arg1,...,argN ); template< typename TargetHolderA,typename TargetHolderB > static inline TargetHolder? bind(); }; When the condition value is true the subsequent invoke or bind operation are performed on target holder A, if the value is false target holder B will be used execute_if_else_c template < bool > struct execute_if_else_c { template< typename TargetHolderA,typename TargetHolderB > static inline typename TargetHolder? ::result_type invoke( arg1,...,argN ); template< typename TargetHolderA,typename TargetHolderB > static inline TargetHolder? bind(); }; The execute_if_else_c variation on the above execute_if_else type provides a less generic version of enable_if which uses a boolean value as the condition upon which to select either target holder A or target holder B. To-Do * Currently manually written nullary,unary,and binary execute_if and proxy functions, needs to be rewritten to use the boost preprocessor lib * Possible move of the return type template parameter into the execute_ifxxx template parameter list (out of the bind and invoke template functions) * Investigate using the preprocessor to automatically generate the template function holder types, and other techniques to reduce the users responsibility * Document the lack of a means of representing a template function in the c++ type system, no function equivalent of template template classes * The current code also implements a set of invoke_fn and bind_fn overloads which operate on function references and function object references, we must determine wether these should be provided at all, and if so they should probably be documented

2 1

gui library
by Matthew Johnson 18 Feb '05

18 Feb '05

I spent some time reading the archives regarding the gui project that was started towards the end of last year. Is that project still underway? What is the best way of keeping up with the status of it? Thanks, Matthew

3 2

New article on BOOST_FOREACH
by Eric Niebler 18 Feb '05

18 Feb '05

For anybody interested in peeking under the hood of BOOST_FOREACH, there is a new article about it at The C++ Source (http://www.artima.com/cppsource/index.jsp) It focuses mainly on the conditional operator and how to use it to write macrco's that do not reevaluate their arguments. -- Eric Niebler Boost Consulting www.boost-consulting.com

1 0

program options documentation
by Rutger ter Borg 18 Feb '05

18 Feb '05

Hi, I noticed that the documentation of the Boost.Program_options library has a small inconsistency regarding the add_options method. In the tutorial section and in the Options Descriptions Component subsection of the Library Overview, add_options is documented in a form that is probably meant as the correct one: desc.add_options() ("compression", po::value<int>(), "set compression level"); while on the other hand, under Library Overview/Options Description Component/Syntactic information it is written as desc.add_options() ("compression", "compression level", value<string>()); , i.e., the 2nd and 3rd arguments are exemplified in a different (likely wrong) order. Best regards, Rutger

2 1

Wave C++ Review Begins Today - February 7, 2005
by Tom Brinkman 18 Feb '05

18 Feb '05

The Wave C++ preprocessor library review begins today February 7, 2005. The library author is Hartmut Kaiser <hartmutkaiser(a)t-online.de> The review manager is Tom Brinkman <reportbase(a)yahoo.com> Download at http://spirit.sourceforge.net/dl_more/wave-1.1.12.zip 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. The Wave C++ preprocessor library is a Standards conformant implementation of the mandated C99/C++ preprocessor functionality packed behind a simple to use interface, which integrates well with the well known idioms of the Standard Template Library (STL). It is not a monolitic application, it's rather a modular library, which exposes mainly a context object and an iterator interface. The context object helps to configure the actual preprocessing process (as search path's, predefined macros, etc.). The exposed iterators are generated by this context object too. Iterating over the sequence defined by the two iterators will return the preprocessed tokens, which are to be built on the fly from the given input stream. The C++ preprocessor iterator itself is fed by a C++ lexer iterator, which implements an abstract interface. The C++ lexers packaged with the Wave library may be used standalone, too, and are not tied to the C++ preprocessor iterator at all. The flexible interface exposed by the library makes it usable in a variety of applications ranging from simple lexing (tokenising) a C99/C++ input stream to complex preprocessing with fine control over the details of the macro expansion process. For instance it's very simple to inject your own #pragma handling into the preprocessing, allowing to expand it in virtually unlimited ways. The Wave C++ preprocessor library is known to be compilable on VC7.1, Intel7.1 and 8.0, gcc 3.2.x and 3.3.x. Work is currently underway to make it usable with VC6.5 as well. The library contains samples, which show different ways of it's usage. A full blown preprocessing command line oriented driver application is included in the Boost tools section as well. The review candidate version of Wave is accessible here: http://spirit.sourceforge.net/dl_more/wave-1.1.12.zip additionally it is included in the Boost-sandbox CVS. If you're interested in what's new or changed since the last releases, please refer to the enclosed documentation or the changelog file contained inside the archive. __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail

15 40

A library: out-of-core containers and algorithms
by Roman Dementiev 18 Feb '05

18 Feb '05

Hello, I am developing a library called Stxxl. It is an implementation of STL for external memory (out-of-core) computations, i.e. Stxxl implements containers and algorithms that can process huge volumes of data that only fit on disks. Currently I have implemented vector, stack, and priority_queue. External memory map, list, and queue are coming soon. The containers take only specified (given) fixed amount of main memory, but can contain more elements than can fit into the main memory. The containers are compatible with STL algorithms, an example: #include <stxxl> // ten billion doubles stxxl::vector<double> HugeVector(10ULL * 1000000000ULL); std::fill(HugeVector.begin(), HugeVector.end(), 0.0); STL algorithms that rely on Output, Input, Forward and Bidirectional iterators will work I/O efficiently with Stxxl containers. For the RandomAccessIterator algorithms (sortting) I have implemented specialized I/O efficient implementations: // ten billion doubles stxxl::vector<double> HugeVector(10ULL * 1000000000ULL); std::generate(HugeVector.begin(), HugeVector.end(), MyRandom()); // sort the vector using only 512 MB of main memory stxxl::sort(HugeVector.begin(), HugeVector.end(), 128*1024*1024); or another example (sort a file): stxxl::file myfile("../myfile.dat",stxxl::file::RDWR); stxxl::vector<double> HugeVector(&myfile); // sort the vector using only 512 MB of main memory stxxl::sort(HugeVector.begin(), HugeVector.end(), 128*1024*1024); More details about the Stxxl library: http://i10www.ira.uka.de/dementiev/stxxl.shtml Would such a library be interesting for Boost users? Does it fit here? Is it worth to boostify it? I would be very glad to know your opinion. With best regards, Roman

9 22

[inspection]
by Jonathan Turkanis 17 Feb '05

17 Feb '05

Hi, A high percentage of the html documents in the iostreams library are listed by the inspection tool as unlinked. These documents are not really unlinked, however, and I am having trouble figuring out what is triggering the erroneous report. Among the documents listed as unlinked are menu.html and home.html, which are the entry points into the iostreams documentation. Any help would be appreciated. Jonathan

4 7

inherited operators
by Jason Hise 17 Feb '05

17 Feb '05

Sometimes I like to play around with obscure code, just to see what it does. The following really surprised me: #include <iostream> struct A { public: bool operator == ( const A & rhs ) { std::cout << "A\n"; return true; } }; struct B { public: bool operator == ( const B & rhs ) { std::cout << "B\n"; return false; } }; struct C : public A, public B { }; int main ( ) { C c1, c2; if ( c1 == c2 ) std::cout << "Equal\n"; return 0; } Compiled on MSVC 7.1, this outputs: A Equal I would have expected this code not to compile at all, because the == overload seems ambiguous. Is this result standards conforming? If not, what would the standards conforming result be? Does this fall into the realm of undefined behavior? -Jason

3 3

Re: [boost] Re: [indirect container] RFC on naming of libraryandclasses
by JOAQUIN LOPEZ MU?Z 17 Feb '05

17 Feb '05

----- Mensaje original ----- De: Thorsten Ottosen <nesotto(a)cs.auc.dk> Fecha: Jueves, Febrero 17, 2005 8:12 pm Asunto: [boost] Re: [indirect container] RFC on naming of library andclasses [...] > | If indirection is not really the unifying theme, perhaps you > should use the > name > | Boost.ManagedContainer, which I think was suggested at some point. > | ('ManagingContainer' might be more correct, but doesn't sound good.) > > Managed container is a good name. To recap, I think these are good > condidates: > Boost. Managed Container > Boost. Managed Pointer Container > Boost. Pointer Container > Boost. Clonable Container > Boost. Clonable Pointer Container > Boost. Cloned Container > > My personal favourite would be Boost.Cloned Container > with class names like this: > > cloned_vector<T> > cloned_map<Key,T> > > When I think about it, I see cloning as the most central concept; > in fact, the > only new policy of the containers is the CloneAllocator. > IMHO, "cloned/clonable container" hardly suggests what the lib is about: a clonable object has a rather well defined meaning, and so a clonable container seems to mean a container with some sort of clone() memfun. "Clonable objects container" (better than "clonable pointer container") is 100% accurate, but too verbose. A possibility without ambiguities is "clone container", i.e. a container of clones. As for the "managed" line, I think it resonates with some issues none of which has to do with the subject at hand: * "managed" as bounds checked. * "managed" as belonging to the world of C++/CLI (ugh!) So, if we rule out "indirect" for the reasons you explained, we're left with "pointer container". I think this is good: * std::set is a value container (elements have value semantics), so it is natural to extend the idea to ptr_set being a pointer container. * The term has some tradition. * It doesn't sugest anything different to what the lib is about. Actually ptr_containers do more than just holding pointers, but well. * When you augment the lib to support shared_ptrs, the name still holds. To sum it up, I vote for "pointer container", "clone container" being my close-second choice. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 5

[indirect container] RFC on naming of library and classes
by Thorsten Ottosen 17 Feb '05

17 Feb '05

Dear all, I will soon start to write some more documentation for the indirect container library (formerly called the smart container library). Before I start on that I would like to get a vote on the preferred naming of 1. the library itself 2. library classes Ad 1: library name: -------------------- Boost.Indirect Cotainer was suggested by Joaquin. It sounds reasonable to me. I don't have any alternatives, but suggestions are welcome. Ad 2: library classes: --------------------- The library currently consists of the following major classes in namespace boost: ptr_array ptr_vector ptr_list ptr_deque ptr_set ptr_multiset ptr_map ptr_multimap ptr_sequence_adapter ptr_set_adapter ptr_multiset_adapter ptr_map_adapter ptr_multimap_adapter Should these names persist? Or should we go for something like indirect_array, indirect_vector etc? br -Thorsten

4 18