- Boost - lists.preview.boost.org

Rave for proposed Boost.Local (functions)
by Gregory Crosswhite 27 Feb '11

27 Feb '11

Hey everyone, The purpose of this e-mail is to rave about Lorenzo's proposed Boost.Local library in the hopes of inspiring people to start the review process for it. :-) I have been experimenting with using this library in my own code, and it has been a godsend for me. In one of the projects I have been working on I ran into many situations where I needed to call a higher-order function with a closure, and the closure was just complicated enough that I couldn't use Boost.Lambda. Before using this library I frequently found myself either writing a lot of extra code to work-around the need for a higher-order function, or writing a lot of boilerplate to create classes that would only be used by a single function in order to create a function object. This library has let me write the closures that I need in a fairly painless fashion and so has made my life a lot easier! At first I thought that the interface needed to use it was ugly, but as I have gotten used to it I have changed my mind. Part of why I thought it was ugly was because of the way that whitespace was used in the example included in the original e-mail: BOOST_LOCAL_FUNCTION( (void) (add)( (double)(num) (const bind)((factor)) (bind)((&sum)) ) ) { sum += factor * num; std::clog<< "Summed: "<< sum<< std::endl; } BOOST_LOCAL_FUNCTION_END(add) add(100.0); To my mind this example looks a lot clearer if you reformat it as follows: BOOST_LOCAL_FUNCTION( (void) (add)( (double)(num) (const bind)((factor)) (bind)((&sum)) ) ) { sum += factor * num; std::clog<< "Summed: "<< sum<< std::endl; } BOOST_LOCAL_FUNCTION_END(add) add(100.0); I would be happy to volunteer to be the review manager if one is needed to move the process along, but since I am new to the community and personally biased in favor of the library (though I would endeavor to be unbiased as a reviewer) I recognize you all will presumably want someone that you all know better and who is more neutral. Regardless, I hope that we can start down the road of incorporating this library into boost because I believe it would be of great benefit to the C++ community at large. Cheers, Greg

13 59

Boost release 1.46.0 available
by Beman Dawes 27 Feb '11

27 Feb '11

Release 1.46.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release includes 1 new library (Interval Container Library) as well as updates to many existing libraries. For details, including download links, see http://www.boost.org/users/news/version_1_46_0 The release can also be downloaded directly from SourceForge. See http://sourceforge.net/projects/boost/files/ To install this release on your system, see http://www.boost.org/doc/libs/release/more/getting_started/index.html Thanks, --The Boost release team

8 14

[Phoenix V3] for_each name conflict
by Mathieu - 27 Feb '11

27 Feb '11

Hi everyone, While reviewing phoenix V3 I encountered a bug while using mpl::for_each with a phoenix lambda, because of a name conflict (lazy phoenix for_each with mpl::for_each). The following code reproduces the bug : #include <boost/mpl/for_each.hpp> #include <boost/mpl/vector_c.hpp> #include <boost/phoenix/phoenix.hpp> #include <iostream> using boost::phoenix::arg_names::arg1; int main(int argc, const char *argv[]) { typedef boost::mpl::vector_c<int,0,1,2,3> vec; boost::mpl::for_each<vec>(std::cout << arg1); return 0; } which fails to compile with the error : In file included from main.cpp:1: dev/phoenix3/boost/phoenix/stl/algorithm/iteration.hpp: In function ‘void boost::mpl::for_each <snip irrelevant long mpl / phoenix types> main.cpp:25: instantiated from here dev/phoenix3/boost/phoenix/stl/algorithm/iteration.hpp:91: error: ‘boost::phoenix::for_each’ is not a function, /usr/include/boost/mpl/for_each.hpp:109: error: conflict with ‘template<class Sequence, class F> void boost::mpl::for_each(F, Sequence*)’ /usr/include/boost/mpl/for_each.hpp:111: error: in call to ‘for_each’ The mpl code does an unqualified call to for_each here : void for_each(F f, Sequence* = 0) { for_each<Sequence, identity<> >(f); // this is line 111 } and phoenix provides : function<impl::for_each> const for_each = impl::for_each(); The (silly) change to mpl::for_each<Sequence, identity<> >(f); obviously unbreak the build. The problem seems to be that ADL kicks in and as f (in the mpl call of for_each) is a phoenix type. I don't have a patch (yet) as I don't really know the best strategy here, nor I'm sure that my diagnostic is accurate (the ADL part that is). Mathieu- :wq

