October 2004 - Boost - lists.preview.boost.org

[review] Formal review of the Smart Container library ends today
by Pavol Droba 18 Nov '04

18 Nov '04

Hi All, Formal review of the Smart Container library ends today. I'd like to thank you all, that participated and offered opinions about this library. I will now take my time as the review manager to sumarize the conclusion for the final verdict. Best regards, Pavol PS: There is still a little time to submit a review if somebody is willing to do so.

2 2

Lazy Metaprogramming Library
by Vesa Karvonen 18 Nov '04

18 Nov '04

Lazy Metaprogramming Library ============================ Vesa Karvonen vesa_karvonen(a)hotmail.com 30. October 2004 This is a minimal proof-of-concept library that shows how one can implement lazy template metaprograms. Problem ------- Most contemporary template metaprogramming libraries are strict, which means that the result of a metafunction call is evaluated completely once the metafunction is invoked. Furthermore, metafunctions are written so that the arguments they receive are assumed to be completely evaluated. In addition to strictly evaluated function calls, most strict programming languages provide lazy control structures, such as `if' and `while', that evaluate their subexpressions only when needed. In contemporary template metaprogramming libraries, there usually is no clear separation between lazy control structures and strict metafunctions, which can make programming quite confusing and burdensome. Basically, a programmer using a contemporary template metaprogramming library has to explicitly annotate the evaluation order of the metacode by carefully selecting when to invoke and when not to invoke a metafunction. The invocations can not simply be completely left out, because strict metafunction do not accept uninvoked arguments. Solution -------- The metaprogramming style used in this library is different. Metafunctions and data structures (type lists) in this library are designed to be lazy. In particular, metafunctions assume that the arguments they receive are only delayed promises to compute the actual argument once explicitly invoked. This change of style eliminates the need to constantly think about evaluation order. Metafunction invocations are only needed when a value explicitly needs to be examined. For example, the metafunction `HEAD<l>' evaluates to the head of the given list `l'. In order to do that, `HEAD' needs to explicitly invoke the parameter `l' to expose the list constructor `CONS' for pattern matching. However, and most importantly, callers of `HEAD' do not need to invoke the parameter. In theory, the style used in this library could be the ideal way to implement template metaprograms, because the C++ standard almost requires template instantiations to be cached, which means that delayed promises are actually computed only once, saving CPU time. In functional programming terms, C++ implementations are almost required to perform memoization or graph reduction. In practice, however, the representation of type information may take a lot of memory and access to the instantiation cache isn't necessarily implemented efficiently. This can make lazy metaprograms less efficient in terms of time and space than their strict counterparts. Contents of the package ----------------------- The `inc/lazy_mpl' directory contains the library implementation. Only a minimal core plus a couple of higher-order functions on lists are provided. The `test' directory contains a couple of ad hoc tests demonstrating the lazy programming style and the use of lazy lists. To get most out of the code, you should take a look at the implementation of the higher-order list manipulation metafunctions `MAP', `FOLD[R|L]', `APPEND', `TAKE', `DROP', `ITERATE', `FILTER', and `ZIP_WITH'. As you can hopefully see, they are very cleanly expressed. That is how lazy metaprogramming would look like to a casually user. Future work ----------- This library is only a proof-of-concept. The intention is to show that lazy template metaprogramming is possible and can yield correct and highly readable metaprograms. The metafunctions in this library are written for clarity rather than optimized for heavy use. In particular, many of the provided metafunctions are strict in one ore more parameters, which means that those parameters are always invoked as a result of invoking the metafunction. An optimization technique called ``strictness analysis'' could be used to systematically optimize the metafunctions. The optimization would not change the way the metafunctions are used, but would change how they are evaluated internally. In some cases the optimization could be significant. Another practical issue would be to implement some sort of lambda mechanism, which would make the use of higher-order metafunctions more convenient. Copyright --------- (C) Copyright Vesa Karvonen 2004. Distributed under the Boost Software License, Version 1.0. (See accompanying file LICENSE.) _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.com/

4 3

[MPL] Wiki docs
by David B. Held 16 Nov '04

16 Nov '04

Here: http://www.mywikinet.com/mpl/mpl_1_32_changelog/numeric-metafunctions-proto… I'm guessing that: template< int n > struct my_int { static int const value = n; typedef my_iny type; }; is really supposed to be: template< int n > struct my_int { static int const value = n; typedef my_int type; ^^^^^^ }; And same for the "After" example. Dave

2 1

logging lib, v1.3
by John Torjo 12 Nov '04

12 Nov '04

Dear boosters, Finally, have had some time to update the logging lib. Get it from: http://www.torjo.com/ (of course, it comes packed with docs) First of all, many thanks to Darryl Green and Caleb Epstein! Summary - solved a few bugs - redesigned so that I allow for scoped logs (no more log IDs, now logs are identified by a 'string name') - ported the code from Caleb - allow for a "log manager" (many thanks to Darryl Green!) (it is not documented yet, but will do so as soon as I have some time) - updated docs - (renaming) add_modifier_func -> add_modifier (renaming) add_logger_func -> add_appender - thread-safety update (again, many thanks to Darryl Green!) - you can log messages even *before* logs are initialized after logs are initialized, just call flush_log_cache(); As for scoped logs, to make a long story short, you'll be able to do: logger gui("app.gui") if (gui) gui.stream() << "something GUIsh"; // or (equivalent) BOOOST_SCOPEDLOG(gui) << "something GUIsh"; Still to do: - docs: write about log managers - cyclic logs Looking forward to your feedback! Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.5 - tooltips at your fingertips (work for menus too!) + bitmap buttons (work for MessageBox too!) + tab dialogs, hyper links, lite html

11 47

[range] warnings on vc7.1
by Jonathan Turkanis 12 Nov '04

12 Nov '04

Hi Thorsten, The program at the end of this message produces twenty C4224 Warnings ("nonstandard extension used : formal parameter 'array' was previously defined as a type") on VC7.1 and VC8.0 beta. Since Boost.Array and Boost.Range will be used together with some frequency, it might be a good idea to disable warning 4224 locally within the range headers. Best Regards, Jonathan ---------- #include <boost/array.hpp> #include <boost/range/begin.hpp> #include <boost/range/end.hpp> #include <boost/range/iterator.hpp> int main() { }

2 3

pqs - physical quantities library
by Andy Little 10 Nov '04

10 Nov '04

Hi, I have been continuing with my physical-quantities library over the last year, http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/index.html and I am now seeking feedback as to whether it is worth putting this forward as a boost library proposal.... *Overview* The physical-quantity type-family provides methods for modeling physical-quantities in C++ programs. The advantages and extra functionality over inbuilt types used in the role include, compile time dimensional-analysis checking, automatic conversion between units and an increase in source code comprehensibility. The type family includes two types, firstly a type where the units are fixed at compile-time referred to in the text as a ct-quantity and secondly a type where the units can be run-time modified, referred to in the text as an rt-quantity. The ct-quantity has many similar features to an inbuilt-type: - concrete type with simple,consistent semantics close to those of inbuilt-types. - aims for speed and code size performance close to that of in-built types. - requires no special framework to use. *Application areas* The application areas are very wide, including scientific-engineering, CAD, 3D games programming among many others. *Future directions* 2D and 3D vector quantities, scene-graphs and scene-modelling, Graphics interface (eg OpenGL), splines and curve analysis, successive approaximation , piecewise differentiation and integration algorithms. finite element analysis, etc etc. Issues from the previous thread on the library and physical quantities in general http://aspn.activestate.com/ASPN/Mail/Message/boost/1926782 issue: Angles. current status: Angles are implemented.There are two types, irrational (ie radians) and rational fractions of revolution ie degrees minutes etc). radians are what you might call a 'weak type'. (Though this behaviour can be modified by a macro switch). They will implicitly decay to (say) double and can be implicitly cast to double. However they also allow implicit conversions to and from degrees etc. hence an implicit conversion from degrees to radians can occur if a function has a radians argument, but not a double argument. They are also useful for output of units. --------------------- issue: Differentiating different but dimensionally equivalent types. current status: This is implemented. --------------------- issue: Implicit conversions between units. current status: Implicit conversions are intrinsic. They are practical instinctive and useful. --------------------- issue: You should be using mpl. current status: Hopefully I will be able to get hold of the metaprogramming book soon, at which point I can decide whether there are advantages. --------------------- regards Andy Little

4 10

Shortcut regex notation
by Schalk_Cronje＠McAfee.com 08 Nov '04

08 Nov '04

Would anyone be interested in having a perl-like regex shortcut notation? The original idea was born during a local C++ focus group discussion. Looking further into the feasibility I thought that this might be a useful addition to Boost. Possibly something like the following (from some proof-of-concept code) using namespace boost::short_regex; std::string str("And he said: 'BLAH BLAH'"); // [1] Substitutes first occurrence and copy (calls boost::regex_replace) // perl: ($s2=$str) =~ s/(BLAH)/Hooray/; std::string s2= _s / "(BLAH)" / "Hooray" / str; // [2] Substitute globally and copy // perl: ($s2=$str) =~ s/(BLAH)/Hooray/g; s2= _s / "(BLAH)" / "Hooray" / _g / str; // [3] Substitute first occurrence in-place // perl: $str=~ s/(BLAH)/Hooray/; ~_s/ "(BLAH)" / "Hooray" / str; In the above _s and _g are special placeholder/tag objects sort of like _1,_2. Other could include _i (case-insensitive), _m (string as multiple lines) and _s (string as single line). Multiple modifiers can be added using (,) // [4] Substitute globally and copy // perl: ($s2=$str) =~ s/(BLAH)/Hooray/gi; s2= _s / "(BLAH)" / "Hooray" / (_g,_i) / str; The purpose will not be to shortcut all of the boost.regex functionality, just the common cases, as in perl or sed. Cases [1] and [3] is very close to the perl and would be easy to understand, however [2] and [4] is moving away from perl-syntax. This might be considered illegible by some.

7 7

[regex] any interest in finite automata-based regex engine?
by Vladimir Pozdyayev 08 Nov '04

08 Nov '04

Hello. Are there any plans to add finite automata-based subengine to the regex library? If there are, I can submit the algorithm/implementation of a modified nondeterministic FA which takes care of * greedy and lazy quantifiers, * eagerness of the alternation operator, * non-longest matches (`best' in the Perl-ish sense with respect to greediness/laziness/eagerness), * substring capturing. All these features being included, the time cost of a match is O(N(E+C)L), where N is the number of states, E is the average epsilon-closure size per state, C is the number of capturing parentheses, and L is the input length. As far as I know that's the lowest order of time complexity in this area (corrections are welcome)---though, of course, deterministic FA would be even faster. I suppose there's no point in adding another regex library, but being able to guarantee linear time cost in an existing one would be nice. -- Best regards, Vladimir Pozdyayev.