3 3

[functional] [shared_ptr] boost::hash<shared_ptr<T>> Returns Only Two Values
by Stewart, Robert 27 Feb '11

27 Feb '11

The following is a program that demonstrates that a null shared_ptr<int> produces a hash value of zero and that (ostensibly) all non-null instances produce a hash value of one. I expected that there'd be a shared_ptr specialization of hash_value to make it work right, but I don't find one. Shouldn't there be one? #include <iostream> #include <map> #include <vector> #include <boost/shared_ptr.hpp> #include <boost/functional/hash.hpp> int main() { typedef boost::shared_ptr<int> ptr_type; typedef std::map<std::size_t, int> hashes_type; std::vector<ptr_type> v(25); hashes_type hashes; boost::hash<ptr_type> hasher; ptr_type null_ptr; ++hashes[hasher(null_ptr)]; for (int i(0); i < 25; ++i) { v[i] = ptr_type(new int(i)); std::size_t const hash(hasher(v[i])); ++hashes[hash]; } for (hashes_type::iterator it(hashes.begin()), end(hashes.end()); it != end; ++it) { std::cout << it->first << ": " << it->second << '\n'; } } _____ Rob Stewart robert.stewart(a)sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

3 7

[typeof] GCC error: expression not defined in this scope
by Lorenzo Caminiti 27 Feb '11

27 Feb '11

On Mon, Feb 7, 2011 at 5:29 PM, Steven Watanabe <watanabesj(a)gmail.com> wrote: > On 2/7/2011 1:52 PM, Lorenzo Caminiti wrote: >> >> void *result_ptr; // Plus append __LINE__... >> typedef typeof(*result_ptr) result_type; > > That's almost what we did. > > void deduce_result(); > typedef boost::function_traits< > typeof(&deduce_result)>::result_type result_type; > > is a little better. (It can handle references.) Hello all, Why the following TYPEOF code does not compile on GCC but it does on MSVC? Is this a GCC bug? If so, is there a workaround for it? #include <boost/typeof/typeof.hpp> int f() { return -1; } template<typename T> void g(T x) { int (deduce_func)(); typedef BOOST_TYPEOF_TPL(deduce_func) func_type; // error also if TYPEOF is used instead of TYPEOF_TPL struct s { void call(func_type func) { func(); } // line 12 } ss; ss.call(f); // line 14 } int main() { g(1); // line 18 return 0; } $ g++ -Wall -Werror -I../../.. r03.cpp r03.cpp: In member function ‘void g(T)::s::call(__typeof__ (boost::type_of::ensure_obj(deduce_func))) [with T = int]’: r03.cpp:14: instantiated from ‘void g(T) [with T = int]’ r03.cpp:18: instantiated from here r03.cpp:12: error: ‘deduce_func’ was not declared in this scope What is this error? I don't understand it because with the local struct at line 12 I am just accessing the type generated by the typedef and not the actual expression that was used to deduce such a type... $ g++ --version g++ (GCC) 4.3.4 20090804 (release) 1 The same error raises even also if TYPEOF is used instead of TYPEOF_TPL. However, no error if g() is not a template so GCC compiles this just fine: #include <boost/typeof/typeof.hpp> int f() { return -1; } void g(int x) { // no template, no error -- why? int (deduce_func)(); typedef BOOST_TYPEOF(deduce_func) func_type; struct s { void call(func_type func) { func(); } } ss; ss.call(f); } int main() { g(1); return 0; } Both examples (template and not) compile instead just fine on MSVC. Do these examples compile on compilers other than GCC and MVSC? Thank you very much! -- Lorenzo

2 2

[function] Merge to release
by Daniel James 27 Feb '11

27 Feb '11

Function hasn't been merged to release for some time. There are a number of fixes on trunk which look okay to me. If no one objects I'll merge once the release branch opens. Daniel

1 0

[phoenix 3] Missing file?
by Michael Caisse 27 Feb '11

27 Feb '11

Tests are complaining about : include/core/mem_obj_ptr.cpp:1:46: error: boost/phoenix/core/mem_obj_ptr.hpp: No such file or directory michael -- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

2 1

Phoenix v3 review
by Mathias Gaunard 26 Feb '11

26 Feb '11

Here is my review of Phoenix v3. First, let me say that I am a big user of Phoenix v2, Spirit and Proto, and that I therefore envision myself a big user of Phoenix v3 as well. It is a great improvement on top of Phoenix v2 (in particular, no strange bugs due to broken type deduction and correct usage of result_of), and for that reason alone it warrants my approval. So here it is: I vote yes for inclusion. I however have concerns about its compatibility with Phoenix v2. I tried to see how Spirit fared if I symlinked its underlying phoenix directory to that of Phoenix v3, and it just doesn't work. Mixing Phoenix v3 with Spirit doesn't work either. I believe this is a very important issue. I'm not sure it needs to be fixed before the first release of Phoenix as a first-class Boost citizen, but it certainly needs to be fixed ASAP by porting Spirit to use the new version. Apart from that, the library is pretty satisfying: - As I said, usage of result_of has been a great improvement, and bind for example is now polymorphic and fully compatible with boost/std::bind. - it supports perfect forwarding up to a limit - It uses Proto in a minimalistic and modular way - It is reasonably fast to compile, thanks to the instrumentation of wave to preprocess headers. Compiling the STL module could be made faster by using free functions instead of global objects (which should be the recommended way to define lazy functions!). - The docs haven't changed much, a few rectifications here and there plus the addition of the new internals. It still contains typos and some things that need to be updated. Let's start on with more detailed remarks: Misc ---- Phoenix v3 is missing a phoenix.hpp header file that includes all modules, which Phoenix v2 had (but in the parent directory). Lazy functions -------------- Using phoenix::function to turn a PFO into a lazy function is the most basic way to extend Phoenix with new functionality, and clearly the recommended way to do so according to the docs. [1] [2] It is directly inherited from Phoenix v2, and only the result type deduction mechanism changed. This approach has several problems, at least in the way it is presented in the documentation. - global objects potentially increase binary size - those objects are not PODs and therefore requires runtime initialization, adding some runtime overhead at application startup - instantiation happens regardless of whether the function is used or not, which affects compilation time negatively. This method is massively used to define a whole lot of lazy functions that forward to standard algorithms and container functions [3], which suggests that this is indeed the recommended way to proceed. It should however be avoided; prefer defining a template function that constructs and applies the adapted function object, if the function object can stay a POD that's better too. I think it would also be valuable to add a "lazy" function (or some other name) that takes a PFO and returns its lazy version, that could be used inline in lambda expressions in a way similar to bind. [1] <http://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/libs/phoenix/doc/h…> [2] <http://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/libs/phoenix/doc/h…> [3] <http://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/libs/phoenix/doc/h…> Phoenix as a Proto-based library -------------------------------- Extension of Phoenix is very nice: you can plug custom subgrammars and subnodes non-intrusively, making it very modular. Phoenix expressions are also refinements of Proto expressions, so I can use Proto transforms to alter the tree. It is also possible to specify custom evaluation strategies on a per-node basis, which paves the way for many exotic applications. Terminals can also be customized for evaluation within the default strategy. I'm not entirely sure this feature is not redundant, but I'm not familiar enough with the code to tell. Phoenix as Proto with statements -------------------------------- One thing I was hoping Phoenix v3 would be is Proto extended to support statements. While it comes pretty for some uses, it still fails one one point: the ability to define custom languages that embed Phoenix statements. The missing piece is handling of domains (extends are missing too, but I don't think they make sense at the statement level). I think that area needs some research though, so it's not relevant to acceptance at all. Documentation ------------- <http://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/libs/phoenix/doc/h…> says that bind is monomorphic. I thought it was polymorphic now? <http://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/libs/phoenix/doc/h…> doesn't talk about perfect forwarding. <http://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/libs/phoenix/doc/h…> Actor cannot be both a concept and a model, it's a concept and a refinement. It would also be nice to highlight the difference with the PFO concept. "The problem is that given an arbitrary function F, using current C++ language rules, one cannot create a forwarding function FF that transparently assumes the arguments of F. " That's wrong. It's not impossible, it just requires an exponential number of overloads. C++0x rvalue references allow to reduce this to a linear amount. <http://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/libs/phoenix/doc/h…> spurious ] at the end. The layout of this section is weird, by the way. The macros appear on top but are not explained until a later page. I remember I saw a couple other typos and similar but I can't find them anymore. Anyway it needs some proofreading. Features I would like to see in a future version ------------------------------------------------- Ok, this has little to do in a review, but here it is anyway. I would like to have an adapter to turn a PFO into a monomorphic function object (i.e. a function object with a result_type) that can be passed to legacy algorithms. This can be done two ways: either by giving the return type or the type of the arguments explicitly. This could also be used to define variant visitors with lambdas. I would like it if Phoenix could detect function objects that are monomorphic and automatically propagate that monomorphism (but that's probably hard to do). I would like it if the polymorphic function objects generated by Phoenix were masked out using SFINAE if their body-expression would result in a hard error. Essentially, to do this, one needs to be able to test whether the default Proto transform of an expression leads to an error. While this should be possible with compilers supporting extended SFINAE, I haven't been able to grok the Proto internals well enough to do it yet myself.