6 22

small library proposal -- rebind template args and function pointer types
by James Harris 04 Nov '04

04 Nov '04

Hello Boost Members, I have written a small library of meta-functions that allow rebinding of template arguments and function pointer return/argument types. I am posting in an attempt to guage interest and hopefully receive pointers on the library proposal process. The library provides the following meta-functions: rebind<int index, class rebind_type, class source_type> -- rebind template arguments rebind_func_arg<int index, class rebind_type, class func_type> -- rebind argument type of func/method ptr rebind_func_return<class rebind_type, class func_type> -- rebind return type of func/method ptr rebind_method_class<class rebind_type, class func_type> -- rebind class portion of method ptr // --- rebind<> example ------------------------------------------------ template <class A, class B, class C> class foo { }; typedef foo<int, int, int> source_type; typedef rebind<1, char, source_type>::type rebound_type; // rebound_type equates to foo<int, char, int> // --- rebind_func_arg<> example --------------------------------------- typedef int (*func_ptr)(int); typedef rebind_func_arg<0, char, func_ptr>::type rebound_type // rebound_type equates to int (*)(char) // rebind_func_args also works with pointer-to-method types // --- rebind_func_return<> example ------------------------------------ typedef int (*func_ptr)(int); typedef rebind_func_return<char, func_ptr>::type rebound_type // rebound_type equates to char (*)(int) // rebind_func_return also works with pointer-to-method types // --- rebind_method_class<class rebind_type, class func_type> --------- typedef int (foo::*method_ptr)(int); typedef rebind_method_class<bar, method_ptr>::type rebound_type; // rebound_type equates to int (bar::*)(int); -- end examples -- I have tested the code using MSVC 7.1 and GCC 3.3.2-1. Please let me know if this library would be useful to any of you, or otherwise any reason why it is not required or, of course any tips/suggestions/questions that you might have. Kind Regards, James Harris.

4 3

RE: [boost] recursive mutex and condition
by Ben Hutchings 04 Nov '04

04 Nov '04

James Ahlborn <james.ahlborn(a)med.ge.com> wrote: > hey, > I was wondering if any of the boost developers could tell me > if recursive mutexes are supposed to work with conditions? I don't believe so. If waiting for a condition releases the mutex only once, this can result in deadlock, and if it releases the mutex completely the protected data can be seen while its invariant is broken. There seems to be no right way to use recursive mutexes with condition variables. <snip> > I'm testing this on red hat 7.3 and fedora core 2. My guess as to > why it's broken is because the boost condition uses posix recursive > mutexes There's no such thing. > internally, which also seem to fail the recursive mutex/condition > test (at least on the OS's mentioned above). Anyone have any > thoughts on this? <snip> I think you should avoid using recursive mutexes. Read <http://groups.google.com/groups?selm=3434E6BA.ABD%40zko.dec.com>. Ben.

4 4