5 19

type traits not in boost.type_traits
by Frédéric Bron 26 Feb '11

26 Feb '11

I found the following files in 1.46.0 that could be either removed or moved to type_traits: * graph/detail/is_same.hpp -> already existing type traits library comment in the file: Deprecate the use of this header. TODO: Remove this file from trunk/release in 1.41/1.42. by the way, it seems that the file is never included so that we could safely remove it. Can we do that and run the tests to see if everything is still working? * iostreams/detail/is_dereferenceable.hpp -> could be moved to type traits but I should have a look to see if I cannot implement it in the extension If it is straightforward, I will implement it. The following will be part of the type trait extension (so let's review the extension first...): * detail/is_incrementable.hpp -> has_operator_increment<T> * exception/detail/is_output_streamable.hpp -> has_operator_left_shift<std::ostream, T> Frédéric

6 12

[Review] Phoenix V3: Mini-review starts February 20th
by Hartmut Kaiser 26 Feb '11

26 Feb '11

Hi all, Thomas Heller worked hard to address the outstanding issues of the original Phoenix review. He ported Phoenix to Boost.Proto. As mandated by the original Boost review, we will conduct a mini-review of his Phoenix V3 library. This mini-review starts today, February 20th, 2011 and ends on March 2nd, 2011. ------------------ About the library: The Phoenix library enables FP techniques such as higher order functions, lambda (unnamed functions), currying (partial function application) and lazy evaluation in C++. The focus is more on usefulness and practicality than purity, elegance and strict adherence to FP principles. Phoenix is a very important infrastructure library. It is currently a utility library included with Spirit V2 and therefore is already available for years from the latest Boost distributions (headers: $BOOST_ROOT/boost/spirit/home/phoenix, docs: $BOOST_ROOT/libs/spirit/phoenix, or http://www.boost.org/doc/libs/1_45_0/libs/spirit/phoenix/index.html) ------------------ The code of new Phoenix V3 (that's what we mini-review) can be found at: https://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/ the documentation is at: http://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/libs/phoenix/doc/ht ml/index.html ------------------ Here are the questions raised during the initial review of Phoenix in September 2008 (see here: http://thread.gmane.org/gmane.comp.lib.boost.devel/180753) <quote> We will have a mini review before Phoenix gets merged to SVN to make sure whether the feedback from the v2 review was accommodated. Additionally this review will have to discuss: - the breaking interface changes from v2 - the migration path from boost::bind and lambda to Phoenix - how the interoperability with std::bind is solved (result_of semantics) - C++0x features such as rvalue references and variadic templates - the new extensibility mechanism - unified placeholders and interoperability issues with other Proto-based DSELs (such as Spirit.Qi, Spirit.Karma, and Xpressive) - compile times </quote> Please note that Phoenix already has been accepted as a Boost library. We don't vote about that anymore. The purpose of this mini-review is to discuss if the newly rewritten Phoenix V3 addresses the outstanding issues from the main review. In the end I will have to make the decision whether to include the new library into SVN trunk. I really hope to see your participation in the discussions on the Boost mailing lists! Regards Hartmut Review Manager --------------- http://boost-spirit.com

4 15

XInt formal review forthcoming
by Vladimir Prus 25 Feb '11

25 Feb '11

Boosters, the review of Boost.XInt library, by Chad Nelson, is scheduled to start on Wednesday, March 2, and will run through Friday, March 11. I will be serving as review manager. Over the years, arbitrary precision arithmetics has been a hot topic on Boost mailing lists, but now we have a concrete proposal that may become an official Boost library. So, block the time on your calendar, and get ready. Thanks, -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40

1 0

svn "Could not read response body"
by Frank Mori Hess 25 Feb '11

25 Feb '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Does anyone else get errors like the following when trying to do things like "svn update"? "svn: REPORT of '/svn/boost/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.boost.org)" I've seen it occasionally for a while, but it seems to be getting worse now. I can rarely get an svn update to complete. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk1nu5kACgkQ5vihyNWuA4We5gCdGZqLMGx2sNMmBs5ihbV4kZJG 4u8An3KpHc22JUMP2KaAqHDtjm18uU6b =62Ci -----END PGP SIGNATURE-----

2 1

[1.46] PDF Build of the docs available
by John Maddock 25 Feb '11

25 Feb '11

A PDF build of Boost's documentation for 1.46 is now available from: http://sourceforge.net/projects/boost/files/boost-docs/1.46.0/ Note that this only includes that subset of Boost which uses quickbook/boostbook/docbook for documentation. Enjoy, John.

4 3

[fusion] Signature Params -> vector
by Daniel Larimer 25 Feb '11

25 Feb '11

I would like to know if there is an existing way to achieve the following: params_to_vector<void(int,double,string)>::type => boost::fusion::vector<int,double,string>

2 3

[ratio] Request to merge to release branche
by Vicente Botet 25 Feb '11

25 Feb '11

Hi, I would like to merge Boost.Ratio to the release branch as soon as possible. Let me know if there is something missing, and if I can do it? Thanks, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/ratio-Request-to-merge-to-release-branch… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 7

[fusion] sequence member pointer
by Daniel Larimer 25 Feb '11

25 Feb '11

I am attempting to use a fusion sequence with a visitor pattern that expects 'member function' or 'member data' pointers. What I would like to do is something like: &fusion::vector<int,double>::m1 But obviously this cannot work because of how fusion::vector<int,double> is implemented with a single vector_n<...> vec data member that is private. So trying to "reflect" a vector in the same way that I "reflect" a struct does not work. Any good ideas? Is there any reason why this 'implementation detail' needs to be hidden? Dan

2 3

[config] request for BOOST_NO_FWD_STD_DECLARATION
by Christopher Jefferson 25 Feb '11

25 Feb '11

libc++ does not allow forward declarations of types for std:: , as it uses inline namespace to allow versioning. Forward declarations occur in many libraries (config, fusion, interprocess). In each case I would like to just include the actual headers. I could just #define all cases for LIBCPP, but other libraries might move to using inline namespaces in future, so I could introduce a macro? Chris

13 38

Google Protocol Buffers library support module
by Rodrigo Souza 25 Feb '11

25 Feb '11

Hello All, I just developed a google protocol buffers library support module for boost build, and I am making this contribution available to everyone under the Boost License. The usage is pretty simple. add the following line in your user-config,jam using pb : /usr/local ; # assuming google protocol buffers is installed in /usr/local and in your Jamfile. import pb ; exe myapp : myapp.cpp messages.proto /pb//protobuflib ; This is the first version, and it doesn't support auto-detection. Enjoy, Rodrigo Pinho Pereira de Souza

1 0

tiny lambda snippet that fails to compile with boost 1.46
by Mark Van Dijk 25 Feb '11

25 Feb '11

I have a question about a particular problem I'm having with boost::lambda. I've distilled it down to a tiny complete app (shown below). The complier is complaining about bl::_1 is a const std::string, but &Map::value_type::second is a member_data_pointer to a non-const string. This line compiles with boost 1.42, but not in 1.46 (using MSVC 2008). I have two questions: 1) is the line of code in question actually valid? I.e. is this a boost::lambda bug or is this my bug? 2) If it is my bug, then to fix the code I need to coerce [&Map::value_type::second] to a CONST - problem is that the only way I can figure out is to use an ugly const_cast<>. Is there a cleaner way to do this? Source code follows: ------------------------------------------------------------------------------------------------------------ #include <iostream> #include <string> #include <map> #include <cassert> #include <boost/assign.hpp> #include <boost/lambda/lambda.hpp> #include <boost/lambda/bind.hpp> namespace bl = boost::lambda; int main() { // create two simple maps and populate them typedef std::map<long, std::string> Map; Map m = boost::assign::map_list_of(0, "hello ")(1, "world!"); // non-const map Map const cm = boost::assign::map_list_of(0, "hello ")(1, "world!"); // const map // this works: // concatenate the std::string parts of the non-const map and send to std::cout // std::string output; std::for_each( m.begin(), m.end(), output += bl::bind(&Map::value_type::second, bl::_1)); std::cout << output << std::endl; assert(output == "hello world!"); // works with boost 1.42, however it fails to compile with boost 1.46 // concatenate the std::string parts of the const map and send to std::cout // output.clear(); std::for_each( cm.begin(), cm.end(), output += bl::bind(&Map::value_type::second, bl::_1)); // <---- COMPILER ERROR HERE WITH BOOST 1.46 std::cout << output << std::endl; assert(output == "hello world!"); // this compiles, but uses an ugly const_cast<> // concatenate the std::string parts of the const map and send to std::cout // output.clear(); std::for_each( cm.begin(), cm.end(), output += bl::bind(const_cast<std::string const Map::value_type::*>(&Map::value_type::second), bl::_1)); // <---- UGLY std::cout << output << std::endl; assert(output == "hello world!"); return 0; }

1 0

[quickbook] broken on 64bit ubuntu
by Daniel Pfeifer 24 Feb '11

24 Feb '11

Hi, Quickbook version 1.5.4 (that is included in Boost 1.46) reports the following error: > error: Unknown version of quickbook: quickbook 1.32741 The reported version number is different on each run. On a 32 bit install, quickbook works. I get this error only on 64 bit. cheers, Daniel

3 3

[local] Simplifying the parenthesized syntax
by Lorenzo Caminiti 24 Feb '11

24 Feb '11

On Sun, Feb 6, 2011 at 10:26 AM, Vicente Botet <vicente.botet(a)wanadoo.fr> wrote: > The fact that you can not use variadic macros at work doesn't means that > your library can not provide in addition variadic macros on compilers > supporting them. I have no idea the work that this suppose, but if the > interface could be more appealing your library will have much more people > interested in. > > Have you an idea of how the interface could be simplified if variadic macros > were used? The purpose of this email if to brainstorm possible ideas to simplify the parenthesized syntax. Sorry in advance if not all that I say is correct -- I haven't implemented it yet so I might be saying inaccurate/unfeasible things here and there. As always, your feedback is very welcome :) PRELIMINARY IDEAS TO SIMPLIFY THE PARENTHESIZED SYNTAX Consider the following parenthesized syntax for local functions: (void) (f)( (int)(x) (double&)(y) (const bind)((a)(&b)) (bind)((&c)(d)) ) // [0] The followings are possible ways to simply this syntax. 1 MERGING PARAMETER TYPES AND NAMES (C++ preprocessor) Parameter names can be passed to function types so I can transform `int x` into `int` at compile-time: int x --[make function type]--> void (int x) --[get 1st parm type]--> int This should allow me to simplify the parenthesized syntax [0] to: (void) (f)( (int x) (double& y) (const bind)((a)(&b)) (bind)((&c)(d)) ) // [1] Note that the (unbound) parameter type and name are merged into a single sequence element. The following should also be possible: (void) (f)( (int x) (double& y) (const bind a) (const bind& b) (bind& c) (bind d) ) // [1a] Is [1a] simpler than [1]? Maybe it is... 2 TOWARD THE NORMAL PARAMETER LIST SYNTAX (C99 preprocessor) Using variadic macros I _might_ be able to use a variable length tuple (can I? I am not very familiar with these yet...) instead of a sequence to represent the function parameters: (void) (f)(int x, double& y, const bind a, const bind& b, bind& c, bind d) // [2] I think, this is a great simplification over [0] because it is the exact same syntax used by C++ to declare function parameters! Note that `const bind` and `bind` have been distributed to all the bound parameters. Given that sequences are best avoided here (to reduce extra parenthesis), I do not think there is a less verbose way to enumerate the bound parameters. The followings could also be possible: (void) (f)(int x, double& y, const bind (a, &b), bind (&c, d) ) // [3] (void) (f)(int x, double& y) (const bind)(a, &b) (bind)(&c, d) // [4] But I think enumerating every bound variable separately as in [2] makes the parameter list syntax look the closet to normal C++ syntax even if it requires the repetition of `const bind` and `bind` as the types of the bound variables. Therefore, I would prefer [2] over both [3] and [4]. 3 RETURN TYPE AND FUNCTION NAME (C++ and C99 preprocessors) I don't know how/if I can simplify the passing of the return type and function name because I do need the function name as a separate token within the preprocessor to do token concatenation and generate unique names that refer to the function name... Something like this should be possible (using tuples instead of sequences): void, f, ( (int)(x) (double&)(y) (const bind)((a)(&b)) (bind)((&c)(d)) ) // [5] void, (f)( (int)(x) (double&)(y) (const bind)((a)(&b)) (bind)((&c)(d)) ) // [6] And again, on C99: void, f, (int x, double& y, const bind a, const bind& b, bind& c, bind d) // [7] void, (f)(int x, double& y, const bind a, const bind& b, bind& c, bind d) // [8] However, I don't see how these are simpler than [0] and [2]. I need to think about this more to see if other syntaxes are possible... 4 DEFAULT PARAMETER VALUES (C++ and C99 preprocessors) Currently local functions support default parameters via the following parenthesized syntax: (void) (f)( (int)(x)(default)(-1) (double)(y)(default)(1.23) ) // [9] I think this could be simplified to (note the removal of the parenthesis around the default value): (void) (f)( (int)(x)(default -1) (double)(y)(default 1.23) ) // [10] An additional simplification could be to merge parameter types and names together as in [1]: (void) (f)( (int x)(default -1) (double y)(default 1.23) ) // [10a] Plus using C99 variadics as in [2]: (void) (f)(int x, default -1, double y, default 1.23) // [11] I am not a big fan of this because `default` is separated from its parameter by the comma `,`... but I don't think I can do better than this. 5 OTHERS CONSIDERATIONS These considerations are not directly relevant to local functions but the parenthesized syntax [0] was designed as a general syntax that makes *all* the elements of a function declaration available for preprocessor metaprogramming. Instead, syntaxes [1] and [2] cannot separate the parameter type token from the parameter name token at preprocessing time. Therefore: a) I don't think [1] and [2] allow to generate a parameter with the specified name but a different type. For example, say I want to add `const&` to `int x`, how can I do that unless `int x` is specified as `(int)(x)` or `(int, x)`? int x --[how can I do this??]--> add_reference<add_const<int>::type>::type x (I have to double check, but I don't think local functions need to manipulate parameter types retaining instead the parameter names so I don't think this is an issue for local functions.) b) Having the parameter names as separate tokens (which is possible with [0] but not with [1] or [2]) could be useful to generate unique names to handle function overloading (even if with some limitations). For example, in another library, I concatenate the function name token with the parameter name tokens to generate unique names for overloaded functions. As long as the overloaded functions use different parameter names (and not just different parameter types) this mechanism works. (Overloading is not supported for local functions -- see Rationale in library docs -- so this is not an issue for local functions.) Therefore, *IF* there was an interest in defining the parenthesized syntax to be as general as possible so it could be adopted everywhere macros spoil function definitions (to avoid requiring programmers to learn different syntaxes for the different macros), [0] is more general because it separates the parameter types from their names (at the cost of the extra parenthesis of course). Of all of these syntaxes, I _personally_ like [0] because it is pure C++ preprocessor and it is the most general (maybe with simplification [10] for default parameters). I also would like to provide [2] if the C99 preprocessor is detected -- ideally, the same parsing macros will be smart enough to accept both [2] and [0] on C99 and just [0] on pure C++ preprocessors. -- Lorenzo

8 19

[interprocess] sharing memory between 32 bit and 64 bit Windows processes
by Arno Schödl 24 Feb '11

24 Feb '11

Hello Ion, > - In a mixed environment, each shared heap can be no larger than 32 bit. > - offset_ptr must have the ability to point to any place _in any of potentially many heaps_ > because at the time of dereferencing it has no information about the heap it is meant > to point to. This requires a heap-relative 32 bit quantity plus some "heap selector", > or a this-relative 64 bit quantity. The latter is simple, fast and not significantly > less compact than the former, so we pick the latter. > - Option 1: For the rest of the code, the easiest option is to make everything 64 bit, e.g., > deriving size_type et. al. from offset_ptr. Unfortunately, this makes all interfaces 64 bit. > So even on 32 bit you can request a 64 bit shared heap. Internally, when going to the OS > to allocate the heap, there is a cast to 32-bit size_t with data loss, which is ugly. > - Option 2: So the interfaces should really be 32 bit on both 32 bit and 64 bit. > This would require a second template parameter size_type for the MemoryAlgorithm, > in addition to the pointer type. We can then migrate parts of the code to use this 32 bit > quantity as much as possible for compactness. I think this Option 2 is safer and > philosophically closer to what is really going on. - Option 3: Actually, the right solution is to make offset_ptr::difference_type of a mixed-environment offset pointer 32 bit, but its internal offset representation 64 bit. So all shared size_types and difference_types will be 32 bit, which is correct because all array sizes and differences between pointers within arrays are limited to 32 bit. For those places where internal algorithms (such as the rbtree memory algorithm) need modulo arithmetic, we will make a custom typedef in offset_ptr to export the "virtual address space size". Any objection? It would be great if you could give us feedback, because we want to get done with that stuff, we need it badly... Thanks! Arno -- Dr. Arno Schödl | aschoedl(a)think-cell.com Technical Director think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany http://www.think-cell.com | phone +49 30 666473-10 | US phone +1 800 891 8091 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl

2 5

About task library
by Jorge Lodos Vigil 24 Feb '11

24 Feb '11

Hi I am currently evaluating the task library currently in the vault for production use. The library is very well thought in my opinion, thank you very much Oliver for providing it to the community. It seems it was scheduled for review before but now it isn't. Vicente was the review manager. Is the library still intended to be reviewed? Is there some active work in the library? What about other libraries task depends on? The bound queues used in thread pools always causes the thread submitting task to wait if the queue is full. In our use cases, we need to fail the queuing, rather than wait. Is there any interest in adding this functionality to the library? In case there is I could perform the programming and testing. Thank you again. Cheers Jorge

2 2

additions to boost community calendar
by Ronald Garcia 24 Feb '11

24 Feb '11

I would like to list the review periods for upcoming library reviews, with brief library descriptions, on the boost community google calendar at http://www.boost.org/community/index.html. What is the process for doing this? Thanks, Ron

2 1

Boost.MPI --- Scatterv / Gatherv
by Júlio Hoffimann 24 Feb '11

24 Feb '11

Hi, Some collective operations are not implemented in Boost.MPI, namely Scatterv and Gatherv. Probably there is a great reason and i don't know. Something related to Boost.Serialization or the "skeleton and content" approach? (due to memory offsets, displacements, etc.) Can i write some code to you? I did check scatter.hpp and maybe is easy to implement by analogy. Best Regards, Júlio.

1 0